Key takeaways
- CIP-007-6 is not the end of the story.
- Treat R2's 35/35-day clock as two separate deadlines, not one.
NERC CIP-007, "Cyber Security — System Security Management," is the mandatory NERC Reliability Standard that sets the day-to-day technical security baseline for North American bulk power system cyber assets: which network ports and services stay open, how security patches get evaluated and applied, how malicious code is deterred and handled, what gets logged and alerted on, and how system access is authenticated and controlled. Per its own Purpose statement, it exists "to manage system security by specifying select technical, operational, and procedural requirements in support of protecting BES Cyber Systems against compromise that could lead to misoperation or instability in the Bulk Electric System (BES)." The currently enforceable version, CIP-007-6, was approved by FERC on 21 January 2016; a successor, CIP-007-7.1, is already FERC-approved but not yet mandatory — see the revision section below.
Who it applies to, and for which systems
CIP-007-6's Applicability section names specific "Responsible Entities": Balancing Authorities, certain Distribution Providers (those owning specified load-shedding, Special Protection System/Remedial Action Scheme, or transmission Protection System facilities), Generator Operators, Generator Owners, Interchange Coordinators/Authorities, Reliability Coordinators, Transmission Operators and Transmission Owners. The Requirements apply to each entity's high- and medium-impact BES Cyber Systems and their associated Electronic Access Control or Monitoring Systems (EACMS), Physical Access Control Systems (PACS) and Protected Cyber Assets (PCA) — the standard's own "Applicable Systems" convention scopes individual table rows more tightly still, for example limiting some parts to "Medium Impact BES Cyber Systems with External Routable Connectivity" or "at Control Centers" specifically. Five categories are explicitly exempt, including Cyber Assets at facilities regulated by the Canadian Nuclear Safety Commission and systems regulated by the US Nuclear Regulatory Commission under 10 C.F.R. § 73.54.
The five requirements, table by table
CIP-007-6 organizes its substantive obligations into five numbered Requirements, each built from a table of parts with matching Applicable Systems, Requirements and Measures columns:
| Req. | Table | What it requires |
|---|---|---|
| R1 | Ports and Services | Enable "only logical network accessible ports that have been determined to be needed," including handling dynamic port ranges; protect unnecessary physical I/O ports used for network connectivity, console commands or removable media |
| R2 | Security Patch Management | Track patch-release sources; evaluate new patches for applicability "at least once every 35 calendar days"; within 35 days of that evaluation, apply the patch, create a dated mitigation plan, or revise an existing one; implement mitigation plans within their stated timeframe |
| R3 | Malicious Code Prevention | Deploy methods to "deter, detect, or prevent malicious code"; mitigate detected code; maintain a tested process for updating signatures/patterns where those methods use them |
| R4 | Security Event Monitoring | Log successful logins, failed access/login attempts and detected malicious code at minimum; generate alerts for specific event types (such as detected malicious code or logging failure); retain logs for at least 90 consecutive calendar days where technically feasible; review a summarization or sample of logged events at intervals no greater than 15 calendar days |
| R5 | System Access Control | Enforce authentication for interactive user access where technically feasible; inventory enabled default/generic accounts; identify individuals with authorized access to shared accounts; change known default passwords; for password-only authentication, enforce minimum length/complexity and periodic changes (at least every 15 calendar months); limit or alert on unsuccessful authentication attempts |
Each Requirement carries a Violation Risk Factor — all five are rated Medium in CIP-007-6 — and a Time Horizon ranging from "Same Day Operations" (R1, R3, part of R4) to "Operations Planning" (R2, R5) and "Operations Assessment" (part of R4), reflecting how quickly a gap in that control could translate into reliability risk.
Compliance: evidence retention and enforcement
CIP-007-6's Compliance section names the NERC Compliance Enforcement Authority (CEA) — NERC itself or the relevant Regional Entity — as responsible for monitoring and enforcing the standard, through Compliance Audits, Self-Certifications, Spot Checking, Compliance Violation Investigations, Self-Reporting and Complaints. Responsible Entities must retain evidence demonstrating compliance with each Requirement for three calendar years; if a non-compliance is found, evidence must be kept until mitigation is complete and approved, or for three years, whichever is longer.
A revision is already approved: CIP-007-7.1, effective 2028
CIP-007-6 is not the end of the story. Under NERC's Project 2016-02 (Virtualization), NERC petitioned FERC on 10 July 2024 (supplemented 20 May 2025) for approval of 11 modified CIP Reliability Standards, including CIP-007-7.1, alongside four new NERC Glossary definitions — Cyber System, Management Interface, Shared Cyber Infrastructure and Virtual Cyber Asset — meant to let Responsible Entities apply virtualization to BES Cyber Systems without fighting the CIP suite's traditionally hardware-centric assumptions. FERC's Order No. 919 (Docket No. RM24-8-000, published at 91 FR 13957) approved all 11 standards; per the Federal Register notice, the Commission "approves 11 modified Critical Infrastructure Protection (CIP) Reliability Standards," naming "CIP-007-7.1 (Cyber Security — Systems Security Management)" explicitly. The order itself was issued 19 March 2026 and states "this final action is effective May 26, 2026."
NERC's own implementation plan, quoted in the order, sets the standards' effective date as "the later of April 1, 2026, or the first day of the first calendar quarter that is 24 months after the effective date of the applicable governmental authority's order approving the Reliability Standards and definitions." Counting 24 months from the order's 26 May 2026 effective date lands on 26 May 2028; the next first-of-quarter date after that is 1 July 2028 — the date multiple secondary trackers cite as the mandatory compliance date for the full set of 11 standards. The implementation plan also permits early adoption 6, 12 or 18 months after the order's effective date, for entities that notify their Regional Entity. A separate, narrower change the order describes: replacing a self-implementing "technical feasibility exception" phrase with "per system capability" wording in places, after NERC reported a drop in submitted technical feasibility exceptions under the prior language.
This guide has not reviewed NERC's final CIP-007-7.1 text directly (it was not yet posted as a standalone clean PDF at the time of research) — treat any claim about exactly which Requirements or Parts of CIP-007 change wording, beyond the virtualization-definition and "per system capability" points described in FERC's order, as to be confirmed against NERC's and FERC's own published CIP-007-7.1 text.
How this fits with the rest of the CIP suite and other OT/ICS frameworks
CIP-007 is one standard in NERC's broader CIP suite: CIP-013 governs vendor supply chain risk management processes rather than day-to-day system hardening, and together with CIP-002 (BES Cyber System categorization), CIP-005 (electronic security perimeters) and CIP-010 (configuration change management), it forms the mandatory, FERC-enforced reliability baseline specific to the North American bulk power system. That differs from voluntary, cross-sector frameworks like IEC 62443 (industrial automation and control systems generally) or protocol-specific standards like IEC 62351 (power system communications security) — a utility's full OT security posture commonly draws on CIP-007 for mandatory system hardening, IEC 62443 or similar for broader program/component guidance, and MITRE ATT&CK for ICS for threat-informed defense planning, since no single one of these fully substitutes for the others. KEV/EPSS vulnerability prioritization is also directly relevant to R2's 35-day patch evaluation cadence: a Responsible Entity still has to decide which of the patches it tracks matter most within that window.
A workable starting point
Treat R2's 35/35-day clock as two separate deadlines, not oneEvaluation of newly released patches is due within 35 calendar days of the prior evaluation; the decision to apply, create or revise a mitigation plan is then due within another 35 days of that evaluation — missing either clock independently creates exposure. Build R4's log retention and review cadence into tooling, not a manual calendarA 90-day minimum retention window and a review interval "no greater than 15 calendar days" are specific enough that an auditor will check actual configuration, not just a written policy. Don't assume "technically feasible" language gives unlimited discretionSeveral Parts (R1.1, R4.3, R5.1, R5.6, R5.7) condition the requirement on technical feasibility, but CIP-007-6's own convention still expects a documented basis for why a given Cyber Asset can't meet the baseline, not a blanket exemption. Start tracking CIP-007-7.1 and the virtualization definitions now, even though 1 July 2028 is years outThe new Cyber System, Shared Cyber Infrastructure and Virtual Cyber Asset definitions change what counts as an "Applicable System" under a virtualized architecture — a utility already planning virtualization should know what the CIP suite will expect before deploying it, not after. Keep CIP-007 evidence separate from CIP-013 evidence, even where they touch the same vendor relationship — CIP-007 governs the deployed system's own hardening (patches, access control, logging), while CIP-013 governs the procurement-time risk management process; an auditor reviews each against its own Requirements and retention rules.
SoftWSP's OT Snapshot builds a passive asset and vulnerability inventory — including which patches, default credentials and open services are present on in-scope BES Cyber Systems — without requiring agent installation on live control systems, supporting the evidence a CIP-007 Requirement R1/R2/R5 program needs: see OT Snapshot.
This guide quotes NERC's own published text of Reliability Standard CIP-007-6 (Purpose, Applicability, Requirements R1-R5, Compliance section) and the Federal Register's published text of FERC Order No. 919 (91 FR 13957); it is not a substitute for the full standards text, NERC's Implementation Plan, or FERC's complete order, and does not constitute compliance or legal advice.
Sources
- NERC: Reliability Standard CIP-007-6 — Cyber Security - System Security Management (official standard text: Purpose, Applicability, Requirements R1-R5 with full Tables, Compliance section, approved by FERC 21 January 2016)
- Federal Register: Order No. 919; Virtualization Reliability Standards, 91 FR 13957, Docket No. RM24-8-000 (FERC order approving CIP-007-7.1 and 10 other modified CIP standards, issued 19 March 2026)
- Federal Register: Order No. 919; Virtualization Reliability Standards — listing page
- NERC: Glossary of Terms Used in NERC Reliability Standards (BES Cyber System, EACMS, PACS, PCA, CIP Senior Manager definitions used throughout CIP-007-6)
Frequently asked questions
What is NERC CIP-007?
CIP-007, "Cyber Security — System Security Management," is a mandatory, FERC-approved Reliability Standard from the North American Electric Reliability Corporation (NERC). Per its own Purpose statement, it exists "to manage system security by specifying select technical, operational, and procedural requirements in support of protecting BES Cyber Systems against compromise that could lead to misoperation or instability in the Bulk Electric System (BES)." The currently enforceable version is CIP-007-6, approved by FERC on 21 January 2016; it applies to Balancing Authorities, certain Distribution Providers, Generator Operators and Owners, Reliability Coordinators, and Transmission Operators and Owners, specifically for their high- and medium-impact BES Cyber Systems and associated Electronic Access Control or Monitoring Systems (EACMS), Physical Access Control Systems (PACS) and Protected Cyber Assets (PCA).
What do Requirements R1 through R5 each require?
Per the standard's own text: R1 (Table R1 — Ports and Services) requires enabling "only logical network accessible ports that have been determined to be needed" and protecting unnecessary physical I/O ports. R2 (Table R2 — Security Patch Management) requires tracking patch sources, evaluating new patches "at least once every 35 calendar days," and within 35 days of that evaluation either applying the patch or creating/revising a dated mitigation plan. R3 (Table R3 — Malicious Code Prevention) requires deploying methods to "deter, detect, or prevent malicious code," mitigating detected code, and keeping signature/pattern update processes current. R4 (Table R4 — Security Event Monitoring) requires logging successful logins, failed access/login attempts and detected malicious code at minimum, generating alerts for specific event types, retaining logs "for at least the last 90 consecutive calendar days" where technically feasible, and reviewing a sample of logged events at least every 15 calendar days. R5 (Table R5 — System Access Control) requires authentication enforcement, inventorying default/generic accounts, identifying individuals with shared-account access, changing known default passwords, enforcing minimum password length/complexity for password-only authentication, periodic password changes, and limiting or alerting on unsuccessful authentication attempts.
What happens if a Responsible Entity misses the patch evaluation or review deadlines?
The specific numeric deadlines are baked directly into the Requirements, not left to interpretation: Part 2.2 sets patch evaluation at "at least once every 35 calendar days," Part 2.3 gives 35 calendar days after that evaluation to act, Part 4.4 sets log-review intervals "no greater than 15 calendar days," and Part 5.6 sets password-change periodicity at "at least once every 15 calendar months" where password-only authentication and technical feasibility apply. CIP-007-6's Compliance section requires each Responsible Entity to retain evidence of every requirement for three calendar years, and the NERC Compliance Enforcement Authority (NERC or the applicable Regional Entity) monitors compliance through audits, self-certifications, spot checks, self-reporting and complaint-driven investigations — each Requirement also carries its own Violation Risk Factor (CIP-007-6 sets all five at "Medium").
Is CIP-007-6 still the current version, or has it been replaced?
CIP-007-6 remains the currently enforceable text as of this guide's publication. A successor, CIP-007-7.1, has already been approved but is not yet mandatory: per the Federal Register notice of FERC's Order No. 919 (Docket No. RM24-8-000, 91 FR 13957, issued 19 March 2026, effective 24 March 2026 under the Federal Register's own effective-date clause and separately stated as effective 26 May 2026 for the order's own rulemaking purposes), the Commission "approves 11 modified Critical Infrastructure Protection (CIP) Reliability Standards," explicitly including "CIP-007-7.1 (Cyber Security — Systems Security Management)." NERC's own implementation plan, quoted in the order, sets the new standards' effective date as "the later of April 1, 2026, or the first day of the first calendar quarter that is 24 months after the effective date of the applicable governmental authority's order" — which, measured from the order's 26 May 2026 effective date, lands on **1 July 2028**. Responsible Entities may also early-adopt starting 6, 12 or 18 months after the order's effective date. Until a Responsible Entity's own early-adoption or mandatory date arrives, CIP-007-6 is what an auditor measures compliance against.
What does the CIP-007-7.1 revision actually change?
The revision is part of NERC's Project 2016-02 (Virtualization), which FERC's Order No. 919 approved together with four new NERC Glossary definitions — Cyber System, Management Interface, Shared Cyber Infrastructure and Virtual Cyber Asset — and 18 revised definitions, specifically to let Responsible Entities apply virtualization technology to BES Cyber Systems in a way the CIP suite's traditionally hardware-centric assumptions did not clearly accommodate. The order also describes a related, narrower change: replacing a self-implementing "technical feasibility exception" phrase with "per system capability" language in places, after NERC reported a significant decrease in submitted technical feasibility exceptions under the old wording. This guide has not reviewed the full CIP-007-7.1 text itself (NERC had not yet posted the final ".1" errata version as a standalone clean PDF at the time of research); treat any claim about exactly which CIP-007 Requirements or Parts change wording as **to be confirmed** against NERC's and FERC's own published CIP-007-7.1 text once available.
In this cluster
