NERC CIP-013-2 (Cyber Security — Supply Chain Risk Management), explained

NERC CIP-013-2, "Cyber Security – Supply Chain Risk Management," is a mandatory, FERC-approved Reliability Standard requiring North American bulk power system operators to build — and keep current — a documented plan for managing cybersecurity risk in how they buy and deploy vendor hardware, software and services. Per its own Purpose statement, the standard exists "to mitigate cyber security risks to the reliable operation of the Bulk Electric System (BES) by implementing security controls for supply chain risk management of BES Cyber Systems." It is issued by the North American Electric Reliability Corporation (NERC), the Federal Energy Regulatory Commission (FERC)-certified Electric Reliability Organization for the United States, and is enforced across the US, Canada, and part of Baja California, Mexico.

Who has to comply, and for which systems

CIP-013-2's Applicability section names a specific list of "Responsible Entities": Balancing Authorities, certain Distribution Providers (those owning specific load-shedding, Remedial Action Scheme or transmission Protection System facilities), Generator Operators, Generator Owners, Reliability Coordinators, Transmission Operators and Transmission Owners. The requirements apply to each entity's high- and medium-impact BES Cyber Systems and their associated Electronic Access Control or Monitoring Systems (EACMS) and Physical Access Control Systems (PACS) — EACMS and PACS were added in this version 2 revision; the original CIP-013-1 covered BES Cyber Systems alone.

Five categories are explicitly exempt, per the standard's own text: Cyber Assets at facilities regulated by the Canadian Nuclear Safety Commission; Cyber Assets tied to communication links between discrete Electronic Security Perimeters; systems regulated by the US Nuclear Regulatory Commission under a cyber security plan per 10 C.F.R. § 73.54; for Distribution Providers, any systems/equipment outside the specific facilities listed in the Applicability section; and any Responsible Entity that has no BES Cyber Systems categorized as high or medium impact under CIP-002.

Requirement R1: the six-part supply chain plan

Requirement R1 requires each Responsible Entity to "develop one or more documented supply chain cyber security risk management plan(s)," built from two parts:

• Part 1.1 — process(es) for planning the procurement of BES Cyber Systems (and associated EACMS/PACS) that identify and assess cyber security risk from vendor products or services, covering both "procuring and installing vendor equipment and software" and "transitions from one vendor(s) to another vendor(s)."
• Part 1.2 — procurement process(es) addressing, verbatim from the standard, six concepts:

Part	Security concept (verbatim)
1.2.1	Notification by the vendor of vendor-identified incidents related to the products or services provided that pose cyber security risk
1.2.2	Coordination of responses to vendor-identified incidents that pose cyber security risk
1.2.3	Notification by vendors when remote or onsite access should no longer be granted to vendor representatives
1.2.4	Disclosure by vendors of known vulnerabilities related to the products or services provided
1.2.5	Verification of software integrity and authenticity of all software and patches provided by the vendor
1.2.6	Coordination of controls for vendor-initiated remote access

FERC's Order No. 850 ties these six sub-parts directly to the four security objectives it originally set in Order No. 829: software integrity and authenticity (1.2.5), vendor remote access (1.2.3, 1.2.6), information system planning (Part 1.1), and vendor risk management/procurement controls (1.2.1, 1.2.2, 1.2.4).

Requirement R2: implementing the plan, without rewriting existing contracts

Requirement R2 requires that each Responsible Entity "implement its supply chain cyber security risk management plan(s) specified in Requirement R1." The standard's own Note to R2 narrows what that means in practice: "Implementation of the plan does not require the Responsible Entity to renegotiate or abrogate existing contracts (including amendments to master agreements and purchase orders)." It further excludes two things from R2's scope entirely: "(1) the actual terms and conditions of a procurement contract; and (2) vendor performance and adherence to a contract." FERC's Order No. 850 reinforces this: the standard is "forward-looking," applying to new procurement activity rather than retroactively to contracts already in place, and vendors themselves are not directly subject to the Reliability Standard — "any resulting obligation that a supplier, vendor or other entity accepts... is a contractual matter... outside the scope" of CIP-013-2.

Requirement R3: review cadence and violation severity

Requirement R3 requires the plan to be reviewed and approved by the Responsible Entity's CIP Senior Manager or a delegate "at least once every 15 calendar months." The standard's Violation Severity Level table escalates the penalty the longer that review slips past 15 months:

Time since last review	Violation Severity Level
15-16 months	Lower
16-17 months	Moderate
17-18 months	High
Beyond 18 months	Severe

Evidence for every requirement — the plan itself, implementation records such as correspondence or working documents, and the dated, CIP Senior Manager-approved review history — must be retained for three calendar years, per the standard's Compliance section.

Where CIP-013 came from, and why there's a "-2"

In July 2016, FERC issued Order No. 829 (Docket RM17-13-000), directing NERC to develop "a forward-looking, objective-driven Reliability Standard" covering supply chain risk management for industrial control system hardware, software and services tied to BES operations — while explicitly stating NERC "need not impose any specific controls or 'one-size-fits-all' requirements," and that any resulting standard should address only Responsible Entities' obligations, not impose requirements directly on vendors. NERC's Board of Trustees approved the resulting Reliability Standard, CIP-013-1, on 10 August 2017; FERC approved it — together with companion standards CIP-005-6 (electronic security perimeters) and CIP-010-3 (configuration change management) — via Order No. 850 on 18 October 2018.

That same Order No. 850 identified a gap FERC was not willing to leave unaddressed: CIP-013-1 excluded EACMS (Electronic Access Control or Monitoring Systems — firewalls, authentication servers, security event monitoring and intrusion detection systems, among others) from its scope entirely. FERC's reasoning, stated directly in the order, was that "EACMS represent the most likely route an attacker would take to access a BES Cyber System or PCA within an ESP" — an attacker does not need physical access to compromise an EACMS the way they would to compromise a Physical Access Control System. FERC directed NERC to close that gap within 24 months. NERC's Board approved the revised standard, CIP-013-2 — adding EACMS (and, in a parallel change to CIP-005-6, Protected Cyber Assets) to scope — on 5 November 2020, and FERC approved CIP-013-2 on 18 March 2021 (Docket RD21-2-000). FERC left Physical Access Control Systems (PACS) and Protected Cyber Assets largely for further study at the time, on the reasoning that compromising those assets typically also requires physical access, making them a lower-urgency gap than EACMS.

How it relates to broader supply chain risk guidance

CIP-013-2 is a mandatory, enforceable reliability standard specific to the North American bulk power system — distinct from voluntary frameworks like NIST SP 800-161 (cybersecurity supply chain risk management, C-SCRM) that cover supply chain risk more generally across sectors. A Responsible Entity's CIP-013-2 plan and a broader C-SCRM program built on NIST SP 800-161 address overlapping ground — vendor vulnerability disclosure, software integrity verification, vendor access control — but only CIP-013-2 carries FERC-backed mandatory compliance and the violation severity levels described above for BES Cyber Systems specifically.

A workable starting point

1. Scope the plan to the right asset classes first. High- and medium-impact BES Cyber Systems plus their associated EACMS and PACS — confirm your CIP-002 impact categorization is current before drafting R1 processes, since the plan's boundary depends entirely on it.
2. Build R1.2's six sub-parts as separate, checkable processes, not one paragraph of intent — an auditor assessing R1 will look for each of 1.2.1 through 1.2.6 individually, and the Violation Severity Levels specifically penalize missing one or more than one sub-part.
3. Don't try to retrofit existing contracts. R2's own Note confirms the standard doesn't require renegotiating or abrogating contracts signed before the plan's effective date — focus R1/R2 effort on new and renewing procurement activity instead.
4. Put the 15-month CIP Senior Manager review on a calendar with margin, not a 15-month countdown — the Violation Severity Level table starts counting at month 15, so a plan reviewed "on time" with no buffer has no slack if the approval gets delayed.
5. Track vendor-side commitments (1.2.1-1.2.6) as contract language, not just internal process. Since CIP-013-2 cannot bind vendors directly, the practical mechanism for getting incident notification, vulnerability disclosure and remote-access coordination from a vendor is contract language your procurement process negotiates in — the Reliability Standard sets what your process must address, not what the vendor must do.

SoftWSP's OT Snapshot and firmware security assessments give Responsible Entities evidence — a passive asset inventory and firmware/vendor vulnerability mapping — that supports the risk identification Parts 1.1 and 1.2.4 of a CIP-013-2 plan call for, without requiring agent installation on live BES Cyber Systems: see OT Snapshot.

This guide quotes NERC's own published text of Reliability Standard CIP-013-2 (Purpose, Applicability, Requirements R1-R3, Violation Severity Levels, Compliance and Version History sections) and FERC Order No. 850 (165 FERC ¶ 61,020); it is not a substitute for the full standard and its associated Implementation Plan and Technical Rationale documents, and does not constitute compliance or legal advice.