CIP-009-6 R3 Recovery plan review and update: requirements

What CIP-009-6 R3 requires after a recovery test or real recovery

When a recovery test or an actual recovery finishes, the compliance clock starts. Under CIP-009-6 Part 3.1, you must, no later than 90 calendar days after the test or recovery, document the lessons learned (or record that there were none), update the recovery plan to reflect them, and notify the people who hold defined roles in the plan. The second trigger is a change to roles or responsibilities, responders, or technology that you determine would affect how the plan runs. Part 3.2 gives you 60 calendar days from that change to update the plan and notify the role holders. Both triggers apply to high impact BES Cyber Systems and to medium impact BES Cyber Systems at Control Centers, along with their associated EACMS and PACS. A violation of R3 carries a Lower Violation Risk Factor, but a missed deadline is still a documented finding, so the clock needs to be tracked.

The work usually stalls at the first step. Teams run a restore, fix the problems on the bridge call, and move on, but nobody writes down what went wrong, what took longer than expected, or why a step failed. Without that written record, there is nothing to update the plan from, and the 90-day window passes quietly. Assign one owner to open a dated record for each test or recovery on the day it ends, and require that it state either the lessons or an explicit note that none were identified. Confirm with your Compliance Enforcement Authority how they expect that record to look, since the standard does not prescribe a format.

Notification is the step most often missed in audits. The standard requires you to notify people with defined roles, so the plan's role list needs to be current and each named person or team needs a provable notice, such as a dated email, ticket, or wiki acknowledgment. For the plan itself, a version-controlled document helps: a wiki that keeps page history, lets you compare versions, and records who changed what can show the update date and the before and after text. Keep the lessons, the plan revision, and the notices together so an assessor can trace one event from the test to the update to the notice. Check the exact notification wording and any internal approval steps against the NERC CIP-009-6 standard before you finalize your procedure.

Which systems, teams and changes bring CIP-009-6 R3 into scope

CIP-009-6 R3 applies to a narrower set of assets than the full CIP program, but the triggers for review are broad. The cards below separate the systems in scope, the changes that start the 60-day clock, and the people and third parties who must be notified.

High impact BES Cyber Systems

R3 applies to every high impact BES Cyber System covered by the recovery plan, which is set by the bright-line categorization under CIP-002-5.1a. Confirm that the categorization list is current, because a system added or reclassified without a matching plan update leaves a gap. Check that each high impact system maps to a named recovery plan and that the plan's review records reference that system.

Medium impact systems at Control Centers

For medium impact assets, R3 reaches only BES Cyber Systems located at Control Centers, not the medium impact systems at substations or generation sites. Entities often assume their whole medium impact population is in scope and over-build the program. Document the Control Center boundary decision, since an assessor will ask how you separated the two groups.

Associated EACMS and PACS

The recovery scope extends to the Electronic Access Control or Monitoring Systems and Physical Access Control Systems associated with those BES Cyber Systems. Authentication servers, access logs and badge systems can fail in ways that block operator access during recovery. Confirm each associated EACMS and PACS is listed in the plan, and that its recovery steps are covered in the same review cycle.

Changes the entity judges to affect execution

The 60-day update clock starts when a change to roles, responders or technology would affect how the plan runs, and the entity makes that call. Write a short decision rule that lists what counts, such as a new backup product, a changed on-call roster or a migrated recovery site. Record the determination for each change, including the ones you decide do not trigger an update.

Internal teams on the notification list

Part 3.1 and Part 3.2 require notifying people with defined roles, so the notification list must match the responder roles in the plan. Include operations, system administration, backup, physical security and the CIP Senior Manager where their duties appear in recovery steps. Confirm that role holders change when staff move, and that the list is reviewed whenever the roster changes.

Third parties and managed service providers

Vendors that host backup platforms, run managed recovery services or support vendor-owned equipment often hold steps in the plan. A change at the provider, such as a new support model or a moved backup target, can trigger R3 review even though your staff made no change. Confirm the contract and support contacts are in the notification list and that the provider receives updated plans when they change.

How an assessor tests the 90-day and 60-day update obligations

This table compares how an assessor tests Part 3.1 (post-test and post-recovery updates within 90 days) and Part 3.2 (change-driven updates within 60 days), with the evidence each test relies on. Read each row as a sample the assessor pulls, the check they run on it, and the gap that most often produces a finding.

Test step	Part 3.1: after a test or actual recovery	Part 3.2: after a relevant change
Population and sample	Assessor requests every recovery plan test and actual recovery in the audit period, then samples a subset of events	Assessor requests the change records the entity determined would affect plan execution, then samples a subset
Deadline check	Compares the event date with the date lessons learned were documented and the plan updated, against the 90 calendar day limit	Compares the change date with the date the plan was updated and notifications sent, against the 60 calendar day limit
Lessons learned evidence	Looks for a dated record of lessons learned, or a documented statement that there were none	Not applicable to this part, but the change record must state what was affected
Plan update evidence	Compares plan revision history with the lessons learned, confirming the updated version exists	Compares plan revision history with the change record, confirming roles, responders or technology references were revised
Notification check	Confirms people with defined roles were notified after the update, with dates and recipients	Confirms notification reached people with defined roles affected by the change, not only the plan owner
Determination check	Confirms the entity recorded a basis for deciding which tests or recoveries required an update	Confirms a dated, signed determination exists for every change judged to affect plan execution, including changes judged not to
Common finding	Lessons learned missing for a completed test, or no record that lessons learned were absent	Late updates beyond 60 days, or changes with no documented determination of effect on the plan
Evidence to keep ready	Test reports, lessons-learned entries, plan revision records, notification emails or distribution logs	Change tickets with impact determinations, plan revisions, role-holder notification records, dated sign-off

How to build a repeatable review and update cycle

This sequence turns CIP-009-6 R3 from an occasional clean-up into a standing routine: every test, real recovery or qualifying change opens a dated record, and the plan, its version history and the notice to role holders are all provable afterward. The output is a closed loop that an auditor can follow from trigger to update to notification.

Define the trigger log
Create one register that lists every event that can start an R3 clock: each recovery plan test, each actual recovery, and each change to roles or responsibilities, responders or technology that the entity judges would affect plan execution. Assign an owner, usually the CIP program lead with input from the recovery plan owner, and write down the criteria used to decide whether a technology or staffing change counts. Done means every in-scope BES Cyber System and its associated EACMS and PACS is covered by the register, and the criteria are approved and dated.
Set the clock on each event
When an event is logged, record its date and calculate the deadline for the applicable part: the 90 calendar day limit for test or actual recovery lessons learned under Part 3.1, or the 60 calendar day limit for qualifying changes under Part 3.2. Put both dates in the tracker with reminders to the owner. Confirm the calendar convention with your Regional Entity and your compliance tool, because the standard counts calendar days. Done means every open event shows a start date, a part reference and a due date.
Capture lessons learned
After the test or recovery, the responders hold a structured review that records what worked, what failed, what was slower than expected and which roles or tools were unclear. If nothing needs to change, the record must still say so, because Part 3.1 accepts documented absence of lessons learned. Attach the test results, backup verification output and timeline. Done means a signed review record exists for the event, with each finding assigned to a plan change or explicitly closed.
Update the plan under version control
Make the plan changes in a wiki or document system that keeps history of every edit, who made it and what changed. Tie each change to a finding or to the triggering change in the log so the reasoning is traceable. Use role-based permissions so only the designated editors can publish. Done means the revised plan is approved, carries a new version number, and the diff from the prior version is retained.
Notify role holders
Send the updated plan, or a clear notice pointing to it, to every person with a defined role in the plan, including backup responders and any contractor or vendor staff with a role. Record the date, method and recipient list, and ask recipients to confirm receipt where practical. Done means each named role holder has a dated notification record that falls within the required deadline.
Retain proof and close the event
Store the trigger entry, the deadline calculation, the lessons learned record, the plan version and diff, and the notification records together under the event identifier. Close the event only when all parts are evidenced. Run a periodic check of the register for any open items past their due dates. Done means an assessor can pick any test, recovery or qualifying change and follow it from trigger to closure without asking for missing records.

How the 90-day and 60-day clocks start and what counts as a change

The two triggers in CIP-009-6 R3 start two different clocks, and mixing them up is the most common way to miss a deadline. The 90-day clock starts when a recovery plan test is performed or when a recovery is actually carried out. The 60-day clock starts when a change to roles or responsibilities, responders or technology occurs that the entity determines would affect how the plan is executed. Each clock has its own start event, so one completed exercise does not reset the clock for an unrelated staffing change, and a staffing change does not extend the time allowed after a real recovery. Before the next test cycle, the team should write down which event starts each clock and who is authorized to declare it.

For the test or recovery trigger, record the actual calendar date the exercise was completed or the restoration was declared finished, not the date the test was scheduled. Keep the exercise record, such as a test ticket, a restore log or a signed close-out note, in the same location as the plan revision history so an assessor can trace the start date to a source document. For the change trigger, the date to record is the date the change took effect or the date the entity first learned of it, depending on what the entity has defined in its own procedure. Confirm that definition with your Compliance Enforcement Authority contact or your internal compliance lead, and apply it consistently. A change log entry that names the change, the date and the owner is usually enough to support the start date.

The entity must make the call on whether a change affects plan execution, and that determination needs its own record. Write a short decision note for every change that states what changed, which recovery steps or responder assignments it touches, the conclusion reached, and who approved the conclusion. Record the decision even when the answer is no, because an assessor will ask how the entity screened changes it did not act on. Decide the clock start rules, the date sources and the determination criteria in writing before the next trigger occurs, since the standard sets the deadline and does not wait for the team to agree on interpretation after the fact.

Evidence that shows R3 was met and how to keep it current

An auditor checking CIP-009-6 R3 looks for a dated trail that connects each test or real recovery to a lessons-learned record, a plan revision, and a notification. The cards below cover the artifacts that make that trail, and the routine checks that keep them complete between Compliance Audits.

Dated lessons-learned records

Each recovery plan test or actual recovery needs a written record of lessons learned, or a documented statement that none were identified. Record the exercise date, the participants, the findings and who reviewed them. Auditors measure the 90 calendar day clock from the test or recovery date, so that date must be written on the record itself. Confirm the record exists even for tests that went cleanly.

Plan revision history with approval dates

Keep every version of the recovery plan with its approval date, approver and a summary of what changed. A revision history lets an assessor match each update to the test or change that triggered it. Versioned wiki tools can record this automatically, but confirm that deleted or overwritten versions remain retrievable for the audit period.

Change determinations for roles and technology

When roles, responders or technology change, record a determination of whether the change would affect plan execution. A dated determination, even one concluding no update is needed, shows the entity assessed the change. Where the determination is positive, the 60 calendar day update clock starts from the change, so the record should state that date plainly.

Notification records for responders

Keep dated evidence that people with defined roles received the updated plan or the lessons learned. Email headers, distribution list snapshots or signed acknowledgments all serve this purpose. Compare the notification list against the current roster each quarter so that staff who changed roles still receive updates.

Current distribution lists

Maintain a distribution list that names each role defined in the plan, the person currently holding it and their backup. Stale lists are a common reason notifications fail review even when the emails were sent. Reconcile the list against access records and personnel changes, and retain prior versions so an assessor can see who held each role during a given window.

Routine checks between audits

Schedule a recurring review that confirms each test, recovery and role change has a matching lessons-learned record, plan revision and notification. Store the review output with the evidence it checked. Gaps found in this review are easier to explain than gaps found by an auditor, and an entity can document its own remediation of them.

Which self-hosted tools keep R3 evidence in order

The R3 Part 3.1 and Part 3.2 deadlines are measured in calendar days from a test, an actual recovery, or a qualifying change. An assessor will ask for the plan version in force at each point, the lessons-learned entry for each test, and proof that the update came inside the window. A wiki with version history can supply much of that trail, provided the entity keeps the plan and its lessons learned in the same controlled space.

Version history: XWiki keeps every change to a page under version control, recording what changed, when and by whom. This gives a dated record for each plan revision.
Version comparison: Users can compare any two versions and roll back to an earlier one, which helps show exactly what an update changed after a test.
Role-based access: BookStack assigns user abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. Editing rights to the recovery plan can be limited to named responders and the CIP Senior Manager's delegates.
Notification evidence: Neither tool sends notices to people with defined roles on its own. Keep a separate record, such as a dated distribution list or acknowledgment, to show the notification happened.

Before relying on either tool, confirm with your own compliance lead that the platform's audit trail and export options meet your retention rules, and that the wiki is not the only copy of records an auditor may request.

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

This table breaks down the cost components of the R3 review cycle, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Read it as a list of quote line items to ask for, since no price figures are supplied for this requirement. The main takeaway is that most of the recurring cost is staff time tied to test frequency and change volume, while the tooling cost can be near zero with self-hosted open-source platforms.

Cost component	Who is paid or who carries the effort	One-time or recurring	What drives it
Lessons-learned review after a test or real recovery	Internal recovery staff, with a facilitator if the entity uses one	Recurring, once per test or actual recovery	Number of tests per cycle and how many responders take part
Recovery plan update within 90 days	Plan owner and subject matter experts writing the changes	Recurring, per test or recovery event	Size of the plan and how many steps the lessons learned change
Change tracking for roles, responders and technology	Plan owner, with input from IT and operations teams	Recurring, per qualifying change	Frequency of staff turnover, reorganizations and system changes
Notification to people with defined roles	Plan owner or coordinator, plus a notification record	Recurring, within the 90-day and 60-day windows	Number of role holders and how often their contact details change
Wiki or document tooling	Internal IT, or an implementation partner for setup if scoped	One-time setup, then recurring hosting and administration	Choice between licensed and self-hosted open-source platforms, and the number of users
Version history and evidence upkeep	Plan owner and records custodian	Recurring, every update	How the platform keeps version history and how evidence is filed and retained
External review of the plan	Independent reviewer or consultant if the entity buys one	Recurring or per engagement, depending on scope	Plan complexity, reviewer experience and whether the review is a fixed-scope engagement
Auditor sampling time	Internal staff preparing evidence for the Compliance Enforcement Authority	Recurring, per audit or data request	Audit schedule set by the Regional Entity and how quickly records can be retrieved

Who owns the update, who can help and where the auditor stops

The registered entity owns the recovery plan, its compliance determinations and its sign-off. Under CIP-009-6 R3, the entity decides whether a test or actual recovery produced lessons learned, whether a change to roles, responders or technology would affect plan execution, and when the update clock starts. Those decisions carry the entity's name, so they cannot be delegated to a consultant or a tool.

Determinations: The entity records whether each change affects plan execution and documents the reasoning behind a no decision as well as a yes.
Clock ownership: The entity tracks the 90 and 60 calendar day windows in Part 3.1 and Part 3.2 against a named owner and an internal due date.
Lessons learned: Responsible staff write, or formally accept, the lessons learned from each exercise, including the statement that there were none.
Notification: The entity sends updates to personnel with defined roles and keeps proof of who was notified and when.
Sign-off: An accountable manager approves each revised plan version before it becomes the operative document.

Check that your internal procedure names the person who makes each determination and that the notification list matches the current roles in your plan.

Where R3 usually fails and how to close each gap

Most CIP-009-6 R3 findings come from process gaps rather than missing plans. The gaps below cluster around three moments: when the clock starts, what happens after a change, and how the updated plan is distributed and kept on record.

No recorded clock start

R3 deadlines run from a specific event: the end of a recovery plan test or actual recovery, or the date a qualifying change occurred. If the team cannot show when the test or recovery ended, the 90-day window cannot be proven. Fix this by making the closing step of every test or recovery a logged event with a date, time and owner. Ask whether your ticketing system records that end point automatically or only when someone remembers to enter it.

Lessons learned written late

Part 3.1 requires documenting lessons learned, or recording that there were none, within the 90-day window. Teams often draft the review weeks later, after the people involved have moved on, and the document ends up dated after the deadline. Set a short internal review date well before the outer limit, assign an author, and store the signed-off record in the same place as the test results so the timing is visible.

Role and technology changes not evaluated

Part 3.2 is triggered by changes to roles, responders or technology that the entity determines would affect plan execution, and the 60-day clock starts from that change. Many gaps occur because staffing moves or a new backup platform is adopted without anyone deciding whether it matters. Create a standing change check in your change management process that asks the plan owner to record a yes or no decision, with reasons, for every role or technology change.

Notifications sent to outdated lists

R3 requires notifying personnel with defined roles after an update, and a notice sent to a former responder or a missing new hire leaves the plan unevidenced. Lists drift because they are maintained in personal inboxes or spreadsheets. Tie the notification list to the roles defined in the plan, pull contact details from the current directory, and keep the sent notice and recipient list as evidence.

Plan updates without version history

An auditor will ask which version of the plan was in force on a given date and what changed. Overwriting a shared document destroys that answer. Keep the plan in a wiki or document system that records each change with its author and timestamp, and allows comparison between versions. Confirm with the platform vendor exactly how version history, diff views and rollback are retained and whether the retention period meets your evidence retention policy.

Access to plan edits not limited

If anyone with wiki access can edit the recovery plan, changes can be made without the approval the update process assumes. Restrict edit rights to named plan owners through role-based permissions, and require that the approver is recorded alongside each version. Review who holds edit rights at the same cadence as your other access reviews so the plan's change trail stays credible.

What buyers ask before bringing in help for CIP-009-6 R3

How much effort does one test-to-update cycle take?

No effort figure is supplied for this cycle, so confirm it against your own plan and test records. The effort depends on how many responders and roles the plan names, how many technologies it covers, and how many findings the test or actual recovery produced. Each cycle includes four pieces of work: documenting lessons learned (or recording that there were none), updating the plan, notifying the people with defined roles, and keeping the records that show each step. A small plan with a clean test is a much lighter job than a plan with failed restore steps that need engineering changes, new procedures and re-testing. Ask any provider for a breakdown of these four tasks in the written scope so you can see who does each one.

Can our own team handle CIP-009-6 R3 updates in-house?

Yes, in many cases. The organization owns its controls, and R3 is a documentation and communication obligation that your own recovery staff can carry out if they understand the standard and have time after each test. The work usually becomes difficult when the same few engineers run the tests, write the lessons learned, and maintain the plan, because the 90-day and 60-day clocks then compete with routine operations. An implementation partner can take on the preparation work, such as drafting update records, organizing role notifications and assembling evidence packages. An independent auditor, not a partner, is the party that assesses whether your updates meet the requirement.

What does a partner need from us to start?

A partner needs enough of your recovery program to see what exists and what has changed. Typical inputs include:

The current recovery plan and the test or recovery records from the last cycle
Your BES Cyber System categorization, so the team knows which systems fall under R3
A list of current roles, responders and their contact channels
A change log for roles, responsibilities and technology since the last update
Read access to the backup and documentation platforms that hold the plan and its records

Agree in writing which of these you will provide, who inside your organization owns each one, and how quickly you expect review comments. Fixed-scope work depends on these inputs being ready when the work starts.

How long does the R3 update work take?

The duration of the work is not supplied as a fixed figure, so confirm it in the written scope rather than assuming one. The requirement itself sets the deadlines you must meet: no later than 90 calendar days after a recovery plan test or actual recovery for Part 3.1, and no later than 60 calendar days after a qualifying change to roles, responders or technology for Part 3.2. Those are the outer limits. The time an update needs depends on the plan's size, how many roles change, and how quickly your reviewers respond. Plan backward from the deadline, and treat any engagement as a schedule that begins only after the scope, the inputs and the review owners are confirmed.

What happens if we miss the 90-day or 60-day deadline?

A missed deadline is a potential violation of R3, and the Compliance Enforcement Authority, either a Regional Entity or NERC, decides how to treat it. Violations can surface during a Compliance Audit, a Spot Check or through a Self-Report that your organization files. Sanctions follow NERC's Sanction Guidelines, and the maximum civil penalty referenced there is $1,584,648 per violation, per day, as adjusted by FERC Order No. 906 and shown in the eCFR entry for 18 CFR 385.1602. In practice, the outcome depends on the facts, your compliance history and the mitigation you show. Reporting promptly and documenting remediation are the steps your compliance lead should plan for, and your counsel should confirm the approach.

How do R1, R2 and R3 fit together in practice?

R1 defines what the recovery plan must contain, including activation conditions, responder roles, backup information and verification. R2 requires the plan to be tested and exercised on the schedule the standard sets, which is every 15 calendar months for the test and, for high impact systems, an operational exercise at least every 36 months. R3 closes the loop. It is the step that turns each test or actual recovery into a dated obligation to record lessons learned, update the plan and notify responders. In practice, a test under R2 starts the 90-day R3 clock, so a weak R1 plan will show up as R3 findings after each test. Review R1 and R2 together with R3 before you set the update schedule.

Which tools help keep R3 update records?

Several open-source tools can hold the records R3 produces, although you should confirm each fit with your own environment. XWiki keeps every change to a page under version control, recording what changed, when and by whom, and it lets users compare versions and roll back. That history is useful evidence that each update followed a test. BookStack assigns abilities through roles and lets permissions be overridden per role at the shelf, book, chapter or page level, which helps limit who can edit the plan and who can see responder details. For the backups that feed recovery tests, Bareos keeps a catalog of backed-up files and supports restores from a given date and time, and restic's check command can read pack files back to confirm stored data is unmodified.

Who confirms that our R3 updates meet the requirement?

An independent auditor or the Compliance Enforcement Authority assesses whether your updates meet R3. DeployOpen and other implementation partners do not issue audit reports or certifications. Their role is to prepare systems, procedures and evidence so your team can show what happened after each test, what changed in the plan, and who was notified. Your organization stays accountable for the outcome. Before the engagement starts, agree with your partner which artifacts will serve as evidence, how they will be stored, and how your compliance team will review them. Read the CIP-009-6 standard directly so your team, not only the partner, understands the wording the assessor will apply.

How DeployOpen prepares R3 records and evidence

DeployOpen sets up the records that CIP-009-6 R3 depends on before any recovery test or real recovery happens. The work is scoped in writing first, with the systems, backup platform and wiki or document tools named, and the scope defines which environments are covered. On self-hosted platforms, we configure a trigger log that records each test, actual recovery or qualifying change to roles, responders or technology, with the date it occurred. That single log lets the entity show when each 90-day (Part 3.1) and 60-day (Part 3.2) clock started. The entity then decides which changes would affect plan execution, because that judgment belongs to the organization and not to the implementation partner.

The lessons-learned section and plan versions are built as a documented structure in the team's own wiki. For example, a page template can hold the test date, the findings or a statement that no lessons were identified, the plan revision that followed, and the notification list. Version history in the wiki keeps a record of what changed, when and by whom, so an assessor can compare the plan before and after an update. Role-based permissions limit who can approve and publish plan changes, and notification records can be kept alongside the revision they relate to. Confirm with the wiki vendor's documentation exactly how version history and permissions behave in your edition.

DeployOpen prepares this evidence for the entity's own review. We do not issue audit reports, we do not determine whether the entity is compliant, and we do not replace the Compliance Enforcement Authority's assessment. Most engagements are fixed-scope: deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope. Ask any implementation partner to state in writing which records they will produce, which remain the entity's responsibility, and how the entity will review them before an audit.

CIP-009-6 R3 Recovery plan review, update and communication