ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
NERC CIP patch management is governed by CIP-007-6 Requirement R2, and it contains a trap that catches well-run programmes: there are two separate 35-calendar-day clocks in that requirement, and they start from different events. A single “patch within 35 days” rule satisfies neither of them cleanly.
That is the whole difficulty. Everything else about NERC CIP patch management is ordinary operational work; the intervals are where the findings come from.
| Clock | Runs from | Ends at | Interval |
|---|---|---|---|
| Evaluation (R2.2) | The patch becoming available at the source named under R2.1 | Your applicability evaluation being complete | 35 calendar days |
| Action (R2.3) | That evaluation completing | Installation, or a dated mitigation plan | 35 calendar days |
| Plan delivery (R2.4) | — | Within the timeframe the plan itself specifies | Set by you |
Read that carefully. An unevaluated patch is a missed evaluation regardless of whether it was eventually installed. So a programme that installs everything promptly but never records an evaluation has failed R2.2 while passing R2.3 — and it will not know until someone asks for the evaluation records.
Track them in separate columns, each with its own trigger date and its own computed due date. Merging them into one field is how the distinction quietly disappears.
R2.1 requires a source, per applicable Cyber Asset, for tracking security patches. A system with no source identified fails this part however well it is actually patched.
The awkward cases are the ones that matter in an operational estate. Embedded devices whose vendor publishes nothing. Software from a supplier that has since been acquired. Systems where an integrator rather than the manufacturer supplies patches. Record the source anyway — “the integrator under contract reference X, who notifies by email” is a source — and record how you monitor it.
Where a source genuinely does not exist, record that determination with a date and say what you do instead. That is a defensible position. A blank cell is not.
The evaluation determines applicability. There are three legitimate outcomes and all three need a date.
The patch is applicable and will be installed. The patch is applicable and will be mitigated under a dated plan. Or the patch is not applicable, with a reason — the component is not installed, the feature is not enabled, the vulnerability does not reach this configuration.
“Not applicable” without a reason is the weakest row in a NERC CIP patch management register, and it is the row an auditor samples. Write the reason at the time; reconstructing it a year later is guesswork wearing a confident tone.
Patching an operational system often needs an outage window that is months away. That is exactly what the mitigation plan route exists for, and using it is not a failure.
But understand what you are signing. R2.4 measures you against the timeframe in your own plan. A plan that says ninety days creates a ninety-day obligation that did not otherwise exist. A plan whose date passes with neither installation nor an approved revision is a violation your own document manufactured.
So set achievable dates. A realistic twelve-month plan with a stated interim mitigation is a far stronger position than an optimistic sixty-day plan that slips twice. And make the mitigation a real control specific to the vulnerability — “the system is inside an Electronic Security Perimeter” is true of every applicable system and mitigates nothing in particular.
Revisions are decisions. Record the original date, the new date, the reason and the approver. Three undated revisions read as drift; the same three with vendor correspondence attached read as management.
Patching is not self-contained, and the links are where cross-standard findings appear.
Installing a patch changes the baseline, so CIP-010 R1.3 requires the baseline configuration to be updated within 30 calendar days of the change. A programme that patches diligently and updates baselines late has converted a CIP-007 success into a CIP-010 finding.
Vulnerability assessments under CIP-010 R3 will surface missing patches you are already tracking. Link the two records rather than opening a parallel track that drifts. And where a vendor discloses a vulnerability under your CIP-013 supply chain terms, that disclosure starts the R2.2 evaluation clock if a patch accompanies it — the clock runs from availability at the source, not from when someone read the email.
Four things, per patch and per system: the source, the availability date, the evaluation date and outcome, and either the installation date or the mitigation plan reference.
They will sample across the whole audit period, weighted toward the early part, because that is where a programme that has since tightened up is weakest. Before an audit, run the arithmetic yourself — take every patch in the period, compute both due dates, and find the ones that slipped. Self-identifying a miss with a mitigation already under way is a materially different conversation from having it found for you.
Read the requirement directly rather than working from a summary; the NERC Reliability Standards are published free, and R2 is a page long.
The register is the control. Design it so the dates are computed rather than typed, and most of this standard looks after itself.
One sheet holds sources: the system, the software or firmware on it, the named source, how that source is monitored, and the date the source was last confirmed. Confirm sources annually — vendors get acquired, notification lists lapse, and a source recorded in 2023 may no longer reach anyone.
A second sheet holds evaluations, one row per patch per system. Availability date, evaluation due date computed at availability plus 35 calendar days, evaluation completed date, applicability decision, the reason where the decision is “not applicable”, then the action due date computed from the evaluation and either an installation date or a mitigation plan reference.
Two columns repay themselves. A computed days-elapsed field for each clock, so a slip is visible without arithmetic. And a flag for patches whose mitigation plan date is inside the next thirty days, reviewed monthly — the plan that fails is almost always the one nobody looked at between writing it and its expiry.
Where a NERC CIP patch management programme covers hundreds of assets, sample your own register quarterly rather than waiting for the internal audit. Take ten rows, recompute both dates by hand, and confirm the register agrees. A register that computes its own dates wrongly is worse than none, because everybody trusts it.
The recurring ones are all arithmetic rather than engineering.
One more is worth naming because it is invisible until an audit. A patch is evaluated as not applicable, correctly, on the grounds that the affected component is not installed — and then eighteen months later that component is installed as part of an unrelated change, and nobody revisits the earlier decision. The register still says not applicable, the system is now exposed, and the record is wrong rather than merely stale. Tie the change process to the patch register so that adding software triggers a re-look at any patch previously excluded on the grounds that it was absent.
A single 35-day rule covering both clocks. Evaluations performed but not recorded. A patch source column left blank for embedded devices because the vendor publishes nothing. Mitigation plans with dates nobody tracks after the day they were written. Baselines updated eventually rather than within thirty days. And “not applicable” decisions with no stated reason.
None of these is a security failure. All of them are findings, and all of them are avoidable with a register that computes dates rather than storing them.
If you are running the same problem outside the North American bulk electric system, OT patch management under IEC 62443 covers the international equivalent, which uses a risk-based cycle rather than fixed calendar-day clocks.
Within CIP, start from the thirteen enforceable standards to see where CIP-007 sits, and the compliance guide for the evidence discipline that applies across all of them.
Our NERC CIP Toolkit includes the patch management procedure, a source and evaluation register with the two clocks in separate columns, and a mitigation plan template that tracks its own date.
Yes, but from different triggers. R2.2 runs from the patch becoming available at its source to your evaluation; R2.3 runs from that evaluation to installation or a dated mitigation plan.
You still need a named source under R2.1. Record the integrator, the notification route or the determination that no source exists, with a date, and say what you do instead.
Yes. R2.3 requires a dated plan, and R2.4 measures you against the date in it. Choose a date you can meet, and record any revision with its reason and approver.
No. Installation or a dated mitigation plan both satisfy R2.3. The route matters less than recording which one you chose and when.
September 3, 2026
September 3, 2026
September 3, 2026
September 3, 2026
September 3, 2026