ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
CIP-013 supply chain risk management splits into two obligations that are easy to conflate and are audited separately: having a plan, and implementing it. R1 is the plan. R2 is the evidence that you applied it to actual procurements. An entity with an excellent plan and no procurement records passes the first and fails the second.
There is a second split inside R1 that causes more trouble still, and it is the reason most CIP-013 supply chain programmes have a hole in exactly one place.
R1 has two parts. Part 1.1 covers the processes used in planning for procurement. Part 1.2 covers the processes used in procuring.
The intuitive reading is that supply chain risk management is a contract review. That reading satisfies 1.2 and leaves 1.1 entirely unmet — because by the time there is a contract to review, the planning stage has already passed.
R1.1 attaches when you are deciding what to buy, how it will be connected, what access the supplier will need and how it will be maintained. You may not yet know who the vendor is. That is what makes the obligation awkward, and it is why it gets skipped: there is no obvious document to attach it to.
Attach it to the specification. Whatever internal artefact records “we are going to buy a new X” is the trigger for the assessment.
The frame R1.1 uses is risk to the Bulk Electric System — the reliability consequence — not risk to your IT estate.
| Question at planning stage | Why it belongs there |
|---|---|
| What reliability task will this support? | Determines the consequence of failure |
| What access will the supplier need, and will it be persistent? | Far cheaper to constrain before purchase |
| How will software and firmware be delivered and verified? | Feeds R1.2.5 and your CIP-010 obligations |
| What happens when support ends? | Sets the support-life expectation while you still have leverage |
| Will this introduce a new remote access path? | Feeds CIP-005 vendor remote access |
The third and fifth rows are where CIP-013 supply chain work pays for itself. A software integrity verification method and a remote access arrangement are dramatically cheaper to require before purchase than to retrofit afterwards.
R1.2 enumerates six matters the procurement process must address. All six, not most.
Vendor incident notification — the vendor tells you about incidents it identifies relating to what it supplies. Coordinated response — you agree in advance who leads, what is shared and what may be disclosed publicly. Notice when access should end — the vendor tells you when one of its people should no longer have access.
Vulnerability disclosure — the vendor discloses known vulnerabilities in the products and services it provides, including in third-party components it incorporates. Software integrity and authenticity — verification of software and patches. Coordination of vendor-initiated remote access — controls for access the vendor starts.
A plan covering five of the six has a gap that is invisible unless you enumerate them as a checklist.
The vendor-personnel-departure notification is the term that fails without anyone noticing. A vendor engineer leaves, the vendor does not think to tell you, and their access to your systems persists indefinitely — because your own leaver process never sees them.
That is a genuine access exposure and it is also a CIP-004 problem you cannot detect from your own records. Do not rely on the contractual term alone. Reconcile vendor access against the vendor’s current personnel periodically, alongside your quarterly access verification. Asking a vendor to confirm its current list is a five-minute email that closes a real gap.
This is the most misread part of CIP-013 supply chain compliance. The requirement is that your procurement process addresses these matters. It is not that you obtain every term from every vendor.
A vendor may refuse. What is not acceptable is failing to ask, or asking and not recording the outcome.
Record the term sought, the vendor’s position, the risk decision, who took it and when. A procurement where three terms were sought and one obtained is evidenced implementation of your plan. A procurement with no record is not — and programmes that over-read the requirement often stop recording refusals altogether, which is worse than the refusals.
R2 needs one row per procurement, not one row per plan. For each acquisition of BES Cyber Systems and their associated EACMS and PACS: which plan processes were applied, the risk assessment reference, the terms sought, the terms obtained, and the decision on anything not obtained.
Include renewals and material extensions. A renewal is a procurement for this purpose, and it is frequently the only realistic opportunity in a decade to change the terms — so treat renewal dates as planning triggers rather than administrative events.
R3 requires the plan to be reviewed and approved by the CIP Senior Manager or delegate at least once every 15 calendar months. Review and approval are two events with two dates; a review with no approval does not satisfy it.
Where a delegate approves, the delegation must have been recorded, in force on that date, and must have covered this specific action. This fails invisibly: the plan is approved on time by a manager whose delegation had lapsed or never named CIP-013 approval, so R3 is unmet despite the date being right. Check the signatory against the delegation register at every approval and record the check.
Make the review examine something. Whether all six R1.2 elements are still addressed. Which terms are consistently refused, and whether the position should change. And — most valuable — whether the planning-stage assessment is actually being run, or whether procurements are reaching contract stage without it. That last question is the only place R1.1 neglect surfaces.
The obligation is narrower than it first appears, and scoping it correctly saves real work.
It reaches procurement of BES Cyber Systems and their associated EACMS and PACS at high and medium impact. It does not reach every purchase you make. A new laptop for the finance team is not in scope; a replacement relay is. Record the scoping decision per procurement so that an excluded purchase is excluded on a recorded basis rather than by silence.
For many entities that is a small number of procurements a year, and a small number is a manageable number to evidence properly. That matters because R2 asks for evidence of implementation, and there is no way to evidence a procurement nobody documented — a CIP-013 supply chain programme is more exposed by missing records than by weak terms.
Two practical habits carry it. Give one person the job of spotting in-scope procurements early, because the planning-stage assessment is worthless once the specification is frozen. And keep the terms schedule as a living document rather than boilerplate — if the same clause has been refused by every vendor for three years, that is information, and the answer is either different drafting or a recorded accepted position, not a fourth refusal.
The software integrity term exists because CIP-010 R1.6 requires you to verify software source identity and integrity when the method is available from the source. If the vendor publishes nothing, your CIP-010 obligation is bounded but your exposure is not. The fix is here, at procurement — ask for published hashes, code signing and a named channel.
Vendor vulnerability disclosures start your CIP-007 R2 evaluation clock if a patch accompanies them, so route them promptly. And where a vendor’s own transient assets connect to your systems, the commitment to present a scanned, dated laptop belongs in the same schedule.
Read R1.2 directly before drafting; the NERC Reliability Standards are published free and the six sub-parts are a short read.
For the wider picture, the thirteen enforceable standards show where CIP-013 sits, patch management covers the clock that vendor disclosures start, and the compliance guide covers the evidence discipline.
Our NERC CIP Toolkit includes the supply chain plan, a vendor risk assessment procedure for the planning stage, a procurement terms schedule and an implementation evidence register keyed to R2.
It attaches to procurement, so it does not require existing contracts to be reopened. A renewal or material extension is a procurement, and that is usually where terms can actually change.
Record the term sought, the refusal, the risk decision and who took it. The requirement is that the process addresses these matters, not that every term is obtained.
No. It reaches high and medium impact BES Cyber Systems and their associated EACMS and PACS. Low impact has its own, narrower vendor obligation under CIP-003.
The CIP Senior Manager or a delegate, at least once every 15 calendar months. If a delegate signs, confirm the delegation covered that action and was in force on the date.
September 3, 2026
September 3, 2026
September 3, 2026
September 3, 2026
September 3, 2026