CIP-003-9 R1 Cyber security policies: requirements and evidence

What CIP-003-9 R1 cyber security policies require

CIP-003-9 R1 asks one question of a compliance lead: can you show written cyber security policies that exist, cover the required topics, and were reviewed and approved by the CIP Senior Manager on time? The policies address a simple risk. If security practice lives in people's heads or in scattered tickets, controls drift between sites and shifts, and nobody can prove what was expected. The standard requires one or more documented policies, reviewed and approved by the CIP Senior Manager at least once every 15 calendar months. Those two facts, the written topics and the approval cadence, are where most findings come from.

The topic list depends on the impact rating set under CIP-002. For high and medium impact BES Cyber Systems, Part 1.1 lists nine topics: personnel and training, Electronic Security Perimeters including Interactive Remote Access, physical security, system security management, incident reporting and response, recovery plans, configuration change management and vulnerability assessments, information protection, and CIP Exceptional Circumstances. For assets with low impact BES Cyber Systems, Part 1.2 lists seven topics, which include the vendor electronic remote access security controls added in version 9. Confirm the exact wording of each topic in the standard PDF and map each one to a named policy document. Do not rely on a summary, because a policy that touches a topic only in passing often fails the test.

The 15-month cycle is easy to miss because it does not match a calendar year, and a policy approved in one month can become overdue well before an annual review would catch it. Approval must come from the CIP Senior Manager or a delegate with documented authority, so the approval record and the revision history must agree on who signed and when. Ask your team to confirm three things for each policy: the last approval date, the date the next review falls due, and the approver's name against the current delegation record. Document management tools with version history and role-based approval can produce this evidence, but the policy content, the approver and the review decision remain the organization's responsibility.

Which systems and teams the R1 policies apply to

CIP-002 categorization decides which topic list in R1 applies to a given asset. Once impact ratings are fixed, each policy topic needs a named owner, and the scoping choices at mixed-impact sites and with vendors determine how much of the policy set must be written and maintained.

High and medium impact scope

Systems rated high or medium impact under CIP-002 fall under the nine topics in Part 1.1, which is the broader policy set. Each topic must be addressed for these systems, so the policy set is the larger of the two. Confirm the categorization list with the CIP Senior Manager before assigning policy owners, because a reclassification moves the whole topic list.

Low impact asset scope

Assets containing low impact BES Cyber Systems fall under the seven topics in Part 1.2. The vendor electronic remote access topic is new in version 9 and is often the one with no existing owner. Check each low impact asset against the list and confirm whether any remote access path exists before writing the topic.

Operations owns recovery and incidents

Operations and control room staff usually own the topics for incident reporting and response, recovery plans, and configuration change management. These owners know the system behavior that a policy must describe. Ask each owner to confirm the systems their topic covers, since a policy written by a central team often misses local procedures.

IT owns system security and access

IT and security engineering typically own system security management, electronic security perimeters, and electronic access controls. Their policies must match the configuration that is actually deployed. Verify that the security topics name the same systems as the CIP-002 list, including support and maintenance hosts.

Physical security and HR own their topics

Physical security teams own the physical security topic, and HR or personnel security teams typically own personnel and training. Both groups must align their policies with access revocation and training records. Confirm that contractor and visitor procedures are covered in these documents, not only employee procedures.

Procurement and vendor scope

Procurement owns the link to vendor controls, and the vendor electronic remote access topic in low impact policies applies to vendors who connect remotely. Check whether contracts, supplier onboarding and remote session procedures reference the same policy. Include contractors in the scope statement so that their access is not assumed to be outside the policy.

Mixed-impact sites change the work

A single site often holds high, medium and low impact systems, so one policy may need to cover several topic lists. Decide whether one policy set applies site-wide or whether each impact level has its own documents. Write the decision down, because assessors will ask which list applies to each asset.

How an assessor tests the R1 policies

This table walks through how a Regional Entity assessor tests CIP-003-9 R1, Part 1.1 and Part 1.2, what evidence each step asks for, and the findings that most often come up. Read each row as a test step with its expected evidence and the typical gap. Entities should walk the same steps internally before an audit notice arrives.

Test step	What the assessor checks	Evidence requested	Common finding
Scope the policy set	Which impact categories the entity has under CIP-002 and whether each policy set applies to high and medium impact systems (Part 1.1) or to low impact assets (Part 1.2)	CIP-002 categorization results and the asset list mapped to each policy set	Policies written for medium impact topics but no matching low impact policy for an asset that holds low impact BES Cyber Systems
Confirm each Part 1.1 topic	A written policy or policies covering all nine topics, including CIP Exceptional Circumstances	The policy documents, with a cross-reference from each topic to the section that covers it	A topic is missing, or it appears only in a procedure that the policy does not reference
Confirm each Part 1.2 topic	A written policy or policies covering all seven low impact topics, including vendor electronic remote access security controls	The low impact policy text and a cross-reference list showing where each topic is addressed	The vendor remote access topic is absent because the entity treated it as a version 8 requirement only
Check the review date	That each policy was reviewed within 15 calendar months of the prior review	Revision history or document management workflow records with review dates	The last review falls outside the 15-month window, or the record shows an edit without a documented review
Check the approval	That the CIP Senior Manager, or a delegate with documented authority, approved each policy	Dated approval record naming the approver and the policy version approved	Approval signed by someone other than the CIP Senior Manager or a documented delegate, or no approval date recorded
Match policy to systems in scope	That the policy scope matches the BES Cyber Systems, Electronic Security Perimeters and sites the entity actually operates	Current CIP-002 list, network diagrams and asset inventory compared against the policy text	Policy refers to a retired Control Center or omits a substation added after the last review
Compare policy with practice	That the procedures and records show the entity follows what the policy says	Samples of operating records, such as access reviews, incident logs and change tickets, tied to policy statements	Policy describes periodic reviews or training that the entity does not perform, which the assessor records as a gap in practice
Verify version control	That the version shown in the evidence is the approved version in effect during the audit period	Document control log, version identifiers and the approval record for each version	Draft and approved copies differ, and the assessor cannot tell which text was in force on a given date

Steps to build and maintain the R1 policy set

This sequence turns CIP-003-9 R1 from a list of topics into a maintained policy set with a traceable topic map, an approved baseline and a revision record that shows the 15-month review cycle was met.

Confirm applicability and the applicable impact tier
Start from your CIP-002 categorization to establish which assets fall under high or medium impact (Part 1.1 topics) and which contain only low impact BES Cyber Systems (Part 1.2 topics). The CIP Senior Manager or a delegate confirms the list. The output is a short scope statement naming each asset group and its impact tier, so the policy set is built against the correct topic list. Confirm the categorization with your Regional Entity if the boundary is disputed.
Build a topic-to-policy map
Create a table that lists every applicable Part 1.1 or 1.2 topic in one column and the owning policy document, its owner and its location in the next columns. Include the CIP Exceptional Circumstances topic, which is easy to miss. Each topic should map to at least one policy, and any policy covering several topics should be cross-referenced. The finished map is the first evidence artifact an auditor will ask for, and it shows that no topic was left uncovered.
Write or update each policy against its topic
Owners draft or revise each policy so it states what the organization requires, who is accountable and where the supporting procedures live. Where existing documents already address a topic, reference them rather than duplicating them. Policies should be specific enough that a reviewer can tell whether the topic is covered. Output: draft policy documents, each with a title, version number and owner, ready for review.
Set the 15-month review calendar
Record a review date for each policy, set no later than 15 calendar months after the last approval, and assign a named reviewer. Place the dates in the same system that tracks other CIP compliance tasks so that a missed review triggers an alert. The output is a review calendar that shows each policy's last approval date and next due date. Confirm your internal alert lead time with your compliance lead, since the standard sets the outer limit only.
Obtain documented CIP Senior Manager approval
Route the drafted policies to the CIP Senior Manager (or an approver whose delegation is documented under R4) for review and approval. Approval must be documented, so record the approver's name, the approval date and the policy version in the approval record. Keep the signed or system-recorded approval attached to each policy version. The output is an approval record showing that each policy was reviewed and approved by the right person within the cycle.
Publish and communicate the approved policies
Make the approved versions available to the personnel who must follow them, through the document repository or intranet. Confirm that staff can find the current version and that superseded versions are retired from circulation without being deleted from the record. The output is a distribution record or access list that shows where the current policy sits and who was notified of changes. This step supports the awareness and training obligations in CIP-004 as well as R1.
Record every revision and review in the history
Each edit, review and approval should be logged with the change made, the reason, the author and the date. Versioned document systems or a controlled document management workflow can keep this history. Before an audit, check that the revision history shows a review within each 15-month window for every policy. The output is a complete revision log that matches the review calendar, which is the evidence M1 expects for review timing and approval.
Re-run the cycle on every trigger and review date
Repeat the topic check whenever the applicable scope changes, such as a new asset, a categorization change or a new standard version that adds topics, as CIP-003-9 did for vendor electronic remote access. Also repeat the review and approval steps on the calendar date. The output is an updated topic map and a dated approval for each cycle, so the maintained set stays current between audits.

Why the 15-month review and CIP Senior Manager approval are the hard part

Writing the CIP-003-9 R1 policies is usually the easier half of the work. The harder half is keeping a review and approval cycle that can be proven every 15 calendar months, with the CIP Senior Manager's approval visible on each version. The standard asks for two things at once: the policy must be reviewed within that window, and the approval must be documented. A policy that was reviewed but whose approval cannot be traced to a named person fails the same test as one that was never reviewed. Before the first audit cycle, confirm who is the CIP Senior Manager under the CIP-003-9 R3 designation, and whether any delegations under R4 cover policy approval. If a delegate signs, the delegation record has to exist and be current when the approval is made.

Review dates drift for a predictable reason. When policies live as Word files on a shared drive, the review date is usually held in someone's calendar or in the file name, and nothing forces a check. A file can be edited without a new approval, a copy can be saved under a new name, and the older version can remain in circulation for months. Each of these creates a gap an assessor can find in minutes. A document management workflow with revision history removes most of that risk. Each version carries a timestamp, an author, a reviewer and an approver, and the system keeps prior versions so the reviewer can show the exact interval between approvals. Open-source wikis such as XWiki and BookStack can hold policy pages with this kind of history, though the team should confirm how each product records approvals, since neither is a compliance system on its own.

A practical check is to pull the approval history for each R1 policy and read the dates as an assessor would. Confirm that every policy has an approval entry from the CIP Senior Manager or a documented delegate, that the gap between approvals does not exceed 15 calendar months, and that the approved version matches the version in use. Then confirm that the sign-off workflow restricts who can publish a new version, so that edits cannot go live without the approval step. Organizations that run this check each quarter usually catch a missed review while there is still time to act. The CIP-003-9 standard and its measures set the evidence expectations, and the team should read them directly before setting the review calendar.

Evidence that satisfies R1 and how to keep it current

CIP-003-9 R1 is proven by three kinds of records: the policy documents themselves, a trail showing review within 15 calendar months, and documented approval by the CIP Senior Manager. Each artifact needs a named owner and a retention rule, because an auditor will ask for the version that was in force on a given date, not only the current one.

Current policy documents

The policy set must address the nine Part 1.1 topics for high and medium impact systems, or the seven Part 1.2 topics for assets with low impact BES Cyber Systems. Map each topic to the document and section that covers it, so an assessor can find it without a walkthrough. Check that each policy names the systems and roles it governs and that no topic is covered only by an unwritten practice.

Review and approval record

Keep a dated approval for each review, signed or recorded by the CIP Senior Manager, that identifies the exact policy version approved. An approval that names only a document title, without a version or date, is weak evidence. Confirm with your Regional Entity which approval format it accepts, since the standard requires documented approval but leaves the form to the entity.

Revision history and workflow log

A revision history shows what changed, when and by whom, and it is the simplest proof that review happened inside the 15-month window. Where policies sit in a wiki, the platform's version history can serve as this record if it keeps author, timestamp and change content for every edit. Test it by comparing two versions and confirming the diff is readable to someone outside the team.

Named policy owner

Assign one accountable owner for each policy and a backup, and record them in the policy header and in the review log. The owner schedules reviews, collects input from operations, security and vendor management, and routes the draft to the CIP Senior Manager. Ownership changes are a common gap, so update the record whenever a staff member moves roles.

Access controls on policy documents

Editing rights should sit with the policy owner and reviewers, while most staff get read access. Role-based permissions let you restrict who can publish or overwrite a controlled policy without blocking reading. Document who holds each role and review the list at each cycle, since an unauthorized edit to an approved policy can undermine the entire evidence set.

Superseded versions and retention

Keep every superseded version with its approval record so you can show which policy was in force on any past date, including the period an audit covers. Store them in a location that resists silent deletion and document the retention period you chose. Confirm the retention expectation for your audit period with your Regional Entity before setting the schedule.

Self-hosted wikis that keep versioned policy records

R1 evidence depends on showing that each policy was reviewed within 15 calendar months. A wiki with built-in version control gives that trail without extra work. XWiki keeps every change to a page under version control, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one, which helps when an assessor asks what a policy said on a given date.

Change record: Each saved edit is kept with its timestamp and author, so the revision history can be exported or shown during an audit.
Version comparison: Reviewers can diff two versions to confirm that a periodic review changed the text or only confirmed it.
Rollback: An unapproved or mistaken edit can be reverted to the last approved version, with the reversion itself recorded.
Review cadence: The platform shows edit dates but does not track the 15-month cycle. Teams usually need a calendar reminder or a ticket that links to the page.
Retention: Confirm how long revision history is kept and whether it can be backed up with the rest of the wiki.

Before relying on this, confirm with your deployment team that the XWiki version and license terms you run match your intended use, and that version history survives your backup and restore process.

What meeting R1 costs in money and effort

This table breaks down the cost components of building and maintaining the R1 policy set, who is paid for each, and whether the cost is one-time or recurring. Use it to scope a quote and to see which costs open-source tooling can reduce, though no prices are stated because none are supplied.

Cost component	Who carries it	One-time or recurring	What drives it up or down
Policy drafting	Internal compliance or OT security staff, or a consultant if bought	One-time, then recurring at each 15-month review	Number of impact categories in scope and how much existing documentation can be reused
Legal and HR review	Legal counsel and HR for personnel, training and exceptional circumstances wording	Mostly one-time, with revisits when policies change	Whether existing employment and contractor policies already cover the nine or seven topics
Document control tooling	Internal IT, or a partner that deploys a self-hosted wiki or document system	Setup is one-time; hosting and administration recur	Use of version history and approval workflow; open-source options may remove license spend, but confirm edition limits first
Engineering and operations alignment	System owners and OT engineers who confirm the policies match actual practice	One-time gap closure, then recurring checks at each review	Number of sites, Cyber Asset types and vendor access paths the policies must describe
CIP Senior Manager review	The named CIP Senior Manager, plus any documented delegate	Recurring at least every 15 calendar months, with approval recorded each time	Number of policy documents and how many approval records are kept per cycle
External review	Outside counsel, consultant or implementation partner, if purchased	Usually one-time for the initial set, optional at later reviews	Scope agreed in writing, policy count and whether the client supplies a current baseline
Auditor sampling and evidence requests	Entity staff who assemble evidence; the Regional Entity or NERC audits	Recurs with each audit or monitoring engagement	Quality of revision history and approval records, which lets staff answer requests quickly

Who owns the R1 policies, who helps, and what the auditor tests

The registered entity owns R1 in full. The obligation sits with the organization, not with any consultant or software vendor, so the entity must decide what its policies say, make sure they cover the topics the standard lists for its impact rating, and show that the CIP Senior Manager reviewed and approved them within the 15-calendar-month cycle. The CIP Senior Manager is named under R3 and carries the approval accountability, so that person must be able to explain the policy content and stand behind it during an audit.

Policy content: Your own subject matter experts write or accept the substance of each policy, based on how your BES Cyber Systems actually operate.
Approval record: The CIP Senior Manager's documented approval, dated and traceable, is the entity's evidence, and no partner can supply it.
Review cycle: Someone in the entity owns the 15-month review calendar and the trigger that starts an early review after a material change.
Staff knowledge: Employees who follow the policies must be able to find them and describe them, because auditors often ask staff directly.

Before you engage anyone, confirm internally who holds the CIP Senior Manager role, who approves policy changes, and where the authoritative copy of each policy is stored.

Gaps that cause R1 findings and how to close them

Most CIP-003-9 R1 findings trace back to a small set of recurring gaps: missing topics, weak approval records, lapsed reviews, stale content and scattered copies. Each card names one gap, the check that exposes it, and the fix that closes it before an auditor finds it.

Missing Part 1.1 topic

High and medium impact programs must address nine topics under Part 1.1, and a single missing topic is enough to produce a finding. Compare your policy set against the list topic by topic, including CIP Exceptional Circumstances, which teams often omit because it rarely applies day to day. Where no policy exists, write a short policy that names the owner, the scope and the procedure, then link it from the index of policies.

Low impact vendor remote access gap

Version 9 added vendor electronic remote access security controls to the Part 1.2 topics for assets containing low impact BES Cyber Systems. Programs written before that change often cover the other six topics and stop there. Check whether the low impact policy names how vendor sessions are authorized, monitored and terminated, and confirm that the topic is tied to the version 9 enforcement date.

Approvals held only in email

R1 requires documented approval by the CIP Senior Manager, and evidence must show that approval in a form an auditor can trace. An email thread that says the policy looks fine does not identify the version approved or the date it took effect. Record each approval in the document itself or in a workflow record that stores the version number, the approver's name, the date and a link to the approved text.

Review dates that lapse

The policies must be reviewed and approved at least once every 15 calendar months, and that clock runs independently of whether anything changed. Programs often track reviews in a calendar that nobody owns, so the date passes silently. Assign a named owner to each policy, set a reminder well before the 15-month limit, and keep the revision history that shows each review date.

Policies describing unused tools

A policy that names a remote access gateway, a removable media scanner or a logging product the organization no longer runs is a finding in itself, because the document no longer matches operations. Walk each policy against the systems actually in service and the tools currently in use. Where a tool was retired, update the policy text and the approval record together so the two stay consistent.

Policy copies scattered across teams

When operations, IT and compliance each keep their own copy of a policy, the copies drift apart and auditors receive a version that differs from the one approved. Store one controlled copy in a wiki or document system with version control, so every change is recorded with its author and date and any earlier version can be compared or restored. Point teams to that single location instead of attaching copies to email.

Common questions about CIP-003-9 R1 policies

How much effort does CIP-003-9 R1 take to meet?

R1 is mainly a documentation and review effort, and its size depends on the impact categories and asset types you operate. Costs fall into three parts: internal staff time to draft or update policies, legal or compliance review and CIP Senior Manager approval, and the recurring review required at least every 15 calendar months. A high or medium impact entity addresses nine Part 1.1 topics, while an entity whose assets contain only low impact BES Cyber Systems addresses seven Part 1.2 topics, so scope shapes the workload. Costs rise with the number of BES Cyber Systems, the number of sites, the quality of existing procedures and the number of teams that must sign off. When you request a quote, ask for a written scope that lists the policy topics, asset classes and document workflow covered, and whether the price includes the recurring review or only the initial drafting.

How long does it take to prepare a CIP-003-9 R1 policy set?

Duration depends on your environment, so confirm it against your own systems and approval process before committing to a date. The main variables are how many of the policy topics need new text, whether existing security procedures already cover them, how many departments review each draft and how quickly the CIP Senior Manager can approve the final version. A set that already exists in internal procedures mostly needs mapping to the required topics and a documented approval. A set written from scratch needs drafting, review and a first approval cycle. Ask any implementation partner for a milestone schedule tied to the written scope, with named client reviewers and approval dates. Also confirm when the first 15 calendar month review clock starts, because that approval date is what an auditor will check against your records.

Can our own team write CIP-003-9 R1 policies in-house?

Yes. The standard places ownership of the policies with the entity, so an internal team can draft, approve and maintain them. The team needs people who understand BES Cyber Systems, the CIP-002 categorization that defines scope, and how each policy topic connects to the systems it covers. In-house programs tend to work when one named owner tracks the 15 calendar month review dates, keeps a revision history and records CIP Senior Manager approval for each version. Outside help is most useful for a gap analysis against the topic list, drafting support or assembling evidence packs. Whichever route you choose, the organization remains accountable for the content. Document tools can help: XWiki keeps version history showing what changed, when and by whom, and BookStack role permissions can limit editing to named roles.

What does the CIP Senior Manager have to do for R1?

The CIP Senior Manager must review and approve the R1 policies at least once every 15 calendar months, and that approval must be documented. Assessors look for the approval record, so it should show the date, the policy version and the approver's name. If the Senior Manager delegates approval authority under the related R4 requirement, each delegation must also be documented. The Senior Manager should confirm that each policy matches the BES Cyber Systems and asset types identified under CIP-002, because a policy that describes the wrong scope creates a gap even when it is approved on time. Schedule the review well before the 15 month date, and set the reminder against the approval record, so the cycle is tied to evidence rather than to the date a draft was last edited.

How does a partner differ from a CIP auditor?

A partner helps prepare systems, policies and evidence, while the Compliance Enforcement Authority, a Regional Entity or NERC, monitors compliance. There is no CIP certificate. Compliance is checked through methods such as Compliance Audits, Spot Checks and Self-Certifications, and the outcome comes from the enforcement authority, not from a consultant. DeployOpen plans, implements and documents controls inside the client's own infrastructure and prepares evidence for compliance assessments. It does not issue audit reports, attestations or certifications. The entity owns its controls and makes the final decisions on policy content and approvals. Before engaging anyone, request a written scope that lists deliverables, and confirm with your Regional Entity which evidence it expects to see for CIP-003-9 R1.

What changed for low impact assets in CIP-003-9 version 9?

Version 9 added a seventh topic to the Part 1.2 list for assets containing low impact BES Cyber Systems: vendor electronic remote access security controls. The earlier list covered cyber security awareness, physical security controls, electronic access controls, incident response, Transient Cyber Asset and Removable Media malicious code mitigation and CIP Exceptional Circumstances. The vendor topic is enforceable from 1 April 2026, according to NERC. Entities with only low impact assets now need a documented policy that explains how vendors reach their systems remotely and which controls govern that access. The same change appears in the low impact cyber security plan under R2, so the policy and the plan should agree. Check the CIP-003-9 standard text and NERC's CIP standards page, since later versions carry separate effective dates.

Which tools help keep R1 policies current and provable?

Tools help most with version control, review scheduling and approval records. Store each policy in a wiki or document system that keeps every revision, so you can show which text was approved and when. Use role-based permissions so only designated owners can edit or publish, and keep the approval step visible in the document history. XWiki supports comparing any two versions and rolling back to an earlier one. A compliance platform such as CISO Assistant can track assessments and evidence, but confirm whether its framework library covers NERC CIP before relying on it, because the published list does not name CIP. Whatever you choose, test that the tool can show the approval date and the version approved, since those are the facts an assessor will ask for.

How DeployOpen prepares R1 evidence

DeployOpen plans and implements the self-hosted systems that hold CIP-003-9 R1 policies and their approval records, then prepares readiness evidence under a written, fixed scope agreed before work starts. In practice that means a document repository inside your own infrastructure, a policy structure that maps each of the nine high and medium impact topics in Part 1.1 or the seven low impact topics in Part 1.2 to a named document, and a review workflow that records when each policy was last reviewed and approved. The scope document should list which asset categories the policies cover, which tools are in the repository, and who in your organization holds each role in the workflow.

Your organization owns the policies, the content of each topic, and every approval. The CIP Senior Manager must review and approve the policies at least once every 15 calendar months, and that approval is a decision your organization makes and records. DeployOpen can configure the approval step, set reminders against the 15-month cycle, and export revision history, but it does not write your security position on the Part 1.1 or 1.2 topics for you, and it does not sign off on them. Confirm early which of your staff will act as approver and editor, and whether your internal policy owner will review draft content before it enters the repository.

Only an independent auditor or the Compliance Enforcement Authority, the Regional Entity or NERC, can assess whether your policies meet R1 and issue any finding. DeployOpen's readiness work helps you show evidence to that assessor: document versions, approval records, and a simple gap list against the M1 evidence expectations. Ask any implementation partner to state in writing that it prepares evidence and does not issue compliance conclusions. For the audit process itself, see the NERC Rules of Procedure, which describes how compliance monitoring is carried out.

How DeployOpen works on this

DeployOpen helps organizations prepare the CIP-003-9 R1 policy set, its review workflow and the approval records an assessor will ask for. The organization owns its policies and its CIP Senior Manager approval, while DeployOpen prepares the documents, systems and evidence around them.

How we scope

Confirm which assets contain low impact BES Cyber Systems and which policy topic set applies to each asset group.
Agree in writing which policy documents, revision records and approval workflows are in scope before work starts.
Identify which existing internal policies already cover the seven Part 1.2 topics and where gaps remain.

How we build

Draft or restructure policy documents so each Part 1.2 topic maps to a named, findable section.
Configure the document platform so every revision keeps author, date and content history for later review.
Set up a review cycle with reminders and a recorded CIP Senior Manager approval step inside the 15 calendar month window.

How we hand over

Deliver the final policy set, revision history export and an evidence index mapping each document to R1 and Part 1.2.
Walk the responsible staff through the review workflow so the next 15 month cycle runs without rebuilding it.
Document the system configuration, roles and permissions so the organization can operate and audit the workflow itself.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and reviews of policy changes, including CIP-003-9 changes, are available as a retainer.
Your Regional Entity or an independent assessor decides compliance, so confirm the evidence format with them early.