CIP-008-6 R2 incident response plan testing and evidence

What CIP-008-6 R2 asks you to prove about your incident response plan

CIP-008-6 R2 requires you to test each Cyber Security Incident response plan at least once every 15 calendar months, and to show that you used the plan in real incidents and exercises, with records of Reportable Cyber Security Incidents and attempts to compromise. A plan that sits in a document library and is never exercised tends to fail under pressure, when responders improvise, skip steps or cannot tell who decides what. R2 exists to force that exercise on a schedule and to leave evidence that it happened. The exact obligations are in the NERC CIP-008-6 standard PDF, and you should read the applicability table and the Part 2.1 to 2.3 wording yourself rather than relying on a summary.

Three things make R2 harder than it looks. The first is the 15-month clock, which runs across staff changes, reorganizations and system migrations, so the next test date must be tracked as a standing obligation. The second is proving the plan was followed. Part 2.2 expects you to document deviations, which means a responder's notes must show which steps were used and where the team departed from the plan, not only that an incident was closed. The third is scattered records. Tickets, chat threads, call bridge recordings and email often hold the proof, and an auditor will ask you to assemble it for each Applicable System. Confirm with your Regional Entity how it expects tabletop, paper drill and operational exercise records to be formatted.

R2 is separate from its neighbors. R1 covers what the plan must contain, R3 covers updating the plan and notifying responders after a test or real incident, and R4 covers mandatory reports to the E-ISAC and the federal cyber incident center. Keep those obligations distinct in your program. A test that produces a lessons-learned list has satisfied R2 only if the record shows the plan was exercised, and the follow-on R3 updates need their own dated evidence. Decide early who owns the test calendar, who writes the exercise record, and where each artifact lives so that one exercise can be shown to satisfy R2 without confusion about R3 or R4.

Which systems, teams and third parties fall under the R2 testing cycle

CIP-008-6 R2 testing covers every Cyber Security Incident response plan the entity has in force, so the first decisions are which BES Cyber Systems the plan protects and who must take part. Each decision below changes how many tests you run, who attends them and what records you must keep, so confirm each one against the current CIP-008-6 applicability section and your CIP-002 categorization before scheduling the cycle.

Impact levels the plan must cover

CIP-008-6 applies to entities with high and medium impact BES Cyber Systems, and to low impact assets under the parts of the standard that reach them. Your CIP-002 categorization decides which assets sit in each tier. Confirm the applicability section against your own list before you decide how many plans exist, because a single plan with a clear scope statement can cover several tiers, while separate plans add separate testing obligations. Ask the compliance lead to document which tier each asset belongs to.

Associated EACMS and PACS

Plans that stop at the BES Cyber Systems leave gaps. Electronic Access Control or Monitoring Systems and Physical Access Control Systems that support those systems are part of how an attacker reaches them, so an incident on either can be a Reportable Cyber Security Incident. Scenarios that include a compromised access control server or a forced badge reader should appear in tabletop exercises. Confirm which EACMS and PACS are associated with each in-scope system before writing the scenario list.

Control room and operations staff

Operators in the control room usually detect the first signs of an incident, such as abnormal system behavior or unexpected alarms, and they hold the authority to isolate equipment. Each test should include the shift roles that would act during a real event, not only the security team. Check that operators can find the plan, know the escalation path and understand when a suspected event becomes a Reportable incident. Record who attended each exercise, because attendance is part of the evidence an auditor will ask for.

IT, OT and engineering participants

Recovery of a BES Cyber System often depends on engineers and IT administrators who hold the configuration, backups and vendor credentials. Testing without them shows whether the plan reads well, but not whether the team can act. Include the people who would restore a system, isolate a network segment or preserve forensic data. Where OT and IT teams report to different managers, confirm in writing who owns each step before the first exercise.

Managed security providers and integrators

When a managed security provider monitors your environment or an integrator maintains your systems, those parties will touch an incident. Decide whether they follow your plan, their own plan or a joint plan, and write that choice into the contract. Test the handoff at least once, because a provider that cannot reach your control room at night or does not know the reporting deadlines will slow the response. Contracts should state who notifies whom and within what period, and the entity still answers for the outcome.

Evidence records held by third parties

Part 2.3 requires you to retain records of Reportable Cyber Security Incidents and attempts to compromise. If a provider holds logs, tickets or forensic images for you, those records still need to be retrievable during an audit within your retention period. Ask each provider where it stores case data, how long it keeps it and how you would obtain it. Tools such as DFIR-IRIS can keep case records and evidence chain of custody inside your own environment, which removes one dependency from this list.

How an assessor tests R2 and what they ask to see

This table compares each R2 test point against the assessor's likely test approach, the evidence requested and the findings that appear most often. Read it as a checklist of what to have ready before a Regional Entity audit, remembering that the Compliance Enforcement Authority selects the sample and the audit period.

Test point	Assessor test approach	Evidence requested	Common findings
15-month test interval (Part 2.1)	Lists each response plan version and its test dates, then checks that consecutive tests fall within 15 calendar months across the audit period. The assessor chooses which plans and dates to sample.	Dated test records for each plan, with the plan version tested, the test type (actual incident, paper drill or tabletop, or operational exercise) and the participants.	Test window missed by a few weeks; a plan with one test recorded but no evidence of a second in the period; test dates that cannot be tied to a specific plan version.
Exercise run against the current plan (Part 2.1 and 2.2)	Traces each exercise back to the plan version in force on the test date and confirms the scenario and steps match that version.	The plan revision history, change log showing when the plan was last edited, and the exercise scenario and after-action notes naming the plan used.	Exercise run against an outdated plan that was revised after the test date but before the audit; scenarios that reference roles or contacts no longer in the plan.
Use of the plan in a Reportable Cyber Security Incident (Part 2.2)	For each sampled Reportable incident, compares the timeline and actions in the incident record against the steps the plan requires, in order.	Incident timeline, ticket or case history, classification decision, and notes showing which plan steps were followed and by whom.	Plan not referenced in the incident record; steps performed out of sequence without explanation; classification not documented against the plan criteria.
Use of the plan in an attempt to compromise (Part 2.2)	Checks whether attempts to compromise handled under the plan were recorded and handled using the same steps as a Reportable incident, where the plan requires it.	Attempt records, triage notes, and evidence that the plan was applied or a reasoned decision that it was not needed.	Attempts handled informally with no record; plan steps skipped for attempts without a documented decision.
Documenting deviations from the plan (Part 2.2)	Compares logged actions against the written plan for each sampled incident or exercise and looks for any step performed differently, skipped or added.	A deviation log or section in the after-action report describing each deviation, the reason and who approved it.	Deviations discussed in meetings but not written down; after-action reports that state the plan was followed with no mention of known gaps.
Retention of records for Reportable incidents and attempts (Part 2.3)	Samples incident and attempt records across the audit period and confirms each sampled item is retrievable, complete and held for the required period.	Indexed incident and attempt records, retention settings or schedule, and evidence that records were not altered after closure.	Records for attempts to compromise missing or stored only in email; records deleted or overwritten by a routine cleanup job; incomplete case files with no closure entry.

Running a compliant test from scheduling to closure

This sequence turns a CIP-008-6 R2 test into a dated, observed and documented exercise that satisfies Parts 2.1 to 2.3 and gives an auditor a clear trail from the calendar entry to the close-out record. Each step produces an artifact that a Compliance Enforcement Authority can ask to see.

Set the test calendar against the 15-month limit
The compliance lead records each Cyber Security Incident response plan in a test calendar and sets a due date no later than 15 calendar months after the last test that satisfied Part 2.1. Plans that cover several sets of BES Cyber Systems should be listed separately so each one has its own clock. The output is a dated calendar entry per plan, with the owner named and the prior test date noted. The step is complete when every plan in scope has a visible due date that a reviewer can trace back to its last qualifying test.
Choose the test type for this cycle
Part 2.1 allows three routes: responding to an actual Reportable Cyber Security Incident, running a paper drill or tabletop exercise, or running an operational exercise. The compliance lead and the incident response owner select one route and record why it fits the cycle, such as whether a live incident has occurred or whether the team needs a walkthrough of decisions. The output is a short test selection note that names the route, the plan being tested and the responsible owner. Confirm with your own Regional Entity how each route is evidenced, since the standard leaves the format of the record to the entity.
Define the scenario and freeze the plan version
The team writes a scenario sheet that describes the simulated or actual incident, the systems involved, the expected detection source and the decision points the responders must work through. The plan version under test is recorded by document identifier and revision, and that version stays fixed for the exercise so that any later edit can be traced to the test that prompted it. The output is a scenario sheet with a plan reference attached. Plan edits that follow the test belong to the review and update work covered under R3, not to this step.
Run the exercise with a named observer
Before the exercise begins, the compliance lead assigns an observer who is not a primary responder. The observer follows the timeline, notes which steps of the plan were used and confirms the roles named in the plan actually acted. For an actual Reportable Cyber Security Incident, the same observer role applies so that the team's use of the plan is documented as it happens. The output is an observer log with timestamps, participants and the plan sections referenced. The step is complete when the log covers the full run from start to stop.
Record every deviation as it happens
Part 2.2 requires the team to document any deviation from the plan. The observer and responders add an entry to a deviation register at the moment a step is skipped, reordered, performed by someone outside the named role or replaced with an undocumented action. Each entry states the plan section, what happened, why, and whether the deviation was approved on the spot. The output is a deviation register attached to the test record. Recording deviations after the fact weakens the evidence, so the register should be open throughout the exercise.
Close out with lessons learned and participants
The team holds a debrief that captures lessons learned, identifies which plan sections worked and which need attention, and assigns follow-up items to owners. The close-out record lists the test date, test type, plan version, scenario reference, participants, observer, deviations and lessons learned, and an authorized manager signs it. Lessons learned feed the R3 review, which sets its own notification and update obligations. The output is a signed close-out record. The step is complete when the record is stored with the other CIP-008 evidence and the calendar entry is updated with the completion date.
Retain the records for the audit period
Part 2.3 requires retaining records related to Reportable Cyber Security Incidents and attempts to compromise applicable systems, and the test record set should follow the same discipline. The compliance lead confirms that the calendar entry, scenario sheet, observer log, deviation register and close-out record are stored together, versioned and retrievable by plan and by date. Ask your auditor or Regional Entity which retention period and format they expect before the first audit, since the answer shapes the storage design. The output is an indexed evidence folder for each test cycle.

Which records satisfy Part 2.2 and Part 2.3 and how to keep them current

Part 2.1 through Part 2.3 each generate a different kind of record: a schedule, a set of exercise and incident artifacts, and a retention trail. The cards below cover what an assessor asks for under each part and how to keep each record current between audits, so the evidence matches the plan the organization actually follows.

Dated test schedule

A dated schedule lists each Cyber Security Incident response plan, the test method chosen under Part 2.1, and the date each test was completed. The assessor checks that consecutive tests fall within 15 calendar months of each other, so the schedule should show the next due date, not only past tests. Review it at each quarterly governance meeting and after any plan change, since a re-scoped plan can reset what is due. Confirm the window start date for each plan before the first audit period begins.

Exercise scenario packs and plan versions

For each paper drill, tabletop or operational exercise, keep the scenario script, injects, objectives and the exact plan version used. Store scenarios in version control next to the plan so an assessor can see that the plan tested was the plan in force on that date. Label every scenario with the plan identifier and revision, and archive superseded versions rather than overwriting them. Check that the scenario reflects current systems and roles, since an outdated scenario weakens the test.

Participant and observer logs

Attendance records show who took part in each test or real response, their role under the plan, and who observed or evaluated the exercise. These logs matter because an assessor will compare the people named in the plan with the people who actually responded. Record names, roles, start and end times and any role substitutions on the day. Keep the log with the exercise package, and review it against the current roles list whenever personnel change.

Deviation register

Part 2.2 requires documenting deviations from the plan when it is used in a real response or exercise. A deviation register lists each departure from a plan step, the reason, who approved it and the follow-up action. Assessors look for entries that show where the plan did not fit reality, and for links from each entry to the plan update made later. Keep the register open between tests so deviations raised during routine operations are captured too.

Incident case records

For each Reportable Cyber Security Incident and each attempt to compromise an applicable system, keep a case record that holds the timeline, affected assets, indicators, tasks, evidence and decisions. Part 2.3 requires retaining these records, so the case must stay intact after closure. Tools such as DFIR-IRIS keep one record per case with an audit trail and evidence hashes, which helps prove the record was not altered. Confirm retention periods with the Regional Entity and your own legal team before setting deletion rules.

Retention index

The retention index maps every test, exercise, deviation and incident record to the plan version and the Part it supports. An assessor who asks for the evidence behind one test should be able to reach it in minutes. Build the index as a single controlled page or table, update it when a record is added, and confirm access permissions allow auditors to view it without editing rights. Permissions on the wiki or knowledge base that holds the index can be set per role, which keeps the index readable and protected.

What meeting R2 costs in staff time, tooling and outside help

This table compares each cost component of CIP-008-6 R2 testing by who is paid, whether the cost is one-time or recurring, and what pushes it up or down. Read it as a scoping checklist: the drivers in each row are where a quote can grow or shrink. The main takeaway is that open-source tools remove license spend but not the staff and facilitation time that R2 requires.

Cost component	One-time or recurring	What drives it up	What brings it down
Staff time to design and run exercises	Recurring (each test cycle)	Number of applicable high and medium impact sites, number of response teams, and number of exercise types used	A fixed test calendar and reusable scenario packs that rotate across sites
Facilitator time (internal or external)	Recurring, with a one-time setup for scenario design	Using a new facilitator each cycle, or scenarios that must be rebuilt from scratch	Keeping one trained facilitator or a standing external contract with agreed scenarios
Tooling and licenses	Recurring for commercial tools, one-time for setup of self-hosted tools	Commercial case management or wiki licenses priced per user or per edition; separate tools for each team	Self-hosted open-source tools remove license spend, but staff time to configure and support them still applies
Evidence upkeep between audits	Recurring	Weak existing records, plan versions kept in email or shared drives, and deviations not written down at the time	Storing exercise records and incident case records in the tools that handle the work, with version history on the plan
External testing or review, if bought	Recurring per engagement, optional	Vendor involvement in tabletop design, third-party observers, and the number of exercise types commissioned	Written scope with a defined number of exercises, and internal staff running routine tabletops
Audit preparation effort	Recurring, before each Regional Entity audit or spot check	Missing test dates, undocumented deviations, and records spread across several systems	Maintaining an evidence index against each Part 2.1 to 2.3 requirement throughout the cycle

Using self-hosted open-source tools for the R2 record trail

Open-source tools can keep the records that CIP-008-6 R2 expects you to hold, but they only support the evidence. No tool makes an incident response plan compliant. The entity still owns the plan, the testing cadence and the decision about what counts as a Reportable Cyber Security Incident or an attempt to compromise. Before adopting any of these tools, confirm that the license and edition you intend to run fit your records needs, including retention, access logging and export. Your Regional Entity will look at what you can produce on request, so test the export path before an audit notice arrives.

DFIR-IRIS is the strongest fit for Part 2.3 records. It holds each case as one record of assets, indicators, tasks and evidence with an audit trail, and it can build a consolidated timeline and reports from case data. For an actual Reportable incident, an attempt to compromise or an exercise, that gives you one place to show what happened and when. Its evidence logging with SHA-256 verification and chain of custody helps where you retain artifacts. Review the DFIR-IRIS documentation against your own case workflow, and confirm how deviations from the plan under Part 2.2 are recorded, because the tool will not decide that for you.

XWiki and BookStack cover the documents around the record. XWiki keeps every page change under version control, showing what changed, when and by whom, and it lets you compare and roll back versions. That helps you show which plan version a test used. BookStack assigns abilities through roles and allows permission overrides at the shelf, book, chapter or page level, so you can limit who edits plan and test records. Both tools may hold BES Cyber System Information, since exercise notes often describe real Cyber Assets. Host them inside your own environment, restrict access to people with a documented need, and apply the CIP-011 information protection controls to these stores as well.

Where R2 programs usually fall short and how to close each gap

Most CIP-008-6 R2 findings do not come from a missing plan. They come from testing that drifts off schedule, exercises that do not follow the plan in force, and records scattered across tools. Each card below names one gap an assessor typically finds and the check that closes it.

Test calendar drifts past 15 months

Part 2.1 requires each plan to be tested at least once every 15 calendar months, and the clock keeps running through staff changes. Tie each plan to a named owner and a dated test record in one register, and review that register at every staffing change. Ask whether the last test date for each plan is visible to someone who did not run it. Illustrative check: a plan tested in March that nobody has scheduled for the next cycle is at risk long before the deadline.

Exercises run against an outdated plan

An exercise only proves R2 if it used the plan that was in force on that date. Version each plan in a controlled wiki with change history, so the team can show which revision the exercise followed. Record the plan version number in every exercise report. Check that no responder kept a printed or cached copy of an earlier revision that they used during the test.

Deviations handled in chat only

Part 2.2 requires documenting deviations from the plan during a real incident or exercise. When responders skip a step under pressure, the reason often lives in a chat thread that is later deleted or never exported. Assign a note-taker role in every response, and require a deviation entry with the step skipped, the reason and the approver before the incident record is closed. Check a sample of closed incidents for entries that say the plan was followed without exception.

Attempts to compromise triaged but not recorded

Part 2.3 covers records for attempts to compromise applicable systems, not only confirmed Reportable incidents. Teams often close a suspicious alert at the triage desk and never log it as an attempt. Set a written criterion for what counts as an attempt, and create a case for every alert that meets it, even when the outcome is no action. Sample alerts from the SIEM against the case register each quarter to find gaps.

Responders who have never read the plan

An assessor may ask responders to explain their role, and a plan that only the program owner has read will not hold up in an exercise. Schedule walkthroughs for each responder role, and record who attended and which version they reviewed. Include shift staff, on-call contractors and backups, not only the named team leads. Ask each responder to state their first three actions without looking at the document.

Records split across tools and personal drives

Part 2.3 asks for retained records that an auditor can locate and trust, but evidence often sits in tickets, email threads and personal folders. Choose one system of record for each incident, with links from the ticket to the case, the exercise report and the deviation log. Confirm retention settings and access controls on that system, and test whether a single incident can be reconstructed from it alone.

Who owns R2 and what an implementation partner can take on

Your organization is the registered entity, so it owns the Cyber Security Incident response plan, the test decisions and the compliance position. No outside party can decide that a tabletop counts as the 15-calendar-month test or that a departure from the plan was justified. Your team also signs the compliance attestation that the program operates as documented.

Plan ownership: Approve the response plan and keep it current, including the roles that respond during tests and real incidents.
Test selection: Choose which test type (a response to an actual Reportable Cyber Security Incident, a paper drill or tabletop, or an operational exercise) satisfies each cycle, and record why it was chosen.
Deviation determinations: Decide whether each departure from the plan during an incident or exercise is acceptable, and document the decision as Part 2.2 requires.
Record custody: Decide what is kept as the Part 2.3 record for Reportable incidents and attempts to compromise, and who may access it.
Attestation: Sign off that the controls operate, and answer auditor questions through the people who ran the tests.

Check that each named owner can explain, without the partner present, how the last test was selected and why the last deviation was accepted.

Questions buyers ask about CIP-008-6 R2 testing and outside help

How much effort does a 15-month incident response test cycle take?

The effort depends on which test method the entity chooses and how much of the plan the test exercises. CIP-008-6 Part 2.1 requires each Cyber Security Incident response plan to be tested at least once every 15 calendar months, using an actual Reportable Cyber Security Incident, a paper drill or tabletop exercise, or an operational exercise. A tabletop is the lightest option, mainly preparation, scenario design, a facilitator and a written record. An operational exercise uses live systems and takes more coordination with operations staff. The main cost drivers are the number of Applicable Systems covered by the plan, how many teams must take part, how often the plan changes, and whether the entity wants a full-scope exercise or a narrow one. Ask any consultant to break its quote into scenario design, facilitation, documentation and follow-up actions, so you can see which parts recur every cycle.

Can we run CIP-008 R2 testing in-house with open-source tools?

Yes, many entities run the test themselves, and open-source tools can hold the evidence. The standard does not prescribe a tool. What it requires is a documented test, a record of the plan being followed, documented deviations and retained records. DFIR-IRIS can keep each case as one record of assets, indicators, tasks and evidence with an audit trail, and it can build a timeline and generate reports from case data. A wiki such as XWiki keeps version history of the plan, so you can show which revision was in force during a test. BookStack can hold the plan with role-based permissions. Confirm each tool's license terms and features against your own environment before you rely on it, and make sure the test record is reviewed by someone who was not the facilitator.

What does R2 testing need from our own staff?

R2 testing needs named people in defined roles, not only a document. At a minimum, plan the following:

A test lead who owns the schedule, the scenario and the written record.
Named responders from each team the plan assigns roles to, such as operations, security and compliance.
Observers, often from compliance or internal audit, who can confirm the plan was followed and note deviations.
Access to the systems the scenario touches, including ticketing, logs, the incident case system and, for an operational exercise, the operators who can authorize changes.

Confirm these roles with your own organization before the test date. The people who run the test are not automatically the people who approve the report.

How long does preparation for a CIP-008 R2 audit take?

No fixed timeline applies, so set one yourself from your audit notification and your test calendar. Regional Entities notify registered entities of an audit in advance, and the notice tells you what period and evidence they will review. Working backward from that date, plan time to confirm the last test falls within 15 calendar months of the audit period, to fill any evidence gaps, to correct the plan where deviations were recorded, and to walk the team through the records. The length of that work depends on how complete your records already are. Ask a consultant to show you the evidence list it will build against Part 2.1, 2.2 and 2.3 and to estimate effort only after reviewing your current records.

Does a tabletop exercise count as a CIP-008 R2 test?

Yes, a paper drill or tabletop exercise is one of the three test methods named in Part 2.1, alongside an actual Reportable Cyber Security Incident and an operational exercise. A tabletop counts only if it tests the response plan itself and produces a record. The record should show the scenario, the participants, the plan steps that were used, any deviations and the follow-up actions. A tabletop that only discusses general concepts, without referring to the plan, is hard to defend at audit. Whether your test meets the requirement in full is a question for your Compliance Enforcement Authority, so confirm the approach with them before you rely on it.

What should a written scope from an implementation consultant include?

A written scope should state exactly what the consultant will prepare and what you will own. Ask for these items:

The Applicable Systems and the response plan version covered by the test.
The test method chosen (tabletop, drill, operational exercise or a real incident review) and the reason for it.
The scenario design, facilitation plan and named participant roles.
The evidence set mapped to Parts 2.1, 2.2 and 2.3, and where each item will be stored.
A deviation log and the process for reviewing it.
Deliverables, dates and what the consultant will not do, such as issuing a compliance opinion.

DeployOpen prepares systems, controls and evidence for compliance assessments, and it works under a fixed scope agreed in writing before work starts. An independent auditor or the Regional Entity makes the compliance determination.

How DeployOpen scopes and prepares R2 testing evidence

DeployOpen helps registered entities prepare the systems, test records and evidence behind CIP-008-6 R2, the requirement to test each Cyber Security Incident response plan at least every 15 calendar months. DeployOpen plans, builds and documents this work inside your own infrastructure, while your organization owns its controls and an independent auditor or Regional Entity makes the compliance determination.

How we scope

Confirm which BES Cyber Systems and associated systems the response plan covers, based on your CIP-002 categorization.
Agree in writing which test methods (actual incident, paper drill, tabletop or operational exercise) will be used in each 15-month cycle.
Define the deliverables, timelines and responsibilities in a fixed-scope written agreement before any work starts.

How we build

Set up a case management platform, such as DFIR-IRIS, to hold incident records, assets, tasks, evidence and the audit trail for each test or event.
Build exercise scenarios and scripts that walk responders through the documented plan and capture every step taken.
Configure version-controlled documentation, for example in XWiki, so plan revisions and deviation notes are traceable over time.

How we hand over

Deliver test records showing the date, plan version, participants and outcomes for each exercise or real incident.
Document deviations from the plan, with the reason and the follow-up action, in a form your compliance team can retain.
Provide a runbook for keeping records of Reportable Cyber Security Incidents and attempts to compromise for the retention period your program requires.

How we support

Ongoing support, plan updates and exercise scheduling are available as a retainer after the initial fixed-scope delivery.
Retainers can cover running the next 15-month test cycle and refreshing evidence packages before an audit notification.
Ask us to confirm the audit evidence expectations with your Regional Entity or auditor, since DeployOpen prepares evidence but does not issue compliance reports.