Patch tracking for the CIP-007 35-day cycle

When an evaluated security patch is applicable, Part 2.3 allows the entity to apply it within 35 calendar days of completing the evaluation. Applying the patch is the simplest path, but it still needs a record that shows the patch, the affected Cyber Assets and the date the change was made, so an auditor can match the evaluation to the installation.

• Link the record to the evaluation: Reference the patch identifier, the source it came from and the evaluation date in the same ticket or change record.
• Record the affected assets: List every applicable Cyber Asset that received the patch, not only the first or primary host.
• Capture the installed version: Keep the post-change version or build so the baseline and later vulnerability scans agree.
• Test before production where your change process requires it: A fast application that causes an outage can create a separate reliability problem, so keep the testing step in the record.

Check that each applied patch has a date inside the 35-day window measured from the completed evaluation, not from the vendor release date.

A patch may be evaluated and found not to apply, for example because the affected component is not installed, the vulnerable feature is disabled or the Cyber Asset is not in the applicable scope. Part 2.2 requires the evaluation itself, so the reason for a decision not to install must be written down and dated. A missing reason is the most common gap in this path.

• State the basis for the finding: Name the component, the version and the configuration that makes the patch inapplicable.
• Date the decision: Record when the evaluation was completed, since the 35-day clock runs from that point.
• Name the reviewer: Show who made or confirmed the determination, using the role your program assigns.
• Revisit when the inventory changes: A new install, upgrade or feature enablement can turn an inapplicable patch into an applicable one.

Check that the inapplicability reason still holds at the next evaluation cycle and has not been copied forward without review.

If a patch is applicable but cannot be applied within 35 calendar days, Part 2.3 allows a dated mitigation plan instead. The plan must state how the vulnerability will be addressed and the timeframe for doing so. Writing the plan is a decision to change how the risk is handled, so it should describe real actions and a realistic end date rather than a placeholder.

• Describe the vulnerability and the action: Explain what the flaw allows and what compensating or remedial step addresses it, such as restricting a service or segmenting access.
• Set a timeframe: State the date by which the action will be completed or the patch applied.
• Date the plan when written: The plan must be dated, and revisions must be dated too.
• Assign ownership: Name the team responsible for implementing the plan under Part 2.4.
• Explain why the patch was deferred: Note the operational or vendor constraint that prevents installation, so the reasoning is reviewable.

Check that the plan's timeframe is achievable and that someone will track it before the date arrives.

Part 2.4 requires each mitigation plan to be implemented within its stated timeframe. If the work will not finish by that date, the timeframe must be revised or extended, and the revision must be approved by the CIP Senior Manager or a documented delegate before the original date passes. Approving an extension after the fact does not satisfy the requirement, so the approval date is part of the evidence.

• Start before the deadline: Raise the extension request while the plan is still in effect, with the reason and the new proposed date.
• Record the approver: Capture the CIP Senior Manager or delegate, the approval date and any conditions.
• Confirm the delegation: Verify that the delegate is named in the program documentation and has authority for this decision.
• Keep the revision history: Retain each prior version of the plan so the sequence of dates is visible.

Check that every open mitigation plan has an approved date that has not yet lapsed, and that no extension was approved by someone outside the delegation.

The registered entity is the organization on the NERC Compliance Registry, and it is accountable for every CIP-007 R2 obligation, whatever tools or contractors it uses. It decides which patch sources it monitors, which Applicable Systems fall under R2, whether a given patch applies, and whether to apply it, write a mitigation plan or revise one. Those decisions are recorded with dates and named approvers, and any extension of a mitigation timeframe needs approval from the CIP Senior Manager or a delegate.

• Source identification: The entity names the sources it monitors for each updateable Cyber Asset and keeps that list current when vendors or assets change.
• Evaluation decisions: The entity documents the applicability evaluation at least every 35 calendar days and records who made each call.
• Mitigation plans and approvals: The entity writes dated plans, states the timeframe, and holds the approval trail for any extension.
• Records retained for audit: The entity keeps the evidence that shows each step happened on time, because the auditor tests what it can produce.

Before engaging any partner, confirm that your own team can explain each decision in the evidence without the partner in the room.

An implementation partner such as DeployOpen helps the entity build and run the mechanics that produce patch evidence. Work typically includes configuring detection tools against the entity's inventory, setting up the tracking workflow, exporting reports on a schedule, and writing the procedures that describe how the process runs. The partner works inside the entity's own infrastructure and does not take over the compliance decisions. It cannot determine applicability for the entity, approve a mitigation plan, or issue a finding.

• Tracking setup: The partner configures inventory collection and vulnerability matching so that the entity can see candidate patches for each in-scope system.
• Evidence exports: The partner builds repeatable exports that show evaluation dates and outcomes, which the entity reviews before filing.
• Documentation: The partner drafts procedures and diagrams that the entity owns, approves and maintains.
• Scope limits: The partner does not decide which patches apply, does not sign off on mitigation timeframes, and does not declare the entity compliant.

In any proposal, ask which deliverables are one-time setup and which recur, and confirm in writing who signs each procedure.

The Compliance Enforcement Authority, which is a Regional Entity or NERC, monitors compliance. It does this through Compliance Audits, Spot Checks, Self-Certifications, Self-Reports, self-logging, periodic data submittals, investigations and complaints. The auditor tests whether the records show that each R2 step was completed within its deadline, and it issues the compliance result. For registered entities that are Balancing Authorities, Reliability Coordinators or Transmission Operators, a Compliance Audit occurs at least once every three years, and other entities are audited on a risk-based schedule.

• Sampling: The auditor selects systems and dates, then checks whether evaluations and decisions fall inside the 35-day windows.
• Traceability: The auditor follows a patch from its source to its evaluation, then to its application or mitigation plan.
• Approval checks: The auditor looks for CIP Senior Manager or delegate approval wherever a timeframe changed.
• Consequences: Missed steps can lead to findings, mitigation plans and penalties under NERC's Sanction Guidelines.

Ask your Regional Entity which evidence formats it accepts, and run a mock sample of your own records before the notice arrives.