What Is NERC and What Does It Stand For?
NERC stands for the North American Electric Reliability Corporation. It is a not-for-profit international regulatory authority focused on the reliability and security of the North American bulk power system. In the United States, NERC operates as the Electric Reliability Organization under Federal Energy Regulatory Commission (FERC) oversight.
What Is NERC CIP?
NERC CIP refers to the Critical Infrastructure Protection Reliability Standards developed by NERC. Their purpose is to reduce security risks that could disrupt the reliable operation of the Bulk Electric System (BES). The cyber security requirements protect BES Cyber Systems against compromises that could cause misoperation or instability in the grid.
What Is NERC CIP Compliance?
NERC CIP compliance means implementing the applicable security requirements and maintaining evidence that they are being met. Organizations must establish documented policies and procedures, put the required safeguards into operation, and complete assessments, reviews, and other activities within the specified timelines.
For security teams, this includes keeping records of control testing, configuration changes, remediation actions, and incident-response exercises. These records help demonstrate how the organization follows its processes and addresses identified weaknesses.
Who Does NERC CIP Apply To?
NERC CIP applies to the Responsible Entities and facilities identified in each standard. These include balancing authorities, generator owners and operators, reliability coordinators, transmission owners and operators, and distribution providers with specified BES protection or restoration facilities.
The requirements an organization must implement depend on its systems and their impact categorization under CIP-002.
- High and medium impact BES Cyber Systems fall within the detailed requirements of the standards discussed below, subject to each requirement's scope.
- Assets containing low impact BES Cyber Systems have a separate set of requirements under CIP-003-9 R2 and Attachment 1.
- Associated systems can also be covered, including Electronic Access Control or Monitoring Systems (EACMS), Physical Access Control Systems (PACS), and Protected Cyber Assets (PCA), where the requirement lists them.
The Applicable Systems column in a requirement table defines which systems each part covers. Scope can vary within the same standard, so teams need to connect each requirement to the systems and evidence it covers. The applicability guidance in CIP-005-7 explains these distinctions.
How Many NERC CIP Standards Are There?
As of September 2026, NERC's register includes 14 distinct CIP standard numbers, from CIP-002 through CIP-015. Some have multiple versions listed. These versions are revisions of the same standard and do not count as separate standards.
Enforcement status applies to each specific version. For example, CIP-003-9 is listed as Mandatory Subject to Enforcement, while CIP-003-10 and CIP-003-11 are listed as Subject to Future Enforcement. CIP-002 through CIP-014 each have a version listed as currently mandatory, while the listed CIP-015 versions are subject to future enforcement. Teams should check the version and implementation dates applicable to their jurisdiction.
What Are the NERC CIP Standards?
The NERC CIP standards address system categorization, security governance, personnel training, electronic and physical access, system security, incident response, recovery, configuration changes, vulnerability assessments, information protection, control-center communications, and supply chain risks. Each standard contains requirements for a particular area of protection.
How Does Picus Help with NERC CIP Compliance?
The Picus Platform supports NERC CIP compliance by continuously validating exposures, attack paths, and the security controls protecting BES Cyber Systems. It produces the evidence security teams need to verify prevention and detection, prioritize remediation, and demonstrate security outcomes to the CIP Senior Manager, compliance teams, and auditors.
The sections below explain how this work supports specific NERC CIP requirements.
CIP-005-7 and CIP-007-6: Malicious Communication Detection, Malicious Code Prevention, and Security Monitoring
|
“Have one or more methods for detecting known or suspected malicious communications for both inbound and outbound communications.” (CIP-005-7, R1, Part 1.5) “Deploy method(s) to deter, detect, or prevent malicious code.” (CIP-007-6, R3, Part 3.1) “Mitigate the threat of detected malicious code.” (CIP-007-6, R3, Part 3.2) “For those methods identified in Part 3.1 that use signatures or patterns, have a process for the update of the signatures or patterns. The process must address testing and installing the signatures or patterns.” (CIP-007-6, R3, Part 3.3) “Log events at the BES Cyber System level (per BES Cyber System capability) or at the Cyber Asset level (per Cyber Asset capability) for identification of, and after-the-fact investigations of, Cyber Security Incidents that includes, as a minimum, each of the following types of events: 4.1.1. Detected successful login attempts; 4.1.2. Detected failed access attempts and failed login attempts; 4.1.3. Detected malicious code.” (CIP-007-6, R4, Part 4.1) “Generate alerts for security events that the Responsible Entity determines necessitates an alert, that includes, as a minimum, each of the following types of events (per Cyber Asset or BES Cyber System capability): 4.2.1. Detected malicious code from Part 4.1; and 4.2.2. Detected failure of Part 4.1 event logging.” (CIP-007-6, R4, Part 4.2) |
Together, these requirements connect malicious communication detection, malicious code protection, and the logs and alerts needed to investigate security events. Security control validation helps teams check whether their deployed controls prevent or detect the tested activity and continue to work as configurations and attacker techniques change.
How Does Picus Support These Requirements?
Picus Breach and Attack Simulation (BAS) simulates real-world threats to test deployed prevention and detection controls. Network and e-mail infiltration attack simulations test whether security controls block or detect malicious code, including malware and ransomware, delivered through these channels. Web attack simulations test whether security controls block or detect attacks targeting web applications. Endpoint attack simulations test how controls respond to attacker techniques executed on the system.
These simulations draw on the Picus Threat Library, maintained by Picus Labs and updated daily with adversary behaviors, techniques, and attack scenarios. Its MITRE ATT&CK mappings help teams select relevant techniques and understand which attack behaviors their defenses prevent or detect. As new threats emerge, teams can use the updated library to test their existing controls against those techniques.
Figure 1. Picus Threat Library, Network Infiltration Attacks Module
Picus measures how those controls respond to the simulated attacks, showing what was blocked, what triggered an alert, what was only logged, and what was missed. For example, a simulated command-and-control technique may generate a security-device log without triggering the expected SIEM alert. That result gives the team a specific detection gap to investigate.
The Picus Mitigation Library provides vendor-specific prevention signatures and detection rules, together with vendor-neutral Sigma rules, to address identified gaps. After applying the relevant fix, teams can rerun the same simulation to verify whether the updated controls prevent or detect the technique.
Figure 2. Picus Mitigation Library provides vendor-specific and vendor-neutral mitigation.
Picus Detection Rule Validation also examines the health of the detection rules themselves without running simulations. It checks log sources, alerting, and performance to identify broken, silent, or skipped rules. This helps the SOC identify the cause of a detection gap, address it, and revalidate after the fix.
Together, these capabilities support CIP-005-7 R1, Part 1.5 and CIP-007-6 R3 and R4 by providing evidence of the effectiveness of the tested prevention and detection controls. The results document the techniques tested, the gaps found, and the outcome after each fix.
CIP-010-4 R3 and CIP-007-6 R2: Prioritizing Vulnerability Remediation
|
“Document the results of the assessments conducted according to Parts 3.1, 3.2, and 3.3 and the action plan to remediate or mitigate vulnerabilities identified in the assessments including the planned date of completing the action plan and the execution status of any remediation or mitigation action items.” (CIP-010-4, R3, Part 3.4) “For applicable patches identified in Part 2.2, within 35 calendar days of the evaluation completion, take one of the following actions: • Apply the applicable patches; or • Create a dated mitigation plan; or • Revise an existing mitigation plan. Mitigation plans shall include the Responsible Entity’s planned actions to mitigate the vulnerabilities addressed by each security patch and a timeframe to complete these mitigations.” (CIP-007-6, R2, Part 2.3) “For each mitigation plan created or revised in Part 2.3, implement the plan within the timeframe specified in the plan, unless a revision to the plan or an extension to the timeframe specified in Part 2.3 is approved by the CIP Senior Manager or delegate.” (CIP-007-6, R2, Part 2.4) |
As new CVEs are disclosed, teams face a growing backlog of vulnerabilities to assess and address. Limited remediation resources and operational maintenance windows make prioritization essential. Teams need to determine which findings pose the greatest risk to their environment and should receive attention first.
Understanding whether an exposure can be exploited, which critical assets it could affect, and whether existing controls stop the associated attack techniques helps teams set those priorities. This gives them a documented basis for directing remediation effort toward the exposures that matter most while meeting the required patching and mitigation timelines.
How Does Picus Support These Requirements?
Picus Autonomous Penetration Testing executes real exploits where testing is safe and a suitable exploit is available. It chains vulnerabilities, exposed credentials, and misconfigurations within boundaries set by the team to show how an attacker could move from an initial foothold toward critical assets.
Figure 3. Picus Autonomous Penetration Testing finds attack paths to critical assets.
For systems too critical to run a live exploit against, or CVEs with no suitable public exploit, Picus Exposure Validation determines whether the exposure is exploitable in your environment without running a live exploit against those systems.
With these capabilities, Picus adds exploitability and security control effectiveness evidence to existing vulnerability findings. By combining that evidence with vulnerability severity and asset criticality, it helps teams prioritize the exposures an attacker could use to reach critical systems and determine which mitigations to apply.
These findings help teams explain which exposures they prioritized and why. Teams can include them in their action plans, together with the affected assets, target completion dates, and progress updates. This supports CIP-010-4 Part 3.4 and CIP-007-6 Parts 2.3 and 2.4.
CIP-010-4 R1: Verifying Controls After Configuration Changes
|
“For a change that deviates from the existing baseline configuration: 1.4.1. Prior to the change, determine required cyber security controls in CIP-005 and CIP-007 that could be impacted by the change; 1.4.2. Following the change, verify that required cyber security controls determined in 1.4.1 are not adversely affected; and 1.4.3. Document the results of the verification.” (CIP-010-4, R1, Part 1.4) “Where technically feasible, for each change that deviates from the existing baseline configuration: 1.5.1. Prior to implementing any change in the production environment, test the changes in a test environment or test the changes in a production environment where the test is performed in a manner that minimizes adverse effects, that models the baseline configuration to ensure that required cyber security controls in CIP-005 and CIP-007 are not adversely affected; and 1.5.2. Document the results of the testing and, if a test environment was used, the differences between the test environment and the production environment, including a description of the measures used to account for any differences in operation between the test and production environments.” (CIP-010-4, R1, Part 1.5) |
A firewall or endpoint configuration update can change how a control blocks or detects malicious activity. Validation helps teams confirm that protection still works after the update and record the results.
How Does Picus Support This Requirement?
Picus Breach and Attack Simulation lets teams test the attacker techniques relevant to an affected control before and after a change. The comparison shows whether an attack that was previously blocked now succeeds, whether an alert has stopped firing, and whether the update closed the gap it was intended to address.
Picus Swarm brings signal-driven workflows to this process through five specialist AI agents orchestrated by Numi AI. Numi AI monitors external feeds and internal changes, and customer-defined triggers determine which signals start a validation workflow. A changed firewall policy or detection rule can trigger the relevant checks as part of the entity's change process.
The Discovery Agent identifies the affected assets and exposures. The Exploitation Agent validates attack paths where live testing is permitted, while the Validation Agent checks the associated prevention and detection controls. The Mobilization Agent turns gaps into remediation actions, and the Reporting Agent records the results. This connects the change, the test, the fix, and the retest in one workflow.
Figure 4. Numi AI orchestrating Picus Swarm’s five specialist agents.
Teams choose Manual, Supervised, or Fully Autonomous operation for each workflow, with an auditable record of agent actions, so autonomy never means a black box.
The results show when each control was tested and how it performed after the change. Teams can use them to support the checks required by Part 1.4 and the testing required by Part 1.5.
CIP-008-6 R2, R3, and R4: Exercising Incident Response and Checking Improvements
|
“Test each Cyber Security Incident response plan(s) at least once every 15 calendar months: • By responding to an actual Reportable Cyber Security Incident; • With a paper drill or tabletop exercise of a Reportable Cyber Security Incident; or • With an operational exercise of a Reportable Cyber Security Incident.” (CIP-008-6, R2, Part 2.1) “Use the Cyber Security Incident response plan(s) under Requirement R1 when responding to a Reportable Cyber Security Incident, responding to a Cyber Security Incident that attempted to compromise a system identified in the “Applicable Systems” column for this Part, or performing an exercise of a Reportable Cyber Security Incident. Document deviations from the plan(s) taken during the response to the incident or exercise.” (CIP-008-6, R2, Part 2.2) “No later than 90 calendar days after completion of a Cyber Security Incident response plan(s) test or actual Reportable Cyber Security Incident response: 3.1.1. Document any lessons learned or document the absence of any lessons learned; 3.1.2. Update the Cyber Security Incident response plan based on any documented lessons learned associated with the plan; and 3.1.3. Notify each person or group with a defined role in the Cyber Security Incident response plan of the updates to the Cyber Security Incident response plan based on any documented lessons learned.” (CIP-008-6, R3, Part 3.1) “After the Responsible Entity’s determination made pursuant to documented process(es) in Requirement R1, Part 1.2, provide initial notification within the following timelines: • One hour after the determination of a Reportable Cyber Security Incident. • By the end of the next calendar day after determination that a Cyber Security Incident was an attempt to compromise a system identified in the “Applicable Systems” column for this Part.” (CIP-008-6, R4, Part 4.2) |
Teams need to know whether their response plans work in practice. Exercises help them check how alerts are escalated, how response decisions are made, and whether the information needed for timely notification reaches the right people. The findings help teams improve their plans and document the changes.
How Does Picus Support This Requirement?
Before an incident, Picus Breach and Attack Simulation tests the attacker techniques that could lead to a compromise and records how prevention and detection controls respond. Validation reports document the controls tested, the gaps found, the fixes applied, and the results of retesting. These records give responders a history of security validation they can review alongside investigation findings if an incident occurs.
Picus findings also help security teams exercise their response plans as part of routine security validation. As teams use Picus, they practice how alerts reach the SOC, how responders assess affected systems, and how information reaches those responsible for incident classification and notification. This gives teams opportunities to check reporting decisions and timelines against the plan, identify deviations, and capture lessons learned.
After an exercise or a contained incident, teams can test the techniques associated with the weaknesses they addressed. Rerunning the same scenarios shows whether the updated controls prevent or detect those techniques and reveals any remaining gaps. This helps reduce the risk of a similar incident and provides evidence of the effectiveness of the tested improvements.
Together with the response team's exercise records, investigation findings, and plan updates, Picus results help the entity explain what it tested before the incident, what it changed afterward, and how its defenses improved.
CIP-003-9 R1: Supporting Security Policy Reviews
|
“Each Responsible Entity shall review and obtain CIP Senior Manager approval at least once every 15 calendar months for one or more documented cyber security policies” (CIP-003-9, R1) |
Security policy reviews benefit from evidence of how defenses perform, which exposures remain open, and how far an attacker could progress through the environment. Teams can use these findings to assess whether their policies address the weaknesses found and whether changes to security practices are needed, supporting the review and approval process under R1.
How Does Picus Support This Requirement?
Picus Breach and Attack Simulation weekly and monthly reports provide security scores, performance trends, and details of threats blocked or missed. MITRE ATT&CK coverage and custom dashboards help teams review testing coverage and changes in prevention and detection over time.
Figure 5. Picus dashboard widgets showing security scores, trends, and MITRE ATT&CK coverage.
Picus Autonomous Penetration Testing reports show the attack paths demonstrated during an assessment, the systems reached, and the privileges gained. They document vulnerabilities, exposed credentials, and misconfigurations, with supporting evidence and mitigation recommendations. Priority mitigation actions highlight where teams can break a successful attack chain.
Picus Exposure Validation reports bring vulnerability findings from integrated tools together with validation insights that help teams prioritize remediation based on risk in their environment. Exported findings also identify affected assets, when an exposure was first seen, its status, and associated remediation and ticket counts. This helps teams explain which exposures need attention and review whether their remediation priorities reflect the risk in their environment.
Together, these records connect security performance, demonstrated attack paths, and exposure priorities to policy decisions. For example, an attack path enabled by exposed credentials may prompt a review of privileged access practices. High-priority exposures that remain open may prompt a review of how remediation work is assigned and followed through. Later assessments can help teams evaluate whether those changes reduced exposure.
Security and compliance teams can bring these findings into the material prepared for the CIP Senior Manager's policy review. They provide evidence to inform policy updates and implementation decisions.
Meeting NERC CIP Requirements with Signal-Driven Validation
NERC CIP sets requirements for protecting BES Cyber Systems and documenting the work. Between scheduled assessments, security controls continue to change. Firewall policies are updated, detection rules lose visibility, and new vulnerabilities create attack paths that teams need to investigate.
Picus brings testing, remediation, and retesting into a signal-driven workflow. Breach and Attack Simulation measures what defenses block and detect. Autonomous Penetration Testing validates real attack paths, while Exposure Validation assesses exploitability even when a live exploit cannot be run against the affected system. Picus Swarm, orchestrated by Numi AI, coordinates validation and remediation workflows as new threats and configuration changes trigger them.
For organizations responsible for BES Cyber Systems, this connects day-to-day security improvements with the evidence needed for NERC CIP reviews. Security teams can show which attack paths remain open, which exposures need attention, and whether remediation has reduced risk. Compliance teams and the CIP Senior Manager can use that record to assess progress and make informed decisions as threats and systems change.
Book a Picus demo to see how security validation can help your organization prioritize remediation, verify control effectiveness, and build defensible evidence for NERC CIP compliance.
.png?width=353&height=200&name=Picus-gartner-july22-post1%20(3).png)
.png?width=353&height=200&name=Picus-gartner-reprint-march10-1%20(1).png)
.png?width=353&height=200&name=vulnerability-vs-exposure-blog-preview%20(1).png)