CIP-009-6 R2 Recovery plan implementation and testing

What CIP-009-6 R2 requires for recovery plan testing

CIP-009-6 R2 requires you to test each recovery plan at least once every 15 calendar months, to test-restore a representative sample of the information used to recover BES Cyber System functionality on the same 15-month cycle, and, for high impact BES Cyber Systems, to run an operational exercise of recovery at least once every 36 calendar months. The plan you wrote under R1 may be well drafted, but R2 is the requirement that shows it works. If your compliance lead cannot point to a dated test record, the plan has not yet been proven under this standard. The scope is narrower than many teams expect. The 15-month plan test and sample restoration apply to high impact BES Cyber Systems and to medium impact BES Cyber Systems at Control Centers. The 36-month operational exercise applies only to high impact systems, and an actual recovery can count toward it. R2 carries a Lower Violation Risk Factor, which signals how NERC rates the reliability risk of a missed requirement, but it does not lower the consequence of a violation. Confirm your Applicable Systems table against your CIP-002 categorization before you build the test calendar.

R2 is hard in practice for three reasons. Backups often go unverified, so a restore attempt may fail for the first time during the test. Recovery configurations drift, so a sample that restored cleanly last year may not match current firmware, network addressing or software versions. Plans also stay on paper, because a tabletop exercise without hands-on steps does not show that staff can rebuild a system within the planned sequence. Ask your team to run a restore of a sample item and record the time, the people involved and any gaps, then compare the result to the current configuration baseline. The enforcement context is material. NERC's Sanction Guidelines and 18 CFR 385.1602(d) set the maximum civil penalty at $1,584,648 per violation, per day, as adjusted by FERC Order No. 906 (January 2025). Compliance is monitored through audits, spot checks and self-reports rather than a certificate, so your evidence file, including test dates, scope, results and follow-up actions, is what an auditor will examine. Review the NERC CIP standards page for current status before you rely on any version.

Which BES Cyber Systems and teams fall under CIP-009-6 R2 testing

Whether R2 applies depends on the impact rating CIP-002 assigns each system, so categorization comes first. Once the systems are rated, the scope decides which parts of R2 apply, whether supporting systems are in view, and who must take part in the tests.

CIP-002 categorization sets R2 scope

R2 applies only to systems that CIP-002-5.1a rates as high impact, or as medium impact at Control Centers. Before planning any test, confirm the current categorization list, the Control Center designations, and the date of the last review. A system moved between impact levels changes which R2 parts apply to it, and the recovery plans must reflect that change.

High impact systems carry all three parts

High impact BES Cyber Systems are subject to Parts 2.1, 2.2 and 2.3. That means plan testing, sample restoration of recovery information, and an operational exercise. For a control room system, confirm that the operational exercise runs in an environment representative of production, since a paper test alone will not satisfy Part 2.3.

Medium impact Control Center systems carry two parts

Medium impact BES Cyber Systems at Control Centers fall under Parts 2.1 and 2.2 only. They do not need the 36-month operational exercise. Check that the Control Center designation is documented, because a medium impact system at a substation or generating plant is outside R2 altogether.

Low impact systems fall outside R2

R2 does not reach low impact BES Cyber Systems. Their recovery expectations are handled through the CIP-003 cyber security plan rather than through CIP-009-6 testing. Document the reasoning for each low impact asset so an auditor can see why R2 was not applied, and avoid borrowing R2 test records as a substitute for low impact controls.

EACMS, PACS and PCA need explicit decisions

R2 is written around BES Cyber Systems, so Electronic Access Control or Monitoring Systems, Physical Access Control Systems and Protected Cyber Assets are not automatically covered by the same testing. Decide whether each supporting system is restored in the same exercise, and record the decision. Systems needed to restore a BES Cyber System, such as domain controllers or jump hosts, should be tested with it.

Operations and system owners lead the tests

Operations staff confirm that restored functionality matches what the control room needs, and system owners verify configurations and dependencies. Both should sign off on test results. Their participation is the evidence that the test proved recovery, not just that a file could be read back.

Backup administrators and vendors hold the media

Backup administrators run restores, check backup integrity and keep the catalog that identifies recoverable data. Third-party vendors often hold recovery media, licenses or firmware images. Confirm in writing who can release that media, how quickly, and whether the vendor takes part in the 15-month test. Contract terms should cover this before the test window opens.

How an assessor tests CIP-009-6 R2 testing cycles

This table compares the three CIP-009-6 R2 test elements by how an assessor approaches each one, the evidence requested and the findings that most often arise. Assessors sample test dates within the audit period and check the interval between consecutive tests, so each row should be read as a dated record question, not a one-time event.

Test element	Assessor test approach	Evidence requested	Common findings
15-month recovery plan test (Part 2.1)	Select sampled recovery plans and confirm each was tested at least once in every 15 calendar month window across the audit period, then confirm the test method matches one of the permitted types.	Dated test records for each plan, the method used (actual incident, paper drill, tabletop or operational exercise), participants and the scenario tested.	Interval between consecutive tests exceeds 15 calendar months; test dated outside the window; plan tested but the record does not name the plan version.
15-month representative sample of recovery information (Part 2.2)	Pick a sample of the backups, configuration files and recovery media the plan relies on, then confirm the sample was restored or checked at least once every 15 calendar months and is compatible with current configurations.	Restore logs or verification output, the list of sampled items, a configuration comparison showing the restored material matches current systems, and the rationale for the sample.	Sample chosen from items that are not the ones the plan actually depends on; sample not representative of the backup population; restored material incompatible with current configurations; no record of the comparison.
36-month operational exercise (Part 2.3, high impact only)	Confirm each high impact plan had an operational exercise, or an actual recovery, at least once every 36 calendar months, and review whether the environment used was representative of production.	Exercise report with scope, environment description, start and end times, recovery objectives met or missed, and lessons recorded; or incident records if an actual recovery substituted.	Exercise run in a lab or reduced environment unlike production; no report; exercise older than 36 months at the time of sampling; scope limited to a single component without explanation.

How to implement the CIP-009-6 R2 test cycle in six steps

This sequence takes an entity from its CIP-002 categorization to a documented 15-month and 36-month test cycle, with each step leaving a record that an auditor can trace back to the requirement.

Confirm applicable systems from the CIP-002 categorization
Start with the approved CIP-002 categorization and list the BES Cyber Systems rated high impact and medium impact at Control Centers, since Parts 2.1 and 2.2 of R2 apply to those systems. Compliance staff and the system owners confirm the list against current asset inventories, including any system added or retired since the last review. The output is a signed applicability register that names each in-scope system and its impact rating, and that register becomes the scope statement for every later step. Confirm the rating basis with your Regional Entity if a system sits near a bright-line threshold.
Map each recovery plan to its systems
Match every documented recovery plan to the systems it covers, so that no in-scope system lacks a plan and no plan is left without a system. Operations and the recovery plan owners review each plan's activation conditions, responder roles and backup sources, then record the mapping in a table. The completed table, reviewed and approved by the CIP Senior Manager or delegate, is evidence that each applicable system is tested under a named plan. Revisit the map whenever a system changes, because a missing mapping is the most common gap found during reviews.
Set the 15-month calendar for plan tests and sample restores
Schedule each recovery plan for a test at least once every 15 calendar months, and schedule a separate sample restore of the recovery information for the same window. Choose the test method for each plan, whether an actual recovery, a paper drill, a tabletop exercise or an operational exercise, and record the method in the calendar. The calendar, approved by the owners, shows each plan's last test date, next due date and selected method. Keep it in the same system as your compliance tracking so the due dates generate reminders.
Schedule the 36-month operational exercise for high impact systems
For each high impact BES Cyber System, plan an operational exercise of recovery at least once every 36 calendar months in an environment representative of production. Confirm with the system owner whether the exercise can run in a non-production copy that matches production configuration, and document any differences that could change the result. An actual recovery within the period can satisfy this part instead. The output is a dated exercise plan with scope, environment description and the people responsible, and it sits alongside the 15-month calendar.
Define the test record each step must produce
Standardize one test record template before the first test runs, so each exercise captures the same facts. The record should state the plan tested, the test method, the date, the participants, the sample of backup information restored, the restore result, the usability and configuration compatibility check, and any deviations. Assessors look for this record to confirm that the test happened as planned and that the sample represents the backups in use. Store records in a location with access control and retention rules that match your evidence policy.
Close findings with plan updates that feed R3
After each test or real recovery, log every gap, failed step and lesson learned as a tracked finding with an owner. Update the recovery plan and any affected backup or restore procedure, then pass the changes into the CIP-009-6 R3 process, which governs recording lessons learned and updating the plan within the deadlines set in that requirement. The closed findings, revised plan version and communication record together show that testing led to improvement. Confirm the deadlines in R3 against the standard before setting internal targets.

What evidence passes a CIP-009-6 R2 audit

An auditor testing CIP-009-6 R2 wants dated proof that each recovery plan was tested on schedule and that the backups behind it can actually restore BES Cyber System functionality. The cards below cover the records that prove those points, the tool output that supports them, and how to keep them current between audits.

Dated plan test records

For each recovery plan, keep a record showing the test date, the test type (actual recovery, paper drill, tabletop or operational exercise), the scope, the participants and the outcome. Each test must fall within 15 calendar months of the previous one, so the record should show the interval at a glance. Ask whether the record names the plan version tested, because an auditor will compare it against the plan in force on that date.

Sample restore records

Under Part 2.2, a representative sample of recovery information must be tested. Record which backup sets were restored, to what target, by whom, and whether the restored configuration matched the current production system. A mismatch is not a failure in itself, but it must be recorded and resolved, since the test exists to show the information is usable with current configurations.

Operational exercise reports for high impact systems

For high impact BES Cyber Systems, Part 2.3 requires an operational exercise of recovery in an environment representative of production at least every 36 calendar months, unless an actual recovery is used instead. The report should describe the representative environment, the recovery steps performed, the time taken, and the gaps found. Confirm with your Compliance Enforcement Authority how they expect representativeness to be shown.

Bareos job and restore records

The Bareos Director schedules and supervises backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files. Exporting job history and restore job records from that catalog gives dated, system-generated proof that backups ran and that specific files were restored. Confirm that the catalog and job logs are retained for the full audit period and backed up themselves.

restic check output for stored data

restic check verifies the structural consistency of snapshots, trees and pack files. Runs with --read-data or --read-data-subset read pack files back and confirm the stored backup data is unmodified, which supports the claim that the sample restored is trustworthy. Save the command output with its date and repository identifier, and note whether the run was a full read or a subset, since the subset covers only part of the data.

Current evidence between audits

Auditors sample from the whole audit period, so evidence gathered only before an audit is weak. Schedule the test calendar against the 15-month and 36-month clocks, store job and check output in a location with retention set by policy, and review each recovery plan after every test or real recovery. Ask your implementation partner to set up these exports so the evidence is produced as a routine byproduct, not assembled on request.

What CIP-009-6 R2 testing costs in money and effort

This table lists the cost components of meeting CIP-009-6 R2 testing, who is paid for each, whether it is one-time or recurring, and what moves it up or down. No prices are given, because a quote follows from the written scope. Use the last column to decide which lines to ask a vendor or partner to price separately.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Backup and restore tooling	Software vendor or open-source project, plus internal or partner engineers to deploy it	One-time setup, recurring if licensed or supported	Self-hosted open source such as Bareos and restic removes license spend but not the engineering to configure and maintain it. Ask whether support or upgrades are priced separately.
Engineering time for test planning	Internal recovery or operations staff, or an implementation partner under a fixed-scope agreement	Recurring every 15 calendar months per recovery plan	Number of recovery plans and the number of BES Cyber Systems each plan covers. Consolidating plans where the standard allows can reduce planning effort.
Engineering time for test execution	Internal staff or partner engineers who perform restores and record results	Recurring every 15 calendar months, plus a larger exercise every 36 calendar months for high impact systems	Number of high impact sites, whether the exercise is a paper drill, tabletop or operational exercise, and how much restoration is automated.
Test environment capacity	Entity for its own hardware, virtualization or cloud accounts, or a provider for rented capacity	Often one-time build, then recurring hosting or maintenance	Environment fidelity to production. A closer match for the operational exercise raises hardware, licensing and network costs. Confirm what the standard requires for representative environments in your own reading.
Backup verification and evidence upkeep	Internal compliance or operations staff, with the backup tool producing logs and verification output	Recurring, with a periodic review of the sample	Size of the representative sample under Part 2.2, how often backups run, and how many systems hold recovery information. Automated verification reports reduce manual collection.
External review or facilitation	Independent consultant, implementation partner or facilitator, under written scope	Usually one-time per exercise or per review cycle	Whether an outside facilitator runs the operational exercise or only reviews the test record. Ask for the scope, deliverables and timeline in writing before work starts.
Auditor sampling time	Regional Entity or NERC audit staff, paid through the audit process	Recurring per audit cycle, not a separate invoice from a vendor	Audit schedule and the evidence the entity can produce quickly. Complete, dated test records shorten the sampling effort. Confirm the current audit cycle with your Regional Entity.

Who runs the test cycle, who prepares the evidence, and who judges it

Your organization owns the recovery plans and the outcome of every test. Your staff decide which BES Cyber Systems are in scope, select the test type for each plan (an actual recovery, a paper drill, a tabletop exercise or an operational exercise), and run or direct the test. They also sign the records, record the results and decide what to do about any gap the test reveals. Under CIP-009-6 R2, the entity must show that each recovery plan was tested on schedule, so the accountability cannot move to a vendor.

Plan ownership: Named staff maintain the recovery plans and approve changes to roles, teams and technology.
Test selection: Your team picks the test type and the representative sample of recovery information for each cycle.
Execution and sign-off: Staff run or supervise the test and sign the test records with dates and participants.
Findings decisions: Your team decides how to handle failed restores, missing or outdated recovery information, and follow-up actions.
Scheduling control: Someone internal tracks the 15 and 36 calendar month intervals for each system.

Before engaging any partner, confirm that your named owners can explain each test record without help from the vendor.

Where organizations fail CIP-009-6 R2 and how to close each gap

CIP-009-6 R2 is easy to satisfy on paper and easy to miss in practice. The gaps below recur in recovery programs because each one looks compliant until an auditor asks for proof of scope, configuration currency or timing. Each card names the gap and a closing action the organization can take before its next test window.

Tabletop exercises logged without recovery scope

A tabletop discussion is an accepted way to test a recovery plan under Part 2.1, but the record often says only that the plan was reviewed. An auditor will look for what was recovered, which systems were in scope and which responder roles were exercised. Write the scope into every exercise record before the session starts, listing the BES Cyber Systems, the recovery steps walked through and the gaps identified. A record without those elements shows discussion, not a test.

Sample restores that miss production configuration

Part 2.2 asks whether the recovery information is usable and compatible with current configurations. A restore drawn from an old snapshot may succeed while proving nothing about the system running today. Pull the restore sample from the backup set matching the current production baseline, and compare the restored configuration against the CIP-010 baseline record. Note any version or firmware drift as a finding.

Backups never restored to a test environment

Many programs verify that backup jobs complete and that catalogs list files, yet never restore those files to an isolated environment. Integrity checks confirm stored data is intact but do not show that a system boots and functions from it. Schedule a restore of each backup set into a non-production environment and record the time to a working state, using a verification tool such as restic check with read-data options as one layer of evidence alongside the restore itself.

Operational exercise scheduled too late

For high impact BES Cyber Systems, Part 2.3 requires an operational exercise of recovery in an environment representative of production at least once every 36 calendar months, unless an actual recovery substitutes. Programs often defer the exercise to the final months of the cycle, leaving no room to fix failures before the deadline. Set the exercise date at the start of each 36-month cycle and place a mid-cycle checkpoint on the calendar, so that a failed exercise still leaves time for a retest.

Test dates drifting outside the 15-month window

Parts 2.1 and 2.2 each require testing at least once every 15 calendar months. Dates tend to slip when a test is booked from the last completion date and that date moves forward with each reschedule. Track the due date for each recovery plan and each sample restore in a single compliance calendar, counted from the prior completed test, and assign one owner who confirms each date before the window closes.

Plans left unchanged after failed tests

A failed test or real recovery is the most useful evidence a program produces, and CIP-009-6 R3 requires recording lessons learned and updating the plan within 90 days after a test or recovery. Programs that log failures without changing the plan repeat the same findings at the next test. Open a plan update ticket for every failed step on the day the test closes, and link the ticket to the R3 lessons learned record so the update date is traceable.

What buyers ask about CIP-009-6 R2 testing cost, time and effort

How much effort does the 15-month recovery testing cycle take?

The effort depends on how many BES Cyber Systems are in scope, how many recovery plans they use, and how much of each test is manual. Part 2.1 requires each recovery plan to be tested at least once every 15 calendar months, using an actual recovery, a paper drill or tabletop exercise, or an operational exercise. Part 2.2 adds a test of a representative sample of the recovery information, such as backups, configuration files and documentation, to confirm it is usable and matches current configurations. Effort rises with the number of plans, the number of distinct system types, and whether restores must be rebuilt by hand. Ask your implementation partner for a written breakdown per plan and per sample, and confirm with your Compliance Enforcement Authority how they expect the evidence to look.

Can our own staff run the R2 tests without an outside partner?

Yes, the standard places the testing duty on the registered entity, so your own staff can perform and document the tests. The question is capacity and independence. Recovery tests need people who know the BES Cyber Systems, the recovery plan and the backup platform, and they need time outside normal operations. A partner can help plan the test, prepare the restore environment, script repeatable recovery steps and assemble the evidence, but the organization keeps ownership of the plan, the decisions and the results. DeployOpen works this way on fixed-scope engagements, with scope and deliverables agreed in writing before work starts.

What does the 36-month operational exercise require for high impact systems?

For high impact BES Cyber Systems, Part 2.3 requires each recovery plan to be tested at least once every 36 calendar months through an operational exercise of recovery. The exercise has to run in an environment representative of production, so a lab that differs materially from the live system does not meet the intent. The exercise is planned around the recovery plan's roles, activation steps and restore sequence, and its results feed the lessons-learned and plan update work covered by the sibling requirement on plan review. Plan the environment, the staff time and the change windows well ahead of the due date, and confirm with your auditor how they will test representativeness.

Can an actual recovery replace the operational exercise?

Yes, Part 2.3 states that an actual recovery can substitute for the operational exercise. This means a real recovery of a high impact system performed under the recovery plan, within the 36-month window, can count toward that requirement. Record the incident timeline, the steps taken, any deviations from the plan, and the time to restore, because an auditor will ask for that evidence. Do not plan around an incident to meet the schedule. Keep a scheduled exercise on the calendar as the fallback, since a real recovery may not happen when the cycle needs it.

What drives the cost of CIP-009-6 R2 testing?

The main cost drivers are the number of high impact and in-scope medium impact Control Center systems, the number of recovery plans, the size and complexity of the backup sets, and how much of the restore environment must be built for each test. Costs fall into one-time work, such as building the restore environment, scripting recovery steps and setting up backup verification, and recurring work, such as running each 15-month test, sampling backups and running the 36-month exercise. Staff time for operations and IT is often the largest component. When requesting a quote, ask for the scope by system and plan, the test types chosen, who performs each activity, the environment assumptions, and which items are one-time versus recurring. DeployOpen does not publish a price list, and a quote follows from the written scope.

Are open-source backup tools acceptable evidence for R2 testing?

The standard does not name products, so an open-source backup platform can support R2 evidence if it reliably produces the records the auditor needs. Bareos's Director schedules and supervises backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files, which helps show what was backed up and restored. restic's check command verifies the structural consistency of snapshots, trees and pack files, and with --read-data or --read-data-subset it reads pack data back to confirm the stored backups are unmodified. Keep job logs, restore reports, checksums and test records together, and confirm with your Compliance Enforcement Authority that the evidence format is acceptable. Check each product's license terms for your use case.

What can a compliance partner not do for our R2 testing?

A partner cannot issue compliance findings, audit reports or attestations. Under the NERC framework, the Compliance Enforcement Authority, which is a Regional Entity or NERC, monitors compliance through audits, spot checks, self-certifications and self-reports. DeployOpen prepares systems, documentation and evidence for these reviews, and it runs tests and reports results, but it does not decide whether your organization is compliant. The organization remains accountable for its controls and for the accuracy of what it submits. Ask any partner to state its role in writing, and to confirm that it will not sign or certify your compliance status.

How DeployOpen prepares CIP-009-6 R2 test evidence

DeployOpen plans, builds and documents the self-hosted backup, restore and verification environment that CIP-009-6 R2 testing depends on, inside your own infrastructure. The organization owns its recovery plans and test decisions, and an independent auditor or the Compliance Enforcement Authority decides whether the evidence meets the standard.

How we scope

Confirm which BES Cyber Systems fall under R2, starting from your CIP-002 impact categorization and the Applicable Systems column.
Agree in writing which recovery plans, backup tools and restore environments are in scope, with deliverables and timelines set before work starts.
Identify which R2 tests your organization will run each 15 calendar months and whether a 36-month operational exercise applies to high impact systems.

How we build

Deploy and harden backup infrastructure, such as Bareos for scheduled backup, restore and verify jobs with a SQL catalog, within your own cloud or data center.
Configure integrity checks, such as restic check with read-data options, so sample backups can be shown to be unmodified before a test relies on them.
Build a restore environment that mirrors current configurations, so the Part 2.2 sample test shows the stored information is usable and compatible.

How we hand over

Deliver test procedures and records that name the test type, date, participants, sample selected and outcome for each R2 test cycle.
Document the restore steps, configuration baselines and job schedules so your staff can repeat the tests without DeployOpen present.
Provide an evidence index that maps each artifact to the R2 part it supports, held in the retention period your Compliance program sets.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover, so backup tooling stays current with your environment.
Support can include preparing evidence packages before a Regional Entity audit or Spot Check, while your compliance team owns the responses.
Confirm with us and your auditor which evidence formats and retention periods your Regional Entity expects before the first test cycle.