Compliance Exceptions and FFT for NERC CIP noncompliance

When do Compliance Exceptions and FFT apply to NERC CIP noncompliance?

A Compliance Exception resolves minimal-risk noncompliance, and Find, Fix, Track and Report (FFT) can resolve minimal or moderate risk noncompliance. Both paths require the entity to mitigate the issue, and neither replaces mitigation with a lighter obligation. Whether a registered entity that has found a CIP gap qualifies for either path depends on three things: the risk assessment of the specific noncompliance, the strength of the entity's internal controls that detected and contained it, and the entity's compliance history. Because those facts differ from one organization to the next, two entities with the same requirement and the same type of gap can reach different outcomes. The entity owns its controls and its risk assessment, and it should build both before anyone asks for a disposition. The risk assessment needs to explain how the gap could affect the reliability of the BES Cyber Systems in scope, what the entity's compensating measures were during the period of noncompliance, and how long the condition existed. The Compliance Enforcement Authority, which is a Regional Entity or NERC, decides which disposition applies. Entities should not assume that a self-described minor gap will be treated as minimal. Confirm the risk category and the disposition options with the Regional Entity early, and record the basis for the entity's own risk judgment in writing.

The compliance history also matters for future treatment. Under Appendix 4C, a past Compliance Exception is not counted for penalty purposes, but the CEA must consider it if a failure to remediate contributed to a later serious or substantial noncompliance. That makes the mitigation record as important as the initial classification. For FFT, the facts remain available to NERC and FERC, and the entity may object to the process. Before submitting a Self-Report, an entity should confirm which mitigation steps are complete, which are scheduled, and who owns each one, so that the description it provides matches what its evidence will show during any later review.

How the lighter resolution paths compare

A Compliance Exception resolves minimal-risk noncompliance as an alternative to a full enforcement action. It is the lightest disposition, but the matter closes only after the entity has mitigated the issue, so the paperwork and remediation still have to be done.

Risk level: Minimal risk only. A finding assessed as moderate or higher does not qualify for this path.
Mitigation: The entity must complete mitigation before the Compliance Enforcement Authority resolves the matter as an exception.
Facts kept available: Keep the records of the noncompliance, its risk assessment and its mitigation, because NERC and FERC can request them. Confirm the retention expectations with your Regional Entity.
Compliance history: A Compliance Exception is not counted in compliance history for penalty purposes. However, the CEA must consider it if failure to remediate it contributed to a later serious or substantial noncompliance.
Right to object: The entity may object to the process.

Before accepting a Compliance Exception, check whether the root cause could recur, because that is the condition under which an earlier exception returns to the penalty analysis. Document the fix so that it can be shown if a later issue has the same cause.

Which risk level qualifies for which path

A compliance lead working through a possible CIP violation weighs four factors: risk level, who identified the issue, self-logging approval, and root cause history. Each one pushes the case toward a Compliance Exception, an FFT, or a full enforcement action. The Compliance Enforcement Authority makes the final determination in every case.

Minimal risk noncompliance

Minimal risk is the entry point for a Compliance Exception. Appendix 4C allows minimal risk noncompliance to be resolved this way, and it still requires mitigation. Before proposing this path, document the risk assessment, confirm the affected BES Cyber Systems and their impact rating under CIP-002, and check that the facts support a minimal rating rather than a convenient one. The entity must still mitigate.

Moderate risk noncompliance

Moderate risk cases fall outside the Compliance Exception path but can still resolve through Find, Fix, Track and Report. FFT keeps the facts available to NERC and FERC and requires mitigation. Ask whether the noncompliance affected a medium impact system, whether it touched external routable connectivity, and whether the facts support moderate rather than serious or substantial risk.

Serious or substantial risk cases

Serious or substantial risk noncompliance does not qualify for either lighter path. These cases move toward a full enforcement action, with penalties set under the Sanction Guidelines. Treat any finding that could reach this level as a signal to involve counsel and to plan the mitigation with the Regional Entity early, since the risk classification drives everything that follows.

Self-identified versus found by audit

Self-reporting as soon as an entity becomes aware of a possible violation is encouraged by Appendix 4C, and timely self-identification supports a lighter outcome. Confirm when the entity first knew of the issue, record it in the Self-Report, and avoid delay while the facts are checked. An issue discovered during a Compliance Audit or Spot Check follows a different track and carries less weight in the entity's favor.

Approval for self-logging

Entities approved for self-logging after a formal review of internal controls may log minimal risk noncompliance instead of reporting each instance. The Compliance Enforcement Authority reviews logs at least every three months and presumptively resolves them as Compliance Exceptions. Check whether the entity holds this approval, whether each log entry carries a detailed description and risk assessment, and whether the approval covers the requirement in question.

Recurrence of the same root cause

A repeat of the same root cause changes the analysis. Compliance Exceptions do not count toward compliance history for penalty purposes, but the Compliance Enforcement Authority must consider past Compliance Exceptions where failure to remediate contributed to a later serious or substantial noncompliance. Review prior Compliance Exceptions and FFTs for the same root cause before choosing a path, and treat any prior failure to remediate as a significant risk factor.

What an FFT resolution involves from discovery to closure

An FFT resolution moves a possible CIP noncompliance from discovery to a documented, mitigated and reported outcome that the Regional Entity can accept without a full enforcement action. Each phase produces a specific record, and the sequence only closes once the facts, the mitigation and the report all agree.

Identify the possible noncompliance
The entity's compliance staff, often prompted by an internal test, log review, audit finding or staff report, identifies a condition that may fall short of a CIP requirement. Someone with compliance responsibility confirms that the condition relates to a specific requirement and applicable system. The output is an internal record that opens the matter, with the date the entity became aware of the possible issue. Confirm with the Regional Entity how it expects an initial possible-violation notice to be submitted, since the entity should not wait for a full analysis before raising the matter.
Document the facts and risk assessment
The entity assembles the facts: which Cyber Assets or systems were affected, the start and end of the condition, the root cause and why existing controls did not catch it. It then assesses the risk to the bulk electric system and classifies the noncompliance as minimal or moderate. The output is a written fact pattern and risk assessment that the Regional Entity can verify against evidence. Staff who ran the affected controls, and any vendor involved, should contribute to the timeline so that the record is complete.
Complete and track mitigation
The entity performs the mitigating activities needed to correct the condition and address its root cause, then records each action with the date it was completed. Where some work cannot finish immediately, the remaining actions are tracked with planned completion dates. The output is a mitigation record with evidence for each completed action, such as configuration exports, updated procedures or training records. Mitigation is required for both Compliance Exception and FFT treatment, so the entity should not treat this step as optional.
Report the facts to the Regional Entity
The entity submits the FFT information to the Compliance Enforcement Authority, covering the noncompliance, its risk assessment, the mitigation and the evidence supporting it. The facts are kept available to NERC and FERC after submission. The output is a submitted report that the Regional Entity can review as a complete record. Entities should confirm the required format and submission route with their Regional Entity before filing, and keep their own copy of everything sent.
Receive the resolution and retain records
The Regional Entity reviews the report and mitigation evidence and resolves the matter as an FFT. The entity may object to the process if it disagrees with how the matter was handled. The output is a resolution outcome that the entity files with its compliance records, along with the evidence set kept for later review. Ask the Regional Entity to confirm in writing how the resolution affects compliance history, and how long the supporting evidence should be retained.

How self-logging feeds Compliance Exceptions

Self-logging is available only after the Compliance Enforcement Authority approves an entity following a formal review of its internal controls. The review is the gate. Before applying, an entity should be able to show how it finds possible noncompliance, how it assesses risk, how it tracks fixes to completion and who signs off. Approval is not a reward for having had few violations, and an entity that cannot show working detection and tracking controls should expect the review to fail. Confirm the current approval process and its documentation expectations with your Regional Entity before planning around it, since the review is performed on the entity's own control evidence.

Once approved, the entity keeps a log of each minimal-risk noncompliance. Each entry needs a detailed description of what happened, the risk assessment for that instance and the mitigating activities completed or planned. The log must be complete enough that NERC and FERC can review it on request, so entries written as bare case numbers or vague summaries will not hold up. A practical check is to ask whether an outside reviewer could reconstruct the facts, the risk reasoning and the status of the fix from the entry alone. Owners of CIP-004 through CIP-011 controls should review entries for their areas, because the mitigation described must match what staff actually did.

The Regional Entity reviews the log at least every three months, and minimal-risk entries are presumptively resolved as Compliance Exceptions. The presumption is not automatic closure. A log entry that is incomplete, that understates risk, or that shows a pattern pointing to a weak control can be pulled out of the presumption and handled differently. Treat the quarterly review as a standing task with a named owner, and check whether any repeated root cause is appearing across entries. For the difference between self-logging and filing individual Self-Reports, see the sibling topics on self-reporting and the self-logging program.

What to have in place before you ask for a lighter path

This table lists the five items a registered entity should have ready before asking for a Compliance Exception, FFT treatment or self-logging approval. Each row says how to check the item and who on the organization's side owns it. The main takeaway is that a lighter path depends on documented controls and a record of mitigation, not on the outcome of a single event.

Readiness item	How to check it	Who owns it
Documented internal controls	Confirm each applicable CIP requirement has a written control, a named procedure and a record that it runs as written. Compare the documents against what staff actually do during a sample walkthrough.	CIP Senior Manager, with control owners in operations and IT
Repeatable risk assessment method	Check that the team uses one written method to rate the risk of each noncompliance, covering likelihood, impact on the BES and any compensating measures. Ask whether two analysts would reach the same rating for the same facts.	Compliance lead, reviewed by the CIP Senior Manager
Evidence of mitigation with dates and owners	For each past item, confirm a mitigation record exists with a completion date, an accountable owner and objective evidence such as a configuration export or signed change ticket. Confirm planned actions carry target dates.	Control owners, with the compliance lead tracking closure
Record of prior noncompliance and root causes	Review prior Self-Reports, Compliance Exceptions and FFTs for repeated root causes. Confirm each record states the cause and whether the same failure appeared before, since repeat causes weigh against lighter treatment.	Compliance lead, with input from the affected departments
Log structure for self-logging content	Check that a log template holds a detailed description, the risk assessment and the mitigating activities completed or planned for each minimal-risk item. Confirm the log can be produced quickly for NERC or FERC requests and that its entries match the source records.	Compliance lead, with IT or records staff maintaining the tool

Who owns the controls, the mitigation and the disposition

The registered entity is the organization that is registered for the applicable function and that carries the compliance obligation. It owns the CIP controls, the root cause analysis, the Self-Report or self-log entry, the mitigation and the record that shows the mitigation is complete. Its compliance lead and control owners decide what happened, what risk it posed and what will change, and they answer to the Regional Entity for every statement in the submission. Accountability does not move to a consultant because a consultant did part of the work.

Noncompliance determination: The entity confirms the facts of the possible violation and the requirement it touches, using its own asset lists and records.
Risk assessment and mitigation: Control owners define the risk, select the mitigating activities and carry them out inside the entity's own change process.
Self-Report or self-log: The compliance lead files the report, or maintains the self-log under an approved program, and keeps it current.
Evidence retention: The entity keeps the records that show completion, since the Regional Entity may ask for them at any time.
Assessor interface: The entity answers requests from the Regional Entity and explains its own controls.

Before you engage any outside party, confirm in writing which of these tasks you will keep in-house and which you will delegate.

Why lighter paths get rejected or fail

Compliance Exceptions and FFT are discretionary alternatives to a full enforcement action, and the Compliance Enforcement Authority can decline them. The cards below cover the causes that most often push a case out of a lighter path, and the checks that prevent each one.

Weak risk assessments

A lighter path depends on the noncompliance being classed as minimal or moderate risk. If the risk assessment understates the exposure of the affected BES Cyber System, the case may be reclassified. Check that the assessment states the impact category from CIP-002, the duration, the systems and data affected, and the controls that actually limited harm, rather than relying on the absence of a reported incident.

Mitigation without evidence

Both paths require the entity to mitigate, and the facts must stay available to NERC and FERC. A mitigation step described in a report but not supported by change tickets, configuration exports, access records or signed approvals is hard to verify. Keep the artifact that proves each step was completed, with a date and an owner, before you submit.

Repeat root causes

Appendix 4B treats repeat violations still ongoing within five years with the same root cause or programmatic failure as aggravating. A case that recurs from the same gap, such as a patch process that misses a source, can lose its lighter treatment. Track root causes across all findings, and fix the shared process rather than the single instance.

Late reporting

Self-Reports are encouraged as soon as an entity becomes aware of a possible violation, and timing affects how the CEA views the entity's response. Delay can make a case look like concealment or weak internal detection. Set an internal rule for escalating suspected noncompliance to the CIP Senior Manager or delegate, and record the date the entity first became aware.

Logs missing required detail

Entities approved for self-logging must keep a log with a detailed description of each minimal-risk noncompliance, its risk assessment and the mitigating activities completed or planned. A log entry that says only that a control was missed does not meet that standard. Use one template with fields for description, risk assessment, mitigation status and dates, and have a second person review entries before each quarterly review.

Unclear ownership of the process

Reviewers look for a named entity accountable for the affected control and for the internal review that identified the gap. When responsibilities sit with a vendor or a shared team, the file often lacks a clear chain from policy to action. Document who owns each control, who approved the mitigation, and how the internal controls review feeding self-logging was conducted.

Questions buyers ask about CIP Compliance Exceptions and FFT

Can an entity choose between a Compliance Exception and FFT?

The entity does not pick the path on its own. The Compliance Enforcement Authority decides how to resolve minimal-risk noncompliance, and it may use a Compliance Exception or FFT, while moderate-risk noncompliance can only go through FFT. Under Appendix 4C, both paths are alternatives to a full enforcement action and both require mitigation. An entity can still raise its view of the risk assessment and the proposed mitigation during the process, so the facts it presents shape which path fits. Confirm with your Regional Entity how it applies these options to your specific finding before you submit anything.

Does a Compliance Exception or FFT affect compliance history?

A Compliance Exception is not counted in compliance history for penalty purposes. FFT is handled differently: it keeps the facts available to NERC and FERC, so the record remains accessible even though the matter is resolved outside a full enforcement action. Neither path removes the underlying facts from regulator view. The Compliance Enforcement Authority must still consider a past Compliance Exception if a failure to remediate it contributed to a later serious or substantial noncompliance. Ask your Regional Entity how an FFT will be recorded in its files.

What must the entity do itself and what can a partner handle?

The organization owns its CIP program, its risk assessment and its mitigation. Mitigation is required for both Compliance Exceptions and FFT, and the entity must carry it out and document it. Its own staff should also own the facts it reports, because the Regional Entity relies on the entity's account of what happened. An implementation partner such as DeployOpen can help prepare systems, configuration evidence, logs and mitigation records for the controls involved. Such a partner does not issue reports, determine the resolution or replace the Regional Entity's decision.

How long does a Compliance Exception or FFT take?

No fixed duration for these resolutions is set in the sources available for this page, so do not plan around a number from a third party. Timing depends mainly on how quickly the entity completes its mitigation, how complete its facts and risk assessment are, and how many rounds of questions the Regional Entity raises. Mitigation that involves outage windows, equipment replacement or software changes usually takes longest. Ask your Regional Entity for its expected process steps and timing in writing, and track each milestone against them.

Can a past Compliance Exception come back into play?

Yes, in a specific case. A past Compliance Exception is not counted in compliance history, but the Compliance Enforcement Authority must consider it where the entity's failure to remediate contributed to a later serious or substantial noncompliance. This makes the quality of the first mitigation important, since a shallow fix can resurface later as a factor against the entity. Keep the mitigation records, root cause analysis and verification evidence for each resolved matter, and review whether the same cause could affect other systems.

Can an entity object to the Compliance Exception or FFT process?

Yes. Under Appendix 4C, an entity can object to the process used for its noncompliance, and it should do so in writing and within the timeframes the Regional Entity sets. An objection is most useful when the entity believes the risk level is wrong or the proposed mitigation does not match the facts. Before objecting, gather the evidence that supports your position and consult qualified counsel or compliance staff, since the choice of process shapes the outcome. Confirm the exact objection steps and deadlines with the Regional Entity.

How does self-logging differ from filing a Self-Report?

A Self-Report is filed each time an entity becomes aware of a possible violation, and the Regional Entity then evaluates it. Self-logging is different: an entity must first be approved after a formal review of its internal controls, and then it records minimal-risk noncompliance in a log instead of filing each one. The Compliance Enforcement Authority reviews the log at least every three months and presumptively resolves those entries as Compliance Exceptions. Each log entry needs a detailed description, a risk assessment and the mitigation completed or planned, and the logs are available to NERC and FERC on request.

Which CIP evidence should an entity keep for these resolutions?

Keep evidence that proves three things: what happened, what was fixed, and that the fix holds. For what happened, retain logs, configuration snapshots and timestamps that show the condition and when it started. For the fix, retain change records, approvals and before and after configuration evidence. For durability, keep periodic checks that show the control stayed in place. An engineer should confirm that the chosen tooling captures these records with reliable timestamps and retention, because a log that cannot be authenticated or shows gaps weakens the entity's position in any review.

When outside help is worth bringing in

Bring in outside help when a possible CIP noncompliance needs a documented mitigation that your team has not produced before, or when you are preparing a self-log and need the log entries to meet the detail the Compliance Enforcement Authority expects. The strongest use of a consultant is preparation work: reconstructing the timeline of the affected system, confirming which Applicable Systems the requirement covers, drafting the risk assessment and the mitigating activities, and assembling the evidence that shows each step was completed. Your organization still owns the controls, the risk decision and the sign-off. A consultant can prepare systems, records and evidence, and can help your compliance staff organize them, but cannot submit findings on your behalf as an independent party, and cannot promise that a Compliance Exception or FFT disposition will be granted.

No outside party can guarantee a disposition. The Regional Entity or NERC decides whether a matter qualifies for a Compliance Exception or FFT, and any independent auditor reviewing your controls reaches its own conclusions. Treat any proposal that promises a specific outcome as a warning sign. Before signing a fixed-scope agreement, ask the provider to state in writing which deliverables it will produce (for example, a mitigation timeline, an evidence index, or a draft self-log entry), which parts of the work remain with your staff, and who will attend discussions with the Regional Entity. Confirm how the provider handles BES Cyber System Information it sees during the work, and whether it has experience with the specific CIP requirements in your finding rather than generic security assessment.

Ask for the scope boundaries before the price, and confirm the acceptance criteria for each deliverable so that a completed mitigation can be checked against the Regional Entity's expectations. Ask what happens if the Regional Entity requests more information, whether change requests are priced separately, and how the provider documents its own work so that your records remain yours to produce. Confirm with your Regional Entity, rather than assuming, which evidence formats and timelines apply to your matter. A clear written scope protects both sides: it defines what the provider delivers, and it keeps the determination on compliance status with the entity, the CEA and the independent auditor where it belongs.

How DeployOpen prepares CIP evidence and mitigation records

DeployOpen prepares the systems, controls and records that a registered entity needs when it resolves CIP noncompliance through a Compliance Exception, FFT or a self-logging program. The entity owns its controls and its submissions, and only the Regional Entity or NERC decides how a matter is resolved.

How we scope

Scope is agreed in writing before work starts, listing the CIP requirements, assets and systems covered.
The written scope states which mitigation activities DeployOpen will build and which the entity will complete itself.
Scoping confirms who owns each record, log entry and approval step, so responsibilities are clear before any work begins.
Engagements are fixed-scope, and the scope document also states how and when ongoing support is available as a retainer.

How we build

We configure the technical controls tied to the noncompliance so the mitigating activity can be shown in system output.
Each mitigating activity is written as a dated, verifiable step with the evidence that proves it was completed.
Risk assessments for minimal or moderate risk findings are drafted with the entity's compliance staff for their review.
Self-logging entries follow a consistent template covering the description, risk assessment and mitigating activities.

How we hand over

Deliverables include the mitigation records, evidence index and configuration documentation, organized for review by the Regional Entity.
Records are kept in a format the entity can retrieve quickly for NERC or FERC requests, with retention settings documented.
Handover covers how to update the log or record after each new finding, so the program stays current after the engagement.
The entity's staff receive a walkthrough of the evidence and records so they can explain each step to an auditor.

How we support

Ongoing support, upgrades and continuous testing are available as retainers for entities that keep self-logging or running FFT programs.
Support can cover periodic log reviews, evidence refreshes and checks that mitigating controls still operate as documented.
Before engaging, confirm with DeployOpen which tasks fall under a retainer and which fall under a separate fixed-scope piece of work.