ERO Self-Report
User Guide
Revised April 2014
3353 Peachtree Road NE
Suite 600, North Tower
Atlanta, GA 30326
404-446-2560 | www.nerc.com ERO Self‐Report User Guide | Revised April 2014 1 of 28 Table of Contents
Table of Contents ...................................................................................................................................................... 2 Disclaimer .................................................................................................................................................................. 3 Acknowledgments ..................................................................................................................................................... 4 Document Revisions .................................................................................................................................................. 6 Introduction and Purpose.......................................................................................................................................... 7 Detailed Description of the Potential Noncompliance and Mitigation Activities ..................................................... 9 Risk Assessment ...................................................................................................................................................... 11 Potential Impact Evaluation ............................................................................................................................. 12 Likelihood Assessment ..................................................................................................................................... 12 Putting it All Together ...................................................................................................................................... 13 Appendix A – Reference Documents ....................................................................................................................... 15 Appendix B – Examples ........................................................................................................................................... 16 Examples to Consider ....................................................................................................................................... 22 ERO Self‐Report User Guide | Revised April 2014 2 of 28 Disclaimer
The guidance contained in this document represents suggestions on particular topics to be applied by Registered Entities according to the individual facts and circumstances surrounding specific instances of noncompliance. This guidance does not create binding norms, establish mandatory reliability standards, or create parameters to monitor or enforce compliance with Reliability Standards. This guidance provides information and advice for Registered Entities to use when reporting instances of noncompliance to a Compliance Enforcement Authority (CEA). ERO Self‐Report User Guide | Revised April 2014 3 of 28 Acknowledgments Acknowledgments
Executive Sponsors Charles A. Berardesco, North American Electric Reliability Corporation Lane Lanford, Texas Reliability Entity, Inc. Daniel P. Skaar, Midwest Reliability Organization Development Team Lead Drafters Rick Dodd, Florida Reliability Coordinating Council Sara E. Patrick, Midwest Reliability Organization Keshav Sarin, Western Electricity Coordinating Council Tasha Ward, Southwest Power Pool Regional Entity Drafting Team Commenters Ingrid Bjorklund, Midwest Reliability Organization Rashida Caraway, Texas Reliability Entity, Inc. Walter Cintron, Northeast Power Coordinating Council, Inc. Theresa M. Cunniff, ReliabilityFirst Derrick Davis, Texas Reliability Entity, Inc. Leigh Anne Faugust, North American Electric Reliability Corporation Michelle Johnson, Florida Reliability Coordinating Council Ed Kichline, North American Electric Reliability Corporation Andrea Koch, SERC Reliability Corporation Chris Luras, Western Electricity Coordinating Council Sonia Mendonça, North American Electric Reliability Corporation Matthew Moore, Western Electricity Coordinating Council Jacob Phillips, Midwest Reliability Organization Niki Schaefer, ReliabilityFirst Industry Reviewers Michael Ayotte, ITC Holdings Tom Bowe, PJM Interconnection, LLC Randy Crissman, New York Power Authority Annette Johnston, MidAmerican Energy Helen Nalley, Southern Company Industry Commenters ACES American Electric Power American Transmission Company Bonneville Power Administration Brazos Electric Power Cooperative Buckeye Power Duke Energy Exelon FirstEnergy Hydro One ERO Self‐Report User Guide | Revised April 2014 4 of 28 Acknowledgments ISO/RTO Council Massachusetts Municipal Wholesale Electric Company MRO Performance Risk Oversight Subcommittee National Grid New York Power Authority Pepco Holdings, Inc. Reliability Compliance Legal Group Santee Cooper Public Service Authority Tampa Electric Company The Southern Company and Affiliates The United Illuminating Company Wisconsin Electric ERO Self‐Report User Guide | Revised April 2014 5 of 28 Document Revisions Document Revisions
Date January 17, 2014 April 17, 2014 Version Number 1.0 2.0 Document Changes Multiple revisions based on Comments received during public comment period, January 22, 2014 through February 21, 2014. ERO Self‐Report User Guide | Revised April 2014 6 of 28 Introduction and Purpose
The ability of a CEA to arrive at a final determination with respect to all noncompliance in an efficient manner is in part dependent on the quality of the information it has about the noncompliance and related mitigation. With that in mind, the ERO enterprise has developed this ERO Self‐Report User Guide and a companion ERO Mitigation Plan Guide to describe the type and quality of information that enables a prompt evaluation. This guide focuses on the information needed to assess the risk to the reliability of the bulk power system (BPS) and to evaluate mitigation activities, whether or not a Mitigation Plan is required. While NERC and almost every Regional Entity has posted guidance on these issues in the past, this Self‐Report User Guide is an ERO enterprise document that Registered Entities may use regardless of location. Overview
This Self‐Report User Guide is intended to provide guidance to assist Registered Entities with the submission of self‐reports. The Self‐Report User Guide enhances the Registered Entities’ understanding of the information necessary for NERC and the Regional Entities to provide efficient and timely resolution of instances of potential noncompliance. Once a Registered Entity has identified an instance of potential noncompliance, the actions taken by the Registered Entity can be as important as the facts that led to the potential noncompliance. Prompt detection is the first step, with prompt cessation, correction, and reporting also being critical steps that a Registered Entity must complete to resolve any instance of noncompliance. Most important, a Registered Entity must mitigate any potential or actual risk to the reliability of the BPS as quickly as possible. Since June 18, 2007, when the NERC Reliability Standards became mandatory and enforceable, Registered Entities have self‐identified the largest percentage of noncompliance processed by the ERO. The practice of self‐reporting and the fact that self‐identified noncompliance (including self‐reports and self‐certifications) represents the largest percent of noncompliance processed by the ERO are key to the success of the regulatory model in which the Compliance Monitoring and Enforcement Program (CMEP) was developed. Other Considerations
The NERC Sanction Guidelines direct CEAs to consider whether noncompliance was self‐reported and whether the Registered Entity voluntarily undertook corrective action. In its “Policy Statement on Compliance” issued October 16, 2008, the Federal Energy Regulatory Commission (FERC) emphasized that “prompt detection, cessation, and reporting of the offense” is a key factor in establishing an effective compliance program. Beyond the NERC Sanction Guidelines and FERC’s Policy Statement, many regulators point to these same qualities. In evaluating a self‐report, CEAs will consider the individual facts and circumstances surrounding each instance of noncompliance, which may include, but is not limited to, any number of the following: •
Did the Registered Entity timely self‐report when it discovered or learned of the potential noncompliance? •
Did senior management actively participate and encourage employees to provide complete information? •
Did the Registered Entity take immediate steps to address the potential noncompliance and did these steps effectively create adequate corrective actions? •
Did the Registered Entity arrange for individuals with full knowledge of the matter to meet with the CEA if/when asked to do so? •
Did the Registered Entity volunteer its relevant findings and provide all relevant evidence regarding the potential noncompliance? ERO Self‐Report User Guide | Revised April 2014 7 of 28 Introduction and Purpose •
•
•
•
•
•
Has the Registered Entity undertaken an extent of conditions review to determine the full scope of the potential noncompliance or described the steps it will take and timeline to complete its review to determine the full scope of the potential noncompliance? Did the Registered Entity’s disclosure include the identification of all relevant steps taken upon learning of the potential noncompliance, and the related corrective actions? Did the Registered Entity’s disclosure include all relevant communications among involved employees and/or third parties? Did the Registered Entity’s disclosure include all documents evidencing the potential noncompliance? Did the Registered Entity uncover the potential noncompliance itself through its own self‐
evaluation, internal audit, or internal compliance program? The Registered Entity’s compliance history, whether the self‐report is a repeat or recurrence of a prior violation or noncompliance. ERO Self‐Report User Guide | Revised April 2014 8 of 28 Detailed Description of the Potential Noncompliance and
Mitigation Activities
A quality self‐report consists not only of identifying the Reliability Standard and Requirement at issue, but also providing enough description to allow the CEA to understand the nature, cause, and duration of the potential noncompliance. Ideally, the self‐report will include: •
Submittal date, •
Start and end dates of potential noncompliance, •
Description of how the potential noncompliance was identified, •
Detailed explanation of the potential noncompliance, •
Why the noncompliance happened, •
Date the Registered Entity discovered the noncompliance, •
Whether the noncompliance has been previously reported to other regions •
Is the noncompliance still occurring, •
Any corrective actions that were taken upon identification of the noncompliance, •
What future corrective actions may be planned to prevent reoccurrence, •
Applicable registered functions, •
References to the specific Reliability Standard and Requirement at issue, •
Time horizon of the potential noncompliance, e.g. whether the potential noncompliance was in real time or on the planning horizon, •
Whether the potential noncompliance is related to documentation, performance, or both, •
Assessment of impact to BPS due to the potential noncompliance, and •
Any other relevant information and evidence to assist the CEA in making a fair and informed assessment of the potential noncompliance. Appendix B contains examples of comprehensive Self‐Reports that highlight where to include the desired information in each of the data systems utilized by the Regional Entities, webCDMS and CTS. Providing this information in a self‐report will allow the efficient and timely resolution of instances of noncompliance. Registered Entities are encouraged to submit self‐reports in a timely manner based on preliminary information and to provide more comprehensive information to the CEA as it becomes known. Although the existing system fields refer to “violation” and “possible violation,” at the self‐report stage, the CEA has not made a determination as to whether it will process the matter through an enforcement action. The CEA will make this determination through the triage process and will notify the Registered Entity of the processing track in accordance with the ERO‐enterprise procedures. It is particularly important for the Registered Entity to include a comprehensive description of any mitigation activities that have concluded or are in progress. If a Mitigation Plan is necessary, the CEA will inform the Registered Entity. However, having comprehensive information on such actions early in the process will help expedite CEA review of the matter and will enhance the likelihood that a Mitigation Plan will not be necessary to convey the information on mitigation activities. For a more detailed description of the steps associated with completing and submitting a Mitigation Plan, please refer to the ERO Mitigation Plan Guide. Mitigating activities should thoroughly address the actual and potential risk to the reliability of the BPS posed by the possible noncompliance, identify controls and/or corrective actions to reduce the likelihood of a recurrence, and outline the steps a Registered Entity will perform to mitigate the possible noncompliance. Registered Entities are strongly encouraged to take prompt steps to remediate possible noncompliance as soon as possible after discovery. ERO Self‐Report User Guide | Revised April 2014 9 of 28 Detailed Description of the Potential Noncompliance and Mitigation Activities Mitigating activities should address, in particular, the following issues. Note that a description of mitigating activities included as part of the self‐report would not repeat information regarding the scope and cause or apparent cause of the possible noncompliance included elsewhere in the self‐report. 1. Scope of possible noncompliance 2. Cause or apparent cause of possible noncompliance 3. Corrective Actions 4. Preventive and Detective Actions 5. Proposed Completion Date and Milestones 6. Interim risk reduction For additional guidance related to descriptions of potential noncompliance or possible violations, please refer to the FERC Guidance Orders on Reliability Notices of Penalty referenced in Appendix A of this document. ERO Self‐Report User Guide | Revised April 2014 10 of 28 Risk Assessment Risk Assessment
This document describes the guidelines to help Registered Entities assess the risk to the reliability of the BPS posed by noncompliance with a Reliability Standard. The purpose is not to establish a rigid set of criteria; rather the goal is to define certain principles to use when assessing risk associated with a particular instance of noncompliance. Depending on a Registered Entity’s size and organizational structure, the nature and complexity of the risk due to similar instances of noncompliance could be different. These guidelines will assist Registered Entities across the different regions to perform a thorough, consistent assessment of risk resulting from an instance of noncompliance. How to Assess Risk
In its “Policy Statement on Compliance” issued October 16, 2008, FERC emphasized the “prompt detection, cessation, and reporting of the offense” as a key factor in establishing an effective compliance program. An element of a good compliance program is to identify procedures to assess risk due to an instance of noncompliance. Noncompliance is in essence a failure to perform an activity required by the Reliability Standards and often is the initiating event for a wide spectrum of risks, ranging from inconsequential to catastrophic. It is important to perform assessments to prioritize these risks to ensure reliable operations and to utilize these assessments to develop plans that efficiently allocate resources. The Regional Entities and NERC refer to instances of noncompliance as posing a minimal, moderate, or serious or substantial risk to the reliability of the BPS. Risk is the likelihood of an event occurring coupled with a negative consequence of the event occurring. In other words, a risk is a potential problem — something to be avoided if possible, or its likelihood and/or consequences reduced if not avoided. Risk assessment involves reviewing the negative consequence or the impact of the event and the probability that the event will occur. The assessment of risk is from the perspective of the potential and actual risk arising out of a failure to comply with the individual Requirement. The potential risk is what might have happened to the reliability of the BPS due to this particular entity‘s specific systems, devices, or activities. The actual risk posed to the reliability of the BPS takes into account any compensating or mitigating factors that existed during the pendency of the noncompliance, in addition to the actual impact of the noncompliance. In its Order Accepting with Conditions the Electric Reliability Organization’s Petition Requesting Approval of New Enforcement Mechanisms, also known as the “FFT Order,” issued on March 15, 2012, FERC underscores the difference between potential and actual risk. Per the order, FERC indicated that risk assessments based on an after‐the‐fact review of the “actual risk,” which may equate to harm, as opposed to potential risk, could lead to misleading or inappropriate results. In other words, the fact that there was no adverse impact to the BPS during the period of noncompliance does not alone support the conclusion that there was minimal risk to the BPS. However, in combination with other factors that mitigated the risk, it may be appropriate to consider that the noncompliance posed a minimal risk to the reliability of the BPS. Further, risk assessments must be based on facts and not assumptions. Risk assessments must be based on facts existing at the time of the possible violation, not on facts that develop later. Risk assessments based on facts that develop after noncompliance is mitigated do not directly address the risk the noncompliance posed when it occurred or while it continues. In addition, FERC has indicated that it will not consider noncompliance as posing a minimal risk if it reveals a serious shortcoming in a Registered Entity’s reliability‐related processes. Finally, FERC indicated that it would be “inclined to accept” risk assessments that examine the use of processes or actions undertaken that made the actual risk of an instance of noncompliance less than its potential risk. ERO Self‐Report User Guide | Revised April 2014 11 of 28 Risk Assessment Potential Impact Evaluation
The first step in risk assessment is an evaluation of the potential impact of the noncompliance. The impact is determined by how the progression of the cause of the noncompliance is affected by compensating or mitigating factors. The impact analysis generally involves identifying the source of a risk and the threat due to the risk. Risk Source: A risk source could be internal or external. Examples include: • An employee or contractor • Inclement weather • Protection System devices Risk Threat: Risk sources trigger events that could lead to threats. Examples include: • Threat of the loss of relay protection for a facility • Threat of degradation or loss of a Bulk Electric System (BES) element • Threat of losing Critical Cyber Asset information • Threat of mistakenly providing unauthorized access to Critical Cyber Assets The following factors play an important role in determining the risk source and risk threat: • Registered Functions performed e.g., Balancing Authority (BA), Transmission Operator (TOP) • The size of the BPS equipment impacted by the noncompliance (e.g., Generation capacity or Load) • Entity’s interconnections with other entities • Duration of the noncompliance It is important to note the relationship between a risk source and risk threat. Risk sources trigger events that can lead to the risk threat. As stated above, subsequent failure of other subsystems, particularly the safety or protection systems, or by human errors made in responding to subsequent events, drives the impact of noncompliance. In such cases, an event tree analysis or inductive risk analysis might be very useful. Examples are provided in the Appendix. Likelihood Assessment
The next step in risk assessment is to determine the likelihood of the potential impact determined above. Likelihood is the probability that something will or will not occur. There are various ways to determine the probabilities. Here are some examples: 
Statistical Information: Internal or External data could provide the probabilities or Mean Time Between Failure (MTBF) that could be helpful in determining the likelihood of each event. 
Best Educated Guess: In many cases, statistical data may be unavailable leading to entities relying on internal or external Subject Matter Experts (SME) to determine the likelihood. 
Internal Controls Analysis: A controls analysis could be performed to determine the probability of each event outlined in the event tree. The below section highlights guidance on how to assess internal controls related to the sequence of events in an event tree. Controls and Likelihood A control could be a process, procedure, system, or a tool and could be implemented in an automatic or manual manner. Controls will vary from entity to entity because no two entities are alike in system design, configuration, program, business plans, and functions performed. Some examples of controls are: • A peer review process • An automatic notification • Frequency and voltage alerts ERO Self‐Report User Guide | Revised April 2014 12 of 28 Risk Assessment • A generation startup checklist There are many ways to classify and categorize controls. This guidance refers to controls as preventive, detective, and corrective. The following are definitions of those control types: Preventive Controls
• Prevent an error or event from occurring
Detective Controls
• Detect an error or event that may have occurred
Corrective Controls
• Correct an error or event that may have been detected
Entities should consider existing controls in determining the likelihood of an event outlined in the event tree. Examples are provided in the Appendix. Putting it All Together
After identifying the potential impact and the likelihood of the occurrence of the impact, entities can use a two dimensional model representing the risk posed by an instance of noncompliance. The Registered Entity may use the risk matrix below to visualize risk and assist in decision‐making on risk management. Although the CEA will make the final determination regarding how noncompliance will be processed and the level of risk, a Registered Entity can use the risk matrix to characterize the risk associated with an instance of noncompliance. Entities can determine the appropriate potential impact and likelihood levels based on their organization. The below matrix is just one such representation of these levels. Sample potential impact levels based on load loss Impact Description Extreme Power loss impact beyond entity’s footprint Substantial Loss of substantial power within entity’s footprint Intermediate Loss of generation or load; Loss of transmission facility Minor Degradation of a BES facility or a piece of BES equipment ERO Self‐Report User Guide | Revised April 2014 13 of 28 Risk Assessment Sample Risk Matrix Likelihood Legend Minimal Moderate Serious or substantial High Moderate Low Potential Impact Minor Intermediate Substantial Extreme Using a risk matrix, entities can discover and prioritize risks based on severity and create scenarios for mitigating risk (for instance, by reducing either the impact or the likelihood). The risk assessment does not end when noncompliance is mitigated. Entities are encouraged to consider implementing continuous risk assessment processes that are essential to a good internal compliance program. ERO Self‐Report User Guide | Revised April 2014 14 of 28 Appendix A – Reference Documents Appendix A – Reference Documents
FERC Guidance or Reference Documents

North American Electric Reliability Corporation, 138 FERC ¶ 61,193 (2012) (March 2012 FFT Order) http://www.ferc.gov/whats‐new/comm‐meet/2012/031512/E‐3.pdf 
North American Electric Reliability Corporation, 134 FERC ¶ 61,209 (2011) (Turlock Order) http://www.ferc.gov/whats‐new/comm‐meet/2011/031711/E‐3.pdf 
Enforcement of Statutes, Orders, Rules, and Regulations, 132 FERC ¶ 61,216 (2010) (Revised Policy Statement on Penalty Guidelines) http://www.ferc.gov/whats‐new/comm‐meet/2010/091610/M‐
1.pdf 
Further Guidance Order on Filing Reliability Notices of Penalty, 129 FERC ¶ 61,069, issued October 26, 2009: http://www.nerc.com/files/Further%20guidance%20order%2020091026‐3041(22732912).pdf 
Guidance 
Policy Statement on Compliance issued October 16, 2008. http://www.ferc.gov/whats‐new/comm‐
meet/2008/101608/M‐3.pdf 
Revised Policy Statement on Enforcement issued May 15, 2008 http://www.ferc.gov/whats‐new/comm‐
meet/2008/051508/M‐1.pdf 
FERC Overall Approach to Root Cause Analysis, http://www.ferc.gov/industries/hydropower/safety/projects/taum‐sauk/consult‐rpt/sec‐5‐overall.pdf 
Department of Energy Root Cause http://energy.gov/sites/prod/files/2013/07/f2/nst1004.pdf Order on Reliability Notices of Penalty, 124 ¶ http://www.ferc.gov/eventcalendar/Files/20080703131349‐AD08‐10‐000.pdf Analysis FERC Guidance 61,015 (2008) Document, NERC Guidance or Reference Documents

NERC Guidance on Self‐reports, Version 1.1, issued October 17, 2012: http://www.nerc.com/pa/comp/Resources/ResourcesDL/NERC%20Guidance%20on%20%20Self‐
reports.pdf 
NERC Rules of Procedure http://www.nerc.com/FilingsOrders/us/RuleOfProcedureDL/NERC_ROP_Effective_20131004.pdf 
Sanction Guidelines of the North American Electric Reliability Corporation http://www.nerc.com/FilingsOrders/us/RuleOfProcedureDL/Appendix_4B_SanctionGuidelines_201
40701.pdf 
Compliance Monitoring and Enforcement Program http://www.nerc.com/FilingsOrders/us/RuleOfProcedureDL/Appendix_4C_CMEP_20130625.pdf Regional Entity Guidance or Reference Documents

OATI webCDMS Registered Entity Training Scenarios V1.2, dated January 2012: https://www.rfirst.org/compliance/Documents/webCDMS%20Registered%20Entity%20Training%20Sce
narios%20v1%202.pdf ERO Self‐Report User Guide | Revised April 2014 15 of 28 Appendix B – Examples Appendix B – Examples
Comprehensive Self Report of Noncompliance with PRC-005-1 R2
ERO Self‐Report User Guide | Revised April 2014 16 of 28 Appendix B – Examples ERO Self‐Report User Guide | Revised April 2014 17 of 28 Appendix B – Examples ERO Self‐Report User Guide | Revised April 2014 18 of 28 Appendix B – Examples Comprehensive Self Report of Noncompliance with CIP-006 3c R1
ERO Self‐Report User Guide | Revised April 2014 19 of 28 Appendix B – Examples ERO Self‐Report User Guide | Revised April 2014 20 of 28 Appendix B – Examples ERO Self‐Report User Guide | Revised April 2014 21 of 28 Appendix B – Examples Description of Potential Noncompliance:
Examples to Consider
Lacking Registered entity identified possible noncompliance with CIP‐006‐1 R1.8 on December 8, 2009. Better Registered entity, as a Balancing Authority, is self‐reporting possible noncompliance with CIP‐006‐1 R1.8. On December 8, 2009, Registered Entity discovered that individuals who had not received CIP training and a Personnel Risk Assessment (PRA), as required by CIP‐004‐1 R3, were allowed cyber access to the access control system database, ProWatch. Best Registered entity, as a Balancing Authority, is self‐reporting possible noncompliance with CIP‐006‐1 R1.8. Under this requirement, the access control system must be treated as a Critical Cyber Asset. In violation of this requirement, individuals that have not received CIP training and a Personnel Risk Assessment (PRA) as required by CIP‐004‐1, R3, were allowed cyber access to the access control system database, ProWatch. The ProWatch application is the system used for physical access control. ProWatch consists of control boards, keycards, card readers, and alarms, and is configured via two servers, ProWatchA and ProWatchB. The system operates with one primary active server and one backup server in the standby mode. At the time of the discovery, ProWatchA was the active server. The noncompliance was discovered on December 8, 2009, while preparing to make the six‐month password change on the ProWatch access control system server, as required by CIP‐006‐1, R1.8. The ProWatch Administrator, while performing the password change, identified that a group called “Domain Admins” was part of the local administrator group the ProWatchA server. Based on his knowledge of the system, the ProWatch Administrator investigated further to ensure that all members of this group were authorized users. His investigation determined that some members of the Domain Admins group were unauthorized users; i.e. did not have the required training or PRA. His investigation also determined that the Domain Admins did not have access to the ProWatchB server, which at the time was in standby mode. Further investigation revealed the unauthorized group, Domain Admins, had been automatically added to the ProWatchA server when the server was rejoined to the network sometime after April 27, 2009, but prior to July 1, 2009. Lacking As required in R1 and R1.1, Registered Entity failed to establish a systematic approach to training (SAT) to establish a training program for the BPS company‐specific reliability‐related tasks performed by its system operators by the April 1, 2013 effective date. Better As required in R1 and R1.1, Registered Entity as a TOP failed to establish a systematic approach to training (SAT) to establish a training program for the BPS company‐specific reliability‐related tasks performed by its system operators by the April 1, 2013 effective date. Specifically, Registered Entity did not: 1) appropriately implement and document a SAT training Program by April 1, 2013; 2) include a description of the SAT process Registered Entity uses for its Training Program in the Training Program ; 3) appropriately outline initial and continuing training consistent with a SAT approach; and 4) define qualifications of Training staff. Best As required in R1 and R1.1, Registered Entity as a TOP failed to establish a systematic approach to training (SAT) to establish a training program for the BPS company‐specific reliability‐related tasks performed by its system operators by the April 1, 2013 effective date. Specifically, Registered Entity did not: 1) appropriately implement and document a SAT training Program by April 1, 2013; 2) include a description of the SAT process ERO Self‐Report User Guide | Revised April 2014 22 of 28 Appendix B – Examples Registered Entity uses for its Training Program in the Training Program; 3) appropriately outline initial and continuing training consistent with a SAT approach; and 4) define qualifications of Training staff. Additionally, Registered Entity did not define a method for selecting or determining its RRTs. Specifically, Registered Entity did not develop a company‐specific definition of Reliability Related, performing a Job Task Analysis (JTA), compiling the list of tasks from the JTA, and applying the company‐specific definition to a list of tasks performed by its system operators, as required by R1.1. This issue was discovered on May 6, 2013 when an internal audit was conducted. The issue occurred until August 15, 2013 when the Training Program was documented and fully implemented. The risk posed to the BPS by the Registered Entity not having implemented a SAT approach by the effective date of the Standard is minimal. Registered Entity’s System Operators have demonstrated competence in performing all of the tasks required to maintain the reliability of the BPS. Registered Entity believes that the risk is minimal since the majority of Registered Entity’s System Operators have each worked in the electric utility industry for longer than 30 years, with the average number of years of electric utility experience being 27 years. Registered Entity has an Operator Training Program in place and was utilizing that program under the PER‐002; however, a Training Program that meets the SAT requirements did not successfully replace it. ERO Self‐Report User Guide | Revised April 2014 23 of 28 Appendix B – Examples Risk Assessment: Examples to Consider
Potential Impact
Example 1: CIP‐006‐3 R1.6 Noncompliance Detail: In this instance, a visitor to a control center was unescorted for two hours. The visitor was an external contractor that did not have authorized access to the Control Center. Risk Impact Identification:  Risk Source: Visitor not escorted  Risk Threat: Unauthorized access to Critical Cyber Assets To determine the potential impact, it might be useful to determine the chain of events (i.e., an event tree) that creates a sequence of events triggered by the noncompliance. The following diagram highlights one such event tree. ERO Self‐Report User Guide | Revised April 2014 24 of 28 Appendix B – Examples Example 2: PRC‐005 R2 Noncompliance Detail: In this instance, five relays located at a single substation were not tested per the scheduled maintenance interval. These relays protect two circuit breakers and one step‐down transformer. Risk Impact Identification: 
Risk Source: Relays not tested 
Risk Threat: Unplanned loss of load Again, to determine the potential impact, it might be useful to determine the chain of events (i.e., an event tree) that links the risk source to the risk threat. The following diagram highlights one such event tree. ERO Self‐Report User Guide | Revised April 2014 25 of 28 Appendix B – Examples Likelihood Assessment
Example 1: CIP‐006‐3 R1.6 Noncompliance Detail: In this instance, a visitor to a control center was unescorted for two hours. The visitor was an external contractor that did not have authorized access to the Control Center. ERO Self‐Report User Guide | Revised April 2014 26 of 28 Appendix B – Examples Example 2: PRC‐005 R2 Noncompliance Detail: In this instance, five relays located at a single substation were not tested per the scheduled maintenance interval. These relays protect two circuit breakers and one step‐down transformer. ERO Self‐Report User Guide | Revised April 2014 27 of 28 Appendix B – Examples Putting it all together—Risk Assessment  Example PRC‐005 R1 Risk Assessment o Given that these relays were located at a single 60 KV substation, the impact of this violation is minor. Considering that the entity did a partial testing of the relays, the chances of the relays misoperating or failing was low. Even if these relays were to fail, the entity had real time monitoring of systems condition with alarms set for voltage increases up to “danger zone” that would have detected and/or prevented the relay failure. Finally, the entity had a backup for the primary relays that would have protected the system. As a result, this issue had a low likelihood of a minor potential impact to the BPS.  Example CIP‐006 R1 Risk Assessment o If the visitor gained access to CCAs located at the Control Center and manipulated the CCAs leading to an unplanned load shed for up to 5000 MW, the potential impact of this violation is substantial. However, the visitor did not have logical access required to gain access to the CCAs. Therefore, the likelihood of the visitor gaining access to CCAs and shedding unplanned load was low. Even if these CCAs were compromised or rendered unavailable, the entity had a redundant system that would have been used to control the SCADA system. As a result, this issue had a low likelihood of a substantial potential impact to the BPS. ERO Self‐Report User Guide | Revised April 2014 28 of 28