ERO Mitigation Plan Guide Revised April 2014

Transcription

1 ERO Mitigation Plan Guide Revised April of Peachtree Road NE Suite 600, North Tower Atlanta, GA

2 Table of Contents Table of Contents...2 Disclaimer...3 Document Revisions...4 Introduction and Purpose...7 Mitigation Plan Contents...8 What is a Mitigation Plan?...8 What should be included in a Mitigation Plan?...8 Appendix Reference Documents of 23

3 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). 3 of 23

4 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 Keshav Sarin, Western Electricity Coordinating Council Tasha Ward, Southwest Power Pool Regional Entity Drafting Team Commenters Jenny Anderson, Southwest Power Pool RE 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. 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 Sara Patrick, Midwest Reliability Organization Jacob Phillips, Midwest Reliability Organization Niki Schaefer, ReliabilityFirst Patrick VanGuilder, Florida Reliability Coordinating Council Industry Focus Group 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 4 of 23

5 Hydro One 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 Acknowledgments 5 of 23

6 Document Revisions Document Revisions Date Version Number Document Changes January 17, April 17, Multiple revisions based on Comments received during public comment period, January 22, 2014 through February 21, of 23

7 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 Electric Reliability Organization (ERO) enterprise has developed this ERO Mitigation Plan Guide and a companion Self-Report User Guide to describe the type and quality of information that must be submitted in order to allow for a prompt evaluation. While the benefits of more thorough and timely mitigation plans being submitted to Regional Entities include faster determination of how an issue of non-compliance should be processed and faster processing times, it is important for the Registered Entity to perform the actions necessary to correct the instant issue to protect reliability of bulk power system (BPS). This guide supplements information provided in the NERC Compliance Monitoring and Enforcement Program, Rules of Procedure, Appendix 4C, Section 6.0, by providing further guidance on what should be included in a Mitigation Plan. While NERC and almost every Regional Entity have posted guidance on these issues in the past, this user guide is intended to be an ERO enterprise document that may be used by Registered Entities regardless of location. 7 of 23

8 Mitigation Plan Contents These guidelines inform a Registered Entity on proper steps to take, and items to consider, when creating Mitigation Plans according to Appendix 4C, if the CEA requests that a Mitigation Plan be submitted. These sections will help guide the Registered Entity to develop a plan that will not only identify and correct the original possible noncompliance but will also include steps to prevent future occurrence of similar issues. For a discussion of mitigation activities that could be provided as part of a Self-Report, please refer to the ERO Self-Report User Guide. What is a Mitigation Plan? A Mitigation Plan is an action plan developed by a Registered Entity to (1) correct noncompliance with a Reliability Standard and (2) prevent recurrence of the noncompliance. As noted above, the guidelines in this document are intended to supplement the requirements and information provided in the CMEP. In addition, a Registered Entity may cover multiple violations of the same standard and requirement in one Mitigation Plan per the CMEP. This guide was not intended to directly address the references to mitigation plans and action plans made in the Reliability Standards. This guide, however, can be used when performing the activities required by those Standards and Requirements as the activities required cover the same areas of topic to be resolved. What should be included in a Mitigation Plan? A Mitigation Plan should address the actual and potential risk posed by the possible noncompliance, identify controls and corrective actions to reduce the likelihood of a future occurrence, and outline the steps a Registered Entity will perform to mitigate the possible noncompliance. It should be noted that the intent of these Guidelines is to outline the activities that should be considered by Registered Entities while submitting a Mitigation Plan. However, the activities are not outlined in the order they should necessarily be implemented. Registered Entities are strongly encouraged to take prompt steps to remediate possible noncompliance as soon as it is discovered. In this guide, there are examples of statements that are included in a Mitigation Plan. For each Mitigation Plan heading, there is a Lacking, Better, and Best example. By providing the three levels, a Registered Entity can gauge where its current Mitigation Plan language stands and set the goal to produce the Best level statements and information going forward. Overview Mitigation Plans should address the following. 1. Scope of Possible Noncompliance 2. Root Cause of Possible Noncompliance 3. Corrective, Preventive, and Detective Actions 4. Milestones 5. Proposed Completion Date 6. Interim Risk Reduction 7. Prevention of Future Risk to Reliability Included in Appendix A is a Mitigation Plan Checklist for a Registered Entity to use to ensure that it is completing the steps of the Mitigation Plan process. 8 of 23

9 Scope of Possible Noncompliance In this section of the Mitigation Plan, the Registered Entity should identify the originally reported scope of the possible noncompliance and note any changes in scope that were found. When identifying the scope of the possible noncompliance, the Registered Entity should consider all procedures, assets, facilities, or personnel that are directly impacted or that could be impacted by the possible noncompliance. The Mitigation Plan should include a brief narrative describing the comprehensive review that was done by the Registered Entity to verify the full scope or extent of condition of the possible noncompliance. Below are some examples of what to include when completing the Mitigation Plan. Scope Example: CIP-007 R3 - Entity failed to assess security Patches for 7 Cyber Assets used in Generation Management System. Patch management program was It was identified that 12 of 27 patches released between April 1 It was identified that 12 of 27 patches released between April 1 not followed. and April 30, 2011 were not and April 30, 2011 were not assessed for applicability within the 30 days prescribed in CIP R3. assessed for applicability within the 30 days prescribed in CIP R3. Scope Review (Extent of Condition) We conducted a review of patches released in the month of April 2011 and determined that 12 of the 27 released patches were not assessed. The patches were for non- Microsoft related applications running on 7 EMS workstations located in the primary and backup control centers. Scope Review (Extent of Condition) On June 17, 2011, we discovered that one patch had not been assessed and conducted a comprehensive review of patches released in the last 120 days. We discovered that in the month of April 2011, 27 patches had been released. We determined that 12 of the 27 patches had not been assessed for applicability within 30 days. We determined that the lapses in assessment occurred due to a change in staff responsible for conducting assessments. The assessment of the 12 patches was completed by June 30, 2011, 13 days after discovering the issue. 9 of 23

10 Scope Example: PRC-005-1b R2.1 Entity failed to provide evidence that its Protection System devices were maintained and tested within the defined intervals of its Protection System maintenance and testing program. Protection System maintenance and testing program not followed. It was identified that battery maintenance for one substation was not completed in accordance with the Protection System maintenance and testing program. It was identified on May 21, 2014, that battery maintenance for one 230kV substation battery bank was not completed in accordance with the defined intervals of the Protection System maintenance and testing program. The interval required that the maintenance be completed quarterly, and was not performed in the first quarter of The substation is not a tie to other Transmission Owners, nor does it connect to BPS Generation. The battery bank represents one of the Transmission Owner s 85 Protection System devices. Root Cause of the Possible Noncompliance Root Cause Analysis (RCA) is not a single, sharply defined methodology; there are many different tools, processes, and philosophies for performing RCA. RCA practice tries to solve problems by attempting to identify and correct the root causes of events (e.g. human performance failure, equipment failure), as opposed simply to addressing their symptoms. By focusing correction on root causes, problem recurrence can be prevented. Conversely, there may be several effective methods that address the root causes of a problem. Thus, RCA is an iterative process and a tool of continuous improvement. Despite the different approaches among the various schools of RCA, there are some common principles. It is also possible to define several general processes for performing RCA. As described in the Cause Analysis Methods for NERC, Regional Entities, and Registered Entities document, there are many methods to determine the root cause(s) for events. This guidance, as well as several other references noted in Appendix B, is designed to provide an accessible reference of the methods and tools routinely used in the investigation, analysis, and determination of causal factors which lead to identification of root cause and contributing factors that drive events. These guidance documents can be used by the Registered Entity along with any other available information they may have to establish a consistent RCA methodology. This RCA methodology will assist those responsible for determining the root of the noncompliance and contributing factors in addition to any latent deficiencies. 10 of 23

11 Root Cause Example: CIP-007 R3 - Entity failed to assess security Patches for 7 Cyber Assets used in Generation Management System. The root cause was a lack of After this issue was discovered, No root cause provided process to assess and implement security patches. an investigation was conducted to determine the root cause of the violation. The results of the investigation highlighted a few reasons which led to this violation. Firstly, there was a failure to establish a clear process to assess and implement security patches. Specifically, there is a patch management in place; however, the person responsible for assessing and implementing patches was not informed about these responsibilities. This person had recently moved into this role and was not aware of the new job duties and as a result did not assess these security patches. Secondly, there was a lack of automatic notification of a new security patch being made available and as a result the person responsible for assessing patches was required to manually visit the vendor s web site to download security patches. Since the person was not aware of the job responsibility and there was not an automatic notification, these security patches were not assessed and implemented. 11 of 23

12 Root Cause Example: PRC-005-1b R2.1 Entity failed to provide evidence that its Protection System devices were maintained and tested within the defined intervals of its Protection System maintenance and testing program. The root cause was a personnel issue. The individual responsible for completing the maintenance was on vacation and no backup responsibility was identified. Following a root cause investigation, it was identified that the Protection System maintenance and testing program did not include both Primary and Backup responsibilities to ensure that all Protective Device maintenance and testing will be completed within the defined intervals. Additionally, the software use to track the maintenance was not fully utilized to include the use of notifications to management when required maintenance and testing intervals are at risk. Corrective, Preventive, and Detective Actions Corrective Actions should be designed with the primary intent to mitigate the possible noncompliance and restore compliance with the Reliability Standard(s) as quickly as possible. Corrective Actions should also consider the Root Cause and any other Reliability Standards impacted by the possible noncompliance. After determining the Corrective Actions, the Registered Entity should ensure any un-documented knowledge (e.g. something an employee knows and performs on a regular basis but is not documented) becomes documented and training on updated and new procedures is provided to relevant personnel. The Registered Entity should document any training records. Preventive and detective actions should be taken with the primary intent to detect the noncompliance in advance and prevent it from reoccurring. Preventive actions are designed to keep noncompliance from occurring and detective actions are designed to detect noncompliance that may have occurred. When identifying these actions, the Registered Entity should focus on both procedural and technical internal controls that may be available to help detect and prevent future occurrences. 12 of 23

13 Corrective Actions Example: CIP-007 R3 - Entity failed to assess security Patches for 7 Cyber Assets used in Generation Management System. Patches were assessed. The patch management program was restarted, and the missed patches were assessed 38 days after availability and have been applied. Immediately upon realizing the patch management application had failed, IT staff restarted the application on April 9, 2012 and inventoried those patches that were not assessed/applied. The 12 missed patches were assessed the same day, 38 days after their availability. These patches were subsequently installed. We now verify daily that the patch management server is operating properly. Personnel responsible for patch management have received training on updated procedures and daily requirements. Corrective Actions Example: PRC-005-1b R2.1 Entity failed to provide evidence that its Protection System devices were maintained and tested within the defined intervals of its Protection System maintenance and testing program. The missed maintenance was completed. Once it was identified that the battery maintenance was missed, the maintenance was completed satisfactorily. It was identified on April 4, 2014, that the quarterly battery maintenance for one 230kV substation battery bank was not completed as required in the Protection System maintenance and testing program. On April 5, 2014 the missed maintenance was completed in accordance with the requirements in the Protection System maintenance and testing program. Completion of the missed maintenance indicated that the substation batteries were in proper working condition. 13 of 23

14 Preventive Actions Example: CIP-007 R3 - Entity failed to assess security Patches for 7 Cyber Assets used in Generation Management System. Patch assessments will be periodically reviewed for accuracy. Patch assessments will be reviewed with patches released periodically to verify all patches released are assessed. New patch tracking system will be developed. Procedural steps to be taken include requiring monthly review of the patch assessments by the EMS team. During this review, the list of patches assessed will be compared with the list of patches released by a vendor. Technical controls taken will include implementing a new patch tracking system to reduce likelihood patches go unnoticed. The system will notify EMS personnel immediately when a new patch or upgrade is made available. Preventive Actions Example: PRC-005-1b R2.1 Entity failed to provide evidence that its Protection System devices were maintained and tested within the defined intervals of its Protection System maintenance and testing program. The procedure will be updated. The Protection System maintenance and testing program will be revised to include appropriate responsibilities for the maintenance. Primary and Backup responsibilities for the completion of all required maintenance in the Protection System maintenance and testing program will be identified and added to the procedure. The tracking software will be updated to include notifications to management when required maintenance and testing intervals are at risk. All appropriate personnel will be trained on the updated procedure and process. 14 of 23

15 Detective Actions Example: CIP-004 R4 - Physical access to a substation for 12 personnel was not revoked within 7 days. Will periodically review access lists for accuracy. Will review access lists every 2 weeks to verify access is accurate. Physical access system was updated. Procedural controls have been updated to require Physical Security to generate report of all individuals with access to PSPs every 2 weeks and require review and approval of lists by asset owner to verify access lists are accurate. Technical controls have also been taken, with the updating of the physical security system to automatically update the access list upon access change or revocation. Detective Actions Example: PRC-005-1b R2.1 Entity failed to provide evidence that its Protection System devices were maintained and tested within the defined intervals of its Protection System maintenance and testing program. An inventory of the system will be completed. An inventory of PRC-005 related Protection System devices will be completed to ensure that all components have been identified. An inventory of all Protection System devices will be completed to determine the components that are applicable to the requirements in PRC-005. The PRC-005 component list will be updated and the previous maintenance and testing completion dates will be compared to the intervals set forth in the Protection System maintenance and Testing program. The tracking software will be updated to include notifications to management when required maintenance and testing intervals are at risk. Any maintenance that has exceeded an interval shall be completed and reported to the Compliance Enforcement Authority. 15 of 23

16 Milestones For Mitigation Plans that take longer than three months, milestones are required and are used to track the Registered Entity s progress. Milestones should be relevant, measurable, and realistic for meeting the proposed completion date. Milestones are required when a proposed completion date is later than three months from submission. Each milestone completion date should be no more than three months apart. Although milestones are not required for Mitigation Plans that are completed in less than three months, Registered Entities are encouraged to have milestones to help both the CEA and Registered Entity track progress and identify any potential issues that could impact the proposed completion date. Milestone Example: CIP-007 R3 - Entity failed to assess security Patches for 7 Cyber Assets used in Generation Management System Verify patch management as running. Proposed Completion/Due Date for Milestone: March 17, 2014 Add patch management server to automated health check system. Proposed Completion/Due Date for Milestone: March 17, 2014 Add patch management server to automated health check system and include a verification control to verify the health check system is running and document results. Proposed Completion/Due Date for Milestone: March 17, 2014 Milestone Example: PRC-005-1b R2.1 Entity failed to provide evidence that its Protection System devices were maintained and tested within the defined intervals of its Protection System maintenance and testing program. Complete all missed maintenance. Proposed Completion/Due Date for Milestone: May 21, 2014 Complete any missed Protective System device maintenance in accordance with the Protective System maintenance and testing program. Proposed Completion/Due Date for Milestone: May 21, 2014 Perform an inventory of all Protective System devices and ensure that all Protective System devices applicable to the requirements of PRC-005 have been maintained in accordance with the intervals set forth in the Protective System maintenance and testing program. Proposed Completion/Due Date for Milestone: July 19, of 23

17 Proposed Completion Date The proposed completion date is the expected date when all Corrective Actions outlined in the Mitigation Plan, including any milestones will be completed. The Registered Entity should consider the scope of actions outlined in the Mitigation Plan, assumptions, risks, and dependencies that may impact the proposed completion date. There are times when a proposed completion date may need to be extended after a Mitigation Plan has been accepted. Section 6.3 of the CMEP states that at the CEA s discretion, the completion deadline may be extended for good cause including, but not limited to: Operational issues such as the inability to schedule an outage to complete Mitigating Activities, and Construction requirements in the Mitigation Plan that require longer completing than originally anticipated. A request of an extension of any milestone or the completion date of the accepted Mitigation Plan by a Registered Entity must be received by the CEA at least five (5) business days before the original milestone or mitigation plan completion date. Interim Risk Reduction The Registered Entity must include steps that will reduce or eliminate risk to the BPS while the Mitigation Plan is being implemented. This step is especially critical for plans with longer durations. In determining interim actions and activities, Registered Entities should identify and address any risks to the BPS that may exist while the mitigation is in progress. It should include those steps that may have already been taken and are in place to reduce or eliminate risk to the BPS. Entities should consider the functions performed by the assets that are in the scope of the Mitigation Plan, and whether or not the functions performed by these assets are/could be impacted during mitigation. Based on the above considerations, actions and activities listed in the plan should include internal controls in place to mitigate the risk to the BPS. Interim Risk Reduction Example: CIP-007 R3 - Entity failed to assess security Patches for 7 Cyber Assets used in Generation Management System There is no risk to the BPS while this noncompliance is being mitigated The process of implementing this Mitigation Plan will present a low risk to the BPS. The current process of evaluating and deploying patches as required per CIP-007 R3 throughout the mitigation plan timeline will be maintained. The risk to the reliability of the BPS remains low until this Mitigation Plan is implemented. There are various compensating measures in place as part of an indepth protection strategy. The 7 Cyber Assets that are involved in the noncompliance have a layered approach that includes isolation by firewalls. This makes it difficult for unauthorized internal or external access to occur. The 7 Cyber Assets are monitored for electronic and physical access, specifically access reports are generated and 17 of 23

18 reviewed by the entity s security personnel to monitor unauthorized attempts into the electronic and physical perimeter. This allows any access to the assets to be known immediately at the time of access. Interim Risk Reduction Example: PRC-005-1b R2.1 Entity failed to provide evidence that its Protection System devices were maintained and tested within the defined intervals of its Protection System maintenance and testing program. There is no risk to the BPS while this noncompliance is being mitigated. There is a low risk to the BPS while the Mitigation Plan is being completed. The initial mitigating activities to complete the missed maintenance reduced the risk to the BPS. Although the initial mitigating activities to complete the missed maintenance reduced the risk, a low risk to the reliability of the BPS will exist until the Mitigation Plan is complete. Inadequate maintenance and testing of Protective System devices can, for a system event, result in improper protective actions leading to BPS equipment damage or a delayed system restoration. 18 of 23

19 Prevention of Future Reliability Risk Mitigation Plan Contents Prevention of future risk to the reliability of the BPS should detail how the successful completion of the Mitigation Plan prevents or minimizes the probability that the Registered Entity will violate the same or similar reliability standards again. Additionally, the Registered Entity should state how the Mitigation Plan actions taken will prevent future risk to the Reliability of the BPS. By completing the actions in the Mitigation Plan, the Registered Entity had prevented the likelihood of recurrence. By adding a patch management server to automated health check system, the Registered Entity has put a system in place to prevent future recurrence of violating the Reliability Standard. By adding a patch management server to the automated health check system and including a verification control to verify the health check system is running and document results, the Registered Entity has added an additional control to ensure that the reliability standard is not violated in the future. Additionally, the Registered Entity conducted training with all affected employees to ensure the employees understood the requirements of the standard and what is required of each employee to meet the requirements of the standard. Also, the Registered Entity has created additional positions related to NERC CIP compliance to address the fast growing needs of the Registered Entity to comply with the Reliability Standards. 19 of 23

20 Prevention of Future Reliability Risk Example: PRC-005-1b R2.1 Entity failed to provide evidence that its Protection System devices were maintained and tested within the defined intervals of its Protection System maintenance and testing program. A backup will be identified. The Protection System maintenance and testing program will be updated to include Primary and Backup responsibilities. Primary and Backup responsibilities for the completion of all required maintenance in the Protection System maintenance and testing program will be identified and added to the procedure. The tracking software will be updated to include notifications to management when required maintenance and testing intervals are at risk. All appropriate personnel will be trained on the updated procedure and process. 20 of 23

21 Appendix A Mitigation Plan Checklist Appendix A Mitigation Plan Checklist Mitigation Plan Checklist This checklist is intended to provide a quick outline of the topics discussed in the ERO Mitigation Plan Guide. The drafters have modeled the flow and content of the guide and checklist to that of both portals (i.e., CTS and webcdms) used by Registered Entities when completing and submitting a Mitigation Plan to their respective Regional Entities. Does the plan describe the scope of the noncompliance being mitigated? Has the scope changed from what was originally reported (e.g. additional devices/facilities/personnel found to be in scope)? Does the plan describe the cause of the noncompliance? Has the root cause been identified? Were there any contributing factors identified? Does the plan include all corrective, detective, and prevention of recurrence actions? Do the actions relate to requirements in scope? What is being mitigated? How is it being mitigated? When is it being mitigated? Has prevention of recurrence been addressed? Have all actions taken to resolve the noncompliance and prevent recurrence been included? Have completion dates for all actions completed prior to submission of the plan been included? Does the plan include milestones as needed? Have milestones been defined where appropriate (for future dated actions)? o If milestones are included, do the milestones have sufficient detail? o Are the milestone intervals reasonable? o Are the milestone intervals no longer than 3 months apart? Remember to retain evidence to provide proof of completion for all actions taken. Does the plan include a proposed completion date? Will all milestones be completed prior to the proposed plan completion date? Describe the interim risk associated with the reliability of the BPS while the Mitigation Plan is being implemented. Does the mitigation plan contain interim steps to address this risk? Describe the prevention of future risk to the reliability of the BPS. How will the successful completion of this Mitigation Plan prevent or minimize the probability that your organization incurs further risk of Alleged Violations of the same or similar reliability standards requirements in the future? How will the Mitigation Plan actions taken prevent the likelihood of recurrence? 21 of 23

22 Appendix B Reference Documents Appendix B Reference Documents FERC Guidance or Reference Documents North American Electric Reliability Corporation, 138 FERC 61,193 (2012) (March 2012 FFT Order) North American Electric Reliability Corporation, 134 FERC 61,209 (2011) (Turlock Order) Enforcement of Statutes, Orders, Rules, and Regulations, 132 FERC 61,216 (2010) (Revised Policy Statement on Penalty Guidelines) Further Guidance Order on Filing Reliability Notices of Penalty, 129 FERC 61,069, issued October 26, 2009: Guidance Order on Reliability Notices of Penalty, 124 FERC 61,015 (2008) Policy Statement on Compliance issued October 16, Revised Policy Statement on Enforcement issued May 15, FERC Overall Approach to Root Cause Analysis, Department of Energy Root Cause Analysis Guidance Document, NERC Guidance or Reference Documents Cause Analysis Methods for NERC, Regional Entities, and Registered Entities, issued September 2011: for%20nerc,%20regional%20entities,%20and%20registered%20entities_ _rev1.pdf NERC Guidance on Self-Reports, Version 1.1, issued October 17, 2012: NERC Rules of Procedure Sanction Guidelines of the North American Electric Reliability Corporation pdf Compliance Monitoring and Enforcement Program Regional Entity Guidance or Reference Documents OATI webcdms Registered Entity Training Scenarios V1.2, dated January 2012: 0v1%202.pdf 22 of 23

23 Appendix C Detailed Description of the Potential Noncompliance Mitigation Plan Appendix C Detailed Description of the Potential Noncompliance Mitigation Plan A quality Mitigation Plan 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, and mitigating activities (i.e., scope determination; root cause analysis; corrective, detective, and preventive actions) that have or will be completed. The table below lists the information that should be included in a Mitigation Plan for Sections C, D, and E, as well as the applicable field in the webcdms and Compliance Portal applications in which to include the information. Desired Information webcdms Mitigation Plan Section (MRO, ReliabilityFirst, SPP RE, Texas RE, WECC) Compliance Portal Mitigation Plan Section (FRCC, NPCC, SERC) Scope of Possible Noncompliance C.2 Scope Review or Extent of Condition C.3 Corrective Actions D.1 Detective Actions D.1 Preventive Actions D.1 Milestones D.3 Proposed Completion Date D.2 Interim Risk Reduction E.1 Prevention of Future Reliability Risk E.2 23 of 23