Exercise Your Incident Response Plan Before You Need It

Your auditor asks whether the incident response plan has been tested. You pull up a PDF last edited fourteen months ago, a RACI chart that still lists two people who left in the spring, and an incident channel nobody has posted in since the last ransomware headline.

That isn't a tested plan. It's a binder.

Most IR plans fail for a boring reason: the first time anyone uses them is during a real incident. Under pressure, nobody remembers which version is current, who owns containment, or how to escalate when the primary on-call is on a plane. Mid-sized companies don't need a week-long war game or a red team engagement to fix that. They need regular, honest exercises that expose the gaps while the stakes are low, and the discipline to close what they find.

Here's how to run them.

Why Unpracticed Plans Break

A written plan quietly assumes calm, complete information, and responders who already know each other. Real incidents deliver none of that. The same failures show up again and again:

Contact lists and escalation paths are out of date
Roles that read clearly in the document get muddy in the room
Evidence preservation and legal hold get skipped because nobody has practiced the sequence
Customer and leadership communications get improvised in a shared doc at 2 a.m.
Containment steps depend on admin access nobody has verified recently

Re-reading the plan won't surface any of this. Running it will.

NIST's current incident response guidance, SP 800-61 Rev. 3 (published April 2025 to replace Rev. 2), frames preparation and lessons learned as ongoing parts of cybersecurity risk management, not a one-time setup step. Exercises are how you make that real.

An exercise that finds nothing was designed too easy. The whole point is to discover your gaps while the cost of discovery is an uncomfortable meeting, not a breach notice.

Tabletop vs. Functional Exercises

NIST SP 800-84, the guide to test, training, and exercise programs, describes the two exercise types single organizations rely on most. You want both, because they test different things.

A tabletop exercise is discussion-based. A facilitator presents a scenario (ransomware on a file share, a compromised SaaS admin account, suspected data exfiltration) and the team talks through what they would do: who detects it, who decides, how you contain it, who you notify, and how you recover. No systems are touched.

A functional exercise has people actually perform the work in a simulated or non-production environment: pull logs, isolate a host in a staging account, rotate credentials, restore from backup, open the incident ticket the way they would in production.

Aspect	Tabletop exercise	Functional exercise
Purpose	Validate decisions, roles, handoffs, and the logic of the plan	Prove that people, runbooks, and tools work in practice
Format	Facilitated discussion of a scenario; no systems touched	Hands-on execution in a simulated or non-production environment
Who participates	Incident commander, technical leads, communications, legal or privacy, an executive decision-maker	The responders who would run the steps: IT, engineering, security, plus the incident commander
Typical duration	60 to 90 minutes	Half a day to a full day
What it finds	Unclear authority, stale contacts, notification gaps, conflicting assumptions	Missing access, broken runbooks, slow restores, logging and retention gaps
Typical output	Decision log, gap list, plan and playbook updates	Measured timings (actual restore time vs. RTO), runbook and access fixes
Prep effort	Low to moderate: scenario, injects, a facilitator	Moderate to high: test environment, safe targets, a rollback plan

Teams that only run tabletops tend to look coordinated on paper and then stall when a break-glass password doesn't work. Teams that only run technical drills tend to contain cleanly and then fumble the customer call.

What Good Looks Like for Mid-Sized Teams

You don't need an enterprise program. For most mid-market teams, good enough looks like this:

One living IR plan. Short, owned, versioned, with a contact list someone actually reviews every quarter.
Clear roles. Incident commander, technical lead, communications, and legal or privacy as needed. One person can wear two hats, but every hat needs a name and a backup.
A few focused playbooks. Ransomware, account takeover, data exposure, critical vendor outage. Four good ones beat fifteen nobody reads.
A cadence you can sustain. More on that below.
After-action reviews that ship fixes. Every exercise ends with owned remediation items and due dates, not a slide deck that dies in someone's inbox.

If you can't name your last exercise, its top three findings, and who closed them, you don't have an exercised program. You have optimism.

A Cadence That Fits Real Teams

Exercising once a year turns the event into a compliance ritual. Monthly war games will burn out a lean team. Aim for a rhythm that survives a normal quarter:

Frequency	Activity	Who's involved	Output
Quarterly	Refresh contacts, on-call rotations, and vendor escalation numbers; skim playbooks for drift	IR plan owner, on-call leads	Updated contact list and plan version
Twice a year	Full tabletop on a high-impact scenario	Leadership, incident commander, ops, communications, legal	Decision log and owned remediation items
At least annually	Functional exercise: backup restore, identity provider compromise, or cloud account containment	Hands-on responders	Measured timings, runbook and access fixes
Within 30 to 60 days of material change	Focused exercise on what changed: new identity provider, major SaaS rollout, acquisition, or a real incident	Owners of the changed system or process	Updated playbooks, confirmed access

Then protect the calendar. An exercise that keeps slipping is a risk acceptance nobody signed.

If You're in Scope for PCI DSS

Check that calendar against your obligations. PCI DSS Requirement 12.10.2 requires the incident response plan to be reviewed and tested at least once every 12 months, and the test has to cover every element listed in 12.10.1. A single tabletop about a phished laptop rarely touches all of them. Here's how to make sure your exercises do:

12.10.1 element	How to exercise it
Roles, responsibilities, and communication and contact strategies, including notification of payment brands and acquirers	Inject a confirmed cardholder data compromise and have the team name who contacts the acquirer, when, and with what information
Incident response procedures with specific containment and mitigation activities for different types of incidents	Run the playbook for the scenario's incident type and check that each step is specific enough to follow without improvising
Business recovery and continuity procedures	Ask how the business keeps taking payments while affected systems are isolated
Data backup processes	Pair the tabletop with a functional restore of an in-scope system and record actual time against target
Analysis of legal requirements for reporting compromises	Have legal or privacy walk through which notification obligations apply and their deadlines
Coverage and responses of all critical system components	Pick scenarios that reach payment applications, databases, network components, and key service providers
Reference or inclusion of incident response procedures from the payment brands	Confirm the current brand procedures are linked from the plan and responders know where to find them

If you split coverage across more than one exercise during the year, document how they add up to the annual test and confirm the approach with your assessor. Keep the records either way: the scenario, attendees, decisions, findings, and plan updates are exactly what a QSA will ask to see.

How to Run an Exercise That Teaches You Something

1. Pick one realistic scenario. Tie it to something that would genuinely hurt: unauthorized access to the production database, a compromised payroll SaaS account, customer PII sitting in a misconfigured storage bucket. Your recent risk assessments and real near-misses are the best source material. Skip the exotic nation-state plot nobody believes.

2. Time-box it. Plan about 90 minutes for a tabletop and half a day for a focused functional exercise. Longer sessions drift into scope creep and debate. A simple tabletop agenda:

Time	Segment	What happens
0:00-0:10	Ground rules	Facilitator sets scope, no-blame rules, and the two or three things you're testing
0:10-0:25	Detection and triage	Initial alert lands. Who sees it, who declares an incident, what severity
0:25-0:50	Containment and escalation	First injects. Decisions on isolation, access, and vendor contact
0:50-1:10	Communications and legal	Customer, leadership, and regulatory notification decisions
1:10-1:20	Recovery	Restore path, a reality check against RTO, criteria for closing the incident
1:20-1:30	Hot wash	Top gaps, owners, and due dates captured before anyone leaves

3. Invite the people who would actually be paged. That means IT, engineering, and whoever owns communications and legal, not just security. Leave out spectators who want to "observe for awareness."

4. Use your real artifacts. Open the actual plan, the actual Slack or Teams channel, the actual ticket queue. If nobody can find the runbook, that's your first finding.

5. Add friction on purpose. Injects are the facilitator's tool for turning a calm walkthrough into a real test. Release them one at a time, and make each one harder than the last. Here's a sample set for a compromised identity provider admin account:

Inject	What the facilitator says	What it tests
1	"Your identity provider flags an impossible-travel login on an admin account at 6:40 p.m. on a Friday."	Detection path, who declares an incident, after-hours escalation
2	"The account owner is on a flight for five more hours. The account has created two new API tokens."	Authority to disable accounts without the owner, backup roles, containment
3	"Logs show those tokens were used to export your customer list from the CRM."	Evidence preservation, scoping the data exposure, bringing in legal and privacy
4	"A customer emails support asking if you've been breached. A reporter follows up an hour later."	Communications approval chain, holding statements, who speaks externally
5	"The vendor says retrieving logs older than your retention window will take 24 hours."	Vendor escalation paths, contract terms, log retention gaps

The point is to surface failure modes, not to win.

6. Capture decisions and gaps as they happen. Assign one scribe. Timestamp the major calls. Note every place someone guessed instead of following a playbook.

7. Close with a remediation list. Every item gets an owner, a due date, and a definition of done. Track them in your risk register or control backlog, the same system you use for the rest of your GRC work, so they don't turn into orphaned meeting notes. Then update the plan itself. PCI DSS 12.10.6 expects the plan to evolve based on lessons learned, and that's good practice whether or not you handle card data.

8. Brief leadership on one page. Cover what you practiced, what broke, what you're fixing, and what you need from them: budget, authority, or a policy decision.

Habits That Turn Exercises Into Theater

Watch for these:

Scoring the exercise so everyone passes
Inviting only security and calling it a company exercise
Choosing scenarios so far-fetched that nobody takes them seriously
Writing findings without owners or due dates
Declaring success because people showed up
Waiting for the perfect cyber range before practicing anything

A messy tabletop that produces five owned fixes beats a polished simulation that produces applause.

Key Takeaways

Unpracticed IR plans fail at the worst possible moment, so exercise them while the stakes are low
Use tabletops to test decisions and handoffs, and functional exercises to test tools and runbooks
Keep the plan short, roles named, playbooks few, and the cadence sustainable
Map exercises to your obligations; PCI DSS 12.10.2 requires an annual test that covers every 12.10.1 element
Time-box each session, invite real responders, use real artifacts, and escalate friction with injects
End every exercise with owned remediation items and an updated plan

Incident response isn't a document you renew for the auditor. It's a capability you rehearse. Teams that exercise regularly still feel the pressure when a real incident hits. They just aren't discovering their gaps for the first time while it's happening.

Could your team prove its incident response plan works before a real incident tests it? episki helps teams track incident response controls, exercise evidence, and remediation owners alongside PCI DSS, SOC 2, risk assessments, and policies, all in one workspace. Get started free