Among the many purposes of this column is to provide transparency into how ReliabilityFirst (RF) enforcement staff assess factors in the Sanctions Guidelines (Appendix 4B of the NERC Rules of Procedure).¹ One of the most frequently analyzed and applied factors from the Sanctions Guidelines is self-reporting credit. This is, in part, because self-reporting is critical to this regulatory model. In this edition of Enforcement Explained, we will look behind the curtain at why self-reporting is valued, what we look for when assessing the quality and timeliness² of a self-report, and how quality self-reports are a tool for entities to more quickly achieve regulatory clarity.

Self-reporting can be an indicator of program health

The ERO has discretion to grant mitigating credit for self-reporting under Section 3.3.8 of the Sanctions Guidelines. This is a regulatory approach to incentivize entities to identify and remediate risk to the Bulk Power System (BPS). Entities with healthy compliance programs are good at identifying, investigating, and resolving issues, and a strong, timely self-report is an entity’s opportunity to demonstrate success in this area.³

Self-report quality directly impacts disposition processing times

RF’s intake has been between 300 and 500 noncompliances per year for the last decade, and to manage its caseload while addressing risk, RF generally prioritizes processing higher risk items and older inventory. Naturally, because of the volume of cases, we often get questions from entities about processing timelines for their specific instances of noncompliance. While we often share projected timelines with entities, we also tell entities (and entities have learned) that the quality of their self-reports in terms of information provided has a material impact on how long it takes RF to process and dispose of their noncompliance.

When reviewing self-reports, the following attributes (also discussed below) are critical to allowing RF enforcement staff to more quickly process the instance of noncompliance:

• detailed descriptions of the fundamental noncompliant act,
• the timeline of events,
• nuanced root cause analysis,
• and relevant risk-reducing and elevating factors.

Without this key information, RF must send written requests or coordinate discussions with the entity, both of which can significantly slow RF’s ability to dispose of the noncompliance. To expedite processing of noncompliances, entities should craft thorough self-reports that tell the story of the noncompliance and its underlying risk.

Assessing the sufficiency of self-reports

To provide examples of how to improve self-reports, the following section is broken down into three categories: (1) detailed description of noncompliance; (2) root cause; and (3) detailed description of risk. For the purposes of this exercise, we will be using a CIP-007-6 R2 (patching) noncompliance to discuss different levels of quality in self-reported information.

1. Detailed description of noncompliance
   In this section, we are looking for the nature and scope of the noncompliance, both of which are necessary for RF’s enforcement processing as well as to inform mitigation. This article provides commentary beyond the Self Report and Mitigation User Guide, in terms of what Enforcement sees in a self-report. The Self Report and Mitigation User Guide on Page 8 includes a detailed list of items to consider and include in the Detailed Description of Noncompliance. In the patching space, that means the number of assets affected, the types of assets affected, the nature and severity of the patch, and the nature of the service or program being patched. Here is an example of the initial description of noncompliance from the CIP-007-6 R2 self-report form with items modified to protect security:“Human Performance Error. During the review, an entity employee missed that the patch was a security patch. The PNC was discovered in a Vulnerability Assessment then confirmed in an internal compliance review. The assessment was conducted by a third party vendor. Impact to the BPS was minimal because there are additional physical and cyber protocols in place. A list of some of the controls includes: a) under CIP-004, access is limited to authorized personnel; b) under CIP-005, the firewall is protected from the public network by being behind the corporate network. Intrusion Detection System (IDS) is in place to detect and alert any suspicious network activity. …”

   From this language, aside from knowing that a security patch was at issue, the description of the noncompliance provides little insight into the actual noncompliant act. RF enforcement sent multiple rounds of Requests for Information and/or Evidence (RFIs) to establish the scope of the noncompliance, which when fully developed, read as follows:

   “This noncompliance involves the entity’s failure to evaluate and install a patch that affected three Electronic Access Control or Monitoring Devices; specifically, the patch was intended for…[f]irewalls. The patch was designed to address a vulnerability in which a malicious actor could persuade an administrator logged into the web management interface to connect to an additional URL, allowing the malicious actor to exploit a cross-site request system forgery vulnerability. The patch was not installed or evaluated after it was released on Nov. 15, 2022, because the responsible SME was only evaluating a certain type of release from Techno Patching Company and this patch was included in a different release type.”
   

   In between these two descriptions of the noncompliance were multiple rounds of RFIs and exchanges over an 18-month period. An aside, if you are an entity looking for feedback, then RF suggests reviewing RFIs issued for prior noncompliances because they are often a strong indicator of what information should have been included in the self-report.

   As an additional note, in most cases, RF expects entities to conduct extent of condition reviews so that it can fully understand the scope of the violation. The results of the review can be reported at the time of self-reporting, or through mitigation evidence or a finding update. And if the entity finds itself identifying and communicating new instances, the entity should provide the same level of detail and information as is appropriate with the initial self-report.

2. Root causeAbsent a thoughtful and sufficiently investigated root cause, the entity and RF enforcement cannot determine what mitigating activities are appropriate to reduce the probability of recurrence. Below is an example of a root cause description that likely indicates a surface-level analysis of the underlying facts and that lacks the specificity needed to develop effective mitigation.
   
   “Human Performance Error. During the review, an entity employee missed that the patch was a security patch.”

   First, we see “human error” and “human performance error” quite frequently, acknowledging that humans play a significant role operating the systems that comprise the BPS. There are times where human error is truly the primary cause of a noncompliance. However, more often, if entities dig deeper, the root cause relates to procedural gaps, technical configurations, or inadequate training. In the example above, RF enforcement determined that the root cause was not human error, but rather:

   “The root cause of this noncompliance was inadequate training, specifically an employee transferred units within the entity and was unfamiliar with the patch management process for certain devices in the new unit.”There are a number of varying approaches to root cause analysis, and RF enforcement does not advocate any one over another. However, the approach must identify, with specificity, the central causal issues. For guidance on performing root cause analysis, please review the Registered Entity Self-Report and Mitigation Plan User Guide or reach out to RF’s Entity Engagement Department for additional information.

3. Detailed description of risk (potential impact/likelihood of impact)
   Risk in the enforcement space is defined as the potential impact to reliability or security multiplied by the likelihood of that impact occurring. The “description of risk component” in a self-report is a place for entities to provide relevant facts that may impact the risk. On the CIP side, this very frequently centers on compensating controls, network configuration, asset function, and other factual circumstances regarding the noncompliance. Determining appropriate risk factors requires a violation-by-violation analysis. However, there are a couple of common approaches we see that will trigger additional follow-up from RF’s enforcement team.First, the “no harm no foul” approach to risk analysis. Frequently, especially in the operations and planning environment, when actual harm does not occur, entities will stop their description at “no harm occurred, therefore the risk of harm occurring was minimal.” This is insufficient as it does not address potential risk (i.e., the probability of actual harm occurring and the potential magnitude of that harm). Thus, the absence of harm alone does not establish a risk level.

   The second problem can be referred to as the “controls/protections avalanche” where the entity enumerates all CIP standards that they are compliant with and broadly mentions their “defense in depth” security posture. Indeed, some entities simply copy and paste the same technical security controls in every self-report, regardless of the actual standard and requirement relevant to the instant noncompliance. This approach will lead to RFIs because frequently those assertions will contradict the violation itself or other facts included in the self-report. Additionally, they very often have a tangential relationship to the risk posed by the discrete noncompliance at hand. For example, continuing the CIP-007-6 R2 example above, it is not often that the entity conducting quarterly cyber security awareness training (CIP-004-6 R1) reduces the risk of an entity installing a critical security patch for its Electronic Access Control or Monitoring Devices 15 months late.

   In drafting the detailed description of risk, narrowly focus on the noncompliance description and whether the facts you are providing actually impact the potential risk (i.e., probability of occurring and/or magnitude of harm) posed by the noncompliance.

If you need help, ask!

Highlighted above are just a few comments on things to consider when self-reporting. Remember, the existence and quality of a self-report can reduce potential sanctions. Second, the quality of a self-report can have a material impact on processing time. If you have questions about how your entity can improve in the self-reporting process, please reach out to your case manager who will happily give you feedback.

¹For a discussion on the application of cooperation credit, see Enforcement Explained Issue 1, 2022.

²The NERC Sanction Guidelines under Section 3.3.8 speak to timeliness as a relevant factor for credit: “(1) within a reasonably prompt time after becoming aware of the violation” and in a footnote it emphasizes “as soon as practical” and importantly “but typically within three months of discovery”.

³As RF enforcement has previously discussed, healthy programs will experience noncompliances, especially in areas involving high frequency conduct (e.g., CIP-004, CIP-007 R2, and CIP-010 R1), so a zero-violation program *can* be a more concerning indicator than one with multiple self-reports. Self-reports are an indicator of health where they are the product of effective identification controls and the noncompliances are narrow in scope with limited durations.