How to self-report a NERC CIP violation

How to self-report a NERC CIP violation as soon as you find it

A registered entity that has found possible CIP noncompliance should self-report as soon as it becomes aware of the possible violation, ideally within about three months of discovery and before any audit, Spot Check or Self-Certification notification arrives. Receiving a notice for one of those monitoring activities generally ends eligibility for self-reporting credit on the in-scope requirements, so the timing decision cannot wait for the internal investigation to finish. The Self-Report itself must include a risk assessment of the noncompliance, its extent and cause, and the actions taken or planned to mitigate it and prevent recurrence. Those three elements are the core of what the Regional Entity reads first, so an entity that reports early but cannot yet state the cause should say so, name the open questions and give a date for the follow-up.

The organization owns the controls, the facts in the report and the decision to file. The Compliance Enforcement Authority, which is the Regional Entity or NERC, decides how the matter is resolved, whether through a Compliance Exception, Find, Fix, Track and Report, or a Mitigation Plan. An implementation partner can help the entity pull configuration records, access logs, patch histories and training files into a coherent evidence set, and can help test whether the proposed mitigating actions actually close the gap. That support does not transfer responsibility. The named point of contact, the signatory and the accuracy of every statement remain with the registered entity, so the partner's role should be written into the engagement as preparation and evidence work, not as filing or representation before the CEA.

Before drafting, the compliance lead should confirm three things with its Regional Entity: the current submission channel and form, the expected level of detail for the risk assessment, and whether the entity is already self-logging for minimal-risk items, since that changes how the same finding is recorded. Teams should also check whether the potential violation touches a requirement that is versioned or changing, such as CIP-003-9 or CIP-012-2, because the applicable text on the date of noncompliance governs the analysis. Documenting the discovery date, the first internal review and each decision point gives the report a verifiable timeline and supports the prompt-reporting argument.

What a Self-Report must contain before you file

This sequence turns a suspected CIP miss into a Self-Report that states the risk, the scope, the cause and the corrective path in the form the Compliance Enforcement Authority expects. Work through it in order, because each step feeds the next and the final filing depends on all of them being documented.

Confirm the possible noncompliance against the exact requirement
Start by identifying the specific CIP requirement and its Applicable Systems table entry that may not have been met, not just the standard family. The compliance lead, working with the system owner, confirms the requirement part, the asset categorization under CIP-002 and the date the gap began. The output is a short written statement naming the requirement, the Applicable Systems affected and the facts that show a possible violation. Do not wait for proof of harm before this step is documented.
Record the date of discovery and the reporting clock
Document when the entity first became aware of the possible violation, who identified it and how. Self-reporting credit depends on reporting within a reasonably prompt time, typically within three months of discovery, and before detection by an audit, Spot Check or Self-Certification notice. The compliance lead should keep a timeline showing discovery, internal escalation and the planned filing date, so the reviewer can see the entity acted promptly.
Define the extent of the noncompliance
Scope how far the gap reaches: which BES Cyber Systems, Electronic Access Control or Monitoring Systems, Physical Access Control Systems and Protected Cyber Assets are affected, which locations and which time window. The operations and asset teams typically produce an inventory extract with asset identifiers, configuration or log evidence and the period of exposure. This extent record is the basis for the Self-Report's statement of scope and for any later Mitigation Plan.
Document the root cause
Identify why the requirement was not met, such as a missing procedure, a tooling gap, a role handoff failure or a misread of the standard. Write a root-cause record that traces the cause to a control that failed or did not exist. An illustrative example: a patch tracking report that excluded one vendor's firmware would point to the inventory process, not to the patch team alone. Reviewers look for a cause that explains the whole extent, so the record should be specific.
Complete the risk assessment of the noncompliance
Assess the risk the noncompliance posed to the reliability of the bulk electric system, considering the impact rating of the affected systems, the duration of exposure, the compensating controls in place and any evidence that the system was attacked or misused. The compliance lead should record the basis for each conclusion. The output is a written risk assessment with its reasoning, which is a required element of the Self-Report.
Set out the mitigation actions taken and planned
List the actions already completed to reduce the risk and the actions planned to correct the noncompliance, with owners and status for each. Include the steps to prevent recurrence, such as a revised procedure, a monitoring rule or a training change. Engineering and the CIP Senior Manager's delegates typically review this list. The output is an action log that separates completed work, with evidence, from planned work, with target steps, so the reviewer can test that the fix addresses the root cause.
Assemble and review the Self-Report package
Bring the scope record, timeline, root-cause record, risk assessment and action log into one Self-Report, then have the CIP Senior Manager or a delegate review it for accuracy and consistency. Check that every statement is traceable to evidence the entity can produce if asked. The output is a reviewed, signed-off package ready for submission through the Regional Entity's process. Independent consultants can help prepare the package, but the registered entity is responsible for its content and for the controls it describes.

The timing that earns self-reporting credit

Penalty credit for a Self-Report depends on timing more than on almost anything else you control. The report must be made within a reasonably prompt time after discovery, typically within three months, and it must come before the Compliance Enforcement Authority detects the noncompliance on its own. The clock starts when your organization becomes aware of a possible violation, not when a root cause analysis is finished, so a compliance lead who suspects a gap should record the discovery date at once and plan the report around it. Confirm the exact interpretation with your Regional Entity, because the three-month figure is a typical window rather than a fixed deadline for every case.

The most common way to lose credit is receiving a notification letter for a Compliance Audit, Spot Check or Self-Certification. Under the rules, that notice generally ends eligibility for credit on the requirements in scope for that engagement, so a discovery made after the letter arrives will not earn the same treatment. If discovery and an audit notice overlap, the first step is to read the notice and map its in-scope requirements against what you have found. Any possible noncompliance outside those requirements may still be eligible, so the report should be filed quickly, with a clear record of when each issue was first identified. Your legal and compliance leads should decide how to sequence this with the audit team, and they should confirm with the Regional Entity how it treats a discovery that falls inside an active notice.

In practice, the record of discovery is often the weakest part of a timely report. Keep dated evidence of the first signal, such as a failed scan, a missed patch window, an access review exception or a log gap, along with the person who escalated it and the time it reached the compliance function. Those timestamps let you show that the report was prompt and that detection had not yet occurred. If you cannot establish a discovery date, assume the earliest plausible date and act accordingly.

Likely outcomes after a Self-Report: Compliance Exception, FFT or Mitigation Plan

A Self-Report does not end the matter. The Compliance Enforcement Authority decides how the possible violation is resolved, and the path depends on the risk it assigns and the facts in the report. The four cards below set out what each outcome requires from your organization and how it affects your compliance history.

Compliance Exception for minimal risk

A Compliance Exception is the lightest route for minimal-risk noncompliance. You must still mitigate the issue, and the Compliance Enforcement Authority presumes this treatment for entities that self-log after a formal review of internal controls. Compliance Exceptions do not count toward compliance history for penalty purposes. However, the Compliance Enforcement Authority must consider earlier Compliance Exceptions if a failure to remediate them contributed to a later serious or substantial noncompliance. Confirm with your Regional Entity how it applies this treatment to your report.

FFT for minimal or moderate risk

Find, Fix, Track and Report applies to minimal or moderate-risk noncompliance. It requires you to mitigate the issue and keep the supporting facts available to NERC and FERC. You may object to the process if you disagree with it. Because the facts remain on file, the record of the event stays available to later reviewers. Ask your Regional Entity early whether a Self-Report will proceed under this path and what documentation it expects to hold.

Formal Mitigation Plan

A Mitigation Plan applies when the noncompliance needs a documented correction path. It must name a knowledgeable point of contact and state the noncompliance, its cause, the activities that will correct it, and how the cause and recurrence will be addressed. It also sets out the interim risk and how you will manage it, plus a completion timetable. Assign the contact and draft the timetable before the plan is submitted, because the plan will be the basis for later review.

Violation proceeds to penalties

A possible violation that is not resolved through a lighter path can proceed to a formal finding and penalty under the Sanction Guidelines. The Sanction Guidelines reference a maximum civil penalty of $1,584,648 per violation, per day, as adjusted by FERC Order No. 906. Reports that were late, incomplete, or made after an audit notice may reduce or remove credit on the affected requirements. Review your risk assessment and cause analysis carefully, since these shape how the Compliance Enforcement Authority weighs the case.

Self-report or self-logging: which path fits your program

Most discoveries are one-off events: a patch cycle missed on a single Cyber Asset, an access revocation completed late for one employee, or a log review skipped during a maintenance window. When your team finds a possible violation of this kind during normal operations, the Self-Report is the route. The Self-Report is the standard way to tell the Regional Entity or NERC that you may have failed a requirement, and it should be filed as soon as you become aware of the possibility. Credit for a Self-Report depends on timing, so the clock matters more than the completeness of your first submission.

Timing window: Credit generally requires reporting within a reasonably prompt time, typically within three months of discovery, and before the Regional Entity detects the issue.
Content: The report should include a risk assessment, the extent and cause of the noncompliance, and the actions taken or planned to mitigate it and prevent recurrence.
Eligibility loss: Receiving a notification letter for an audit, Spot Check or Self-Certification generally ends eligibility for credit on the in-scope requirements.
Outcomes: Depending on risk, the matter may resolve as a Compliance Exception, through Find, Fix, Track and Report, or require a Mitigation Plan.

Before filing, confirm the requirement and the Applicable Systems with your Regional Entity's process and the current standard text, since scope drives the risk assessment.

What a Mitigation Plan needs once the Self-Report is filed

A Self-Report is not the end of the process. Under NERC Rules of Procedure Appendix 4C, a Mitigation Plan must name a knowledgeable point of contact and state the noncompliance, its cause, the activities that will correct it, the steps that correct the cause and prevent recurrence, the interim risk and how that risk will be managed, and a completion timetable. The reader should treat these as separate deliverables. Each one needs an owner inside the registered entity, a dated milestone, and evidence that the milestone was reached. The point of contact should be someone who can answer the Regional Entity's technical questions directly, not an outside advisor who is not on the entity's payroll.

The entity owns the plan and its execution. Its senior management decides which corrective actions to fund, which risks to accept during the interim period, and when the work is complete. An implementation partner or consultant can help draft the root cause analysis, prepare configuration baselines, assemble screenshots and logs, and build the milestone tracker. That drafting work is useful, but a consultant cannot sign or certify the plan, attest that a corrective action is complete, or vouch for the evidence to the Compliance Enforcement Authority. Confirm with your own counsel and compliance lead who signs each submission, and make sure the internal sign-off path is written down before the first milestone is due.

Before drafting, check the interim risk statement against the facts in the Self-Report, because the two documents will be read side by side. Confirm with your Regional Entity which milestone format and submission channel it expects, and ask whether it wants interim evidence at each milestone or only at completion. Then ask your team to answer one question for every milestone: what artifact would convince an independent reviewer that this step happened? If the honest answer is a meeting note or an email, add a stronger artifact, such as an exported configuration file, a ticket with timestamps or a signed change record, before the timetable is set.

Mistakes that weaken a Self-Report

A Self-Report earns credit only when it arrives on time, describes the noncompliance accurately and shows that mitigation is already under way. The mistakes below undermine one or more of those tests, and each has a specific check that prevents it.

Delayed filing

Credit depends on reporting within a reasonably prompt time, typically within three months of discovery, and before the Compliance Enforcement Authority detects the issue. Teams often wait while they debate whether an event is really a violation. Record the discovery date in the case file the day it is known, and set an internal deadline that falls well inside that three-month window. If a question remains open, file the report with what is known and state what is still being verified.

Incomplete cause analysis

A Self-Report must explain the cause of the noncompliance, not only the symptom. A report that says a patch was missed without showing why the tracking process failed invites follow-up questions and weakens the case for lighter treatment. Trace the failure through people, process and tooling, and confirm that each finding is backed by a log, ticket or configuration record. Ask a reviewer outside the affected team to test whether the cause would explain the whole pattern.

Understated affected systems

The risk assessment must cover the full extent of the noncompliance, including every BES Cyber System, Electronic Access Control or Monitoring System, and Physical Access Control System touched by the same failure. Teams often count only the asset that was discovered first. Pull asset lists from the CIP-002 categorization and the configuration management database, then compare them against the affected control. Any system that shares the failed mechanism belongs in the scope statement, even if it was not yet tested.

Missing mitigation evidence

A Self-Report should describe actions taken or planned to mitigate the risk and prevent recurrence. Statements such as "the issue has been fixed" carry little weight without proof. Attach dated change records, configuration exports, access revocation logs or test results that show the correction on each affected system. Where work is still open, list each action with an owner and a completion date so the reader can see that the plan is real and measurable.

Waiting for an audit notice

Once an entity receives a notification letter for a Compliance Audit, Spot Check or Self-Certification, eligibility for self-reporting credit on the in-scope requirements generally ends. Some teams hold findings back until the audit team asks, hoping the issue will not surface. Run internal control reviews on a fixed schedule, and treat any gap found during that review as a reportable event on the day it is confirmed. Confirm with your Regional Entity how it treats issues found during a pre-audit self-review.

Self-reporting NERC CIP questions answered

Who files a NERC CIP Self-Report and who decides the outcome?

The registered entity files the Self-Report, and the Compliance Enforcement Authority decides how the possible violation is resolved. The Compliance Enforcement Authority is either the Regional Entity responsible for the entity's area or NERC itself. The entity's CIP Senior Manager or a designated compliance lead normally signs off on the submission, since it commits the organization to a risk assessment and a corrective path. Contractors and consultants can support the work, but the registered entity remains the party that reports and answers for the outcome. Confirm the submission channel, required form and named contacts with your Regional Entity before filing.

How long does a NERC CIP Self-Report take to prepare?

No researched figure establishes a typical preparation time, so the duration depends on the entity's size, the number of affected systems and how quickly the facts can be pulled together. The work falls into three parts: confirming the possible noncompliance and its extent, assessing its risk, and documenting the cause and the actions taken or planned. Each part draws on the compliance team, system owners and operations staff who can confirm what happened and when. Reporting is expected promptly once the entity becomes aware of a possible violation, so the preparation effort should be planned to fit that expectation rather than extended indefinitely. Ask your Regional Entity what level of detail it expects in an initial submission and whether supplementary facts can follow.

Can a consultant prepare a NERC CIP Self-Report for us?

A consultant can help assemble the facts, draft the risk assessment and prepare the mitigation steps, but the registered entity must own the content it submits and the decisions behind it. DeployOpen is an implementation partner. It plans, implements, documents and supports self-hosted open-source platforms inside a client's own infrastructure, and it can help gather configuration records, logs and system evidence that support a Self-Report. DeployOpen does not act as the registered entity, does not decide the risk rating, and does not issue reports or attestations to the Regional Entity. Scope and deliverables for any such support would be agreed in writing before work starts.

What happens if we miss the three-month self-reporting window?

Self-reporting credit generally requires reporting within a reasonably prompt time, typically within three months of discovery, and before detection. If the window is missed, the entity may lose the credit it would otherwise earn for self-reporting on that noncompliance. The bigger risk is detection by someone else: receiving a notification letter for a Compliance Audit, Spot Check or Self-Certification generally ends eligibility for credit on the in-scope requirements. Missing the window does not necessarily mean the violation will be penalized more heavily, since the outcome still depends on risk, duration and the entity's conduct. Confirm with your Regional Entity how it treats late reports before deciding how to proceed.

Is a NERC CIP Self-Report public?

Confirm the disclosure rules with your Regional Entity, since publication practices depend on how the matter is resolved. A Self-Report starts the compliance process rather than announcing a penalty. Outcomes such as Compliance Exceptions or Find, Fix, Track and Report resolutions keep the facts available to NERC and FERC, and the entity can object to the process. Whether and when particular findings become public is a separate question that turns on the resolution path and the Regional Entity's practices. Ask the Regional Entity how it will handle the information you submit and what it will publish, and plan internal communications accordingly.

What evidence will the regulator ask for after a Self-Report?

The regulator will expect enough evidence to verify the risk assessment, the extent and cause of the noncompliance, and the actions taken or planned. Typical items include:

Logs, configuration records and system data showing when the issue started and how far it reached
Change records and baseline configurations relevant to the requirement
Documentation of the root cause analysis and the internal controls that failed or were missing
Records of the mitigating actions, with dates and owners, and evidence they were completed
Updated procedures or training records showing steps taken to prevent recurrence

The exact evidence list depends on the requirement involved. Ask the Regional Entity which records it expects for your specific standard and how long it will accept supplementary evidence.

Should we self-report or self-log a possible CIP violation?

Self-reporting is the general route when an entity becomes aware of a possible violation, while self-logging applies only to entities that have been approved after a formal review of their internal controls, and only for minimal-risk noncompliance. An entity that has not been approved to self-log should file a Self-Report. Self-logged items are reviewed by the Compliance Enforcement Authority at least every three months and presumptively resolved as Compliance Exceptions. Whether your entity qualifies is a question for your Regional Entity, and the choice affects how much documentation you prepare and how quickly you must act. Confirm your eligibility before assuming either path applies.

Can we describe a self-reported violation as resolved before the regulator closes it?

Describe the status accurately as the facts stand, and treat the Regional Entity's acceptance as the point at which the matter is resolved. A Self-Report usually leads to a Compliance Exception, a Find, Fix, Track and Report resolution or a Mitigation Plan, and each path has its own steps. Mitigation must be completed as committed, and the entity should keep records of every action. Internal messaging should say that corrective actions are underway or complete while the Regional Entity review continues. Confirm the resolution path and closure steps with your Regional Entity so that internal and external statements match the process.

How DeployOpen prepares CIP evidence for a self-report

DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a possible CIP violation, we help prepare the systems, configuration records and evidence your team needs to write a Self-Report, while the organization owns its compliance decisions and the Compliance Enforcement Authority makes the determinations.

How we scope

Engagements are fixed-scope, with the affected CIP requirements, systems and deliverables agreed in writing before work starts.
We confirm which BES Cyber Systems, EACMS, PACS and PCA are in the noncompliance area, using your existing CIP-002 categorization.
Scope documents list the evidence to collect, the owners on your side and the decisions that stay with your compliance team.

How we build

We reconstruct the timeline of the possible noncompliance from logs, configuration baselines and change records held in your environment.
We help draft the cause analysis, extent assessment and interim risk narrative that a Self-Report must contain.
We build or adjust the technical controls and monitoring needed to show the corrected state and prevent recurrence.

How we hand over

You receive an evidence package indexed by CIP requirement, with source system, collection date and custodian for each item.
Documentation covers the corrective actions taken or planned, written so your team can submit and defend them directly.
We walk your compliance staff through the artifacts so they can answer Regional Entity follow-up questions without us in the room.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement closes.
Retainers can cover monitoring of the corrected controls so recurrence evidence stays current through the mitigation period.
Confirm with your Regional Entity which evidence format and retention period it expects before the engagement is scoped.

How to self-report a NERC CIP violation