CIP-008-6 R3 Incident response plan update requirements

What CIP-008-6 R3 asks for after a test or a real incident

After a test or a Reportable Cyber Security Incident, or after a change to roles, teams or technology, CIP-008-6 R3 requires you to update the incident response plan and tell every person or group with a defined role about the update. The clock depends on the trigger. Part 3.1 covers two events: a test of the plan, and an actual Reportable Cyber Security Incident response. Within 90 calendar days of either, you must document the lessons learned, or document that there were none, update the plan based on them, and notify each person or group with a defined role. Part 3.2 covers planned or unplanned changes to roles or responsibilities, Cyber Security Incident response groups or individuals, or technology that you determine would affect how the plan runs. Within 60 calendar days of such a change, you must update the plan and notify the people with defined roles.

The lessons learned record is the piece most often missing. An auditor will look for a dated document that names what the exercise or incident showed, what was changed in the plan as a result, and who was told. A test that produced no findings still needs a record saying so. Confirm with your Compliance Enforcement Authority how it expects the notification to be evidenced, such as distribution lists, acknowledgments or meeting minutes, because a plan revision that nobody can show reached its responders will not satisfy the requirement. Keep the trigger dates, not only the completion dates, in your tracking system, so you can show the start of each clock.

R3 carries a Lower Violation Risk Factor, which is lower than many other CIP requirements, but the deadlines are hard to meet in practice. Lessons learned from a real incident often arrive while the response team is still busy with recovery, and role changes such as a staff departure or a new contractor on the response team can happen with little notice. A reasonable first step is to name an owner for each trigger, define who receives each update, and check that the notification list matches the current org chart before the next test. Organizations that treat the 90 and 60 day limits as the start of work, rather than the end, usually avoid the scramble that follows a late update.

Which CIP-008-6 R3 obligations apply to which systems, teams and changes

R3 is triggered by events, not by a calendar, so the work it creates depends on what the entity decides counts as a plan change. The cards below cover the decisions that set that scope: the plan itself, the response roles, the technology changes and the third parties. The entity owns each decision and must be able to justify it to an assessor.

The incident response plan in scope

R3 applies to each Cyber Security Incident response plan the entity has documented under R1, so the first decision is how many plans exist and which BES Cyber Systems each one covers. An entity with separate plans for control centers and field sites carries separate 90-day and 60-day clocks for each. Confirm the plan inventory against the CIP-002 categorization before listing triggers, because a plan missing from the inventory is a plan that never gets reviewed.

Roles and response groups listed

Part 3.2 is triggered by changes to roles, responsibilities, response groups or individuals, so the list of who holds a defined role is the baseline for every change check. Record each named role, its alternates and its contact route, including on-call rotations. Any person added, removed or reassigned in that list is a trigger the entity must track, even when the change looks administrative.

Technology changes that affect execution

Part 3.2 covers technology changes the entity determines would affect the plan's execution, which means the entity must define that test in writing. Typical candidates include a new SIEM or log source, a replacement ticketing or case system, a change to the channel used for E-ISAC reporting, or a new jump host for responders. Record the reasoning for each change you decide does not affect execution, since that reasoning is what an assessor will examine.

Third parties with defined roles

A managed security provider, an integrator or a monitoring service that performs detection, triage or reporting on the entity's behalf may hold a defined role in the plan. When that provider changes staff, tooling or escalation paths, the change can start a Part 3.2 clock even though the entity did not make the change itself. Confirm contractually how the provider notifies you of such changes, and name the provider's responsible individuals in the plan.

Documenting the scoping decision

Each scoping choice should appear in a dated record that names the decision maker, the rule applied and the evidence reviewed. Assessors typically ask why a change did not trigger an update, so a short rationale attached to each change ticket is more defensible than a general policy statement. Keep the record in the same system that holds the plan so its version history supports the entity's position.

How an assessor tests CIP-008-6 R3 and which evidence passes

This table walks through how a Compliance Enforcement Authority typically samples and checks Part 3.1 (test or incident events) and Part 3.2 (role, group or technology changes), with the evidence each step asks for. Read each row as a test step, then check your own records against the request column. The main takeaway is that an assessor will trace dates end to end, so the timestamps and notification records must line up.

Test step	What the assessor samples or checks	Evidence requested and common findings
Build the event population (3.1)	Every plan test and every actual Reportable Cyber Security Incident response in the audit period, with the date each one closed	Test schedule, exercise reports, incident tickets with close dates. Finding: tests run but no event list exists, so the assessor cannot confirm completeness
Confirm the 90-day clock (3.1)	Date of each event against the date lessons learned were documented, the plan updated and responders notified, all within 90 calendar days	Dated lessons learned entries and plan revision records. Finding: plan updated on day 95 because the trigger date was taken from the report date, not the event close
Read lessons learned (3.1)	A record for each test and incident, or a documented statement that no lessons were identified	Written lessons learned or a signed no-lessons statement per event. Finding: missing records for tests, which are often treated as lower priority than real incidents
Check plan revision history (3.1)	That each lesson learned that required a change appears as a specific plan revision, with the reason tied to the lesson	Version history showing what changed, when, and by whom, plus the approved plan version in force. Finding: plan edited with no link to a lesson or no approval record
Trace the change population (3.2)	Every change to roles or responsibilities, response groups or individuals, and technology, in the audit period	Change requests, HR or org chart updates, tooling change records and a log of changes reviewed for plan impact. Finding: staffing or tooling changes never logged, so none were assessed
Check the 60-day clock (3.2)	Date of each change against the date the plan was updated and people with defined roles were notified, all within 60 calendar days	Change date, assessment date, plan revision date and notification timestamps. Finding: change assessed as no impact without a documented rationale
Verify the effect assessment (3.2)	That each relevant change was judged for whether it would affect plan execution, and that the judgment was recorded	Written impact determination per change, signed by the plan owner. Finding: technology changes such as a new logging or ticketing platform not assessed for effect on the plan
Confirm notifications reached each role (3.1 and 3.2)	Sample named roles in the plan and test that each received notice of the update, using current contact data	Distribution list, acknowledgment records or message logs, and the contact roster dated near the notice. Finding: notices sent to a stale contact list, so departed staff or retired contacts were not reached

How to implement the R3 review and update cycle

This sequence turns CIP-008-6 R3 into a routine that starts with each test or reportable incident, produces a documented lessons learned record and a revised plan, and ends with proof that every person with a defined role was notified. Each step leaves a record an auditor can trace from trigger to notice.

Define triggers and the change assessment question
The compliance lead, with the CIP Senior Manager or delegate, writes down every event that starts an R3 clock: a plan test, an actual Reportable Cyber Security Incident response, and any change to roles or responsibilities, Cyber Security Incident response groups or individuals, or technology. For each change type, record the assessment question that decides whether it would affect how the plan runs. The output is a short trigger standard that the change owners sign. It is done when every IT, OT and HR change channel knows to route candidate changes to compliance and the question is answered in writing for each one.
Set up a register of tests, incidents and changes
Create one register, in a controlled tool such as a wiki with version history or a case tracker, with one row per trigger. Each row holds the event type, the date it occurred, the owner, the assessment outcome, a start date, and a deadline date: 90 calendar days for test or incident events and 60 calendar days for role, team or technology changes. The register is the clock. Review it at a fixed cadence and confirm that every open row has a named owner. Ask the vendor or your own administrators to confirm how the tool exports this register for an evidence request.
Hold and record the lessons learned session
After each test or real response, the incident commander convenes the people who ran the response, including OT operations, IT, security and any vendor involved. The session covers what worked, what failed, what was missing from the plan, and what should change. If the session finds nothing to change, the record must say so. Capture attendees, the date, the findings and the decisions in a single document, and store it with the case file. The session is complete when the record is signed by the incident commander and linked to its register row.
Update the plan and log the revision
The plan owner turns each agreed lesson into a specific change to the response plan, such as a new contact, a revised escalation step, or a corrected evidence procedure. Each edit is made in version-controlled documentation so that the previous version, the reason for the change, the author and the approver remain available. Record the revision number and effective date in the register. The step is done when the updated plan is approved, the old version is archived, and the register row links to the revision that resulted from the lesson.
Notify people with defined roles and keep proof
Send the updated plan, or a summary of the changes that affect each person, to every individual or group with a defined role in the plan. Use a method that produces a timestamped record, such as an acknowledgment request, a distribution list with read receipts, or a signed roster. Track each recipient and follow up on those who do not respond. The output is a notification log per revision, stored with the register. The clock is closed only when the log shows that every defined role was notified on or before the deadline date.
Track the 90 and 60 day clocks and review the register
Run a recurring check, at a frequency the CIP Senior Manager sets, that compares each open register row against its deadline date. Flag rows at risk, escalate overdue items, and record the escalation. Use the register and its linked records to answer an audit request without rebuilding the story from email. Confirm with your assessor or consultant which evidence formats they accept. The output is a dated review log showing that the clock was monitored throughout the period.

Evidence that shows the plan was reviewed, updated and communicated on time

Auditors testing CIP-008-6 R3 look for a dated trail: what happened, what changed in the plan, and who was told. The four to six artifacts below connect each test or incident to a lessons learned record, a revised plan and a notification. Keep them current between audits, not assembled the week before one.

Lessons learned records per test or incident

For every plan test and every actual Reportable Cyber Security Incident response, keep a dated lessons learned record. If a test produced no lessons, the record should still exist and say so. Check that each record names the event, the date it closed, and the plan sections it affects, since the 90 calendar day clock in Part 3.1 starts from that event. Auditors often sample these first.

Revised plan with version history

Keep each approved version of the incident response plan with its change summary, approver and effective date. Version history lets you show what the plan said on a given date, which matters when a test finding is traced to an earlier revision. Confirm that your wiki or document system records who changed each page and can restore an earlier version if a revision is later disputed.

Change-trigger register with dates

Maintain a register that logs each change to roles or responsibilities, Cyber Security Incident response groups or individuals, and technology that could affect plan execution. Record the date the change was identified and the date the plan update and notifications were completed. Part 3.2 allows 60 calendar days from the change, so the register is what proves the clock was managed. Include staff reassignments and tool replacements, not only formal reorganizations.

Notification records with recipients and dates

Record each notification to people or groups with a defined role after a plan update, including the recipient, channel, date sent and any acknowledgment. Email logs, ticket records or signed acknowledgments can serve. Check that the list of recipients matches the current roster, not the roster from before the change, because a notice sent to a former responder does not show the current team was informed.

Current contact roster for defined roles

Keep a roster that maps every defined incident response role to a named person or group, with backup contacts and the date it was last verified. Auditors compare this roster against the notification records and the plan. Confirm access to it is limited to the people who need it, since it contains personal contact details. BookStack's role-based permissions can restrict who edits the roster and who only reads it.

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

This table lists the cost components of keeping a CIP-008-6 R3 plan current, who is paid for each, whether it is one-time or recurring, and what moves it up or down. No dollar figures are given because none were supplied, so use the questions in the final column to request quotes from a partner or vendor. Read it as a checklist for scoping a written quote.

Cost component	One-time or recurring	What drives it up or down	What to ask a partner to quote
Tooling and licenses	Recurring for commercial case management and wiki tools; one-time for setup	Number of named users, editions and modules; open-source options such as DFIR-IRIS and XWiki remove most license spend but still need hosting and administration	Itemized license or subscription lines, hosting assumptions, and whether the quote assumes self-hosting inside your own environment
Security staff time for lessons learned and plan revisions	Recurring, tied to each test or Reportable Cyber Security Incident	Number of tests per year, incident complexity, and how many plan sections change after each event	Estimated hours per test and per real incident, with the assumptions behind each estimate
Notification and contact roster upkeep	Recurring	Number of people and groups with defined roles, staff turnover, and the number of role or team changes in a year	Who maintains the roster, how often it is reviewed, and how changes trigger the 60-day and 90-day clocks
Exercise facilitation	Recurring, aligned with the testing cycle	Test format (tabletop or functional), number of participants, and whether a third party facilitates	Facilitator effort per exercise, materials, and who records the lessons learned
Change control for technology and vendors	Recurring	Number of third-party services, cloud platforms and monitoring tools that touch plan execution	Which technology changes the partner will track against the plan, and how that tracking is evidenced
External review of the updated plan	Recurring, usually per plan revision	Plan complexity, number of revisions, and whether the review is independent of the team that wrote the plan	Review scope, reviewer qualifications, and whether the review is documented as a separate evidence item
Auditor sampling time	Recurring, per compliance audit or monitoring engagement	Number of test and incident records the auditor samples, and how quickly records can be produced	Whether preparing evidence packages is in scope, and whether the partner supports the Evidence Request Tool workflow
Internal compliance coordination	Recurring	Number of Registered Entity sites, number of responsible groups, and the depth of documentation kept per change	Coordinator hours, reporting cadence and the owner of the CIP-008 evidence index

Who owns the R3 update, what a partner prepares and what the auditor tests

The registered entity is accountable for CIP-008-6 R3 and for every decision that the standard places on it. Someone on the entity's side must review the lessons learned from each test or Reportable Cyber Security Incident, decide what the plan should change, approve the revised plan, and confirm that each person or group with a defined role has been notified within the required window. A partner can draft material, but the entity signs off on the substance and keeps the authority to explain it later.

Lessons learned decisions: Staff with incident response authority document what worked, what failed and what changed, or document that there were no lessons learned.
Plan updates: The entity approves the revised plan and records the version, date and reason for each change.
Role roster: The entity maintains the current list of people, teams and technology that the plan depends on, and triggers the 60-day clock when it changes.
Notifications: The entity sends and records notices to each role holder and keeps proof of delivery.
Approval records: The entity retains the signed approvals and the reason for any decision not to act.

Before you engage anyone, confirm that a named owner can make these decisions without waiting on an outside party.

Where R3 updates usually fall short and how to close each gap

Most CIP-008-6 R3 failures come from missing records rather than missing intent. The gaps below share one root cause: the deadlines for updating the plan and notifying responders are triggered by events that are not logged, dated or routed to anyone. Each fix creates a dated record that an auditor can trace from event to notification.

No register for tests and changes

Without a single register, no one can prove when the 90-day and 60-day clocks started. Keep one log that records each plan test, each real Reportable Cyber Security Incident, and each change to roles, teams or technology, with the date the event occurred and the date the clock expires. Assign an owner to review the register at each change board. Under the event date column, the auditor's first question is answered before it is asked.

Lessons learned written after the deadline

Teams often hold the post-exercise review weeks after the test, then find the 90-day window has closed. Schedule the lessons-learned meeting before the exercise ends and record the output in a case or wiki page dated that day. Even when a test produces no findings, the record should state that no lessons were identified, which satisfies the requirement to document the absence of lessons.

Technology changes never assessed for plan impact

R3 Part 3.2 applies to technology changes that could affect how the plan runs, such as a new SIEM, a replaced EDR console or a moved logging pipeline. Add a required question to the change request: does this change affect plan execution? Record the answer even when it is no. A change marked as affecting the plan starts a 60-day countdown that should appear in the register.

Notifications sent to outdated contacts

A plan update counts only if the people with defined roles receive it. Maintain a contact roster that lists each role, the named individual, a backup and the notification channel. Review it on the same schedule as the plan and after every staffing change. Keep the sent notifications, with recipients and timestamps, as evidence that the roster was current.

Plan edited without version history

An auditor needs to see what the plan said before and after an update, and which lessons drove the change. Store the plan in a platform that keeps every revision with the author, time and change summary, and that allows rollback. Tag each revision with the test or incident that triggered it, so the link between lessons learned and the update is visible.

No record for tests that produce no lessons

A test with no findings still needs a record. Teams often skip documentation because nothing changed, leaving no evidence that the test occurred or that the review took place. Use a standard template with fields for test date, participants, scenario, review date and the statement that no lessons were identified. Store it next to the plan revision history so both can be pulled together for an audit.

Questions about CIP-008-6 R3 cost, timing and whether to hire help

How much does it cost to keep a CIP-008-6 R3 review cycle running?

No fixed price applies, because the cost depends on the systems in scope, how many response teams and roles exist, and how often roles and technology change. The main components are internal staff time for the lessons-learned review, plan revision, and notifications, plus any tooling and any outside help you buy. Most of the cost recurs, since the review follows every test and every qualifying change. Ask any implementation partner for a fixed-scope quote that lists deliverables, assumptions about your environment, and which tasks stay with your staff.

How long does it take to put the R3 review cycle in place?

The duration depends on scope, including how many incident response plans you maintain, how mature your current plan and records are, and whether you need new tooling for case records and version history. Setup usually runs in parallel with your next plan test, so the first documented cycle is ready before the 90 day clock matters. Ask for a written timeline that shows each milestone, the owner of each task, and the dependencies on your own approvals.

Can our own staff run the R3 process without outside help?

Yes, many entities run it internally. The process needs a named owner for the plan, people who can document lessons learned from tests and real incidents, and a way to record who was notified and when. Internal teams often struggle with the change-tracking part, because the 60 day clock starts from changes that may be easy to miss, such as a new response contact or a new logging tool. Outside help is most useful for gap assessment, building the records workflow, and training the people who maintain it.

What does the R3 work require from our organization?

The work requires named role holders, a current roster of response groups and individuals, and access to test reports, incident records and change requests. It also requires executive or senior manager approval of updated plans, and a notification method that can prove each defined role received the update. Expect to supply subject matter experts for lessons learned, because a partner can organize the review but cannot know what happened in your operations.

Can a consultant or partner sign off that our plan is compliant?

No. Your organization owns its compliance obligations, and an implementation partner can prepare the plan, records and evidence. Compliance is judged by the Compliance Enforcement Authority, which is a Regional Entity or NERC, through audits, spot checks, self-certifications or self-reports. Ask any partner to state in writing that it prepares evidence and that your auditor or the enforcement authority makes the determination.

How do the 90 and 60 day clocks interact with the annual test?

The 90 day clock starts after a plan test or a Reportable Cyber Security Incident response, and requires lessons learned to be documented, the plan updated, and each defined role notified. The 60 day clock starts after a change to roles, response groups or technology that affects plan execution. Because tests are required at least every 15 calendar months, a test can trigger a 90 day update that lands inside the next test cycle, so schedule tests so that each update window is visible in your calendar. Confirm the exact clock start rules against the standard text.

What happens if we miss an R3 deadline?

A missed deadline is a potential noncompliance with CIP-008-6 R3, which carries a Lower Violation Risk Factor. Enforcement outcomes depend on the facts, the duration, the entity's compliance history and its mitigation, and they are decided by the Compliance Enforcement Authority rather than by a consultant. Entities can self-report or self-log issues, and a Mitigation Plan may follow. For penalty structures, self-reporting, Compliance Exceptions and Mitigation Plans, read the NERC CIP violations and enforcement guide.

How DeployOpen prepares the R3 review cycle and its evidence

DeployOpen helps registered entities prepare the systems, records and documentation that show their CIP-008-6 R3 review cycle works after each test, real incident or qualifying change. The organization keeps ownership of its plan, its roles and its compliance decisions, while DeployOpen builds and documents the supporting workflow inside the client's own infrastructure.

How we scope

Each engagement starts with a written scope that names the response plan versions, teams and systems covered by the R3 cycle.
We confirm which triggers apply: plan tests, real Reportable Cyber Security Incidents, role changes, group changes and technology changes.
Scope, deliverables and timelines are agreed in writing before work starts, and the written scope is the basis for any quote.

How we build

We set up a version-controlled documentation space so each plan revision records what changed, when and by whom.
We configure role-based access so only named responders can edit the plan, with permissions overridden per role where needed.
We build case records and lessons-learned templates in a self-hosted case management tool so each incident keeps a traceable audit trail.

How we hand over

We deliver a written R3 procedure covering the 90-day lessons-learned update and the 60-day change-driven update windows.
We provide a notification register listing each person or group with a defined role, with the method and date of each notice.
We hand over evidence packages that map records to each R3 part, so your team can present them to an independent auditor or Regional Entity.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
We can rerun the review workflow after each plan test to confirm the records and notifications still meet the agreed procedure.
Ask us to confirm with your compliance team which evidence the Compliance Enforcement Authority expects for your registration category.

CIP-008-6 R3 Incident response plan review, update and communication