ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
NERC CIP compliance is not a state you reach and hold. It is a body of evidence you can produce, on demand, covering every day of an audit period that may stretch back three years. That distinction is the whole subject, and it is where most programmes coming from a voluntary framework go wrong.
You can operate every control impeccably and still fail. If the records do not exist for the period, the control might as well not have run.
A registered entity is monitored by its Regional Entity — the organisation NERC delegates enforcement to for the region in which you operate. Monitoring takes several forms: a scheduled audit, a spot check, a periodic self-certification, or an investigation following an event.
In each case the instrument is the same. Compliance is assessed against a Reliability Standard Audit Worksheet, one per standard. The RSAW walks through the requirement parts in order and asks two questions about each: what did you do, and what proves it.
So NERC CIP compliance has two halves that are easy to conflate. Performing the control is the first. Being able to demonstrate you performed it, throughout, is the second — and it is the half that fails.
Almost every finding reduces to one of three things.
Evidence covers the period, not the moment. A quarterly control needs evidence for every quarter in the audit window. A programme that has run beautifully for six months and patchily for the eighteen before that will be sampled in the early part of the window, because that is where the risk is.
Dates are computed, not asserted. Where a requirement says “at least once every 15 calendar months”, record both the previous date and the date by which the next occurrence must happen. Calendar months, calendar days and calendar quarters are not interchangeable and are not rounded.
Evidence names its source. A record with no document reference, version and date cannot be produced as evidence of a controlled process. It shows something happened; it does not show a process governed it.
Two independent things set your obligation, and getting either wrong invalidates everything downstream.
The first is registration. Your registered functions determine which requirements reach you at all — Transmission Owner is in scope for all 46 requirements across the enforceable set, while an Interchange Authority is in scope for 13. The second is impact rating, decided by CIP-002, which sorts your BES Cyber Systems into high, medium and low.
Get this right before designing anything. Over-scoping is not caution: every control you adopt beyond your obligation becomes evidence a Regional Entity can ask for, and which you must then produce for the whole period. An entity with only low-impact systems that adopts the high-impact control set has manufactured an evidence burden it will fail to carry.
They read your narrative first. The narrative frames how everything after it is read, so a narrative that overstates produces findings the evidence alone would not have produced.
Then they sample. Sampling is across the audit period, chosen by the auditor rather than offered by you, and weighted toward the parts most likely to fail — interval-based controls, and anything where an approval or a delegation is involved.
Three checks are worth running on yourself before they do. Sample your own approvals and confirm the signatory either held the CIP Senior Manager role on that date or held a delegation in force covering that specific action. Confirm every Technical Feasibility Exception you rely on is approved and unexpired. And test your applicability decisions — the rows you marked “does not apply” are the first thing examined, and one with no recorded reason is the weakest position in the programme.
Periodically you will be asked to certify your own NERC CIP compliance in writing. Treat that as the formal representation it is, and work from the evidence register rather than from the absence of complaints. Certifying on the basis that nobody has reported a problem is how an entity certifies a gap it already had the means to find.
Where you find non-compliance yourself, self-reporting is available and the promptness and quality of your mitigation matter. Two practical points. Separate the immediate correction — restoring the control — from the mitigation that stops it recurring; a plan whose only action is “the control has been performed” is a correction wearing the wrong label. And answer the extent-of-condition question explicitly: where else could this same failure exist? An unanswered extent-of-condition question is the commonest reason one finding becomes several.
Do not hold mitigation while deciding whether to report. The two run in parallel, and a mitigation already under way is what makes the conversation manageable.
| Failure | Why it happens | What fixes it |
|---|---|---|
| A calendar quarter with no record | “Quarterly” read as “every 90 days” | Track by quarter, not by gap |
| Backup verified only by the job log | A successful job is read as verification | Restore or read the archive, and record the method |
| Approval signed under a lapsed delegation | Nobody checks signatory against register | Sample approvals at each internal audit |
| Access revoked on the wrong clock | One interval applied to all revocation parts | Drive each part from its own trigger |
| Evidence deleted on a retention schedule | Automated policy set to the minimum | Confirm the audit period before destruction |
The last row is the only one that cannot be remediated. Once the records are gone, you cannot evidence a control you genuinely operated.
A surprising share of the obligation is recurring, and recurring work is what quietly lapses. Building the calendar early — and computing each next-due date from the last occurrence rather than from a fixed anniversary — removes a whole class of finding.
Some cycles are short. Security awareness reinforcement runs each calendar quarter under CIP-004. Access held is verified against access authorised each quarter too, and that is a comparison rather than a listing: a report of who has access, with nothing to compare it against, is not a verification. Configuration monitoring runs at least once every 35 calendar days, and patch evaluation on its own 35-day clock.
Others are long enough that nothing in the operating rhythm reminds you. The cyber security policy review, the categorization review, the supply chain plan review, incident response plan testing and recovery plan testing all run at least once every 15 calendar months. A fifteen-month cycle drifts against the calendar, which is exactly why it gets missed — there is no annual ritual to attach it to.
Longer still, personnel risk assessments renew on a seven-year cycle, and physical access control system testing runs on an interval measured in calendar months rather than weeks. Neither will be prompted by anything except a tracked due date.
Treat the calendar as a control in its own right, with an owner. Most NERC CIP compliance programmes that fail an audit did not fail because a control was absent; they failed because an occurrence of a control was late, and nobody was watching the date.
Run it as one programme rather than thirteen projects. Give every requirement and part a named accountable owner, so nothing is orphaned and no auditor question lands on nobody. Maintain the evidence register continuously rather than assembling it under deadline — the RSAW response is then largely an export of it.
Run internal audits the way the Regional Entity will: sample across the period, compute intervals rather than accepting descriptions, and test the negative cases. A programme that finds nothing across a full cycle is not a clean programme; it is one whose audits are not testing anything.
Read the source material directly — the NERC Reliability Standards are published free, so there is no barrier to checking exactly what a requirement part says before you design a control around it.
When an audit is scheduled, the audit preparation guide covers the RSAW narrative and the checks worth running on yourself first. CIP-002 categorization is where an auditor starts, because everything else inherits its scope.
Start from the thirteen enforceable standards to see the shape of the obligation. Set against IEC 62443, the differences are mostly about enforcement rather than controls. If you are securing industrial systems outside this jurisdiction, the IEC 62443 series is the international equivalent, and the Purdue model is the shared vocabulary for describing where those systems sit.
Our NERC CIP Toolkit ships the documented processes and an evidence register pre-loaded with all 46 requirements and 210 requirement parts, so the gap between what you do and what you can prove is visible on day one.
It covers the window the Regional Entity specifies, which commonly spans several years. Your evidence and your superseded document versions both need to reach back across it.
No. NERC CIP compliance is evidence produced by controls you actually operate. Templates give you the documented processes and the evidence structure; running them is what produces the proof.
Yes. If you cannot evidence it for the period, it is treated as a possible violation. That is the single most important difference from a voluntary framework.
The CIP Senior Manager, on the compliance manager’s assessment. Record the decision and its reasoning either way, and keep mitigating while it is being made.
September 3, 2026
September 3, 2026
September 3, 2026
September 3, 2026
September 3, 2026