CIP-007 consistently produces the most serious and moderate CIP noncompliance, and patch management (R2) is a large part of the reason. The rules aren’t complicated. The problem is repetition: a 35-day cycle, across every piece of software and firmware, on every applicable Cyber Asset, forever.
The requirement in one paragraph
Identify a source for security patches for everything installed (R2.1). At least once every 35 calendar days, evaluate released security patches for applicability (R2.2). Within 35 calendar days of completing an evaluation, for each applicable patch, apply it, create a dated mitigation plan, or revise an existing mitigation plan (R2.3). Then carry out each mitigation plan by its date, or get the CIP Senior Manager or delegate to approve an extension (R2.4).
A workflow that holds up
1. Build the source list from your baselines. Your CIP-010 baselines already list installed software and firmware. For each item, record the patch source: a vendor portal, an integrator’s bulletin, a mailing list. “No patch source exists” is a legitimate answer, but it must be documented.
2. Run one evaluation per source, per cycle. Pick a fixed rhythm (every four weeks is common) so you never approach day 35. For each source, record the date checked, what was released since the last check, and whether each item applies. Record “nothing new” explicitly.
3. Decide within 35 days. For each applicable patch, choose: apply, mitigate, or revise an existing plan. Start the 35-day clock on the evaluation completion date, not the release date.
4. Make mitigation plans real. A mitigation plan needs the vulnerability addressed, the actions taken to mitigate it (for example, disabling a service or restricting a port), and a planned implementation date. Track the date like any other deadline.
5. Close the loop. When a patch is applied, the baseline changes. That triggers CIP-010: authorization before the change, software integrity verification (R1.6), baseline update within 30 days, and security control verification.
Evidence to keep
- the source list per software/firmware item, with the date it was last reviewed;
- dated evaluation records for every cycle and source;
- installation records or mitigation plans for each applicable patch;
- CIP Senior Manager or delegate approval for any mitigation plan extension;
- the matching CIP-010 change records.
Mistakes auditors find
- Gaps longer than 35 days between evaluations for one source, usually during vacations or staff changes.
- The clock started late because the team counted from installation planning instead of evaluation completion.
- Mitigation plans with no date, or dates quietly missed.
- Firmware forgotten. Relays, RTUs, switches and PACS controllers have patch sources too.
- Evidence reconstructed later from memory instead of recorded at the time.
Doing this without a spreadsheet
The reason this area produces so many violations is that spreadsheets don’t warn you. A good system starts a clock for every applicable patch the moment it is evaluated, shows mitigation plan deadlines alongside it, and connects the resulting baseline change to change control.
CIP Sentry’s System Security module tracks patch sources per software group, counts down the 35-day action deadline for each applicable patch, and turns missed patches into mitigation plans with their own clocks. See the platform.