CIP-009-6 R1 Recovery plan specifications: evidence guide

What CIP-009-6 R1 requires in a recovery plan

If your organization owns or operates high or medium impact BES Cyber Systems, CIP-009-6 Requirement R1 requires a documented recovery plan that still works after a cyber incident has damaged or disabled those systems. The plan must cover five things: when to activate it (Part 1.1), who does what (Part 1.2), how the information needed to rebuild functionality is backed up and stored (Part 1.3), how you prove those backups actually completed and what you do when they fail (Part 1.4), and how you preserve data so the cause of the incident can be determined (Part 1.5). The requirement carries a Medium Violation Risk Factor. Which systems fall under it is decided by your CIP-002 categorization, and it extends to the associated Electronic Access Control or Monitoring Systems and Physical Access Control Systems of those high and medium impact systems.

Each part addresses a specific failure. Without activation conditions, teams argue about whether an event is serious enough to start recovery while the outage grows. Without named roles, responders wait for decisions nobody owns. Without tested backups of configurations, firmware, and application settings, a rebuilt Cyber Asset may not match what it replaced. Without preserved data, such as logs, memory captures or system images taken before a rebuild erases them, you may be unable to determine how the attacker got in. The plan is hard to make real because the backup and preservation parts depend on what each device can actually export, so confirm with your vendors which configuration and log data each Cyber Asset can produce and where it is stored off the affected network.

Practically, inventory the recovery information for each BES Cyber System, then decide the backup tooling and retention for it. Open-source tools such as Bareos can schedule backup, restore and verify jobs and keep a catalog of what was backed up, while restic's check command with read-data options can confirm stored backup data has not been modified. Confirm how each tool's verification output will be retained as Part 1.4 evidence. Keep the written plan itself in a version-controlled wiki, so the revision history shows when each activation condition or responder role changed. Your internal compliance and operations staff should own the plan, while an outside party may help draft the procedures or check them against the standard, and the auditor or Regional Entity makes the compliance determination.

Which systems and teams CIP-009-6 R1 reaches

CIP-009-6 R1 applies to a defined set of systems, not to every asset an entity operates. Scope is set by the CIP-002 impact rating, and responsibility for recovery is spread across operations, IT, vendors and cloud providers, so the recovery plan has to name who does what for each system it covers.

High and medium impact BES Cyber Systems

R1 requires documented recovery plans for high impact and medium impact BES Cyber Systems. The CIP-002 categorization decides which systems those are, so the scope starts with a current, approved list of BES Cyber Systems and their ratings. Check that every system in that list maps to a recovery plan, and that a system re-rated after a change in CIP-002 is brought into or out of the plan on purpose.

Associated EACMS and PACS

R1 also reaches the Electronic Access Control or Monitoring Systems and Physical Access Control Systems associated with those high and medium impact systems. Teams often forget these supporting systems. Losing an access control server can block recovery of the systems it protects, so its backups and recovery steps belong in the plan with the same rigor as the BES Cyber Systems themselves.

Low impact assets and PCA

Low impact BES Cyber Systems are not in the R1 scope, so an entity whose assets are all low impact should confirm that its CIP-003 cyber security plan covers recovery in its own terms. Protected Cyber Assets are relevant only where they sit within the scope of a covered system, so confirm their status against the applicable table before assuming they are in or out.

Virtualized and shared backup infrastructure

A recovery plan must cover backup systems that hold information needed to recover a BES Cyber System, even when those systems are virtual or shared with IT. Confirm which hypervisors, backup servers, catalogs and storage targets are in the scope of the plan, whether they are dedicated or shared with corporate workloads, and whether a single failure could remove the backups for several covered systems at once.

Operations and IT recovery roles

Part 1.2 requires the plan to set out roles and responsibilities of responders. Control room operators typically decide when recovery is activated and confirm that restored functionality is safe, while IT or platform staff perform the restore. Write these roles by name or function, record who covers each role after hours, and confirm that the operations and IT leads have both read the plan.

Vendors and cloud provider duties

When a vendor or cloud provider holds backups, runs a restore or hosts a recovery environment, the plan must still make the responsibility clear. Record each external party's role, the contract or support terms that govern its response, and how the entity reaches it during an incident. Confirm these terms with the vendor, since the entity remains responsible for the plan even when another party performs the work.

How an auditor tests the recovery plan

This table compares, part by part, how a Regional Entity auditor tests the recovery plan, what evidence is requested and where entities commonly fall short. Read each row as a checklist: the test approach shows what the auditor will do, and the findings column shows what to fix before the audit begins.

Requirement	Test approach and evidence requested	Common findings
Part 1.1: Activation conditions	The auditor reads the documented recovery plan and confirms it states the conditions that trigger activation, such as loss of a BES Cyber System function or a Cyber Security Incident. Evidence is the current plan with its revision history and approval record.	Plans list generic triggers without linking them to the systems in scope, or the plan was never updated after the asset inventory changed.
Part 1.2: Responder roles and responsibilities	The auditor compares the roles named in the plan against current staff, on-call rosters and organization charts. Evidence includes role assignments, responsibilities for each responder and records showing who holds each role today.	Plans name roles or individuals nobody holds, departed employees remain listed, or responsibilities overlap with no clear owner.
Part 1.3: Backup and storage of recovery information	The auditor samples backup job logs and storage locations for the systems in scope and checks that the information needed to rebuild functionality is covered. Evidence includes the backup process documentation, job schedules, storage location records and access controls on the stored copies.	Backup scope omits configuration files, credentials needed for restoration or licensing information, or backups are stored where the entity cannot readily retrieve them.
Part 1.4: Backup verification and failure handling	The auditor reviews verification records for a sample of backups, confirms that completion was checked and that failures were investigated and resolved. Evidence includes verification logs, failure tickets and the corrective action taken.	Verification is described in the plan but no records exist, or backup failures are logged without evidence that anyone addressed them.
Part 1.5: Preservation of data for incident analysis	The auditor asks how data is preserved for determining the cause of a Cyber Security Incident that activates the plan, and checks what each in-scope Cyber Asset can actually retain. Evidence includes the preservation procedure, the capability of each asset type and any tested preservation steps.	The plan assumes logs or memory contents are kept, but the Cyber Asset cannot retain them, or preservation steps conflict with the restoration steps that overwrite evidence.
Audit timing	The auditor's schedule follows the registration. Under Section 403.10.1 of the NERC Rules of Procedure, Balancing Authorities, Reliability Coordinators and Transmission Operators receive a Compliance Audit at least once every three years, while other registered entities are audited on a risk-based schedule set by the Regional Entity. Confirm your entity's schedule with your Regional Entity.	Entities prepare only when notified, leaving insufficient time to assemble the plan, role records and verification logs for the audit period.

Sequence for writing and implementing the plan

This sequence turns the CIP-009-6 R1 requirements into a recovery plan that names the systems it covers, says when it activates, assigns who acts, and shows that backups can be restored and that incident data is preserved. Each step produces a document or record an auditor can compare against the requirement parts.

Confirm in-scope systems from CIP-002
Start from the CIP-002 categorization and list every high impact and medium impact BES Cyber System, together with its associated Electronic Access Control or Monitoring Systems (EACMS) and Physical Access Control Systems (PACS). The registered entity's CIP senior manager or delegate owns this list, and the engineering team checks it against the asset inventory. The step is complete when each system has a named owner and a recorded impact rating, and the scoped inventory is approved and dated.
Define recovery plan activation conditions
Write the conditions under which the recovery plan is activated, such as loss of a BES Cyber System function, the need to rebuild a Cyber Asset, or a Cyber Security Incident that requires recovery. Tie each condition to a decision authority so responders know who declares activation. The output is an activation section of the plan that a reviewer can read and apply without interpretation, and that is cross-referenced to the incident response plan under CIP-008-6.
Assign responder roles and responsibilities
Map each recovery task, including restoration, configuration rebuild, communications, and evidence handling, to a named role and a backup for that role. Record who is accountable for each role, including contractors or vendor staff who would perform restoration. The output is a signed role matrix that matches the current org chart, with contact details kept under the entity's information protection controls. Confirm that role holders have the access and training the recovery work needs.
Design backup and storage of recovery information
Identify the information needed to rebuild each system's functionality, such as configurations, images, credentials held in a protected vault, licenses, and vendor media, then set a backup method, schedule, and storage location for each item. Storage that leaves the Electronic Security Perimeter or the premises must be assessed against BCSI protection expectations under CIP-011-3. Open-source tools such as Bareos can schedule and catalog backup jobs, but the entity must confirm capabilities against its own environment. The output is a backup inventory mapping each system to its recovery data and storage target.
Set backup verification and failure handling
Write a procedure that confirms each backup completed successfully and that the stored data is readable and unmodified. Checks can include catalog reconciliation and structural verification, and for repositories such as restic, reading pack data back with its read-data options. Define what happens when a backup fails: who is alerted, how the gap is closed, and how the failure is recorded. The output is a verification procedure with a sample log entry showing a failed backup, its handling, and its closure.
Define incident data preservation per Cyber Asset capability
For each in-scope Cyber Asset, document what data can be preserved for determining the cause of a Cyber Security Incident, such as logs, memory captures, configuration snapshots, and file hashes, and how it is collected without disrupting recovery. Where a device cannot retain certain data, record that limitation and the compensating step. The output is a preservation matrix by asset type, reviewed with the incident response team so that recovery activity does not destroy evidence needed for analysis.
Document, approve and store the plan
Assemble the activation conditions, role matrix, backup and verification procedures, and preservation matrix into one controlled recovery plan, then record the approval by the responsible senior manager. Store it in a version-controlled wiki or document system that keeps change history and permits rollback, and restrict edit rights to named maintainers. The output is an approved, dated plan version with a change log, and a confirmed location where responders can reach it when the primary environment is unavailable.

Evidence that passes a CIP-009-6 R1 review

A CIP-009-6 R1 review checks whether the recovery plan exists, is current, and is backed by records showing the processes work. The six artifacts below connect the plan to the people, backups, verification results and preserved data an auditor will sample. Keep each one dated and version-controlled so the set stays consistent between audits.

Approved recovery plan with version history

The recovery plan itself must be documented for each applicable high or medium impact BES Cyber System and its associated EACMS and PACS. Auditors look for an approval record, the effective date, and a change history showing who edited what and when. Keep the plan in a wiki or document system that records every revision and allows comparison between versions, so you can show the plan in force on any date in the audit period. Check that the plan names the systems it covers, since a plan that omits an in-scope system fails the requirement even if the rest is sound.

Role and responsibility matrix

Part 1.2 requires the plan to define who responds and what each responder does. A matrix that maps roles to named teams, alternates and contact paths is the artifact auditors compare against the activation record. Review it whenever personnel or on-call rotations change, and confirm that the people listed have the access the role needs. Store the matrix with the plan so a reviewer can see the assignments in force at a given time. Note that the review cadence for role changes is covered in the sibling topic on plan review.

Backup job records and storage locations

Part 1.3 requires processes for backing up and storing the information needed to recover BES Cyber System functionality. Job logs from your backup tool show what was backed up, when, and to which repository, and the storage location record shows where copies are kept. Bareos keeps a SQL catalog of backed-up files that can support this evidence, and its Director records scheduled backup, restore, verify and archive jobs. Document which configuration, credentials and recovery information are included, and confirm with your own environment how long job logs and catalogs are retained.

Backup verification and failure records

Part 1.4 requires a process to verify that backups completed successfully and to address failures. Keep verification output alongside the failure tickets showing how each failed job was investigated and resolved. Restic's check command verifies the structural consistency of snapshots, trees and pack files, and its read-data option reads pack files back to confirm stored data is unmodified. Retain both the successful verification results and the records of failed backups, because an auditor will ask how a failure was handled, not just whether one occurred.

Data preservation procedures per asset type

Part 1.5 requires processes to preserve data, to the extent each Cyber Asset supports it, so the cause of a Cyber Security Incident can be determined. Write a procedure for each asset type, such as servers, workstations, network devices and PACS hardware, that states which logs, memory captures, configuration snapshots or disk images are collected and where they go. Mark the limits for devices that cannot export certain data, since the requirement is framed by per Cyber Asset capability. Test the procedure against at least one asset per type so the written steps match what the device can actually produce.

Activation records from exercises and real events

Part 1.1 requires defined conditions for activating the plan, so activation records show that those conditions were applied. Record the date, the trigger, the decision maker, the roles activated and the actions taken, whether the event was a test or a real Cyber Security Incident. These records also feed the lessons learned and plan updates covered in the sibling topic on review and communication. If no activation occurred in the period, keep the most recent exercise record instead, and confirm with your auditor what evidence they expect for that case.

Self-hosted tools that produce backup and documentation evidence

Bareos is an open-source backup system licensed under AGPL-3.0-only. Its Director schedules and supervises backup, restore, verify and archive jobs, and keeps a SQL catalog of the files it has backed up. That catalog is what lets an operator select files from the current backup or from a backup taken before a given date and time, which matters when the recovery question is what state a system was in before an incident. For R1, Bareos can supply evidence that the processes in Part 1.3 exist and run, including job schedules, catalog records and restore logs. It does not decide which information is required to recover BES Cyber System functionality, so the entity still has to define that list and map it to the jobs.

Scheduled jobs: Job definitions and schedules show what is backed up, how often and to which storage target.
Catalog records: The SQL catalog shows which files were backed up and when, which supports the storage evidence.
Point-in-time restore: Restore selections from an earlier date and time show that older recovery points are retrievable.
Verify and archive jobs: These show the process is more than a copy job, but they still need to be linked to the Part 1.4 record.
Licensing: AGPL-3.0-only has network-use obligations if the software is modified and offered to users, so legal review is needed.

Confirm with your compliance and legal teams that the Bareos catalog, job logs and storage location fit your CIP-009 evidence retention and any BCSI handling rules that apply to backup media.

What meeting CIP-009-6 R1 costs in money and effort

Meeting CIP-009-6 R1 has almost no license cost if the recovery tooling is open source, but it still has real spend. The main components are engineering time to write the recovery plan and its role matrix, the infrastructure that holds backups, support or maintenance for the backup and wiki platforms, and the time spent keeping evidence current. Bareos, restic, XWiki and BookStack carry no license fee in the sense that matters for budgeting, so the money goes to people, storage, hardware and any support contract you choose to buy. Ask any partner to show each of these as a separate line in a written quote, so you can see who is paid for design, who is paid for build, and who is paid for ongoing operation.

The one-time work is front-loaded and fairly predictable in shape: defining activation conditions and responder roles (Parts 1.1 and 1.2), designing the backup and storage scope for each high and medium impact BES Cyber System and its associated EACMS and PACS (Part 1.3), designing how backup completion and failures are checked (Part 1.4), and specifying how Cyber Asset data is preserved for incident analysis (Part 1.5). Recurring work is the less visible part: keeping the plan current as systems change, reviewing backup verification output, storing and rotating media or repository copies, and collecting evidence for the Compliance Enforcement Authority, which audits on a schedule set by the Regional Entity or, for Balancing Authorities, Reliability Coordinators and Transmission Operators, at least once every three years under Section 403.10.1. External review and auditor sampling are costs you control mainly through preparation: the more consistent your records, the less time an auditor or consultant spends reconstructing them.

Cost drivers are the number and diversity of in-scope systems, the data volume and retention periods you must keep, the number of sites and whether storage is on premises or in a provider's environment (see the cloud guidance on this site for how BCSI and backups are handled there), and how often your responder roles change. To ask for a quote that is comparable across bidders, request a written scope listing the in-scope systems by impact rating, the backup targets and storage locations, the verification method for each target, the evidence set you will receive, the hours assigned to each one-time deliverable and to each recurring activity, and the assumptions about your staff's availability. Confirm with your own compliance team which costs already exist internally, such as storage and retention, so the quote does not double-count them.

Who owns the recovery plan, the partner and the auditor

The registered entity is the organization that holds the NERC registration and is accountable for compliance with CIP-009-6 R1. It decides which BES Cyber Systems and associated EACMS and PACS fall within the plan, sets the activation conditions, names the responder roles and approves the plan through its own governance. Those decisions reflect operational knowledge that no outside party holds in full, including how control rooms operate, which vendors support which systems and who has authority to declare a recovery.

Plan ownership: The entity approves the plan, assigns an accountable owner and keeps it current as systems and staffing change.
Roles and activation: The entity defines who declares activation, who leads recovery and how responders are reached outside business hours.
Backup decisions: The entity chooses what information is needed to recover functionality, where copies are stored and how long they are kept.
Evidence: The entity holds the records of backups, verifications, failures and data preservation that an auditor will request.
Sign-off: Senior management or the CIP Senior Manager approves the plan under the entity's own delegation records.

Before engaging any partner, confirm that your internal owner can explain every activation condition and responder role without reading the document aloud.

Where recovery plans usually fail review

Assessors reviewing CIP-009-6 R1 tend to find the same gaps: plans that leave out key elements, roles that no longer match the staff, and backup processes that exist on paper but are not proven. Each card below names one gap, why it matters under Requirement R1, and the check that closes it.

Activation conditions are missing

Many plans describe how to rebuild a system but never state what event triggers the plan. Part 1.1 requires conditions for activating the recovery plan, so an assessor will look for written criteria, such as loss of a BES Cyber System's function or a confirmed Cyber Security Incident, tied to who decides to activate. Check that each high and medium impact plan names its triggers and the decision owner, and that operators can find them without reading the whole document.

Roles name people who have left

A responder table listing individuals rather than positions fails quickly once staff change. Part 1.2 requires the roles and responsibilities of responders, and a plan that names a former engineer as the restore lead shows the plan is not maintained. Assign roles to positions, keep a current contact roster, and confirm the list against HR changes and on-call schedules at each plan review.

Backups run but are never verified

A green backup job does not show that the data can restore. Part 1.4 requires processes to verify that backups completed successfully, and a restore test is the strongest proof. Record the verification method for each backup set, such as catalog checks in Bareos or restic check with --read-data-subset, and keep the output as evidence that the stored data was read back.

Failed backups lack a handling process

Plans often describe successful backups but say nothing about a failed one. Part 1.4 also requires processes to address backup failures, so the plan needs a defined response: who is alerted, how long a gap may persist before escalation, and how a missed backup is rerun or compensated. Document the alert path and the escalation step, then show a sample ticket or log entry proving the process was followed.

Incident data overwritten during recovery

Restoring a system can erase the logs, memory captures and configuration state that show how an incident happened. Part 1.5 requires processes to preserve data, to the extent each Cyber Asset allows, so the cause of a Cyber Security Incident can be determined. Set a preservation step before rebuild begins, record what each asset can retain, and coordinate it with the CIP-008 response plan so forensic copies are taken first.

Questions about CIP-009-6 R1 cost, effort and support

Can our team write the CIP-009-6 R1 recovery plan ourselves?

Yes, in most cases the registered entity writes and owns its recovery plan, because the standard places the obligation on the entity, not on a consultant. The plan needs documented activation conditions, responder roles, backup and storage processes, backup verification processes and data preservation processes for each applicable BES Cyber System, EACMS and PACS. Staff who know the systems and the operating procedures can draft it directly. A partner can help with structure, technical content and gap review, but the entity approves the plan and keeps it current. Confirm internally who signs off and who holds the CIP Senior Manager's accountability before work starts.

What drives the effort needed for CIP-009-6 R1?

Effort rises with the number of applicable systems and how they are grouped. The main drivers are the count of high and medium impact BES Cyber Systems in scope, the number of associated EACMS and PACS, how many distinct recovery procedures exist, and whether systems share backup infrastructure. Other factors include how well current backups are documented, whether restore steps are written down or live only in people's heads, and how many vendors or off-premise locations hold recovery information. Entities with well-kept configuration baselines usually have less reconstruction work to do.

How long does it take to produce a compliant recovery plan?

No fixed duration applies because the time depends on the scope and the current state of the environment. The reliable way to estimate is to inventory the in-scope systems, list the recovery information each one needs, and check what backups already exist. Ask any partner for a written scope and a timeline tied to those deliverables, not a generic figure. Plan for time to gather information from system owners, test restore steps where possible, and get internal review. Confirm the schedule with your compliance team, since it must align with the CIP-009-6 R2 testing cycle.

What does the work need from our staff?

The work needs time from people who own the systems, backups and access controls, plus someone who understands the CIP obligations. Typical contributors are system administrators who know restore steps, backup operators who run and monitor jobs, security staff who define incident preservation needs, and a compliance lead who checks the plan against the requirement parts. Ask system owners to confirm the activation conditions and responder roles they actually use. Budget for review cycles, because a plan that no responder has read rarely survives an assessor's questions.

Can a partner issue CIP compliance evidence for us?

No. Compliance is monitored by the Compliance Enforcement Authority, which is a Regional Entity or NERC, through audits, spot checks, self-certifications and self-reports. There is no CIP certificate that a consultant or implementation partner can issue. DeployOpen prepares systems, documentation and evidence for review, but it does not issue audit reports, attestations or certifications. The registered entity owns its controls and presents its evidence to the Compliance Enforcement Authority. Confirm with your Regional Entity which evidence formats and retention periods it expects.

How do open-source backup tools fit into the recovery plan?

Open-source tools can supply the backup, verification and restore evidence that the plan describes. Bareos schedules and supervises backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files, which helps document what is stored and how to restore it. restic's check command verifies structural consistency and, with the read-data options, reads pack files back to confirm stored data is unmodified, which supports the backup verification process. The tools do not decide the plan's content. Confirm each tool's license terms, such as Bareos under AGPL-3.0-only, against your own policies and procurement rules.

Which parts of the recovery plan cost the most to get right?

The costliest parts are usually the ones that depend on accurate knowledge of live systems. Writing activation conditions and responder roles is relatively quick once the organization agrees on them. Confirming backup and storage processes, proving that backups can be restored, and defining data preservation for each Cyber Asset type take more time because they involve testing and tracing data locations. Preservation can be complex where asset capabilities vary. Ask any quote to separate documentation work from technical verification and to state which systems each line covers.

How DeployOpen prepares CIP-009-6 R1 evidence

DeployOpen plans, implements and documents the self-hosted, open-source backup, verification and documentation systems that support a CIP-009-6 R1 recovery plan, inside your own cloud accounts, data centers or air-gapped networks. The work runs under a fixed written scope that names the in-scope BES Cyber Systems, the associated EACMS and PACS, the backup targets, the retention settings and the deliverables before anything is built. DeployOpen does not own your controls. Your organization decides its recovery plan contents, responder roles and activation conditions, and DeployOpen helps turn those decisions into configured systems and records a Regional Entity or auditor can inspect.

In practice, that means configuring a Bareos Director to schedule backup, restore and verify jobs with a catalog that shows what was backed up and when, and setting up restic check runs with --read-data-subset so that stored backup data is read back and confirmed unmodified. It also means keeping the recovery plan itself in a versioned wiki such as XWiki, where each change records what changed, when and by whom, and in BookStack with role-based permissions so that only named responders can edit the plan. Each of these outputs maps to a Part of R1, and DeployOpen documents how the evidence was produced. Confirm with your team which Part 1.5 data preservation steps your Cyber Assets can actually support, since that depends on each asset's capability.

DeployOpen prepares systems and evidence but does not issue audit reports, attestations or compliance determinations. Only the Compliance Enforcement Authority, which is a Regional Entity or NERC, can monitor compliance and reach a finding, and the audit timing and scope are set by the Regional Entity under its schedule. If you want to discuss how these systems could be scoped for your environment, contact DeployOpen for a scoping conversation. Bring your impact categorization from CIP-002, your current backup inventory and any open findings. The written scope, and therefore the quote, follows from that discussion, and DeployOpen does not publish a price list.

CIP-009-6 R1 Recovery plan specifications