CIP-007 R2 Patch Management and the 35-Day Window for Utilities

For electric utilities, the 35-day clock in NERC CIP-007 R2 is where good intentions go to die at audit. Z Cyber runs CIP-007 patch management as an operating partner, standing up the process, the cadence, and the evidence inside our Glance platform so the 35-day windows close on time and every decision is documented before an auditor ever asks.

Why CIP-007 R2 is the requirement auditors love

NERC CIP-007-6 Requirement R2 governs security patch management, and it is one of the most consistently cited requirements in CIP audits and self-reports. The reason is structural. R2 is not a posture statement. It is a recurring, date-driven obligation with two stacked deadlines, and it applies to a large population of devices that often live in environments built for availability, not for monthly patching. That combination produces a steady stream of missed windows, thin documentation, and incomplete mitigation plans.

Z Cyber approaches CIP-007 R2 the way a responsible entity should: as an operating program rather than a once-a-quarter scramble. We act as your forward-deployed security team. We define the patch management process, identify your patch sources, run the 35-day evaluation and action cadence, and capture the evidence in Glance so the record is complete and contemporaneous. The goal is not to pass a single audit. It is to make the program durable enough that any audit window looks the same.

What Requirement R2 actually requires

R2 obligates each responsible entity to implement a documented process for security patch management for applicable Cyber Assets. Stripped to its load-bearing parts, the requirement breaks into three obligations.

First, identify a source or sources to monitor for the release of security patches for applicable Cyber Assets. This is the part many entities under-document. The source has to be named, tracked, and tied to the specific assets it covers. Vendor security advisory feeds, OS vendor bulletins, and firmware portals all count, but the patch source for each applicable asset has to be on record.

Second, at least once every 35 calendar days, evaluate security patches for applicability that have been released since the last evaluation from the identified source or sources. This is the first clock. The evaluation has to happen on a recurring 35-day cadence, and the evaluation itself has to be evidenced.

Third, within 35 calendar days of completing the evaluation, take one of three actions for each applicable patch: install the applicable patch, create a dated mitigation plan, or revise an existing mitigation plan. This is the second clock. A mitigation plan must include the actions to mitigate the vulnerabilities addressed by the patch and a timeframe to complete those mitigations.

R2 obligation	Clock	Required evidence
Identify patch source(s)	Ongoing	Documented source per applicable asset
Evaluate patches for applicability	At least once every 35 calendar days	Dated evaluation record per cycle
Install, create plan, or revise plan	Within 35 calendar days of completing evaluation	Install record, or dated mitigation plan with actions and timeframe

The two 35-day windows are sequential, not concurrent. The first runs from one evaluation to the next. The second starts when an evaluation that identifies an applicable patch is completed, and it ends when you install, create a plan, or revise a plan for that patch. Treating these as one window is a common way to fall behind without realizing it.

Which assets CIP-007 patch management covers

R2 does not stop at servers. It applies to high impact and medium impact BES Cyber Systems and their associated Cyber Assets. That associated population is where teams most often discover scope they did not account for. The requirement reaches the Electronic Access Control or Monitoring Systems (EACMS), Physical Access Control Systems (PACS), and Protected Cyber Assets (PCAs) tied to those high and medium impact systems.

In practice this means a firewall or jump host functioning as an EACMS, a badge controller acting as a PACS, and a workstation on the protected network as a PCA all sit inside the same 35-day discipline as the relay or RTU you first think of. Z Cyber and our clients build the applicable-asset inventory deliberately, because a patch source and an evaluation cadence are only as complete as the asset list they run against. If an associated EACMS is missing from the inventory, its missed evaluations are invisible until an auditor finds them.

Electric and energy utilities can read how we structure these programs end to end on our utilities security and compliance page, and the Glance platform is where the inventory, sources, and evidence live as one connected record.

The OT reality: why mitigation plans exist

The R2 drafters understood that operational technology cannot be patched like an IT fleet. A relay, a controller, or a substation gateway often cannot take an update outside a scheduled maintenance window. Some devices require vendor qualification of a patch before it is safe to apply. Some legacy assets have no vendor patch at all. Availability and safety requirements legitimately constrain when and whether a patch can be installed.

The mitigation plan is the mechanism R2 provides for exactly this situation. When you cannot install an applicable patch inside the window, the compliant move is to create or revise a dated mitigation plan that states the actions you will take to mitigate the underlying vulnerabilities and the timeframe to complete them. A mitigation plan is not a way to ignore a patch. It is a documented, time-bound commitment to reduce the risk by other means, such as compensating network controls, access restrictions, monitoring, or a scheduled install at the next maintenance window.

The failure mode is not having a mitigation plan. It is having one that is vague. A plan that says the patch will be applied "during the next available outage" without specific mitigating actions and a real timeframe is the kind of finding auditors write up. Z Cyber drafts mitigation plans with concrete actions and dated timeframes, then tracks them to completion in Glance so a plan never quietly expires.

The audit findings we see repeatedly

The same handful of issues account for most CIP-007 R2 trouble. Knowing them lets you build the program to avoid them rather than discovering them at audit.

Common finding	Root cause	How Z Cyber prevents it
Missed 35-day evaluation window	No recurring cadence or owner	Scheduled cadence with owners and reminders in Glance
Missed 35-day action window	Evaluation done, decision not recorded in time	Action deadline tracked from evaluation completion date
Undocumented patch source	Source monitored informally, never recorded	Source mapped to each applicable asset
Incomplete mitigation plan	No specific actions or timeframe	Plans require actions plus dated timeframe
Gaps for vendor-managed or hard-to-patch OT	Asset falls outside the regular workflow	Hard-to-patch assets flagged for standing mitigation review

Two patterns drive most of these. The first is treating R2 as an IT patch task instead of a compliance program, which loses the dated evidence even when the patching itself happens. The second is letting hard-to-patch OT assets drift outside the workflow, so the assets that most need mitigation plans are the ones that never get them.

R2 does not live alone: CIP-010 and CIP-013

CIP-007 R2 connects directly to two adjacent requirements, and treating them together is what turns patch management from a checkbox into real risk reduction. CIP-010 governs configuration change management and vulnerability assessments. The vulnerabilities your patch evaluations surface should feed your CIP-010 vulnerability management, and the configuration baselines CIP-010 maintains tell you what is actually deployed and therefore what needs patching. The two requirements describe the same assets from different angles, and the evidence should reconcile.

CIP-013 governs supply chain risk management, including software integrity and authenticity. When you obtain a patch, verifying that it came from a legitimate source and was not tampered with is a CIP-013 concern, and the patch sources you document under R2 are part of that supply chain story. We cover this connection in depth in our CIP-013 supply chain risk management guide. For a broader view of how these requirements fit together across a program, our NERC CIP compliance checklist for 2026 walks the full set of standards an entity has to satisfy.

How Z Cyber runs CIP-007 R2 as your operating partner

Z Cyber is a cybersecurity operating partner, not a tool you have to staff and run yourself. For CIP-007 R2 that means we stand up and operate the program with you. We build the applicable-asset inventory across BES Cyber Systems and their associated EACMS, PACS, and PCAs. We document the patch source for each asset. We run the recurring evaluation on the 35-day cadence and record each cycle. We drive each applicable patch to a decision inside its action window, whether that is an install, a new mitigation plan, or a revision to an existing one. And we keep every artifact in Glance so the evidence is contemporaneous and audit-ready by default.

Glance is the AI-native GRC platform we operate on your behalf. It holds the asset inventory, the patch sources, the dated evaluation and action records, and the mitigation plans with their timeframes, all linked so an auditor can follow a single thread from a CVE to the decision and the evidence. Because the platform tracks both 35-day clocks against the actual evaluation completion dates, the windows close on schedule rather than slipping in a spreadsheet. The result is a patch management program that holds up not just at the next audit, but every audit after it.