CIP-013-2 R1 supply chain risk management plan explained

What the CIP-013-2 R1 supply chain risk management plan requires

If you are a compliance lead or engineer who must show a documented plan for vendor risk, start with this: CIP-013-2 R1 requires a written supply chain cyber security risk management plan that covers how your organization identifies vendor risk when it plans procurements, and which vendor-related controls every relevant procurement must address. The requirement applies to high and medium impact BES Cyber Systems and their associated EACMS and PACS. The plan is the document itself. Whether procurements actually follow it is tested under the sibling requirements R2 (implementation) and R3 (review and approval at least once every 15 calendar months), so keep those separate when you build your evidence.

Part 1.1 asks for processes used in procurement planning that identify and assess cyber security risks to the BES from three sources: vendor products or services, the procurement and installation of vendor equipment and software, and transitions between vendors. In practice, the plan should name who performs the assessment, when in the purchasing lifecycle it happens, what criteria rate a vendor or product as higher risk, and how a vendor change or contract exit is assessed. Ask your procurement and security teams to show one completed example for a recent purchase, because an assessor will look for a traceable decision, not a generic statement.

Part 1.2 is where most plans lose specificity. It lists six topics that procurement processes must address, as applicable: vendor notification of vendor-identified incidents, coordination of responses to those incidents, notification when vendor remote or onsite access should end, vendor disclosure of known vulnerabilities, verification of software integrity and authenticity, and coordination of controls for vendor-initiated remote access. Each topic should map to a clause your contract template or procurement checklist can actually carry, and to the operational control that later checks it. Software integrity links to CIP-010-4 R1 Part 1.6 and vendor remote access links to CIP-005-7 R2 Parts 2.4 and 2.5 and R3. Confirm each linkage in your own environment rather than assuming the plan language covers it.

Which systems, vendors and procurements fall under the plan

R1 scope is set by three decisions: which BES Cyber Systems are high or medium impact, which associated EACMS and PACS travel with them, and which vendor-related activities count as procurement. Each card below is one of those decisions and the work it adds to the plan.

High and medium impact BES Cyber Systems

R1 applies to plans covering high and medium impact BES Cyber Systems. The impact rating comes from the categorization done under CIP-002-5.1a, so the scope of this plan depends on that list being current. Check that every system rated high or medium is named in the plan's procurement scope, and that any reclassification after a change in assets or ratings is pushed into the plan. A system missing from the categorization will not be covered by the procurement controls, even if it is critical in practice.

Associated EACMS and PACS

The plan also reaches the Electronic Access Control or Monitoring Systems and Physical Access Control Systems associated with those high and medium impact systems. Teams often forget these when they scope procurements, because access gateways, authentication services and badge systems sit outside the control room. Build an inventory that links each EACMS and PACS to the BES Cyber Systems it protects, and check that procurements for those tools follow the same plan steps as the systems they serve.

Why low impact assets fall outside R1

CIP-013-2 R1 does not require a supply chain plan for low impact BES Cyber Systems. Vendors supplying only low impact assets may therefore sit outside this plan, although CIP-003 contains its own controls for low impact assets. Confirm which assets are rated low impact, document why each is excluded, and check whether the same vendor also supplies high or medium impact systems, because that overlap brings the vendor back into scope.

Vendor products and services

Procurement planning under Part 1.1 covers the risk from vendor products and services used with in-scope systems. This includes managed services, support contracts and hosted tools that touch the BES environment. A product bought from a vendor who does not operate it still needs a risk assessment if the vendor can affect cyber security. Ask each procurement owner to name the vendor product or service being bought and whether the vendor gains any access to in-scope systems.

Software and installed equipment

Part 1.1 extends the risk review to the procuring and installing of vendor equipment and software. Installation work, firmware loads and software patches are all points where risk enters an in-scope system, so they belong in the plan's procurement steps. Build a checklist for each acquisition that lists the hardware, firmware, software and patch sources, and records who installs them. This is where the Part 1.2 controls on software integrity and authenticity are checked.

Transitions between vendors

Part 1.1 also covers risk arising from transitions between vendors, such as replacing a support provider, changing a managed service or migrating to a new product. These transitions often leave old access, unrevoked credentials and undocumented configurations behind. Include a transition step in the plan that addresses access revocation notice, handover of configuration and knowledge, and removal of the outgoing vendor's remote access. Treat each change of vendor as a new procurement event in the plan.

How an auditor tests the CIP-013-2 R1 plan

This table sets out what an assessor checks for the documented supply chain plan, each Part 1.1 and Part 1.2 process, and the operational links to CIP-010-4 and CIP-005-7, with the evidence usually requested for each. Reviews run through Compliance Audits, Spot Checks or Self-Certifications by the Compliance Enforcement Authority, so read each row as a question the entity should be able to answer with dated records.

Test area	What the assessor checks	Evidence requested	Common findings
Documented plan	That a written plan exists, covers high and medium impact BES Cyber Systems and their associated EACMS and PACS, and is specific enough to follow in a procurement	Current plan version, scope statement mapping applicable systems, revision history and approval record	Plan is generic, omits EACMS or PACS, or does not name the owner responsible for procurement
Part 1.1 procurement planning	That the processes identify and assess vendor risk from products, services, equipment and software installation, and from vendor transitions	Risk assessment criteria, completed vendor risk assessments, and records of how transition risk was considered	Risk assessment is documented but never applied to specific vendors or transitions
Part 1.2 vendor incident notification and response	That procurement processes require vendor notice of vendor-identified incidents and coordination of responses	Contract clauses or procurement checklist language, and examples of notices or coordinated responses where they occurred	Clause is missing from standard terms or applies only to some vendors
Part 1.2 access and vulnerability disclosure	That processes address notice when vendor access should end and vendor disclosure of known vulnerabilities	Access revocation notice procedure, vendor contact list, and vulnerability disclosure terms in procurement documents	No defined path for vendors to report access changes or disclosed vulnerabilities
Part 1.2 software integrity and authenticity	That processes verify integrity and authenticity of vendor software and patches before use	Verification method description, hash or signature check records, and link to CIP-010-4 R1 Part 1.6 procedures	Verification described in the plan but not performed or recorded in change tickets
Part 1.2 vendor remote access	That processes coordinate controls for vendor-initiated remote access	Remote access coordination procedure, access request records, and alignment with CIP-005-7 R2 Parts 2.4 and 2.5 and R3	Vendor remote sessions occur without documented coordination or without matching CIP-005-7 controls
Link to CIP-010-4	That software integrity checks from procurement feed into configuration change management and baselines	Change records showing verified software, baseline updates and vulnerability assessment outputs	Procurement verification and change management run as separate processes with no shared record
Link to CIP-005-7	That vendor remote access paths match the electronic access controls and monitoring the standard requires	Network diagrams of vendor access paths, Intermediate System configuration and session logs	Vendor access paths are undocumented or bypass the controls named in the plan

Building the plan in six implementation steps

The sequence below turns CIP-013-2 R1 into a plan an auditor can trace, from the list of in-scope systems and vendors through to a recorded, approved version. Each step closes with a named output that feeds the next.

Confirm in-scope systems and vendors
Start from your CIP-002 categorization and list every high and medium impact BES Cyber System, along with its associated EACMS and PACS. For each, record the vendors that supply hardware, software, firmware, patches, managed services or remote access. The CIP-002 owner and the procurement lead should sign off on the list. The output is a scoped inventory of systems and the vendors tied to each, which becomes the boundary for every later step.
Document the Part 1.1 risk identification process
Write the procurement planning process that identifies and assesses cyber security risk from vendor products and services, from procuring and installing vendor equipment and software, and from transitions between vendors. Name the roles that run each check, such as security architecture reviewing a new product or operations reviewing a vendor change. The output is a written Part 1.1 procedure that a reviewer can follow without asking the author how it works.
Map each Part 1.2 topic to procurement terms
For each of the six Part 1.2 topics (vendor incident notification, coordination of incident response, notice when access should end, vulnerability disclosure, software integrity and authenticity verification, and coordination of vendor-initiated remote access), write the contract clause, questionnaire item or checklist entry that addresses it. Mark where a topic does not apply to a given procurement and record why. The output is a matrix that links each topic to a specific term or checklist item, with the owner of each.
Define exception approval
Decide who may accept a procurement that cannot meet a Part 1.2 topic, and under what conditions. Document the approver, the required justification, the compensating measures and how the exception is recorded and revisited. Confirm the approval chain with your legal and procurement teams, since they hold the contract leverage. The output is a written exception procedure with a log template, so every accepted gap has a named owner and a recorded rationale.
Connect the plan to CIP-010-4 and CIP-005-7
Cross-reference the plan with the operational controls it depends on. Software integrity verification ties to CIP-010-4 R1 Part 1.6, and vendor remote access ties to CIP-005-7 R2 Parts 2.4 and 2.5 and R3. Confirm the procurement terms and the operating procedures describe the same handoffs, such as who verifies a patch hash and who approves a vendor session. The output is a traceability table that shows which plan item is enforced by which operational control.
Record and approve the version
Assemble the Part 1.1 procedure, the Part 1.2 matrix, the exception procedure and the traceability table into one plan document. Route it for approval, then store the approved version with its date and approver in a version-controlled repository, so changes are visible and earlier versions can be restored. Confirm the approval process against the review and approval rules in CIP-013-2 R3 before you begin. The output is an approved, dated and versioned plan that is ready to be applied to procurements under R2.

Where the Part 1.2 controls connect to CIP-005 and CIP-010

A CIP-013-2 R1 plan cannot stand alone because the Part 1.2 procurement terms only matter if operations check them. Vendor software integrity verification connects to CIP-010-4 R1 Part 1.6, and vendor remote access coordination connects to CIP-005-7 R2 Parts 2.4 and 2.5 and to R3. The supply chain standard requires procurement processes that address these topics, as applicable, but the operational standards are where the same topics are enforced day to day. Your procurement team should read the plan alongside those two standards and confirm that each Part 1.2 term has a named operational owner who will perform the matching check.

Consider a procurement term requiring the vendor to provide hashes or signatures for each software release, or requiring notice before a vendor technician connects remotely. If nobody checks the hash during baseline and change work, or no one reviews remote sessions against the coordinated access process, the term exists only on paper. An assessor testing R1 will ask how the procurement commitment was carried into the configuration change and remote access records, and a gap between the contract and those records is the kind of finding that is easy to identify. (Illustrative example.)

Before the next procurement cycle, map each Part 1.2 topic to a named CIP-010 or CIP-005 control, the record that proves it ran, and the person who reviews that record. Confirm the exact wording of these requirements in the current NERC standards, because the operational parts apply to specific Applicable Systems and may not cover every system your plan addresses. Where a term has no operational counterpart, decide whether to add a check, narrow the term, or document why it does not apply, and keep that decision in the plan so the change history shows it.

Evidence that shows the R1 plan exists and covers the six controls

An auditor testing CIP-013-2 R1 looks for two things: a documented plan that was approved and kept current, and proof that procurements address the vendor-related topics the plan names. The cards below cover the core documents and records that show both, and how they connect to operational records under CIP-010-4 and CIP-005-7.

Approved plan with version history

The plan itself is the first artifact an auditor requests. It should name the high and medium impact BES Cyber Systems and their associated EACMS and PACS in scope, state who approved it, and show each revision with its date and reason. Keep the approval record with the plan so the reviewer can see the current version was signed off. Confirm with your Compliance team how the plan is stored, since version history is only useful if every revision is retained. Ask for the full revision log before any audit.

Part 1.1 vendor risk assessment records

Part 1.1 requires procurement planning processes that identify and assess cyber security risk from vendor products, from procuring and installing vendor equipment and software, and from transitions between vendors. Evidence is the completed assessment for each procurement or vendor category, with the risks found and how they were handled. Records of vendor transitions matter because auditors often test them last. Confirm that the assessment method is written in the plan, not only applied in practice.

Procurement checklist mapped to Part 1.2

A procurement checklist or template turns the plan into something buyers use. Each Part 1.2 topic should appear as a line item: vendor incident notification, coordination of incident response, notice when access should end, known vulnerability disclosure, software integrity and authenticity verification, and coordination of vendor-initiated remote access. Mark each topic as applicable or not applicable with a reason, because Part 1.2 applies only as applicable. Completed checklists tied to specific contracts are stronger evidence than a blank template.

SBOM and vulnerability tracking records

Software integrity and known vulnerability disclosure are easier to evidence when vendor software is inventoried. OWASP Dependency-Track consumes and produces CycloneDX SBOMs and VEX, flags components with known vulnerabilities, and tracks license risk. Trivy can generate an SBOM from a target or scan an SBOM a vendor supplies. Keep exported reports with the procurement file and confirm both tools fit your environment and data handling rules before rollout.

Cross-references to CIP-010-4 and CIP-005-7

R1 connects to operational controls. Software integrity verification appears in CIP-010-4 R1 Part 1.6, and vendor remote access appears in CIP-005-7 R2 Parts 2.4 and 2.5 and R3. Keep a cross-reference table that links each plan topic to the operational record that proves it runs, such as change tickets that verify software authenticity or Intermediate System access logs for vendor sessions. Auditors use these links to test whether the plan describes real practice.

Vendor communications and notices

Vendor notification of incidents, vulnerabilities and access end dates happens through correspondence, so the record of those exchanges is evidence. Retain the contract clauses that require notice, plus examples of notices received and how they were routed. Where a vendor did not provide a required notice, keep the follow-up record. Confirm with each vendor which contacts receive notices and how those contacts are kept current.

What meeting CIP-013-2 R1 costs in money and effort

This table compares each cost component of writing and maintaining the CIP-013-2 R1 plan, who is paid for it, whether it is one-time or recurring, and what moves it up or down. Use it to build a quote request, not as a budget, because no fee or duration figures are supplied for this requirement.

Cost component	Who is paid, one-time or recurring	What drives it up or down	What to ask for in a quote
Plan drafting	Internal compliance and procurement staff, or an outside consultant. One-time to draft, recurring when reviewed.	Number of vendor categories, number of high and medium impact sites, and how many procurement processes already exist to reference.	A named deliverable list: the plan document, the vendor risk criteria, and the procurement checklist, with a review cycle.
Legal review of vendor terms	Counsel, internal or external. Mostly one-time per contract template, recurring for each new vendor agreement.	Whether standard contract templates already contain the notification, access and vulnerability terms, and how much negotiation vendors accept.	Confirmation of which Part 1.2 topics the template covers, and whether counsel reviews each renewal or only the template.
Engineering time for control mapping	Internal engineers or the implementation partner. One-time to map, recurring as systems and vendors change.	Size of the BES Cyber System inventory, number of EACMS and PACS, and whether the asset inventory is already current.	A mapping of each Part 1.2 topic to a named procedure, system or record, with the effort estimate for each.
Tooling and licenses	Software vendors or open-source projects. Recurring for commercial subscriptions, one-time for setup on self-hosted tools.	Commercial SBOM or vulnerability platforms charge per seat or asset. Self-hosted tools such as OWASP Dependency-Track (Apache-2.0) and XWiki (LGPL-2.1-or-later) remove license spend but still need hosting and upkeep.	Written license terms for each tool, the hosting and support model, and what the vendor charges for updates.
Evidence upkeep	Internal staff or a retained partner. Recurring, tied to each procurement and each review cycle.	Frequency of procurements, the number of vendors whose records must be kept, and whether evidence is collected automatically or by hand.	A description of the evidence set per procurement, retention periods, and the reporting schedule.
External review	Independent consultant or reviewer. Optional, usually one-time before a first audit and after major plan changes.	Plan complexity, internal review capacity, and how far the review extends into vendor contracts.	Scope limits in writing, including whether the reviewer tests the plan only or also sample procurements.
Auditor sampling	The Compliance Enforcement Authority or its auditors, funded through the entity's compliance program. Recurring by audit cycle.	Number of procurements in the audit period, quality of records, and how quickly evidence can be produced.	Not a vendor quote. Ask your Regional Entity which evidence it will request and how far back the audit period reaches.

In-house, implementation partner or auditor: who owns each part of R1

The registered entity is accountable for CIP-013-2 R1. Its team writes the supply chain cyber security risk management plan, decides which vendor risks are acceptable, and obtains the approvals the plan needs. Procurement, legal and the security function usually negotiate vendor terms, because the entity, not a partner, is the party that signs contracts and accepts residual risk. Nobody outside the organization can make these decisions for it, and an auditor will ask who made them and on what basis.

Plan ownership: The organization writes and maintains the plan, including how procurement planning identifies vendor risk under Part 1.1.
Risk decisions: Staff decide which vendors, products and transitions are assessed and which risks are accepted, mitigated or escalated.
Contract terms: Procurement and legal negotiate the notification, access revocation, vulnerability disclosure, software integrity and remote access language that Part 1.2 calls for.
Approvals: The CIP Senior Manager or delegate approves the plan and its reviews, and the organization keeps those records.
Vendor relationships: Staff own the ongoing contact with vendors that will later report incidents and vulnerabilities.

Ask your team which named individuals hold each of these roles and where the approval record is kept.

Gaps that cause R1 findings and how to close them

Most CIP-013-2 R1 findings trace back to a plan that reads well on paper but has no procurement behavior, approval history or operational link behind it. The cards below cover the gaps auditors most often test for and the fix for each.

Topics listed without procurement terms

The plan names the six Part 1.2 topics but the procurement templates, security addenda and purchase checklists never ask for them. Auditors look for the topic appearing in the actual buying process, not only in the plan narrative. Check each topic against a recent purchase order or contract and confirm the clause or checklist item that carries it. Where a topic does not apply to a product, record why it does not.

No risk process for vendor transitions

Part 1.1 covers risks from vendor transitions, such as moving a substation system to a new vendor or handing support to a successor, yet many plans only assess risk at initial purchase. Define who reviews a transition, what they examine (access handover, software ownership, unsupported components) and where the review is recorded. Confirm that the process runs when a vendor is replaced, not only when a new product is bought.

Plan versions with no approval record

Plan revisions often change in a shared drive with no dated approval by the CIP Senior Manager or delegate. Without that record, an auditor cannot tell which plan governed a given procurement. Keep each version under version control with the date, author and approver, and tie each procurement record to the plan version in force at the time. Confirm that the approval step is evidence, not just a signature on the cover page.

No link to CIP-010-4 and CIP-005-7 checks

The plan promises software integrity verification and coordinated vendor remote access, but the operational teams running CIP-010-4 and CIP-005-7 may not know those procurement promises exist. Map each Part 1.2 topic to the operational control that checks it, such as software integrity verification under CIP-010-4 and vendor remote access under CIP-005-7. Confirm the owner of each check and where its output is kept.

Vendor software inventory missing

A plan that requires verification of software integrity is hard to evidence when the entity cannot list which vendor components are in its BES Cyber Systems and their EACMS and PACS. Maintain a current inventory of vendor products, versions and sources, ideally as a software bill of materials. Confirm that the inventory covers the systems in scope for the plan, and that procurement adds new components to it before installation.

Questions buyers ask about the CIP-013-2 R1 plan

How much effort does a CIP-013-2 R1 supply chain plan take to write?

The effort depends mainly on how many vendors and procurement paths the organization uses for high and medium impact BES Cyber Systems and their associated EACMS and PACS. A plan for a small set of OEMs and one managed service provider is far narrower than one covering software publishers, cloud services, integrators and contractors. Effort rises with the number of procurement processes that must be described, the number of existing contracts that must be reviewed for the six Part 1.2 topics, and how much current procurement practice has to be documented before it can be assessed. Ask any partner to break the estimate into inventory, process mapping, drafting and stakeholder review, and to state which of those are one-time and which recur at each 15-month review.

What drives the timeline for writing the plan, and what should I confirm first?

No researched duration applies here, so the timeline should come from a written scope and from your own environment. The main drivers are the size of the in-scope asset inventory, whether procurement already has documented steps, how many approvers must sign off, and how quickly legal and purchasing can agree on standard vendor language. Confirm which BES Cyber Systems are high or medium impact under CIP-002-5.1a, which vendors touch them, and who holds the CIP Senior Manager delegation before agreeing dates. Any partner should commit to milestones in writing before work begins.

What does the plan need from our own staff?

The plan needs people who know the procurement process and the operational systems. Expect to involve procurement or contracting staff, the CIP compliance lead, operations and engineering owners of the in-scope systems, security staff who handle vendor remote access, and whoever holds the CIP Senior Manager role or its delegation. Procurement staff explain how purchases really happen, operations staff explain how vendors connect and patch, and the CIP lead decides which controls become mandatory. Your organization must own the final decisions, approvals and any contract changes, because those cannot be delegated to an outside party.

Can a small compliance team write the CIP-013-2 R1 plan alone?

A small team can write the document alone if it has access to procurement records, the in-scope asset list and engineers who understand remote access and patching. The harder part is not drafting but deciding how each of the six Part 1.2 topics applies to each vendor type, and that usually needs input from purchasing and operations. Teams without procurement experience often miss contract clauses that make vendor incident notification or access revocation notice enforceable. Teams that do write it alone should still test the plan against two or three real procurements before the review and approval step under CIP-013-2 R3.

What does an implementation partner do for the plan, and what does it not do?

A partner can inventory in-scope systems and vendors, map existing procurement and remote access controls to the topics named in CIP-013-2 R1, draft the plan and procedures, and prepare the evidence trail that shows how the plan was built and reviewed. It can also set up supporting tooling, such as an SBOM and vulnerability tracking workflow for software integrity, and document the plan in a version-controlled wiki. It does not own your controls, negotiate vendor contracts for you, decide the plan's final approval, or issue any audit finding. Compliance is assessed by the Regional Entity or NERC, so no partner can certify conformance.

Who can issue an official finding that the plan meets CIP-013-2?

Only the Compliance Enforcement Authority, which is a Regional Entity or NERC, makes compliance determinations for CIP standards. Compliance is monitored through Compliance Audits, Spot Checks, Self-Certifications, Self-Reports and other mechanisms, and there is no CIP certificate that a consultant or auditor can issue. An implementation partner can help you prepare for those engagements, but its work product is not a finding. Your registered entity remains responsible for the outcome. Ask any firm to confirm in writing that it will not represent its own work as a compliance determination.

How does the plan change after a vendor transition?

CIP-013-2 R1 requires the plan to address risks from transitions between vendors, so a change of vendor should trigger a documented review of the affected procurement steps. Typical changes include updating vendor notification contacts, reassessing software integrity verification for the new supplier's products, confirming how remote access is revoked from the outgoing vendor, and recording the transition decision in the plan's change history. Keep that history in version control so reviewers can see what changed and when. Ask your team to define which transitions count as material before a vendor change arrives, because that decision drives how much rework follows.

How DeployOpen works on this

DeployOpen plans and prepares the systems, procurement records and evidence that a CIP-013-2 R1 plan depends on, inside the registered entity's own infrastructure. The entity owns its supply chain plan and its approval, and an independent auditor or Regional Entity decides whether the evidence meets the standard.

How we scope

Engagements are fixed-scope, with the systems, vendors and procurement processes covered agreed in writing before work starts.
We confirm which BES Cyber Systems, EACMS and PACS fall under high or medium impact categorization, since that sets which procurements the plan must cover.
The written scope names each Part 1.2 vendor topic and the operational tools that will hold the resulting evidence, so gaps are visible before build work begins.

How we build

We help document procurement planning steps that identify vendor risk, including vendor product, installation and vendor transition risks under Part 1.1.
We set up tooling that tracks vendor-disclosed vulnerabilities and software bills of materials, such as Dependency-Track, against the procurement records the plan requires.
We align vendor remote access coordination and software integrity checks with the operational controls in CIP-005-7 and CIP-010-4 so evidence from both sides matches.

How we hand over

Deliverables include the plan documentation, procurement checklists and evidence mapping, stored in version-controlled wiki pages that record changes, dates and authors.
We walk the entity's compliance and procurement staff through each Part 1.2 control so they can run the process after handover without us.
Handover records state which items remain the entity's responsibility, including plan approval, vendor negotiations and the final compliance judgment.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing separately from the initial engagement.
Before any assessment, we can help prepare the evidence package for the Regional Entity's review, while confirming current audit timing with the entity's compliance team.
Ask us to confirm which tool capabilities, licenses and editions apply to your environment before you rely on them for CIP-013 evidence.