CIP-013-2 R3 Supply chain plan review and approval

CIP-013-2 R3 requires entities to review their supply chain cyber security risk management plan and obtain CIP Senior Manager or delegate approval at least once every 15 calendar months.

On this page

What CIP-013-2 R3 asks for and why the 15-month cycle matters

If you own the supply chain program for a registered entity, CIP-013-2 R3 asks for two things on a fixed clock: a review of your supply chain cyber security risk management plan, and documented approval of that plan by the CIP Senior Manager or a delegate. Both must happen at least once every 15 calendar months. The requirement is simple to state but easy to miss, because nothing in day-to-day procurement forces it. A plan can sit untouched for longer than the cycle while purchases continue, and the auditor will test the dates, not your intentions. The review checks whether the plan still reflects how you actually buy, from vendor risk assessment through the six procurement controls described in R1. The approval is the separate act that makes the reviewed plan the organization's plan, signed off by someone with the authority to accept that risk. Keep the two distinct in your records: a review with no approval, or an approval of a plan nobody reviewed, both leave a gap.

The risk that R3 targets is drift. Procurement teams adopt new contract templates, cloud and remote support arrangements, or new vendor categories, and the written plan falls behind. A plan that describes a process nobody follows is harder to defend than a plan that is merely old, because it shows the organization knew its controls and did not run them. Several things make R3 hard in practice. Ownership is often split between IT, supply chain, legal and the CIP team, so nobody is clearly responsible for starting the review. Delegations of CIP Senior Manager authority may exist in someone's memory but not on paper, and CIP-003-9 R4 requires those delegations to be documented. Approvals also tend to happen by email, which may be real evidence but is often scattered, unsigned or impossible to link to the plan version it approved. Confirm with your Regional Entity and your own counsel what approval record they expect, and set a calendar trigger well inside the 15-month window.

Which plans, approvers and procurements R3 covers

R3 applies to the supply chain plan, and the people who approve it, that govern procurement of BES Cyber Systems and their associated systems. Each card below marks one scoping decision or role that determines how much work the review involves, and each should be confirmed against the entity's own CIP-002 categorization.

High and medium impact scope

The supply chain plan is built around procurements for high impact BES Cyber Systems and medium impact BES Cyber Systems, together with their associated Electronic Access Control or Monitoring Systems (EACMS) and Physical Access Control Systems (PACS). Confirm the list of in-scope systems from the CIP-002 categorization before the review starts, because a system missing from that list can fall outside the approved plan. Record the date of each categorization update so the reviewer can match plan revisions to the asset list in force at the time.

Low impact only entities

Entities whose assets contain only low impact BES Cyber Systems do not fall under the high and medium impact scope of CIP-013-2 in the same way. Whether an entity owes a supply chain plan review depends on how the requirement's applicability table applies to its categorization, so confirm this against the current standard rather than assuming. Document the reasoning in the CIP-002 file so an auditor can see why the plan was or was not required.

CIP Senior Manager and delegates

The review must be approved by the CIP Senior Manager or a delegate. Any delegation used for R3 approvals must be documented under CIP-003-9 R4, including who holds the authority, what it covers and when it took effect. Check that each delegate actually holds the delegation on the approval date, since an approval signed by someone outside the documented delegation will not support the evidence.

Procurement input to the review

Procurement staff hold the records of vendor selection, contract terms and purchase timing that show how the plan is applied in practice. Ask procurement to supply a current list of vendors and contracts touching in-scope systems, along with any changes since the last review. Without this input, the reviewer cannot judge whether the plan still reflects how buying actually happens.

Security and operations input

Security staff confirm whether threats, vulnerability disclosure practices and incident notification expectations have changed since the last review. Operations staff describe how in-scope systems are maintained, accessed and changed, including vendor remote access. Record each team's written input in the review file so the approver can see which risks were considered and which were accepted.

Review timing and records

The plan must be reviewed and approved at least once every 15 calendar months. Track the approval date of each review in a document management workflow so that the interval is provable without reconstructing it later. Keep the approved version, the review notes and the approver's delegation reference together, because an assessor will ask for all three at once.

How an auditor tests the 15-month review and approval

This table walks through the test steps an auditor typically follows for CIP-013-2 R3, from confirming the plan exists to matching revision history against approval records. Read each row as a test step, the evidence it draws on, and the failure that most often appears when that step is not met.

Test stepWhat the auditor checksCommon finding
Confirm the plan existsA written supply chain cyber security risk management plan is in place and identifies the version under reviewNo identifiable plan version, or the plan in use differs from the one presented
Date of last reviewThe most recent documented review falls within 15 calendar months of the audit look-back dateThe last review is older than 15 calendar months, leaving a gap in the interval
Date of last approvalA documented approval follows the review and is dated within the same 15-calendar-month intervalReview recorded but no approval record, or approval dated after the interval closed
Approver authorityThe approver is the CIP Senior Manager or a delegate named in a documented delegation under CIP-003-9 R4Approval signed by someone with no documented delegation, or a delegation that has expired
Revision history matchVersion numbers, change dates and approval dates in the revision history agree with the approval recordApproval cites a version that does not match the revision log, or changes appear with no approval
Review substanceThe review record shows what was examined and what decision was reached, including whether changes were madeReview recorded with no change and no stated decision, so the review cannot be shown to have occurred
Evidence retrievalPolicy documents, review records, workflow records and approval records can be produced for the audit periodRecords held in email or personal files, or not retrievable within the request window

Setting up a review and approval cycle that passes an audit

This sequence turns the 15-calendar-month review requirement into a repeatable cycle that produces dated review records and a signed approval an auditor can trace from the plan to the procurement records behind it.

  1. Assign a named plan owner

    Name one person who owns the supply chain cyber security risk management plan and the review cycle, and record that assignment in the CIP program documents. The owner coordinates procurement, legal, security and operations input, but does not approve the plan. Done means a written assignment exists, it names a backup, and both people know where the current plan and its revision history live.

  2. Set the review trigger and calendar

    Set a recurring review date on the calendar that falls inside the 15-calendar-month window in CIP-013-2 R3, and record the last approval date so the next deadline is visible. Also define event triggers, such as a major change in procurement practice or a new vendor risk finding, that start a review early. Confirm the exact window arithmetic with your Regional Entity and your compliance tooling. Done means the calendar entry, the trigger list and the owner's acknowledgment are stored together.

  3. Review the plan against procurement records

    Compare the current plan with the procurement records for the period since the last review: contracts, purchase orders, vendor questionnaires, notifications received and any exceptions granted. Check whether the plan still reflects how BES Cyber System procurements are actually run and whether the vendor-related controls in R1 still fit. Record which procurement samples were checked and what each one showed. Done means a review memo lists the records examined and the gaps found.

  4. Record decisions and proposed changes

    Write each finding as a decision: no change needed, or a specific revision with a reason and a responsible owner. Keep the review record separate from the plan itself so an auditor can see what was reviewed, when, and by whom, even when no edits were made. Done means every finding has a decision, every change has an owner, and the review record is dated and signed off by the plan owner.

  5. Route the revised plan for approval

    Send the revised plan, or the unchanged plan with the review record, to the CIP Senior Manager or a documented delegate for approval. Confirm the delegation covers supply chain plan approvals and that it is documented under CIP-003-9 R4. Approval should happen after the review, not before, so the approver sees the findings. Done means the approver has the plan, the review memo and the decision log, and the approval request is logged with a date.

  6. File the signed approval with the revision history

    Store the signed approval, the approved plan version, the review record and the change history in one controlled location. Version control in a wiki or document management system can show what changed, when and by whom, and can compare versions. Done means an auditor can follow a single chain from the review date, to the approval, to the plan version in force, and the evidence list for the next cycle points to these records.

  7. Confirm the cycle before the next deadline

    Before the next review date, check that the prior approval is on file, the delegation is current and the calendar entry is active. Include the cycle in internal audit or self-assessment so gaps surface before a Compliance Audit or Spot Check. Done means a short readiness check is recorded and any missing items are assigned with a due date.

Evidence that shows R3 was met on time

CIP-013-2 R3 is met by a dated record, not by a single document. Auditors look for a plan that carries version identifiers, a review inside each 15-month window, and an approval trail that names the CIP Senior Manager or a documented delegate. The cards below cover each artifact and the upkeep that keeps them defensible between audits.

Supply chain plan with version identifiers

The plan itself is the first artifact an auditor opens. Each issued version should carry a version identifier, an effective date and a short statement of what changed, so the reviewer can match a plan version to a specific review cycle. Confirm that the version in force on the audit date is the one that was approved, and that no later draft has replaced it without approval. Keep the plan in one controlled location so the copy shown to the auditor is the copy that was approved.

Revision history for each version

A revision history shows who changed the plan, when, and what they changed. Auditors use it to confirm that the 15-month review actually produced edits or a documented decision to make none. Wiki platforms such as XWiki keep page versions under version control and let users compare any two versions and roll back, which gives you this history without a separate spreadsheet. Check that the history is complete and that no edits were made outside the recorded workflow.

Dated review records

Each review needs its own record: the reviewer, the review date, the scope examined and the outcome, even when the outcome is no change. A single line in a meeting log is weak evidence. A short signed review note per cycle, filed next to the plan, lets the auditor trace every 15-month interval to a concrete event. Confirm that the review dates in these records fall inside the intervals you claim.

Document workflow showing timely review

A workflow record shows when the review task was assigned, when it was completed and when approval was requested and granted. It is the strongest proof of the 15-month interval because it is generated as work happens, not reconstructed later. Permissions matter here: role-based access in tools such as BookStack limits who can publish or approve, so the record also shows that only authorized people moved the plan forward. Confirm that the workflow timestamps match the dates in the review records.

Documented CIP Senior Manager approval

R3 requires approval by the CIP Senior Manager or a delegate, so the approval record must name the person who approved and show that person held that authority on the approval date. Keep a signed or otherwise attributable approval for every version. The evidence is only as strong as the identity behind it, so confirm that the approver's account and signature trail are retained with the version they approved.

Delegation records under CIP-003-9 R4

When someone other than the CIP Senior Manager approves the plan, that delegation must be documented under CIP-003-9 R4. Keep the delegation instrument with its effective date and any end date, and file it alongside the approvals it covers. Revisit delegations whenever a delegate changes role or leaves, because an approval signed after the delegation lapsed is a finding. Check that every delegate who approved a version held the authority on that date.

What meeting R3 costs in staff time, tooling and outside review

This table breaks down the cost components of reviewing and approving the CIP-013-2 supply chain plan every 15 calendar months, showing who is paid for each, whether it is one-time or recurring, and what drives it up. Use the quote questions in the last row to compare proposals on the same basis. The main takeaway is that most recurring cost comes from staff time and evidence upkeep, so a lean tooling choice does not remove the need for people to review and sign.

Cost componentWho is paid or who spends timeOne-time or recurringWhat drives it
Plan owner reviewInternal supply chain or CIP compliance lead drafts the review and records changesRecurring, once per 15-month cycleNumber of revisions since last review and how much the plan changed
Procurement reviewer timeProcurement and vendor management staff check that the plan still matches current buying practiceRecurring, once per cycleNumber of procurement categories and vendors covered by the plan
CIP Senior Manager or delegate approvalApprover time to read, decide and sign, plus any delegation records under CIP-003-9 R4Recurring, once per cycleWhether a delegate is used, and how many approvals are chained
Document toolingInternal platform administrator; open-source wiki or document system licenses may be zero, but hosting, patching and backup are paidOne-time setup, then recurring administrationHosting model, number of users, and whether version history and approval workflow are configured
Outside review of the planExternal consultant or reviewer, if the organization chooses oneOptional, usually per review cycleScope of the plan, number of CIP environments, and whether the reviewer also reviews vendor evidence
Auditor sampling effortStaff time to pull the review record, approval record and revision history for the auditorRecurring, at each audit that samples R3Quality of version history and whether approval evidence is easy to locate
Environment scopeStaff time to confirm the plan covers each CIP environment and its applicable systemsRecurring, once per cycleNumber of CIP environments, high and medium impact sites, and associated EACMS and PACS
Questions to ask in a quoteAsk the provider to state which hours are fixed scope, which are recurring, and who signs the approval recordApplies to the proposal itselfWritten scope, named deliverables and how changes to scope are priced

Which open-source documentation tools can hold R3 evidence

XWiki (LGPL-2.1-or-later) suits the part of R3 evidence that shows the supply chain plan was reviewed within 15 calendar months and how it changed over time. Each page edit is kept under version control, so the wiki can show 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 the plan said at the time of a prior review.

  • Change record: Each saved revision keeps the author, timestamp and content difference, which forms the core of a review history.
  • Version comparison: Reviewers can set two revisions side by side to show what the review actually changed, or that nothing changed.
  • Rollback: Restoring an earlier version creates a new revision rather than erasing history, so the trail stays intact (confirm this behavior in your installed version).
  • Review metadata: Entity-defined fields or a review date section on the plan page can state the last review date and the next due date.
  • Limit: The wiki records that an edit happened. It does not record that the CIP Senior Manager or a delegate approved the plan.

Before relying on XWiki, confirm with your own administrator how long revisions are retained and how backups protect the history. Ask the auditor which review record format they expect before you finalize your structure.

Where R3 reviews usually fail and how to close each gap

Most CIP-013-2 R3 findings come from records that do not line up: a date that slipped, an approval without a delegation, or a review with no visible outcome. Each card below names one gap, what it looks like in the evidence, and the fix that closes it.

Review dates drift past 15 months

The requirement sets a ceiling of 15 calendar months between reviews of the supply chain plan, and the clock runs from the last review, not from the last edit. Teams often miss this because the review is a calendar item owned by no one. Set a recurring task with a due date at least a month before the ceiling, assign a named owner, and keep the calendar entry next to the plan so an assessor can see the cadence. Check the revision history against the date of each approval, not against the date someone opened the file.

Approvals with no delegation record

The approval must come from the CIP Senior Manager or a delegate, and a delegate's authority must be documented under CIP-003-9 R4. A signature from a manager who was never formally delegated is a common finding. Before each approval, confirm the approver's delegation is on file, dated, and still in force. Store the delegation record in the same location as the plan so the approval and its authority can be shown together.

Reviews with no documented outcome

A review that concludes with no written result is hard to defend, even when the plan was reasonable. The evidence should show what was examined, who examined it, and what changed or why nothing changed. For example, a short review record might note that the vendor notification controls were checked against recent procurements and left unchanged. Keep this record with the approval so the review and its conclusion are provable as a single event.

Revision history that does not match approval

A plan can be edited after approval, or approved in one version while a different version is in use. An assessor will compare the approved document with the revision history and the procurement records that cite it. Before approval, freeze the version, record its identifier, and confirm the document circulated to procurement is that exact version. Version control that records what changed, when and by whom makes this comparison straightforward.

Plans stored with no retention

Evidence is only useful if it survives the audit period. Plans kept in a shared drive, a chat tool or an individual's mailbox often lose their review and approval history when files are overwritten or accounts are removed. Choose a document system with fixed retention, restricted deletion, and per-role permissions, and confirm with the vendor how long older versions remain recoverable. Ask the auditor which evidence window applies to your registration before setting retention rules.

Questions buyers ask about R3 cost, effort and outside help

How much effort does one CIP-013 R3 review cycle take?

The effort depends on how many supply chain plans you maintain, how many procurement teams use them, and how much evidence you already keep. A review cycle has four parts: reading the plan against current procurement practice, recording what changed, routing the revised plan for approval, and filing the evidence. A single plan with a stable vendor base and a clear revision history is a small task. A plan spread across several business units, with changes scattered over email and shared drives, takes far longer to assemble. The NERC standard does not set hours or staffing levels, so ask any partner or auditor to show you how they estimated the work, and compare that estimate against your own count of plans, reviewers and approvers.

Can our own team run the R3 review and approval in-house?

Yes. R3 is an internal governance task that the entity owns, and nothing in the requirement requires an outside firm. What the entity must be able to show is that the plan was reviewed at least once every 15 calendar months and that the CIP Senior Manager or a documented delegate approved it. Most teams can do this internally if they assign a named owner, keep a calendar of review dates, and store each version with its approval record. Outside help is most useful when the team lacks a document workflow, has no record of past reviews, or needs a second reader to test whether the plan still matches how procurements are run.

What would a partner do for R3 and what would it leave to us?

A partner such as DeployOpen can prepare the systems and evidence that support R3. Typical work includes setting up a version-controlled document repository, configuring review reminders and approval workflows, organizing past revisions, and producing a clear evidence folder for each cycle. Under a fixed scope, the deliverables are agreed in writing before work starts. A partner does not decide the content of your plan, does not act as the CIP Senior Manager or a delegate, and does not issue audit reports or attestations. The entity still owns the approval decision and the compliance position, and an independent auditor or Regional Entity makes any finding of compliance.

How is the 15-month review clock counted?

The requirement sets a maximum interval of 15 calendar months between reviews. The safest practice is to record the date of each review and approval, then calculate the next due date from the last approved review, not from the start of the calendar year. Confirm with your Compliance Enforcement Authority how they count the start and end of the interval, and whether they expect the approval date or the review date to anchor it. Keep the date evidence in one place, because the clock question usually arises during an audit, when a reviewer asks how a review date was established.

What happens if a review is late?

A late review is a potential noncompliance with R3, and the entity should treat it as a compliance matter rather than a scheduling inconvenience. The exposure depends on the facts, including how late the review was, whether the entity identified it, and how it responded. Penalties under NERC's Sanction Guidelines reference the civil penalty maximum set in 18 CFR 385.1602(d), which the eCFR shows as adjusted by FERC Order No. 906. Confirm the current figure in the eCFR and the factors in the Sanction Guidelines with your legal and compliance team, and consider how self-reporting and a documented mitigation plan would affect the outcome.

What should we ask for in a written scope for R3 support?

Ask for a scope that names the plans covered, the systems and repositories to be set up, the approval workflow, and the evidence each cycle will produce. Request a list of deliverables with acceptance criteria, a clear statement of what the entity must do itself, and a timeline agreed before work starts. Ask who holds administrative access to the repository, how records are exported if you change providers, and how the partner will handle your confidential procurement and vendor information. Also confirm that the partner will not sign approvals or make compliance representations to the Regional Entity on your behalf. A fixed-scope quote should follow directly from this written scope.

What drives the cost of an R3 review cycle up or down?

Costs are driven mainly by internal staff time and, if you engage outside help, by the scope of that help. Internal costs rise with the number of plans, the number of business units involved in procurement, and the amount of manual record-keeping. Outside costs are one-time for setting up the repository and workflow, and recurring if you retain support for each review cycle. Ask for a quote that separates setup from recurring review support, states the assumptions about plan count and approvers, and identifies which items are your responsibility. No external price figure is supplied for this requirement, so use your own staff hours and the written scope to compare options.

How DeployOpen prepares R3 evidence for your team

DeployOpen helps your team prepare the systems and records that show CIP-013-2 R3 supply chain plan review and approval happened on time. Your organization owns the plan, the review and the CIP Senior Manager or delegate approval, while an independent auditor assesses the result.

How we scope

  • Engagements are fixed-scope, with the review workflow, evidence set and deliverables agreed in writing before work starts.
  • We confirm which supply chain plan documents fall under R3 and who holds the CIP Senior Manager or delegate approval role.
  • We agree how the 15-calendar-month review cycle will be tracked, so the scope names the dates and owners in writing.

How we build

  • We set up a versioned document workspace where each plan revision records what changed, when and by whom.
  • We configure role-based permissions so reviewers and approvers can act while edits stay limited to authorized owners.
  • We document the approval workflow so each review produces a dated record of the approver's decision.

How we hand over

  • You receive the plan, revision history, review records and approval documentation mapped to the M3 evidence examples.
  • We write a short runbook explaining how your team records each review and approval for future audit requests.
  • We walk your compliance and procurement staff through the evidence set so they can produce it without us.

How we support

  • Ongoing support, upgrades and continuous testing are available as a retainer, which can cover the next review cycles.
  • We can update the evidence workflow when the plan changes, the delegation list changes or the standard is revised.
  • Independent auditors and certification bodies issue any assessment findings. DeployOpen prepares systems and evidence only.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.