How to write a NERC CIP Mitigation Plan when a violation is alleged
When an Alleged Violation notice arrives and you do not contest it, a Mitigation Plan is due within 30 days of the notice. Submitting the plan is not an admission of a violation, so the document should be written as a factual, verifiable account. It must name a knowledgeable point of contact and state the noncompliance, its cause, the activities that will correct it, the steps that correct the root cause and prevent recurrence, the interim risk and how you will manage it, and a completion timetable. Read the notice against the exact standard, requirement part and Applicable Systems it cites before you draft anything, because every statement in the plan should map back to that scope.
The organization owns the plan. An officer, employee, attorney or other authorized representative must sign it, and that signer is accountable for the commitments in it. An implementation partner can help prepare the technical evidence, such as configuration baselines, scan results, access reviews or recovery test records, and can help rebuild the affected control so the corrective steps are real. The partner does not sign the plan, speak for you to the Compliance Enforcement Authority, or determine whether the Regional Entity accepts it. Assign the internal owner for each milestone early, because milestones are typically no more than three months apart and missing an accepted milestone can create additional violations.
The content of the plan depends on the specific standard, requirement and root cause. A missed patch evaluation under one CIP-007 part calls for a different correction than a failed access revocation under CIP-004, and a repeat finding with the same root cause raises the stakes, since the Sanction Guidelines treat such repeats as an aggravating factor. Confirm with your Regional Entity the review timelines, the evidence format it expects and any outage-related deadline extension you may need, and confirm them in writing. Check the current text of Appendix 4C directly before you rely on any timing, because the sections that govern acceptance and extensions are the authoritative source.
What a CIP Mitigation Plan must contain
This sequence turns a confirmed or self-reported CIP noncompliance into a signed Mitigation Plan that names an accountable contact, explains the cause, sets out correction and prevention steps, manages interim risk and commits to dated milestones the Compliance Enforcement Authority can review.
Name a knowledgeable point of contact
Start by naming one person who understands both the violated requirement and the affected systems well enough to answer the Regional Entity's technical questions. This person is usually a CIP Senior Manager delegate, a compliance lead or an operations manager, not an outside consultant. Record the name, role and contact details at the top of the draft. The step is done when the Regional Entity can reach that person directly and the plan identifies them by name.
State the noncompliance precisely
Describe which Reliability Standard and requirement was not met, which Applicable Systems were affected and the period during which the gap existed. Use the facts from the Notice of Alleged Violation or your Self-Report, and keep wording consistent with them. Avoid speculation about impact at this stage. The output is a one-paragraph statement that a reviewer could check against your evidence without needing to ask follow-up questions about scope.
Document the root cause
Explain why the noncompliance happened, separating the immediate trigger from the underlying cause. Examples of underlying causes include an unclear procedure, a tool that did not alert, a missing role assignment or a change process that skipped a step. Base the explanation on investigation records such as tickets, logs, interviews and configuration history. The output is a written root cause statement that the corrective actions in later steps can be traced back to.
Define correction and prevention activities
List the specific activities that will return the entity to compliance and address the root cause so the failure does not recur. Each activity should name an owner, an expected output and the system or procedure it changes. Include both the fix for the affected systems and the change to the process, training, tooling or oversight that prevents a repeat. The output is an activity table that maps each action to the cause it addresses, which reviewers use to judge whether the plan goes beyond a one-time patch.
Assess and manage interim risk
Describe the risk to the bulk electric system while the noncompliance continues and until the corrective activities are complete. Identify the compensating measures in place, such as added monitoring, restricted access or manual review, and state who approves them and how they are checked. Confirm the assessment against your own risk framework and the facts of your environment. The output is an interim risk section that shows how the entity keeps the exposure controlled during the implementation period.
Build the milestone timetable
Convert the activities into a dated schedule with a completion date for the full plan. Space milestones so that each one is typically no more than three months after the previous one, and make each milestone verifiable, such as a configured setting, a signed procedure or a completed test. Note that failing to complete an accepted milestone can lead to additional violations, so build in realistic dependencies such as outage windows. Confirm any scheduling constraints with the Regional Entity before submission. The output is a milestone table with a clear evidence item for each date.
Obtain officer signature and submit
Have the plan signed by an officer, employee, attorney or other authorized representative, and confirm that the signer has authority to commit the entity to the timetable. Check the submission deadline against the notice you received, which is generally 30 days when the entity does not contest the Alleged Violation, and note that submitting a Mitigation Plan is not an admission of a violation. The output is a signed, dated plan and a submission record showing it reached the Compliance Enforcement Authority.
Mitigation Plan deadlines, milestone spacing and deemed acceptance
If you do not contest an Alleged Violation, you must submit a Mitigation Plan within 30 days of the notice. Treat that date as the start of the clock, not a target to plan toward. Submitting a plan is not an admission that a violation occurred, so an entity can file one while still reviewing the facts. That distinction matters for the wording of the plan: describe the noncompliance and its cause factually, without characterizing legal responsibility, and have counsel review the document before it goes to the Compliance Enforcement Authority (CEA). Confirm the exact notice date and calculation method with your Regional Entity contact at the start, because the 30 days runs from the notice itself.
Once the plan is received, the CEA has 60 days to accept or reject it. If it does neither within that window, the plan is deemed accepted. Deemed acceptance does not end the process, because NERC then has its own separate 60 days to approve or disapprove the plan. Entities should not treat silence from the Regional Entity as a green light to start work on an unapproved approach. Keep a dated record of every submission and every acknowledgment, and track both 60-day windows on the compliance calendar so that a change request, an outage schedule conflict or a request for an implementation extension is raised while there is still time to act on it.
Once accepted, each milestone becomes a commitment, and missing an accepted milestone can create a new violation in its own right. For that reason, set milestone dates from the work you can actually deliver, including procurement lead times, change windows and outage scheduling, rather than from the earliest date you hope to hit. Milestones are typically no more than three months apart, so a multi-year remediation needs several checkpoints. Assign each milestone an internal owner, a verification artifact, and a buffer, and review progress monthly against the plan. If a dependency such as a vendor delivery or a required outage slips, ask the CEA for an extension for good cause before the milestone date passes, not after.
When the implementation deadline can move
A Mitigation Plan sets dates the entity has to meet, but the CEA can extend the implementation deadline when a good-cause reason outside the entity's control stands in the way. The cards below cover what qualifies, what records support a request, and when to ask rather than wait.
The CEA's authority to extend
The Compliance Enforcement Authority may extend the implementation deadline in an accepted Mitigation Plan for good cause. The most common example is an inability to schedule an outage needed to install a patch, change a configuration or replace a Cyber Asset. Confirm with your Regional Entity how it expects the request to be made, and whether it wants the request in writing before the original deadline passes.
Outage scheduling records
Keep a dated record of every outage request, including the work it covered, the reliability coordinator or operator response, and any denial or rescheduling. A request that shows the outage was asked for early and refused or pushed back is far stronger than a request filed at the last minute. Record who made each contact, when, and what constraint was given.
Vendor lead times
When the fix depends on hardware, licensed software or a vendor's engineers, save the purchase order dates, the vendor's written delivery or availability confirmation, and any revised estimates. Illustrative example: if a replacement device is backordered, the delay is documented by the vendor's dated notice rather than by an internal estimate. Ask vendors to state lead times in writing so the record stands on its own.
Change approvals and sign-offs
Keep the change tickets, approval records and test results that show the planned work was ready to execute before the deadline. Evidence that a change was approved, scheduled and then blocked by an external factor separates a genuine good-cause request from a schedule slip. Store these records with the Mitigation Plan evidence so they can be produced quickly during a review.
Requesting early instead of waiting
Submit the request as soon as the entity can see that a milestone or the completion date will be missed for a reason outside its control, not after the deadline has passed. Include the original date, the revised date proposed, the cause, the records listed above and the interim risk controls still in place. A request that arrives before the deadline leaves the entity in a defensible position, while a late request can be read as a failure to manage the plan.
Keeping the interim risk managed
An extension does not pause the obligation to manage the noncompliance's interim risk. Confirm which compensating controls, access restrictions or monitoring will stay in place during the added time, and record them in the request. Reviewers are more likely to grant additional time when the entity shows the risk is contained and the schedule is tied to a named outage or vendor date.
How repeat violations with the same root cause raise penalties
The Sanction Guidelines treat a repeat violation as an aggravating factor when the earlier violation is still ongoing within five years and shares the same root cause or a programmatic failure. The presumption is that the penalty is doubled. For a Mitigation Plan, this means the root cause section is not a formality. If the plan closes the specific instance (a missed patch on one Cyber Asset, one late access revocation, one unreviewed log set) but leaves in place the process, tooling or ownership gap that produced it, the next finding of the same kind can be assessed as a repeat with the same cause, and the penalty presumption shifts against the entity.
Before drafting milestones, the responsible team should ask three questions that a Regional Entity reviewer will also ask: Is the cause a single event or a pattern across Applicable Systems? Would the same failure recur if the named individual left or the tool was replaced? Does any other CIP requirement depend on the same broken step, such as a change ticket that feeds both baseline management and vulnerability assessment? If the answer to the last question is yes, the plan should include milestones for those dependent controls, not only for the requirement that was cited. Record the analysis in the plan so the reviewer can see that the cause was tested, not assumed. Confirm with the Regional Entity how much root-cause detail it expects in the plan version you submit.
How the plan differs by situation
When the noncompliance is a single, identified technical gap, such as a missed security patch evaluation or a port left open on one Cyber Asset, the plan can usually be short and linear. The entity corrects the configuration or applies the patch, confirms the correction across the affected population, and then shows that the same gap cannot reappear. The milestones follow the work itself, and the Regional Entity will expect to see the fix verified rather than only announced.
- Milestone structure: Usually a small number of milestones, each tied to a discrete action such as scoping the affected assets, deploying the fix and verifying it. Milestones are typically no more than three months apart, so a short plan may need only one or two.
- Expected evidence: Before and after configuration captures, change tickets, patch or baseline records for every affected asset, and a sample or full population check that matches the scope named in the Self-Report or Notice.
- Interim risk: State how the gap is being covered until the fix is verified, for example by compensating access restrictions or added monitoring.
- Scope creep: Confirm that other systems sharing the same configuration or tool were checked, since an incomplete extent statement is a common reason a plan is revised.
- Recurrence prevention: Add a control, such as a recurring review or an automated check, so the fix does not depend on one person remembering it.
Before submitting, confirm with your Regional Entity whether the closure evidence must cover the full population or a sample, and who signs the plan.
Some violations cannot be corrected without replacing equipment, rebuilding a network segment or waiting for a generation or transmission outage window. These plans are longer and carry more uncertainty, so the milestones must show steady progress and a credible path to the completion date. The Compliance Enforcement Authority can extend an implementation deadline for good cause, including an inability to schedule an outage, but the request must be supported by records of what was attempted and why it failed.
- Milestone structure: Separate milestones for engineering, procurement, installation, testing and cutover, with an outage scheduling milestone that is tracked on its own.
- Expected evidence: Procurement and vendor schedules, outage requests and denials, design documents, test records and dated status reports that match each milestone.
- Interim risk: Describe the compensating measures in place for the whole period, not only at the start, and update them when conditions change.
- Deadline extension risk: Ask early. A request made after a milestone is missed carries less weight, and the outage record must show the entity tried to schedule work.
- Vendor dependency: Where a supplier controls the timeline, document the contract terms and escalation steps so the delay is clearly outside the entity's control.
Confirm the extension process and the documentation expected for an outage request with your Regional Entity before the first milestone date passes.
When the root cause is a gap in a process, such as an access review that was not performed, a training program that was not run, or a change process that was bypassed, a technical fix alone will not satisfy the Compliance Enforcement Authority. The plan must correct the process, confirm that the process works across the program, and show that the cause has been removed. Because the Sanction Guidelines treat repeat violations with the same root cause or programmatic failures as aggravating, the plan should also look at prior findings in the same area.
- Milestone structure: Milestones usually cover the process redesign, ownership assignment, training or tool changes, a first operating cycle and an independent check of that cycle.
- Expected evidence: Revised procedures with approval dates, role assignments, training completion records, and records from at least one full cycle of the revised process.
- Root cause depth: Trace the failure back to why the process allowed it, such as unclear ownership or a missing control. A plan that names only the symptom is likely to be revised.
- Repeat violation exposure: Check whether earlier violations in the same area had a similar root cause. Repeats within the aggravation window can double the penalty presumption.
- Management involvement: Confirm that an accountable officer or senior manager approved the plan and the resources, since leadership involvement is also an aggravating factor when it reflects poorly on oversight.
Before writing milestones, ask your compliance team to review prior Self-Reports and Mitigation Plans in the same requirement area.
Common mistakes that weaken a Mitigation Plan
A Mitigation Plan is judged on whether it names the real cause, sets a credible path to completion, and gives the Compliance Enforcement Authority proof that each step happened. The weaknesses below recur across submissions, and each one is easier to prevent when the plan is drafted than to explain after the CEA has rejected it.
Vague root-cause statements
A root cause such as "staff did not follow the procedure" describes the symptom, not the reason the control failed. Name the specific gap, for example a patch tracking process that depended on one person's calendar, and explain why it allowed the noncompliance to occur. Then check that each corrective activity addresses that exact cause. The Mitigation Plan must correct the cause and prevent recurrence, so a shallow cause leaves the plan unable to do either.
Milestones spaced too far apart
Milestones are typically no more than three months apart, so a plan with one completion date set twelve months out invites questions about progress in between. Break the work into dated milestones that each produce something checkable, such as a configured baseline or a completed test. Confirm with your Regional Entity whether a longer interval is acceptable before you submit, because the typical spacing is the default expectation.
Missing signature authority
The plan must be signed by an officer, employee, attorney or other authorized representative. A signature from someone without documented authority can delay acceptance and force rework on a clock that is already running. Confirm before submission who in your organization holds this authority, that the signer understands the commitments in the plan, and that the named point of contact can answer technical questions about it.
Interim risk left unmanaged
Every plan must state the interim risk while the fix is in progress and how that risk will be managed. Writing "low risk pending completion" without describing compensating steps, monitoring or access limits reads as an assumption rather than a plan. For example, if a patch is late on a system in scope, list the interim controls such as restricted access or added monitoring, who reviews them, and how often. Confirm these measures are running before you describe them as active.
No evidence plan for each milestone
Each milestone needs a defined artifact that proves completion, such as a signed change record, a configuration export or a test report with dates. Without this, staff close milestones from memory and cannot show the CEA what was done when a milestone is reviewed. Assign an owner for each artifact, decide where it is stored and how long it is retained, and confirm the evidence is collected at the time of the milestone, not reconstructed later.
Who owns the plan, who prepares the evidence and who reviews it
The registered entity owns the Mitigation Plan from start to finish. It is the party that has the noncompliance, carries the penalty exposure and must meet the milestones it commits to. Submitting a plan is not an admission of a violation, but once the plan is accepted, missed milestones can create additional violations, so the entity needs to choose its commitments carefully.
- Ownership and signature: An officer, employee, attorney or other authorized representative signs the plan, and the entity names a knowledgeable point of contact who answers questions from the Compliance Enforcement Authority.
- Content it is accountable for: The plan states the noncompliance, its cause, the correction, the steps to fix the root cause and prevent recurrence, the interim risk and how it is managed, and the completion timetable.
- Milestones and deadlines: The entity sets milestones, typically no more than three months apart, and tracks them internally.
- Penalty exposure: The entity bears the consequences of a missed commitment, including repeat violations with the same root cause.
- Internal decisions: Outage scheduling, staffing and budget approvals remain with the entity, even when outside help is used.
Before signing, check that each milestone has a named internal owner and that the timetable accounts for outage windows your operations team can actually grant.
An implementation partner such as DeployOpen works on the technical substance of the plan under a written, fixed scope. It prepares systems, configurations and evidence, documents the remediation work and helps the entity show what changed. The partner does not decide whether the plan is adequate, does not sign it on the entity's behalf unless authorized to do so in writing, and does not issue approvals, attestations or compliance determinations.
- Systems and configuration: The partner can build or harden the platforms, baselines, access controls or monitoring that a milestone requires, within the agreed scope.
- Evidence preparation: The partner produces records that an auditor or Regional Entity can review, such as configuration exports, change tickets, test results and screenshots with dates and sources.
- Remediation documentation: The partner writes the technical record of what was done, when, by whom and how it was verified.
- Milestone support: The partner can flag technical risks to a milestone early so the entity can request a deadline extension through the proper channel.
- Limits of the role: The partner does not represent the entity to the regulator unless the entity has authorized that role in writing.
Before engaging a partner, confirm in writing which deliverables are theirs, which the entity signs off on, and who keeps custody of the evidence.
The Compliance Enforcement Authority, a Regional Entity or NERC, reviews the plan and decides whether it is accepted or rejected. NERC then reviews the accepted plan and can approve or disapprove it. The regulator also verifies that milestones are completed and that the noncompliance is closed. These are the only parties whose review determines the plan's status.
- Acceptance or rejection: The Compliance Enforcement Authority must act within 60 days of receipt, or the plan is deemed accepted.
- NERC approval: After acceptance, NERC has 60 days to approve or disapprove the plan.
- Deadline extensions: The Compliance Enforcement Authority may extend an implementation deadline for good cause, such as an inability to schedule an outage.
- Verification of closure: The regulator reviews the evidence that milestones and the corrective action were completed.
- Independent role: Neither the entity's consultant nor the implementation partner can speak for the Regional Entity or NERC.
Ask your Regional Entity contact which evidence format and submission channel it expects before you start building milestone packages.
Each document in a Mitigation Plan has a clear author and approver. Keeping those lines visible prevents the common problem of a technical record being mistaken for a regulatory decision. No partner issues an approval, attestation or certificate for CIP compliance. CIP has no certificate, and the regulator's acceptance or closure is the only outcome that matters for the plan's status.
- Plan and submissions: The entity's authorized representative signs the plan and any formal submission.
- Technical evidence: The partner or internal engineers prepare it, and the entity reviews and accepts it before it is used.
- Milestone completion statements: The entity states completion; the regulator verifies it.
- Approvals and closure: The Regional Entity and NERC decide acceptance, approval and closure.
- Assessor reports: Where an independent auditor is engaged for other work, the auditor issues its own report, which is separate from any Mitigation Plan decision.
Check that your engagement letter states that the partner does not sign regulatory submissions or issue compliance conclusions.
Questions about writing a NERC CIP Mitigation Plan
Does submitting a Mitigation Plan admit a NERC CIP violation?
No. Submitting a Mitigation Plan is not an admission of a violation. The plan is the entity's proposed way to correct a noncompliance the entity has accepted or has not contested, and it sets out how the cause will be fixed and recurrence prevented. The practical point is timing: if the entity does not contest an Alleged Violation, the Mitigation Plan is due within 30 days of the notice, so the decision to contest should be made quickly with counsel. Whether a plan is filed does not settle the question of the violation itself, which is handled through the enforcement process. Confirm the current wording and procedure with your Regional Entity and your legal team before filing.
How soon must a CIP Mitigation Plan be submitted after a violation notice?
If the entity does not contest the Alleged Violation, it must submit a Mitigation Plan within 30 days of the notice. That deadline is short relative to the work it can involve, so the internal team should start scoping the root cause and corrective activities as soon as the noncompliance is identified, not when the notice arrives. Contested violations follow a different path, so confirm with the Compliance Enforcement Authority which deadline applies to your case. Ask the Regional Entity to confirm the notice date in writing so that the 30-day clock is tracked correctly.
Who must sign a CIP Mitigation Plan?
The plan must be signed by an officer, employee, attorney or other authorized representative of the entity. The signer should have authority to commit the organization to the milestones and completion timetable, because those commitments are enforceable once accepted. The plan must also name a knowledgeable point of contact who can answer the Regional Entity's technical questions. Many entities use the CIP Senior Manager or a compliance officer as the contact and an executive as the signer. Confirm internally who holds signing authority before the draft is finished so that approvals do not delay submission.
What happens if a Mitigation Plan milestone is missed?
Failing to complete accepted milestones can lead to additional violations, so a missed milestone is a compliance risk in its own right, not only a schedule problem. Mitigation Plan milestones are typically no more than three months apart, which gives the entity regular checkpoints to report progress and raise problems early. If a milestone is at risk, the entity should contact the Compliance Enforcement Authority before the date passes and explain the cause and the revised plan. Keep dated evidence of each completed milestone, because the Regional Entity will ask for it when it verifies completion.
Can an outage justify extending a CIP Mitigation Plan deadline?
Yes, the Compliance Enforcement Authority may extend the implementation deadline for good cause, and inability to schedule an outage is one example of good cause. Outage-dependent work such as replacing equipment or changing configurations on operating BES Cyber Systems often cannot be scheduled on demand. The request should be made before the deadline, explain the outage constraint with records of attempts to schedule it, and propose a revised date with interim risk controls in place. An extension is not automatic, so the justification must be specific and documented. Confirm the request process with your Regional Entity.
Does a complex CIP Mitigation Plan require an outside consultant?
The entity owns its compliance program and is responsible for the plan, its signatory and its commitments. Outside help is optional and usually depends on capacity and technical depth. An implementation partner can help prepare the technical evidence, configuration baselines, system changes and milestone records that the plan describes, while the entity keeps the decisions and the submission. DeployOpen works this way for self-hosted open-source platforms inside a client's own environment, under a written, fixed scope. Ask any consultant to show which parts of the plan they prepare and which the entity must approve, and confirm that the entity keeps full control of the submission.
How do repeat violations with the same root cause change the penalty?
A repeat violation can raise the penalty. Under the Sanction Guidelines, one aggravating factor is a repeat violation still ongoing within five years that shares the same root cause or reflects a programmatic failure, and the presumption in that case is to double the penalty. This is why the root-cause section of a Mitigation Plan matters: a plan that fixes only the symptom leaves the next violation open to aggravation. Review prior violations before drafting, identify whether the cause is shared, and document the controls that prevent recurrence. Confirm the current Sanction Guidelines text with counsel.
How DeployOpen prepares systems and evidence for a Mitigation Plan
DeployOpen is a Chainscore Labs company that plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure. For a Mitigation Plan, we help prepare the systems, configuration records and evidence that the entity's milestones depend on, while the entity keeps ownership of its controls and its submissions to the Regional Entity.
How we scope
- Fixed-scope engagements agree the affected CIP requirements, systems and milestones in writing before any work starts.
- We confirm which BES Cyber Systems, EACMS, PACS and PCAs the remediation touches, using the entity's own categorization.
- Scope documents name the internal point of contact and who signs off on each milestone deliverable.
How we build
- We implement the technical corrections in the client's environment, such as configuration baselines, logging or access controls.
- Each change is tested against the requirement language and recorded so the interim risk controls are documented as they operate.
- We document how the cause is corrected and how recurrence is prevented, so the entity can state both in its plan.
How we hand over
- Deliverables include dated configuration records, test results and change logs organized by milestone for the entity's evidence file.
- Runbooks explain how each control is operated and reviewed after the plan closes, so milestones stay complete.
- The entity or its authorized representative decides what is submitted, and independent auditors or the Regional Entity review the result.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers for systems that must keep meeting CIP requirements.
- Retainers can cover evidence collection between Compliance Audits or Spot Checks, which helps with milestone reporting.
- Ask us to confirm which platform features and licence terms meet a given requirement before the scope is signed.
