#Chapter 18 — Exercising the Playbook

How to design, run, score and close out the exercises that turn a plausible-looking playbook into one you know works — for the price of a conference room and three hours, not a seven-figure tool.

Who needs this: CISO, IR lead, SOC lead, detection engineers, exercise facilitators, executive sponsors, Legal, Comms, HR | Read time: 28 min | Maps to: CSF 2.0 IDENTIFY (ID.IM-01, ID.IM-02, ID.IM-03), GOVERN (GV.SC-08, GV.RR), PROTECT (PR.AT) | CIS v8.1 Controls 11, 14, 17, 18 | ISO/IEC 27001:2022 A.5.24, A.5.27, A.5.30, A.6.3

Welcome back, cyber-survivors. This is the chapter where we stop writing the plan and start finding out whether it is fiction.

Start with the failure that should be tattooed on the inside of every exercise planner's eyelids. When Equifax patched Apache Struts across the company, the notice telling people to do it went out to a distribution list — and, in GAO's words, "the recipient list for the notice was out-of-date and, as a result, the notice was not received by the individuals who would have been responsible for installing the necessary patch" (GAO-18-559). A stale mailing list. Not a zero-day, not a nation-state capability. A list nobody had ever sent a test message down.

That is the argument of this chapter. The controls that fail in real incidents are overwhelmingly the ones nobody exercised, and they fail in ways that are embarrassingly cheap to have discovered in advance. The British Library, website and intranet down, ended up running its response over social media and WhatsApp cascades (British Library, Learning Lessons from the Cyber-Attack). The Cyber Safety Review Board found Microsoft had stopped its manual rotation of consumer signing keys in 2021 after a cloud outage linked to the rotation process itself — a safety control abandoned precisely because using it hurt (CSRB). Every one is a testable proposition that went untested until an adversary tested it for free.

I have never once seen a tabletop exercise fail because it was too realistic. I have seen plenty fail because they were too comfortable — a scenario read from a slide, six people agreeing they would probably do the right thing, a document that changed nothing. This chapter is about the other kind, the one that ends with nine owned, dated findings and a playbook diff. Chapter 13 owns the lifecycle, the roles and the real-incident hotwash; Chapter 2 owns playbook metadata and the last_exercised field this chapter exists to populate; Appendix F carries the full scenario card set.

#The exercise ladder

NIST SP 800-84 is still the canonical methodology, and the first thing it does is take a vocabulary away from you: "the term 'test' is reserved for testing systems or system components; it is not used to describe 'exercising' plans" (NIST SP 800-84).

That sounds like pedantry until you notice what it buys. A test produces a number: did the call-tree cascade complete inside the prescribed time limit, and in how many minutes. An exercise produces a judgement: did people make defensible decisions with the information they had. You need both, they cost wildly different amounts, and conflating them is how a program ends up with an annual tabletop, no measured restore time, and a contact list last verified in 2023.

SP 800-84 names four categories — tests, training, tabletop exercises, and functional exercises — and a four-phase event methodology every rung below inherits: Design → Develop → Conduct → Evaluate.

Rungs 1–3 are discussion-based: people talk, nothing in production moves. Rungs 4–6 are operations-based: something happens, and something can break.

SP 800-84 adds two rules most programs violate immediately. First: separate senior-level and operational-level exercises before you combine them. "Senior-level teams and operational-level teams should participate in separate tabletop exercises initially because of their different levels of responsibility. Once these two groups have been exercised individually, both groups should participate in a combined exercise to validate coordination between the groups." Put the CFO in the same first session as the detection engineers and one of two things happens: the engineers stay quiet, or the CFO stops coming. Second: duration — 2–4 hours senior-level, 2–8 hours operational-level, with anything over four hours paired with a training session, because past that point you are teaching, not testing.

The off-the-shelf starting kit costs nothing. CISA's Tabletop Exercise Packages (CTEP) ship 100+ sample Situation Manuals organized by threat vector, plus an Exercise Brief deck, an Exercise Planner Handbook, and a Facilitator and Evaluator Handbook telling evaluators how to capture "strengths, areas for improvement, and recommendations" for the After-Action Report / Improvement Plan (CISA CTEP). CTEP delivers scenarios as time-phased injects rather than dumping the whole story at once, which is the most important design choice in the format. In the UK, NCSC's Exercise in a Box offers around 20 free exercises across a dozen-plus topics in micro, tabletop and simulation formats (NCSC), and NCSC now runs an assured-provider Cyber Incident Exercising scheme for those wanting a vetted external facilitator (NCSC).

The compliance floor, if you need one to get the invite accepted: SP 800-53 IR-3 requires testing the IR capability at an organization-defined frequency, noting that testing "includ[es] the use of checklists, walk-through or tabletop exercises, and simulations" (IR-3); IR-8 requires the plan be reviewed and approved at a defined frequency (IR-8); and SP 800-84 records 800-53's baseline expectation that federal agencies exercise or test contingency and IR capabilities at least annually. SP 800-61r3 rates ID.IM-02 — "Improvements are identified from security tests and exercises, including those done in coordination with suppliers and relevant third parties" — as High priority, tying supplier participation in through GV.SC-08 (NIST SP 800-61r3).

Actionable takeaway: Write the ladder into your plan with a named frequency per rung, then check which rungs you climbed in the last twelve months. Most programs find they did rung 3 once and rungs 4–6 never. The gap between "we do tabletops" and "we have measured our restore time" is where incidents live.

#Design: objectives first, then injects, then the scenario

Almost everyone does this backwards. Someone reads a threat report, gets excited about a scenario, writes three pages of narrative, and then bolts on some objectives the scenario happens to touch. The result tests whatever the story author found interesting, which is not the same as whatever your program is weakest at.

SP 800-84's design sequence is the opposite order: determine the topic → determine the scope → identify objectives → identify participants → identify exercise staff → coordinate logistics. Objectives come third, before you have written a single word of story, and everything downstream is derived from them.

The second rule sounds wrong and is right. Keep the scenario short. SP 800-84: "A common misconception is that scenarios must be very detailed to be effective. Actually, it is often more effective to develop a short, concise scenario," because with long scenarios "participants often spend more time dissecting the scenario… than they spend on meeting the objectives." A detailed scenario invites the room to argue with your fiction. Every minute spent debating whether the EDR would really have missed that is a minute not spent finding out who is allowed to shut down production.

#Writing an objective you can actually score

An objective is testable when a data collector who has never met your team can mark it true or false from what they observed. That means a role, an action, a threshold and a clock.

Five to eight objectives is right for a three-hour operational tabletop. More than eight and your data collector cannot watch them all.

#Then the injects, then the story

Once objectives exist, write the injects — the pre-scripted messages that force the decisions your objectives measure. SP 800-84 defines an inject as "a pre-scripted message that will be provided to participants during the course of an exercise," and specifies what each must carry: time, to whom, from whom, delivery means, and the message text. The chronological list of them is the Master Scenario Events List (MSEL) — "a chronologically sequenced outline of the simulated events and key event descriptions that participants will be asked to respond to," including expected actions and the objectives each event maps to. The MSEL is for exercise staff only; participants never see it.

Volume guidance from the same source is deliberately vague and deliberately correct: enough injects "to keep participants adequately occupied but… not be so many that participants will become overwhelmed." My working ratio, offered as judgement and not as NIST doctrine, is one inject per fifteen to twenty minutes of exercise clock, plus two spares in the facilitator's pocket for when the room solves something faster than expected.

Only now do you write the scenario narrative, and only enough to make the injects land. Then the artefact people skip, which is what turns scoring into vibes: evaluation criteria must be written before the exercise, "to ensure data collectors know what type of information to capture during the exercise."

Printed and in the room: the participant briefing; a Facilitator Guide (purpose, scope, objectives, scenario narrative, full question list, and a copy of the plan); a Participant Guide (the same, minus the question list); and the After-Action Report template, already populated with your objectives.

Actionable takeaway: Before your next exercise, write the objectives and the scoring sheet and get both signed off by the plan owner — with the scenario still unwritten. If you cannot get sign-off on the objectives, the scenario was never going to save you.

#A ready-to-run tabletop: identity-first extortion with recovery denial

A complete operational-level tabletop you can run in three hours, grounded in what 2026 intrusions actually look like: identity-first entry, near-instant hand-off, deliberate targeting of the recovery path, extortion without encryption. Appendix F carries this and the rest of the scenario card set in printable form.

Profile assumed: roughly 400 staff, cloud identity provider with SSO, one on-premises file estate, an outsourced service desk, a cyber insurance policy, an IR retainer. Adjust the nouns, keep the decisions.

Scenario, in full — this is everything participants get up front: A routine quality review of service desk tickets has flagged a password reset and MFA re-enrolment completed six hours ago for a finance manager, requested by phone. The requester's identity was verified using employee number and date of birth. It is 09:40 on a Thursday.

Everything else arrives as an inject.

#Objectives

#The Master Scenario Events List

Two facilitator notes. Inject 6 produces the highest-value finding in almost every organization I have seen run something like it, and it is a pure announcement — no story required. Inject 8 exists because contract collisions are discovered at the worst possible moment and are trivially fixable in peacetime.

The threat model is not invented. Help desk impersonation to obtain password resets and MFA token transfers to attacker-controlled devices is documented TTP, and CISA explicitly notes that the presence of legitimate remote-management tools is not on its own malicious (CISA AA23-320A). The compressed timeline reflects Mandiant's finding that the median hand-off from initial-access broker to the operator who does the damage is now 22 seconds, down from over eight hours in 2022, and that operators increasingly target backup infrastructure, identity services and virtualization management planes — attacking your ability to recover rather than only your ability to operate (M-Trends 2026). Before the room debates payment in inject 7, it is worth knowing Coveware measured the Q2 2026 payment rate for data-exfiltration-only cases at 15% (Coveware by Veeam). The regulatory threat in that inject has precedent: ALPHV/BlackCat filed an SEC complaint against a victim for failing to disclose the breach ALPHV itself had caused.

Actionable takeaway: Run this as written next quarter, printed plan on the table, laptops closed. Then swap injects 7 and 8 for a supplier-breach pair and run it again the following quarter with your top vendor in the room — ID.IM-02 explicitly contemplates exercises "done in coordination with suppliers and relevant third parties."

#Running it: facilitation is the whole job

A tabletop is a facilitated conversation with a scoring rubric attached. SP 800-84 specifies two staff roles as the minimum: a facilitator who leads the discussion and a data collector who records observations. Both must be thoroughly familiar with the plan and objectives, and both should meet beforehand and review previous exercises' results. One person cannot do both — facilitating takes all of your attention, and if you are also writing you record only what you already expected.

Open with the no-fault frame, out loud. Something close to: Nothing said in this room becomes a performance conversation. We are testing the plan, not the people. If the honest answer is "I have no idea," that is the most valuable thing you can say today, because it is a finding and I will write it down as one. CISA's version for real incidents applies identically: "Retrospectives must be blameless… Security incidents are rarely the result of one person's action. They are almost always the result of a failure of the overall system" (CISA IRP Basics).

Seat people away from their own teams. SP 800-84 is specific: participants are deliberately not seated with teammates, to encourage independent thinking and cross-exposure. It feels fussy for four minutes, then starts producing answers you would not otherwise have heard.

Keep the engineers from solving it. This failure mode is unique to security tabletops and it is not a discipline problem — it is what good engineers do. Someone starts designing the detection rule that would have caught inject 2, and the room follows, because that conversation is more comfortable than the one about who may call the CEO at 02:00. Two phrases handle most of it: "Assume it works — what do you do with the output?" for the person building the tool, and "Assume it doesn't — now what?" for the person whose plan depends on it. One rule resolves the rest: play the plan you have, not the plan you meant to write. When someone says "well, we'd obviously check the vault" and the plan does not say that, the data collector writes undocumented step relied upon and the exercise moves on.

Timekeeping. Hold the exercise clock visibly and give each inject a hard discussion budget. When the budget expires with no decision made, say so — "we are at time; the decision was not reached" — and let the data collector record it. A stalled decision is data; rescuing the room from a stall destroys it. Anything important but off-objective goes on a visible parking lot and gets an owner at the end.

The evaluator's job. Data collectors write against the criteria set in advance, capturing four things per inject: what was decided, who decided, how long it took from delivery, and what participants reached for — a document, a person, or a memory. That last one matters more than it looks. If four people reached for a colleague's memory rather than the playbook, you have a discoverability problem regardless of how correct the playbook's contents are.

Actionable takeaway: Name a facilitator and a separate data collector for every exercise, and have them meet a week beforehand with the objectives, the scoring sheet and the last exercise's findings in hand. If you cannot spare two people for three hours, you cannot spare the finding you were going to get.

#Scoring against objectives, not vibes

Most organizations end an exercise with a warm feeling and a slide. Produce this instead.

Per-objective rating. Four levels, applied to the objective and never to a person:

"Only because one specific individual was present" is deliberately a minor challenge rather than a pass. Key-person dependency is the most common quiet finding in security exercises, and it never shows up unless you score for it.

Measured times. Record these regardless of rating, because they trend across exercises where ratings do not: time to declaration; time to assemble incident command; time to first containment action approved; time to out-of-band bridge established; time to first holding statement approved.

Stall count. The number of decisions that stopped awaiting an absent authority. This single integer is the most persuasive number you will take to an executive, because it converts "our escalation paths are unclear" into "on Thursday, four decisions stopped for an average of eleven minutes each, waiting for someone who was not reachable."

Then the artefacts. CISA's CTEP discipline is the After-Action Report paired with an Improvement Plan, and the pairing is what separates exercise value from exercise theatre, because the Improvement Plan is where every finding acquires an owner and a due date (CISA CTEP). SP 800-84 says the same: after the report, "the plan coordinator might assign action items to select personnel to update the IT plan" — and should then actually update it.

A finding record that survives contact with a busy quarter carries seven fields:

The acceptance test field is the one people cut, and it is the one that makes the finding real. A finding without a written acceptance test closes when someone feels it is done.

Actionable takeaway: Score every objective, publish the stall count, and put exercise findings into the same tracking system as your vulnerability findings so they reach the same executive on the same report. Findings that live in a separate document die in it.

#Purple teaming and adversary emulation

Exercises test whether the plan works. Purple teaming tests whether the detections and response actions the plan invokes actually fire. Different question, different budget, different failure mode.

The distinction from a penetration test is not snobbery. A pen test asks whether an attacker can get in, and is scored on findings — usually perimeter and application weaknesses. An adversary emulation asks whether, given an attacker already executing a specific known behavior on your estate, your telemetry sees it, your logic alerts on it, and your responders act on it. A clean pen test report alongside zero detection coverage is a very common combination, and the second condition is the one that determines how long an adversary lives in your network.

The material is free. MITRE's Center for Threat-Informed Defense publishes an Adversary Emulation Library of plans modeled on real threat actors' behaviors, in full emulation form (initial access through exfiltration) and micro emulation form (CTID). Micro emulations are the on-ramp for a small team: a single behavior, executed deliberately, checked against your SIEM, in an afternoon. The Purple Team Exercise Framework provides the open methodology for the collaborative CTI-plus-red-plus-blue version, with a named coordinator role and a flow from threat intelligence through attack planning, emulation, detection and response (PTEF). And RE&CT does for the response side what ATT&CK coverage mapping does for detection — coverage and gap analysis across response actions (RE&CT).

CISA builds emulation into post-incident activity, with a warning attached: "Advanced SOCs should consider emulating adversary TTPs to ensure recently implemented countermeasures are effective… This testing should be closely coordinated with a blue team to ensure that they are not mistaken for true adversary activity" (CISA Playbooks).

Report the coverage triple, never a percentage. For each prioritized technique, three separate values: do we have the telemetry (a visibility score, from a tool like DeTT&CT), do we have logic (a rule exists and is enabled), and has it fired on a validated test (a date). Green on all three is coverage; anything else is a named gap with a named owner. A mapped technique is not a validated detection, and a validated detection is not coverage (DeTT&CT / NVISO Labs). A technique with no telemetry is not a detection-engineering problem at all — it is an ingest and budget problem, and conflating the two is how teams burn a quarter writing rules that can never fire. Palantir's Alerting and Detection Strategy framework makes the point structurally: every documented detection carries a Validation section describing "the steps required to generate a representative true positive event which triggers this alert. This is similar to a unit test" (Palantir ADS).

One 2026-specific item belongs on every purple team's list this year. MITRE ATT&CK v19 split Defense Evasion into two tactics — TA0005, renamed Stealth, and a new TA0112 Defense Impairment — as of v19.2, current since 28 April 2026 (ATT&CK versions). Any coverage map, SIEM dashboard or purple-team report built on v18 or earlier now has a stale tactic axis. Chapter 9 owns detection engineering; the exercise-program obligation is narrower: re-baseline your coverage map against the pinned ATT&CK version once a year, and record which version each report was built on.

Actionable takeaway: Pick three techniques from your top scenario, run the micro emulations this month, and record the coverage triple for each. Three validated detections beat a spreadsheet claiming eighty percent coverage that nobody has ever fired a test through.

#Testing the things nobody tests

This is the part of the chapter with the best return per hour spent, and it needs no scenario, no facilitator and no budget. These are tests in SP 800-84's strict sense — quantifiable checks on whether a mechanism works — and every one has failed for real, in public, at an organization better resourced than yours.

Look at the right-hand column and notice the pattern. Policy is universal; enforcement is not; and the exception is almost always at the seam with a third party or a legacy system. No playbook fixes that. A quarterly enumeration test surfaces it.

Do the call tree first. Not next quarter. This quarter. It costs one email and an hour of chasing acknowledgements, and it has already cost somebody else a great deal more.

Actionable takeaway: Put all nine rows on a recurring calendar with a named owner and a recorded result per run. None require a facilitator; most take under an hour. This is the highest-yield hour in the chapter.

#The hotwash: producing changes, not a document

Chapter 13 owns the post-incident review for real incidents. The exercise hotwash is the same instrument at lower stakes, and it happens immediately after the exercise, in the room, before anyone leaves. SP 800-84 gives the agenda as three questions the facilitator asks the participants: in which areas did they excel, where do they need training, and which parts of the plan should be updated. Fifteen minutes, verbal, no slides. The written report comes later; the hotwash catches what people will have rationalized away by Monday.

Blamelessness is not politeness, it is an information-gathering technique, and Chapter 13 sets out the evidence base for it. The exercise-specific consequence is narrower and worth saying plainly: the information you need lives in the head of the person who would look worst telling you. Blame is the mechanism by which you guarantee they do not.

Two current moves are worth importing into exercise reviews: the shift from "blameless" to "blame-aware" — everyone works within constraints, and some only become visible after the fact — and Calibrate, circulating draft findings before the review meeting so nobody is surprised in front of their peers (Howie: The Post-Incident Guide). Ambushing someone with a finding in a room full of colleagues buys you one finding and costs you a year of honest reporting.

Actionable takeaway: Run the verbal hotwash before anyone leaves the room, circulate draft findings for calibration within five business days, and hold the written review within ten. Momentum is the only thing that converts observations into changes.

#Cadence

Frequency is an organization-defined parameter under IR-3 and IR-8, which means you must choose and document it — "as needed" is not a frequency. Here is a defensible default set, and the tiers scale down honestly for a small team.

That last row is not padding. NIST SP 800-61r3 enumerates where improvements come from and each is a trigger: evaluations and audits (ID.IM-01), tests and exercises (ID.IM-02, rated High), and the execution of operational processes (ID.IM-03, also High) (NIST SP 800-61r3). Calendar cadence alone produces a review that finds nothing, because the calendar does not know that you changed identity providers in March.

Actionable takeaway: Publish the exercise calendar twelve months out, with owners, and treat a missed exercise the way you treat a missed patch SLA — as a tracked exception with a named accepter. Exercises that float are exercises that slip.

#Closing the loop

Everything above is overhead unless the findings change the playbook. That is the whole point, and it is where most programs quietly stop.

The mechanism is described fully in Chapter 2, so here is only the exercise-side half. Every playbook header carries a last_exercised field; every exercise that touches a playbook updates it; and a CI check fails or flags any playbook whose date is older than your documented interval, flipping its status from Active to Draft. Not because someone noticed — because the pipeline noticed. A playbook nobody has rehearsed in a year is a hypothesis, and labeling it accurately is the cheapest honesty available to you.

Then the finding lifecycle: every after-action finding becomes an issue with an owner and a due date, carries a written acceptance test, produces an identified playbook change, and — the step everyone forgets — is re-tested at the next exercise touching the same objective. Findings that close on assertion reopen in production. A finding is verified when someone other than the owner has run the acceptance test.

Update the authorities every time, whether or not anything about them came up. CISA's hotwash objectives put "reviewing and updating roles, responsibilities, interfaces, and authority to ensure clarity" on the standing list, and it is there because unclear authority is a recurring real-world finding. Authorities rot faster than procedures. A reorganization does not send a notification to your playbooks.

One closing calibration, because this chapter has been enthusiastic and the enthusiasm has limits. Mandiant's conclusion from over 500,000 hours of 2025 incident response is that most intrusions still stem from human and systemic failures, not from novel adversary capability (M-Trends 2026). Exercises are how you find human and systemic failures before someone else monetises them. That is not a small claim, and it does not require a single new license.

Rehearse it, time it, write down what broke, and fix the thing before the calendar makes you do it again.

#Chapter checklist

• EX-01A documented exercise program exists, naming an owner, the exercise types in use, and a stated frequency for each — with no entry reading "as needed". [IG1] [ID.IM-02] [CIS 17] [A.5.24]
• EX-02Written, testable objectives and evaluation criteria are approved before the scenario is written, for every exercise. [IG1] [ID.IM-02]
• EX-03Every exercise has a named facilitator and a separate named data collector, who meet in advance with the objectives, scoring sheet and prior findings. [IG2] [ID.IM-02]
• EX-04A Master Scenario Events List exists for every operations-influenced exercise, with each inject specifying time, recipient, source, delivery means and message text, and mapped to an objective. [IG2] [ID.IM-02]
• EX-05Senior-level and operational-level exercises are run separately before any combined exercise is attempted. [IG2] [GV.RR] [A.6.3]
• EX-06Every exercise is scored per objective on a four-level scale, records time-to-milestone for declaration, command assembly, first containment approval and first holding statement, and records a count of decisions stalled awaiting an absent authority. [IG2] [ID.IM-02]
• EX-07A verbal hotwash is held immediately after every exercise, before participants leave, and draft findings are circulated for calibration before the written review. [IG1] [ID.IM-02] [A.5.27]
• EX-08Every exercise produces an After-Action Report paired with an Improvement Plan in which each finding carries an ID, owner (a role), due date, written acceptance test and the specific playbook change it requires. [IG1] [ID.IM-02] [A.5.27]
• EX-09Exercise findings are tracked to closure in the same system as vulnerability findings, and closure requires the acceptance test to be run by someone other than the finding's owner. [IG2] [ID.IM-02]
• EX-10Every playbook header carries a last_exercised date, and an automated check flags or fails any playbook whose date exceeds the documented interval. [IG3] [ID.IM-02]
• EX-11The notification/call-tree cascade is tested unannounced at least quarterly, with acknowledgement rate and elapsed time recorded. [IG1] [RS.CO] [CIS 17]
• EX-12An out-of-band incident bridge, reachable without the primary identity provider, is convened as a test at least quarterly, using details held offline. [IG1] [CIS 17] [A.5.29]
• EX-13A printed copy of the plan, the relevant playbooks and the contact list is verifiably held by every named responder, and currency is spot-checked each quarter. [IG1] [A.5.24]
• EX-14At least one defined critical system is restored end-to-end to an isolated environment each quarter, with the measured duration compared against its documented RTO. [IG1] [CIS 11] [RC.RP] [A.5.30]
• EX-15Every break-glass account is used in a controlled window at least quarterly, verifying that access succeeds, the alert fires, and the use is reviewed. [IG2] [PR.AA]
• EX-16The after-hours escalation chain is paged unannounced outside business hours at least twice a year, with acknowledgement times recorded at every tier. [IG2] [RS.MA]
• EX-17The IR retainer and insurer breach-response lines are called annually to confirm reachability, contract currency, and any panel constraint that conflicts with the retained provider. [IG1] [GV.SC-08] [CIS 15]
• EX-18At least one exercise per year includes a critical supplier or third-party provider as a participant. [IG2] [GV.SC-08] [ID.IM-02]
• EX-19Adversary emulation is run against the organization's prioritized techniques at least quarterly, under written authorization naming scope, operator, time window and emergency stop contact. [IG3] [CIS 18] [DE.AE]
• EX-20All emulation activity is deconflicted with the defending team in advance, with a staffed deconfliction channel, an agreed automated-containment exclusion list, and a canary convention that lets an analyst identify the activity as authorized. [IG3] [CIS 18]
• EX-21Detection coverage is reported as a per-technique triple — telemetry present, logic enabled, last validated firing date — and never as a single coverage percentage. [IG3] [DE.CM] [A.8.16]
• EX-22The ATT&CK version underlying every coverage map and purple-team report is recorded, and the coverage baseline is rebuilt at least annually against the current pinned version. [IG3] [DE.AE]
• EX-23Following every SEV-1 or SEV-2 incident, the adversary's observed TTPs are emulated to verify that the newly implemented countermeasures detect or mitigate them. [IG3] [ID.IM-03] [DE.CM]
• EX-24A register of internet-facing systems without enforced phishing-resistant MFA is enumerated at least quarterly, with an owner and an end date against every entry. [IG1] [PR.AA] [CIS 6]
• EX-25A missed scheduled exercise is recorded as a tracked exception with a named accepting authority and a rescheduled date. [IG2] [GV.RR] [ID.IM-01]

#Sources

1. NIST SP 800-84 — Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities — https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-84.pdf
2. NIST SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations for Cybersecurity Risk Management — https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r3.pdf
3. CSF Tools — NIST SP 800-53 Rev. 5, IR-3 (Incident Response Testing) — https://csf.tools/reference/nist-sp-800-53/r5/ir/ir-3/
4. CSF Tools — NIST SP 800-53 Rev. 5, IR-8 (Incident Response Plan) — https://csf.tools/reference/nist-sp-800-53/r5/ir/ir-8/
5. CISA — CISA Tabletop Exercise Packages — https://www.cisa.gov/resources-tools/services/cisa-tabletop-exercise-packages
6. CISA — CTEP package documents — https://www.cisa.gov/resources-tools/resources/ctep-package-documents
7. CISA — CTEP Exercise Planner Handbook — https://www.cisa.gov/sites/default/files/publications/2%20-%20CTEP%20Exercise%20Planner%20Handbook%20(2020)%20FINAL_508_1.pdf
8. CISA — Federal Government Cybersecurity Incident and Vulnerability Response Playbooks — https://www.cisa.gov/sites/default/files/2024-08/Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf
9. CISA — Incident Response Plan (IRP) Basics — https://www.cisa.gov/sites/default/files/publications/Incident-Response-Plan-Basics_508c.pdf
10. CISA / FBI and partners — AA23-320A (Scattered Spider TTPs) — https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a
11. Cyber Safety Review Board — Review of the Summer 2023 Microsoft Exchange Online Intrusion — https://www.cisa.gov/sites/default/files/2025-03/CSRBReviewOfTheSummer2023MEOIntrusion508.pdf
12. NCSC — Exercise in a Box — https://www.ncsc.gov.uk/section/exercise-in-a-box/overview
13. NCSC — Effective steps to cyber exercise creation — https://www.ncsc.gov.uk/pdfs/guidance/effective-steps-to-cyber-exercise-creation.pdf
14. NCSC — Cyber Incident Exercising scheme — https://www.ncsc.gov.uk/news/ncsc-launches-cyber-incident-exercising-scheme
15. MITRE Center for Threat-Informed Defense — Adversary Emulation Library — https://ctid.mitre.org/resources/adversary-emulation-library/
16. SCYTHE — Purple Team Exercise Framework — https://github.com/scythe-io/purple-team-exercise-framework
17. RE&CT — response action coverage framework — https://atc-project.github.io/atc-react/
18. MITRE ATT&CK — version history (v19.2, 28 April 2026) — https://attack.mitre.org/resources/versions/
19. MITRE ATT&CK — Enterprise tactics — https://attack.mitre.org/tactics/enterprise/
20. NVISO Labs — DeTT&CT: mapping detection to MITRE ATT&CK — https://blog.nviso.eu/2022/03/09/dettct-mapping-detection-to-mitre-attck/
21. Palantir — Alerting and Detection Strategy Framework — https://github.com/palantir/alerting-detection-strategy-framework
22. GAO-18-559 — Data Protection: Actions Taken by Equifax and Federal Agencies in Response to the 2017 Breach — https://www.gao.gov/assets/gao-18-559.pdf
23. British Library — Learning Lessons from the Cyber-Attack (8 March 2024) — https://www.bl.uk/home/british-library-cyber-incident-review-8-march-2024.pdf/
24. Healthcare Dive — Change Healthcare: compromised credentials, no MFA — https://www.healthcaredive.com/news/change-healthcare-compromised-credentials-no-mfa/714824/
25. Joseph Blount, Colonial Pipeline — Senate Homeland Security and Governmental Affairs Committee testimony, 8 June 2021 — https://www.hsgac.senate.gov/wp-content/uploads/imo/media/doc/Testimony-Blount-2021-06-08.pdf
26. Mandiant / Google Cloud — M-Trends 2026 — https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026
27. Sophos — State of Ransomware 2026 — https://www.sophos.com/en-us/blog/sophos-state-of-ransomware-2026
28. Coveware by Veeam — Cyber extortion payment trends, Q2 2026 — https://www.veeam.com/blog/cyber-extortion-payment-trends-q2-2026.html
29. Howie: The Post-Incident Guide — https://howie-guide.pagerduty.com/