CIP-013-2 R2 supply chain plan implementation guide

CIP-013-2 R2 supply chain plan implementation: what the requirement asks

R2 asks you to prove that the supply chain plan you wrote under R1 is actually used when you buy. If you are the compliance lead for a registered entity, you already have a documented plan. The harder question is whether procurements for BES Cyber Systems, Electronic Access Control or Monitoring Systems (EACMS) and Physical Access Control Systems (PACS) went through the steps that plan describes. R2 is about implementation, not about the plan's wording. An auditor will pick real purchases and check whether the plan shaped how they were handled. The risk R2 addresses is a plan that sits on a shelf while purchasing teams buy hardware, software, cloud services and contractor support on their own terms. The full text of the requirement is in the NERC CIP-013-2 standard PDF, and it is worth reading alongside your plan before you start gathering evidence.

The difficulty is that the evidence rarely sits in one place. Procurement records are scattered across purchasing, legal, security, the operations team that requested the product, and whoever approved the invoice. A vendor questionnaire may sit in a security inbox, a signed notice may be in a contract folder, and a software integrity check may be in a change ticket. Start by listing the procurements in scope for the audit period, then ask each owner which plan steps applied and where the proof is. Under CIP-013-2 M2, evidence of implementation can include correspondence, policy documents or working documents that show the plan was used, so informal records count if they are dated and traceable. Confirm with your Regional Entity which document types it expects before you decide what to collect.

R2 has limits you should state clearly in your own records. Implementing the plan does not require renegotiating or abrogating existing contracts, including amendments to master agreements and purchase orders, and the actual terms of a procurement contract, along with vendor performance and adherence to contract terms, sit outside R2. Your job is to show the plan was applied at the point of procurement, not to police what a vendor does afterward. Where a contract lacks a term your plan calls for, record that gap and how you handled it, such as a documented exception or a request to the vendor, because that record shows implementation. Ask your legal and procurement leads to confirm how they will log these decisions before the next purchase cycle.

Which procurements and systems R2 reaches

R2 applies only to the procurements that bring in equipment, software and services for in-scope systems. The decisions below determine how many purchases, vendors and internal teams end up in the plan's evidence trail, so settle them before the first procurement is reviewed.

High and medium impact BES Cyber Systems

The first scoping decision is which assets the plan protects. CIP-002 categorization determines which BES Cyber Systems are rated high or medium impact, and those ratings define the procurements R2 implementation must cover. Low impact systems fall under a different set of requirements, so a purchase for them does not automatically create R2 evidence. Confirm the current categorization list with the CIP Senior Manager before you scope a procurement review, because a reclassification changes which purchases are in scope.

Associated EACMS and PACS

R2 also reaches the Electronic Access Control or Monitoring Systems and Physical Access Control Systems associated with high and medium impact BES Cyber Systems. Access management platforms, authentication services and badge systems often arrive through general IT purchasing, not OT procurement. Ask IT and facilities to flag these purchases so they enter the plan's review process. Missing them is a common gap because the purchase looks routine.

Hardware, software and services channels

Equipment, licensed software, firmware updates and support contracts usually enter through different channels, each with its own approval path. A plan that covers only capital hardware leaves out subscriptions, patch services and remote support agreements. Map every channel that can add or change an in-scope system, including emergency purchases and renewals that happen automatically. Ask procurement for a list of channels and the systems each one feeds.

Integrators, cloud and SaaS providers

Systems integrators, managed service providers and cloud or SaaS vendors often hold administrative access or store data related to in-scope systems, even when the entity never buys their hardware. Decide whether each third party counts as a supplier for R2 and document that decision. Contracts for these providers are often standard online terms, so check which vendor-related controls the plan can actually request before onboarding.

Procurement, operations and security roles

Procurement issues purchase orders, operations owns the systems, security reviews risk, and legal manages master agreements. R2 implementation needs evidence that each team followed the plan, so assign a named owner for each step in the procurement workflow. Document which team decides when a purchase falls outside the plan's controls. Confirm these roles with your internal governance before the first audit cycle.

Existing master agreements and purchase orders

R2 does not require reopening signed contracts. Master agreements and open purchase orders remain as they are, and the plan applies to new procurements and renewals. Record which existing agreements are carried forward without change so that the scope boundary is clear to an auditor. Work with legal to identify renewal dates, since each renewal is a point where the plan's requirements can be applied.

Where R2 stops: contract renegotiation and vendor performance

R2 requires you to implement the supply chain plan, but it does not require you to renegotiate or abrogate existing contracts. The requirement's notes make this explicit, and that includes amendments to master agreements and purchase orders. The notes also place the actual terms and conditions of a procurement contract, along with vendor performance and the vendor's adherence to a contract, outside R2's scope. In practice, R2 is tested on whether your procurements follow the plan you wrote under R1, not on whether the contract language you signed matches that plan or whether the vendor delivers what the contract promised.

Illustrative example: your R1 plan adds a step requiring a security review of any vendor's remote access and software integrity commitments before a purchase order is issued. The procurement team adds a checklist to the intake form for new purchases, and the file for each new order records who reviewed the commitments and what they found. An existing master agreement with a long-standing vendor is left alone. That is a valid implementation of R2 for new buys. The evidence that supports it is the intake form, the completed checklists, and the correspondence showing the review, which M2 allows as evidence of implementation.

Some plan steps cannot work through new intake alone. If a step depends on the vendor accepting new notification timelines or access revocation terms in a contract that is already in force, R2 does not compel that change, so you will need a different route, such as a contract amendment you negotiate voluntarily, a documented compensating control, or a planned renewal date. Do not assume the requirement's silence on renegotiation resolves the gap. Confirm with your Regional Entity how it treats plan steps that rely on existing contracts, and record that conversation, because the answer determines what evidence you need to keep.

How to show the plan was used in a procurement

The sequence below turns the R1 plan into a procurement record that shows each in-scope purchase was checked against the plan's vendor controls. It gives an assessor the decisions, correspondence and sample review that show R2 was carried out, not just documented.

Confirm the R1 plan is approved and current
Before any procurement is routed, the CIP Senior Manager or delegate should confirm that the supply chain cyber security risk management plan is the approved version and that its review and approval are recorded. Keep the approved plan, its version history and the approval record together so the plan in force on each procurement date can be shown. Output: a dated, approved plan reference that every procurement file cites. For how the plan itself is built and reviewed, see the CIP-013-2 R1 and R3 pages.
Route in-scope procurements through intake
Create a documented intake step that asks whether a purchase involves a BES Cyber System, an EACMS or a PACS in scope under the entity's CIP-002 categorization. Procurement, the requesting team and security should all use the same intake form or ticket type so no purchase reaches a contract without the question being answered. Output: an intake record for each purchase, marked in scope or out of scope, with the reason. Ask your team to confirm the exact scope list, since it depends on the entity's own categorization.
Apply the plan's vendor controls to each purchase
For each in-scope purchase, the reviewer checks the vendor against the controls the R1 plan requires: incident notification, access revocation notice, vulnerability disclosure, software integrity, and remote access coordination. Where the vendor's standard terms do not cover a control, the team records what it asked for and what the vendor answered. This step does not require renegotiating existing contracts, and the requirement does not review the contract terms themselves. Output: a completed control checklist per purchase with the vendor's responses attached.
Record decisions and vendor correspondence
Keep the reasoning behind each decision in the procurement file: which controls were requested, which the vendor accepted, which were declined, and who approved the exception. Store emails, questionnaire answers, statements of work and other working documents that show the plan was used. The CIP-013-2 measure explicitly accepts correspondence, policy documents and working documents as evidence of implementation. Output: one indexed file per purchase that a reviewer can follow from intake to signature without asking the buyer.
Store the procurement file in a version-controlled wiki
Keep the procurement records in a wiki or document system that tracks changes, authors and dates, so later edits do not erase the original decision. A wiki with page history lets reviewers compare versions and see who changed a record and when. Confirm with your own IT team that retention and access settings meet the entity's CIP information protection rules, because vendor correspondence may contain BES Cyber System Information. Output: a stable location per procurement with its full change history preserved.
Sample procurements against the plan
Select a sample of closed procurements at a regular interval and check each file against the R1 plan. The reviewer confirms that intake happened, the vendor controls were applied, and each decision is recorded and approved. Findings go back to the plan owner, who decides whether the plan, the intake step or the team's practice needs to change. Output: a dated sample review record with findings, owners and follow-up actions. Ask your auditor or compliance lead to confirm how many files and how often the sample should be drawn for your entity's program.

How an assessor tests R2 implementation

This table walks through how a Regional Entity assessor typically tests whether the R1 supply chain plan was used in procurements, what evidence is requested at each step, and where entities commonly fall short. Read it as a checklist for preparing procurement records before an audit, and note that the assessor looks at use of the plan, not at contract terms or vendor performance.

Test step	Evidence requested	Common finding
Confirm the R1 plan is the plan being tested and was in force during the audit period	Approved plan version, approval record, and the revision history showing the version in effect for each procurement	Entity presents a current plan but cannot show which version governed procurements earlier in the period
Identify in-scope procurements for high and medium impact BES Cyber Systems and their EACMS and PACS	Procurement register or purchase records tagged by asset category, plus the entity's scoping rationale	Procurements for associated EACMS or PACS are missing from the register or never tagged as in scope
Select a sample of in-scope procurements and trace each to the plan steps	Correspondence, policy documents and working documents showing use of the plan for each sampled procurement	Plan steps such as vendor risk review or notification terms have no matching record in the procurement file
Check that procurements passed through the entity's intake process before award	Intake or request forms, approval routing, and dated records showing review by the responsible owner	Purchase orders or renewals bypass intake, often through urgent buys or departmental contracts
Check that the plan's vendor-related topics were addressed in each sampled procurement	Working notes, vendor questionnaires or correspondence showing topics such as incident notification and software integrity were raised	Records show the topic was discussed in general terms with no evidence of the vendor's response
Check renewals and amendments of existing agreements against the plan	Renewal workflow records and dated correspondence showing the plan was applied at renewal	Entity assumes existing contracts are exempt and applies no plan step at renewal
Confirm the assessor is not reviewing contract terms or vendor performance	Scope statement agreed for the engagement, showing contract wording and vendor performance are outside R2	Entity over-supplies contract negotiations or vendor service reports that the assessor does not need for R2

Evidence that shows the plan was used in procurements

CIP-013-2 R2 requires implementation of the R1 plan, and M2 accepts a broad range of records as evidence of that use. The cards below cover the artifacts an auditor is most likely to ask for, what each one shows, and how to keep it current between audits. No single record guarantees a favorable finding, because the auditor judges whether the records together show the plan was applied to real procurements.

Vendor correspondence raising plan controls

Emails, portal messages and meeting notes exchanged with vendors during a procurement show that plan controls were actually raised with the supplier. Examples include requests for incident notification commitments, vulnerability disclosure contacts, software integrity practices or remote access coordination. Keep the thread attached to the procurement record, not in a personal mailbox. Check that each thread names the vendor, the date and the plan control discussed. Keep the correspondence with its version history wherever it is stored so later edits to the thread can be traced.

Procurement intake procedure

The policy and procedure documents define how a purchase enters the supply chain review, who starts it, which plan controls are checked and who signs off. They show the plan is a working process rather than a static document. Confirm that the intake procedure names the roles that hold the procurement decision and that it matches the plan approved under R3. Record each revision with its date, approver and reason for change, and retain superseded versions so an auditor can see which procedure governed a given purchase.

Risk review worksheets

Completed worksheets record how a specific vendor or product was assessed against the plan's risk factors, including the vendor's security posture, its remote access needs and its software update practices. They are the clearest link between a plan and a single procurement. Keep one worksheet per procurement with a unique identifier, the reviewer's name and the date of review. Note any factor marked as not applicable and the reason, since unexplained gaps invite questions.

Approval and exception records

Approval records show who accepted the residual risk for a procurement, and exception records show where the team accepted a deviation from a plan control. Both demonstrate that decisions were made by the right people and documented. Confirm that approvals identify the approver's authority under the entity's CIP governance and that exceptions state the compensating action taken. Store these in the same system as the worksheet so they can be retrieved together during an audit.

Purchase records linked to plan steps

Purchase orders, contract references and receiving records tie a procurement to the plan steps applied to it. This linkage is what lets an auditor follow one purchase from intake to delivery. Use a shared identifier across the purchase system, the worksheet and the correspondence. Confirm that contract amendments made under the plan are recorded without implying that existing terms were renegotiated, since R2 does not require that. Keep purchase records for the period your retention schedule sets, and confirm the period with your Compliance Enforcement Authority and internal records policy.

What meeting R2 costs in money and effort

This table lists each cost component of running CIP-013-2 R2 procurements, who is paid for it, whether it is one-time or recurring, and what pushes it up or down. No figures appear because none were supplied, so use the drivers to frame a written quote and ask for each line item to be priced separately.

Cost component	Who bears it and one-time or recurring	What drives it up	How to keep it down
Procurement and compliance staff time per in-scope purchase	Entity staff. Recurring, every in-scope procurement	Number of in-scope procurements, and how many plan controls each one must address	Standard intake templates that record which plan controls apply before a purchase starts
Legal review where a plan control is raised with a vendor	Entity legal team or outside counsel. Recurring, per negotiation touchpoint	Vendors that reject standard language, and controls needing bespoke wording	Pre-agreed clause language and vendor correspondence that can be reused across contracts
Setup of the procurement record and supporting tooling or licenses	Entity IT, or an implementation partner for setup. One-time for setup, recurring for licenses	Number of vendors tracked, number of plan controls, and whether records sit in separate systems	Self-hosted open-source record keeping, such as a wiki with version history, kept inside the entity's own infrastructure
Ongoing maintenance of vendor records and evidence of plan use	Entity compliance staff. Recurring, tied to each procurement and review cycle	Vendor churn, duplicate records and evidence scattered across email and shared drives	One record per vendor and per procurement, linked from a single index page
External review or sampling support before an audit	Independent consultant or implementation partner, if engaged. One-time per cycle or recurring if retained	Size of the procurement population and the number of records that must be assembled	Fixed-scope review agreed in writing, limited to a defined sample of procurements
Auditor sampling time and evidence requests	Entity staff responding to the Compliance Enforcement Authority. Recurring, per audit or monitoring engagement	Number of procurements selected in the sample and how quickly records can be produced	Keep evidence indexed and retrievable so sampled items can be answered without rebuilding history
Contract renegotiation or vendor performance monitoring	Not required by R2. Any such work is a voluntary business decision	Scope choices the entity makes beyond the requirement	Confirm with compliance counsel that these items stay outside the R2 budget line

How self-hosted open-source tools can hold the procurement record

Self-hosted tools can keep the CIP-013-2 R2 record inside the entity's own environment, which matters because the M2 evidence is mostly correspondence, policy documents and working documents. XWiki keeps every change to a page under version control, recording what changed, when and by whom, and lets reviewers compare any two versions or roll back to an earlier one. That suits the supply chain plan and the working files that show it was applied, such as the procurement checklist completed for each purchase. Confirm with your own administrators that page history is retained for the period your evidence retention schedule requires, and that the wiki is hosted in a location your CIP information protection program already covers.

BookStack controls who can change procurement records. Abilities come from the roles assigned to each user, and permissions can be overridden per role at the shelf, book, chapter or page level. A practical setup is a restricted book for each procurement file, with edit rights limited to the procurement and CIP compliance staff who prepare it and read rights extended to the people who approve it. Check the role configuration during your own review, because a permission granted at a higher level flows down unless it is overridden, and an over-broad shelf setting can expose records you meant to restrict.

CISO Assistant (AGPL-3.0-only) ships more than 200 frameworks and can run assessments with automatic mapping between them, which may help a team that tracks CIP-013 alongside other frameworks. Before relying on it, confirm with the project whether a NERC CIP library is included in the version you plan to deploy, and what it covers. Whatever the tool, these platforms hold records; they do not make a procurement compliant. Whether a contract, vendor response or approval satisfies R2 is a judgment the entity and its CIP Senior Manager or delegate must make and document.

Who does what: your team, a partner and the auditor

Your organization owns the CIP-013-2 R2 obligation. Your team carries the R1 supply chain cyber security risk management plan, makes each procurement decision, manages vendor relationships and records who approved what. The people who sign purchase orders and negotiate with vendors are the ones whose conduct the auditor will ask about, so they need to know the plan well enough to show it was used.

Plan ownership: the CIP Senior Manager or delegate owns the R1 plan and its approval cycle under R3.
Procurement decisions: buyers and contract owners decide whether and how each plan control applies to a purchase.
Vendor relationships: account owners handle notifications, access coordination and vulnerability disclosures with suppliers.
Records of use: correspondence, checklists and working documents that show the plan was applied.
Likely outsourced work: intake workflow design, evidence repository setup and mock sampling, with final decisions kept in-house.

Check that every in-scope procurement has a named owner and a retrievable record, because the auditor will sample from those records, not from the policy.

Where entities usually fall short on R2 and how to close each gap

Most R2 findings come from the gap between a plan that exists on paper and procurements that cannot show the plan was used. The gaps below cover intake, documentation, evidence storage, scope confusion, sampling and version traceability, each with the symptom an assessor would see and the fix.

Procurements that skip intake

Purchases of BES Cyber Systems, EACMS or PACS often start with a purchase order or an email from an operations team, and the supply chain review never happens. An assessor who selects a recent purchase will ask where the plan was applied and find no record. Fix this by adding a mandatory intake step to purchasing workflows for in-scope asset types, with a field that records the plan version consulted and the reviewer. Ask procurement to confirm which order types bypass the step, such as emergency or renewal orders.

Controls discussed but never documented

Teams often agree in meetings that a vendor must give incident notice or software integrity verification, then never write it down. CIP-013-2 M2 accepts correspondence, policy documents and working documents as evidence of use, so the gap is usually a missing record rather than a missing practice. Fix this by logging each agreed control against the specific procurement, with the date and the person who confirmed it. Check that the log names the controls from the plan, not general good intentions.

Evidence scattered across email and drives

When correspondence sits in individual mailboxes and working files sit in personal folders, an assessor cannot reconstruct a procurement from start to finish. Staff turnover makes this worse, because the people who held the evidence leave. Fix this by keeping one case record per procurement in a controlled wiki or document system that tracks authorship and change history. Ask the team to confirm who can edit each record and whether departed staff have access removed without losing their records.

Chasing amendments R2 does not require

Some teams read R2 as a duty to renegotiate existing contracts, so they spend months seeking amendments from vendors. The requirement says implementing the plan does not require renegotiating or abrogating existing contracts, including master agreements and purchase orders. Fix this by documenting that R2 is about applying the plan during procurement, and by recording where a contract already lacks a plan control as a risk decision. The actual terms and vendor performance are outside R2, so an assessor will not test them under this requirement.

No sampling of past purchases

Entities often discover gaps only when an auditor selects purchases they never reviewed. Without an internal sample, there is no evidence the team tested its own records or corrected problems before the audit. Fix this by drawing a sample of recent in-scope procurements each review cycle, checking each one against the intake and documentation steps, and logging the results and corrective actions. Confirm the sample size and selection method with your Regional Entity or auditor before relying on it.

No link to the plan version

A procurement made in one year may have been checked against a plan version that was replaced months later, and nobody can say which version applied. Under R1 and R3 the plan is reviewed and approved on a cycle, so version dates matter. Fix this by recording the plan version and approval date on every procurement record, and by keeping prior versions retrievable. Check that procurement dates can be compared with the approval dates in force at that time.

Questions buyers ask before bringing in help on R2

How much effort does CIP-013-2 R2 take compared with drafting the plan?

R2 is an ongoing implementation duty, so it usually takes less effort than drafting the R1 plan, but it recurs with every in-scope procurement. Drafting the plan is a one-time project that sets policy, vendor risk criteria and the six vendor-related controls. R2 then asks for proof that those controls were actually used when buying. Effort depends on how many procurements touch high or medium impact BES Cyber Systems, their EACMS and PACS, and how well procurement already records its steps. Ask any partner to scope the effort from your procurement volume and your current intake process, in writing, before work starts.

Does R2 require us to renegotiate existing vendor contracts?

No. The requirement does not require renegotiating or abrogating existing contracts, including amendments to master agreements and purchase orders. R2 is about implementing the plan when you procure. Existing agreements can stay as they are, and the plan's expectations are applied to new or renewed procurements where your process reaches them. Before you decide how to handle older agreements, confirm with your legal team how your plan treats renewals and amendments, and record that decision so an auditor can see how you handled it.

Does an audit check whether vendors perform well under our contracts?

No. The actual terms and conditions of a procurement contract, and vendor performance and adherence to a contract, are outside the scope of R2. An assessor looks at whether the plan was used in procurements, not at whether the vendor met its obligations afterward. Vendor performance is still a sound management concern, and your other CIP controls, such as remote access and vulnerability handling, may test parts of vendor conduct. Treat contract monitoring as a business process you run separately, not as R2 evidence.

What drives how long it takes to set up a procurement record before an audit?

The main drivers are the number of procurements in scope, whether records already exist in tickets, email or contract systems, and how many teams touch a purchase. Records are easier to assemble when each procurement links to the plan section it applied, the risk review, and the approval. Gaps take longer, especially where purchases were made through a different channel or by a business unit that did not use the standard intake. Evidence may include correspondence, policy documents or working documents that show use of the plan, so a consistent intake template reduces the reconstruction work. Ask any partner how they would build the record for your existing procurements and what they need from you to start.

What does R2 need from our procurement and legal staff?

R2 needs procurement and legal staff to follow the plan's steps in the purchasing workflow and keep the outputs. In practice, procurement should use a standard intake that captures which BES Cyber Systems or related EACMS and PACS the purchase touches, the vendor risk review, and the vendor-related controls agreed in the deal. Legal should confirm which plan terms appear in new contract language and how renewals are handled. Both teams should know who approves exceptions and where records are stored. A named owner on each side, plus a short written procedure, usually matters more than tooling.

Can we implement R2 in-house without an outside partner?

Yes, an entity can implement R2 in-house if it has the people, the procurement discipline and the records to show the plan was used. Many teams handle it internally. An outside implementation partner can help by preparing the intake workflow, the evidence structure and the records, but it does not own the controls and cannot issue audit results. Accountability for the plan and its approval stays with your CIP Senior Manager or delegate. Bringing in help makes most sense when procurement volume is high, records are scattered, or internal staff lack time. Any engagement should be fixed in writing with scope and deliverables agreed up front.

How DeployOpen works on this

DeployOpen helps registered entities prepare the supply chain plan, procurement records and implementation evidence that CIP-013-2 R2 asks for, inside your own infrastructure. We prepare systems and evidence; your organization owns its controls, and only the Regional Entity or NERC auditors judge compliance.

How we scope

We agree a written scope before work starts, listing which procurements, plan sections and high or medium impact systems are covered.
The scope states which procurement records and working documents will be collected as implementation evidence for R2.
Ongoing support for plan use and evidence upkeep can be added as a retainer once the fixed-scope work is complete.

How we build

We set up a procurement evidence structure that links each purchase to the plan steps applied to it.
We configure a self-hosted wiki or documentation platform to keep plan versions, reviews and approvals traceable.
We test that records show who used the plan, when, and for which vendor, before anything is handed over.

How we hand over

You receive documented procedures, evidence templates and an index mapping each record to the R2 implementation requirement.
Handover includes a walkthrough so your procurement and compliance staff can add records without our involvement.
We document the limits of R2 in the handover, including that contract renegotiation and vendor performance auditing are excluded.

How we support

Retainers can cover periodic evidence reviews, platform upgrades and updates to procurement templates as your vendor base changes.
Support does not include issuing compliance reports or determinations; those remain with your Regional Entity or NERC.
Confirm with us during scoping which support level, response expectations and review cadence the retainer will include.