The testing requirement in NERC CIP-008-6 is 47 words long. Here are all of them, as Part 2.1 of the standard prints them.
Test each Cyber Security Incident response plan(s) at least once every 15 calendar months: By responding to an actual Reportable Cyber Security Incident; With a paper drill or tabletop exercise of a Reportable Cyber Security Incident; or With an operational exercise of a Reportable Cyber Security Incident.
Three ways to meet it. Each one ends on the same four words: Reportable Cyber Security Incident.
So here is the uncomfortable question. The tabletop your team ran last spring, the one with the phishing email and the ransom note on the finance server: was that incident reportable?
NERC's glossary answers it, and NERC's own audit worksheet for CIP-008-6 reprints the definition. A Reportable Cyber Security Incident is one that compromised or disrupted a BES Cyber System that performs one or more reliability tasks, an Electronic Security Perimeter of a high or medium impact BES Cyber System, or an Electronic Access Control or Monitoring System of one. A ransom note on the finance server compromises none of those. It can still be a good exercise. Whether it is the exercise Part 2.1 describes is a question the text settles without any help from us.
One qualifier before going further. The R2 and R3 tables apply to high and medium impact BES Cyber Systems and their associated EACMS. If everything you own is low impact, these tables are not yours, and what follows is background reading.
For everyone else, the problem is rarely that the test did not happen. The requirement reads so easily that the calendar invite starts to feel like the test. You probably suspect what the folder holds: an invite, a sign-in sheet, a slide deck. Those prove a meeting took place. The standard asks for more, and it says so in the column most readers skip, the one headed Measures, because each cell in it introduces its contents as examples.
The column nobody reads
Read the Measures column for Part 2.1 and it asks for "dated evidence of a lessons-learned report that includes a summary of the test or a compilation of notes, logs, and communication resulting from the test." Part 2.2 adds that the plan must actually be used during the exercise, and that deviations from it get written down. Part 3.1 then starts a 90 day clock: lessons learned (or a documented statement that there were none), the plan updated, and every person or group with a role in the plan told about the update.
NERC's audit worksheet is blunt about where the flexibility ends. Its note to auditors on Part 2.2 reads:
"while deviations from the incident response plan are permissible, deviations from the language of the Requirement (testing of the plan at least once every 15 calendar months, notification to the E-ISAC and NCCIC of applicable incidents, etc.), are not permissible."
Your team may improvise. The paperwork may not. Put the two columns side by side and a test turns into a list of things it has to leave behind.
A note on the right-hand column. CIP-008-6 asks for no signatures. Not one. What the Measures column keeps asking for is "dated", and a date with no name beside it is a date anyone could have typed on any afternoon. The names are our addition, and they cost a pen.
Three clocks, and they do not share a start
The first is the 15 calendar months between tests. The standard's own severity table grades lateness by the month: past 15 is a lower severity, past 16 moderate, past 17 high, and past 18 severe. Schedule the test at twelve months and you keep three months of slack for the turnaround that swallows your spring.
The second is the 90 calendar days after a test for records 5 to 7. The third runs on its own: Part 3.2 gives 60 calendar days to update the plan and notify role-holders after a change to roles, responders or technology that would affect the plan, test or no test. Behind all three sits retention. The standard's compliance section requires evidence for each requirement to be kept for three calendar years.
A quick check, and no is an acceptable answer. Can you put a date on your last test, and does its scenario sheet name the system it compromised? If the second answer is no, the first matters less than you would like.
"Our enterprise tabletop already covers this"
Legal, comms and the CISO's team run a ransomware tabletop every October. Forty people, an outside facilitator, a very handsome after-action deck. I am not running a second exercise for a standard that says "tabletop" and nothing else.
It might count. The standard does not say "tabletop" and nothing else, though. It says a tabletop of a Reportable Cyber Security Incident, testing each plan documented under R1. So the October exercise has three questions to answer. Was the plan in play your CIP-008 plan, or the corporate one? Did the scenario reach a BES Cyber System, an Electronic Security Perimeter or an EACMS? And did the handsome deck become records 5 to 7 inside 90 days?
The cheapest fix is usually one inject, not a second exercise. Add twenty minutes in which the attacker crosses into the Electronic Security Perimeter, hand the room to the CIP-008 plan, and bring in the people who hold roles in it. The scenario sheet records the reportability check against that inject.
"I can't pull four operators off a running process"
I have six people on shift and a process that does not pause. You want four of them in a conference room for a morning to talk about something that has not happened? Fine. Who runs the plant?
Nobody needs the morning. Part 2.1 sets no duration and no minimum attendance, and a paper drill is one of the three permitted methods. What the evidence pack needs is a name against every role the plan defines, which is not the same as a crowd.
A workable shape is ninety minutes, timed to the overlap at shift handover so nobody leaves the board unattended. Ten minutes to set the scene. The scenario crosses the perimeter at minute ten. Three decision points, each one a question the plan should answer: who isolates, who calls whom, what state the process goes to. The last twenty minutes are findings, written into record 5 before anyone leaves. Where an operator genuinely cannot step away, record 2 says who covered the role and how.
"Getting the plan revised in 90 days is not up to me"
Running the test is the easy part. Engineering owns the plan document. Getting them to revise it, approve it and send it to everyone with a role inside 90 days? I chase. I don't control.
This is where folders thin out, and the cause is scheduling, not effort. Book the lessons-learned meeting and the plan-revision slot before the test runs, in the same invite, with the plan owner as a required attendee and named on the scenario sheet. The 90 day clock becomes a meeting already in the diary rather than a request sent in week eleven.
Two details save rework. Part 3.1.1 lets you document the absence of lessons learned, which is honest after a clean test and awkward after a messy one, so let the deviation record decide. And Part 3.1.3 says each person or group with a defined role, so send the update to the role list in the plan, not to whatever distribution alias is handy.
A test is what the folder can show
Part 2.1 is 47 words, and most of the weight sits on four of them. A scenario that never reaches a BES Cyber System, a perimeter or an access control system is a rehearsal of something else. A test with no deviation record, no lessons learned inside 90 days and no proof the role-holders heard about the change did happen, in the sense that people attended. Whether it happened in the sense an audit worksheet means is something only the folder can answer.
None of this makes anyone compliant. Compliance is judged by your Regional Entity across the whole program. What the pack gives you is records an auditor can check, assembled while the exercise is still fresh, instead of reconstructed from memory eleven months later.
Sources: NERC, CIP-008-6, Cyber Security, Incident Reporting and Response Planning (Requirements R2 and R3, Measures, Violation Severity Levels, Evidence Retention) | NERC, Reliability Standard Audit Worksheet, CIP-008-6, 2020 v5 (auditor notes, evidence table, glossary definition of Reportable Cyber Security Incident)
