NERC CIP-009: recovery plans for BES cyber systems, explained

Last updated:

Key takeaways

  • Part 2.1 — test each recovery plan "at least once every 15 calendar months," by recovering from an actual incident, a paper drill or tabletop exercise, or an operational exercise.
  • Evidence for every R1-R3 requirement must be retained for three calendar years, per the standard's Compliance section, and CIP-009 carries no Regional Variances.
  • CIP-009-6 is the standard enforced today, but a successor is already locked in.
  • Don't apply the Part 2.1/2.2 "Control Center" scoping assumption to Part 2.3.

NERC CIP-009-6, "Cyber Security — Recovery Plans for BES Cyber Systems," is the mandatory, FERC-approved Reliability Standard that tells utilities and grid operators how to recover Bulk Electric System (BES) Cyber Systems after a disruptive event — whether a Cyber Security Incident, equipment failure or natural disaster. Per its own Purpose clause it exists "to recover reliability functions performed by BES Cyber Systems by specifying recovery plan requirements in support of the continued stability, operability, and reliability of the BES." CIP-009-6 was adopted by the NERC Board of Trustees on 13 November 2014 — addressing directives in FERC Order No. 791 — and approved by FERC on 21 January 2016. It remains the enforceable version today, even though a virtualization-focused successor, CIP-009-7.1, is already FERC-approved for a 2028 compliance date (see below).

Who must comply

Section 4.1 names eight "Responsible Entity" functional types: Balancing Authority, a Distribution Provider that owns specific load-shedding, Special Protection System/Remedial Action Scheme or protection facilities, Generator Operator, Generator Owner, Interchange Coordinator or Interchange Authority, Reliability Coordinator, Transmission Operator and Transmission Owner. The Interchange Coordinator/Interchange Authority entry is notable — most of the current CIP suite (including CIP-008 and CIP-010) lists only seven functional types, and CIP-009 is one of the few standards still carrying this legacy functional entity forward. The requirements apply to each entity's BES Cyber Systems categorized as high or medium impact under the separate CIP-002 process, together with their associated EACMS and, for most requirement parts, Physical Access Control Systems (PACS).

Five exemption categories (Section 4.2.3) take Cyber Assets out of scope entirely: facilities regulated by the Canadian Nuclear Safety Commission; communication networks and data links between discrete Electronic Security Perimeters; systems regulated by the US Nuclear Regulatory Commission under 10 C.F.R. § 73.54; for Distribution Providers, systems and equipment outside the standard's Section 4.2.1 scope; and any Responsible Entity that identifies it has no high- or medium-impact BES Cyber Systems under CIP-002 at all.

R1: the five-part recovery plan

Requirement R1 (Violation Risk Factor: Medium) requires one or more documented recovery plans covering five table parts:

Part Applies to Core obligation
1.1 High Impact + EACMS/PACS; Medium Impact + EACMS/PACS Conditions for activation of the recovery plan(s)
1.2 Same Roles and responsibilities of responders
1.3 Same One or more processes for the backup and storage of information required to recover BES Cyber System functionality
1.4 High Impact + EACMS/PACS; Medium Impact at Control Centers + EACMS/PACS Processes to verify successful completion of the Part 1.3 backup processes and to address any backup failures
1.5 High Impact + EACMS/PACS; Medium Impact + EACMS/PACS Processes to preserve data, per Cyber Asset capability, to determine the cause of a Cyber Security Incident that triggers plan activation, without impeding recovery

Part 1.5's own text ties directly back to CIP-008: the standard's Guidelines and Technical Basis section notes that "CIP-008 addresses the retention of data associated with a Cyber Security Incident" — meaning the two standards' data-handling obligations are designed to work together when an incident, rather than a hardware failure, triggers the recovery. See NERC CIP-008.

R2: testing — and why high-impact systems get a second, heavier test

Requirement R2 (Lower VRF) requires implementing the plan(s) across three table parts, and it is where CIP-009 diverges most from the rest of the CIP suite's single-cadence testing pattern:

  • Part 2.1 — test each recovery plan "at least once every 15 calendar months," by recovering from an actual incident, a paper drill or tabletop exercise, or an operational exercise. Applies to High Impact systems and Medium Impact systems at Control Centers only (plus their EACMS/PACS) — ordinary Medium Impact substations and generation resources are not in scope for this part.
  • Part 2.2 — test a representative sample of the backup information itself, on the same 15-month cadence, to confirm it is usable and compatible with current configurations. An actual recovery that uses that information substitutes for the test. Same applicability as Part 2.1.
  • Part 2.3 — High Impact BES Cyber Systems only: an operational exercise of the recovery plans "at least once every 36 calendar months" in an environment representative of production. An actual recovery response may substitute. This is the standard's heaviest test obligation, and it has no Medium Impact equivalent.

The Violation Severity Level table enforces both cadences independently: a Part 2.1/2.2 test gap of 15-16 months is Lower, escalating to Severe beyond 18 months; a Part 2.3 gap of 36-37 months is Lower, escalating to Severe beyond 39 months.

R3: review, update and communication

Requirement R3 (Lower VRF) uses the same two-trigger structure as CIP-008's R3: no later than 90 calendar days after completing a test or an actual recovery, the entity must document lessons learned (or their absence), update the plan, and notify every person or group with a defined plan role (Part 3.1); and no later than 60 calendar days after a change to roles, responders or technology that would impact the ability to execute the plan, the entity must update the plan and notify affected personnel (Part 3.2). The standard's own Guidelines and Technical Basis adds a handling note worth repeating directly: because recovery plans "may be considered BES Cyber System Information," entities should redact the plan itself or other sensitive plan content "from Email or other unencrypted transmission" when distributing updates.

Evidence for every R1-R3 requirement must be retained for three calendar years, per the standard's Compliance section, and CIP-009 carries no Regional Variances.

CIP-009-7.1 is already approved — the 2028 compliance clock is running

CIP-009-6 is the standard enforced today, but a successor is already locked in. On 19 March 2026 the Federal Energy Regulatory Commission issued Order No. 919 (Docket No. RM24-8-000), whose own summary states it "approves 11 modified Critical Infrastructure Protection (CIP) Reliability Standards" and explicitly lists "CIP-009-7.1 (Cyber Security — Recovery Plans for BES Cyber Systems)" alongside CIP-002-7, CIP-003-10, CIP-004-8, CIP-005-8, CIP-006-7.1, CIP-007-7.1, CIP-008-7.1, CIP-010-5, CIP-011-4.1 and CIP-013-3 — published in the Federal Register on 24 March 2026 at 91 FR 13957, with the order stating "this final rule is effective May 26, 2026." The package also approves four new NERC Glossary definitions — Cyber System, Management Interface, Shared Cyber Infrastructure and Virtual Cyber Asset — plus 18 revised definitions, needed to let the CIP suite apply cleanly to virtualized infrastructure such as Shared Cyber Infrastructure (SCI) hosting virtual machines for multiple BES Cyber Systems (see NERC CIP-010 and NERC CIP-002). Order No. 919 also approved replacing most "technical feasibility exception" language across the CIP suite with a self-implementing "per system capability" standard, after NERC reported a significant decrease in submitted technical feasibility exceptions under the prior wording.

Per NERC's own implementation plan, quoted directly in the order, the revised standards "will become effective on 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, from the order's 26 May 2026 effective date, computes to 1 July 2028. Responsible entities may elect early adoption at six, 12 or 18 months after that date instead of waiting for the mandatory date. This guide has not independently reviewed every redlined Part of the final CIP-009-7.1 text, so treat the exact wording changes to R1-R3 as something to confirm against NERC's and FERC's own published CIP-009-7.1 text before compliance planning.

A workable starting point

  1. Don't apply the Part 2.1/2.2 "Control Center" scoping assumption to Part 2.3Part 2.1 and 2.2's 15-month tests cover High Impact systems and Medium Impact systems at Control Centers only; Part 2.3's heavier 36-month operational exercise applies to High Impact systems regardless of whether they sit at a Control Center — treating all three parts as having identical scope is a common reading error.
  2. Build backup verification (Part 1.4) and backup testing (Part 2.2) as two distinct controls, not one. Part 1.4 confirms a given backup job completed without failure; Part 2.2 periodically confirms a sample of that backed-up information is actually usable and current — a backup can pass Part 1.4's completion check and still fail Part 2.2's usability test months later if configurations have drifted.
  3. Coordinate CIP-009's Part 1.5 data preservation with CIP-008's incident evidence retentionrather than building them separately — the standard's own guidance points to CIP-008 for incident-data retention, and a recovery plan that preserves data in a way that conflicts with the parallel incident response plan creates two competing chains of custody for the same event.
  4. Redact recovery plan content from unencrypted distribution channels, per the standard's own Guidelines and Technical Basis note that recovery plans may themselves be BES Cyber System Information — a plan-update email sent in the clear can itself become the exposure the plan exists to recover from.
  5. Start tracking CIP-009-7.1 even though it isn't enforceable yetWith a FERC-approved 1 July 2028 compliance date already set, entities planning virtualized or shared infrastructure for BES Cyber Systems should evaluate how Shared Cyber Infrastructure and Virtual Cyber Asset concepts affect recovery-plan scope now, rather than retrofitting backup and recovery processes after the fact.

SoftWSP's OT asset and firmware assessments can help build and verify the backup, recovery and testing evidence CIP-009 requires: see OT Snapshot.

This guide quotes NERC's own published text of CIP-009-6 and the Federal Register text of FERC Order No. 919; it is not a substitute for the full standard, NERC's Implementation Plan, or compliance/legal advice. CIP-009-6 remains the enforceable standard as of this guide's publication — CIP-009-7.1 is approved but not yet mandatory.

Sources

  1. NERC: CIP-009-6 — Cyber Security – Recovery Plans for BES Cyber Systems (currently effective standard, full text: Purpose, Applicability, Requirements R1-R3 with Tables, Compliance, Guidelines and Technical Basis, Version History)
  2. Federal Register: Order No. 919; Virtualization Reliability Standards, 91 FR 13957-13965 (FERC, Docket No. RM24-8-000, issued 2026-03-19, published 2026-03-24, effective 2026-05-26) — lists CIP-009-7.1 among the 11 approved standards, with NERC's implementation plan formula
  3. NERC: CIP-009-7 — Project 2016-02 virtualization drafting redline (draft text circulated during standards development; not the final adopted CIP-009-7.1, cited for the project's scope and drafting history only)

Frequently asked questions

What is NERC CIP-009-6, and who must comply?

CIP-009, "Cyber Security — Recovery Plans for BES Cyber Systems," is the mandatory, FERC-approved NERC Reliability Standard that tells utilities and grid operators how to recover Bulk Electric System (BES) Cyber Systems after a disruptive event. Per its own Purpose clause it exists "to recover reliability functions performed by BES Cyber Systems by specifying recovery plan requirements in support of the continued stability, operability, and reliability of the BES." The currently enforceable version, CIP-009-6, was adopted by the NERC Board of Trustees on 13 November 2014 to address directives in FERC Order No. 791, and FERC approved it on 21 January 2016 (Docket No. RM15-14-000). Section 4.1 names eight "Responsible Entity" functional types — Balancing Authority, certain Distribution Providers, Generator Operator, Generator Owner, Interchange Coordinator or Interchange Authority, Reliability Coordinator, Transmission Operator and Transmission Owner — one more than most of the CIP suite, because CIP-009 is one of the few standards that still names the legacy Interchange Coordinator/Interchange Authority role. The requirements apply to each entity's BES Cyber Systems categorized as high or medium impact under the separate CIP-002 process, together with their associated EACMS and, for most parts, Physical Access Control Systems (PACS).

What does Requirement R1 (the recovery plan itself) require?

R1 (Table R1 — Recovery Plan Specifications, Violation Risk Factor Medium) requires one or more documented recovery plans covering five table parts, applicable to High Impact BES Cyber Systems and their associated EACMS/PACS, and — for most parts — Medium Impact BES Cyber Systems and their associated EACMS/PACS as well. Part 1.1 requires defining "conditions for activation of the recovery plan(s)." Part 1.2 requires defining "the roles and responsibilities of responders." Part 1.3 requires "one or more processes for the backup and storage of information required to recover BES Cyber System functionality." Part 1.4 requires processes to verify that those backups completed successfully and to address backup failures. Part 1.5 requires processes to preserve data, per Cyber Asset capability, for determining the cause of a Cyber Security Incident that triggered the recovery — the standard's own text cross-references CIP-008's incident-data retention for this purpose, and notes that data preservation must not impede or restrict recovery.

What does Requirement R2 (testing) require, and why does the cadence differ for high-impact systems?

R2 (Table R2 — Recovery Plan Implementation and Testing, Lower VRF) sets three distinct testing obligations. Part 2.1 requires testing each recovery plan "at least once every 15 calendar months" — by recovering from an actual incident, with a paper drill or tabletop exercise, or with an operational exercise — applicable to High Impact systems and Medium Impact systems **at Control Centers**. Part 2.2 requires testing a representative sample of the backup information itself, on the same 15-month cadence, to confirm it is usable and compatible with current configurations; an actual recovery using that information substitutes for the test. Part 2.3 adds, for **High Impact BES Cyber Systems only**, a further obligation: an operational exercise of the recovery plans "at least once every 36 calendar months" in an environment representative of production — a heavier, longer-interval test that Medium Impact systems are not subject to, reflecting the standard's own two-tier approach to proving recovery actually works rather than just that a plan exists.

What does Requirement R3 (review, update and communication) require?

R3 (Table R3 — Review, Update and Communication, Lower VRF) mirrors the two-trigger structure used elsewhere in the CIP suite. Part 3.1 requires that no later than **90 calendar days** after completing a recovery plan test or an actual recovery, the entity documents lessons learned (or documents their absence), updates the plan based on those lessons, and notifies every person or group with a defined plan role of the updates. Part 3.2 requires that no later than **60 calendar days** after a change to roles, responders or technology that the entity determines would impact its ability to execute the plan, the entity updates the plan and notifies affected personnel. The standard's own Guidelines and Technical Basis section adds a security note: because recovery plans may themselves be BES Cyber System Information, entities should redact sensitive plan content from email or other unencrypted channels when distributing updates. Evidence for all R1-R3 requirements must be retained for three calendar years.

Is CIP-009-6 already being replaced, and by when do entities need to comply?

Yes — a successor, CIP-009-7.1, is already FERC-approved, though CIP-009-6 remains the enforceable standard today. On 19 March 2026 the Federal Energy Regulatory Commission issued Order No. 919 (Docket No. RM24-8-000), which the order's own summary states "approves 11 modified Critical Infrastructure Protection (CIP) Reliability Standards," explicitly listing "CIP-009-7.1 (Cyber Security — Recovery Plans for BES Cyber Systems)" alongside CIP-002-7, CIP-003-10, CIP-004-8, CIP-005-8, CIP-006-7.1, CIP-007-7.1, CIP-008-7.1, CIP-010-5, CIP-011-4.1 and CIP-013-3 as part of NERC's Project 2016-02 virtualization package — published in the Federal Register on 24 March 2026 (91 FR 13957-13965) with the order stating "this final rule is effective May 26, 2026." Per NERC's own implementation plan, quoted directly in the order, the revised standards "will become effective on 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 computes to **1 July 2028** from the order's 26 May 2026 effective date. Responsible entities may elect early adoption at six, 12 or 18 months after that date instead of waiting for the mandatory compliance date. This guide has not independently reviewed every redlined Part of the final CIP-009-7.1 text; treat any claim about exactly which R1-R3 Parts change wording as something to confirm against NERC's and FERC's own published CIP-009-7.1 text before relying on it for compliance planning.

In this cluster

NERC CIP-009: recovery plans for BES cyber systems, explained