Run an incident response tabletop exercise to test whether your team actually knows what to do when a breach hits — not just whether the policy document reads well.
Why this matters
A written incident response plan means nothing until people follow it under pressure.
Auditors reviewing ISO 27001 (Annex A.5.24, A.5.26) or SOC 2 don't just want the document — they want evidence you've tested it. A tabletop exercise is the cheapest, fastest way to generate that evidence: no live systems touched, no downtime, just a room (or a call) and a scenario.
Managing that evidence trail by hand is where most teams lose the thread. OneClickComply automates the compliance side — logging the exercise, the findings, and the remediation actions — so the tabletop itself stays focused on people and process, not paperwork.
What you'll need
- A written incident response plan to test against — even a rough draft works for a first run
- 60-90 minutes blocked in every relevant participant's calendar
- A facilitator who isn't playing a role in the scenario
- One realistic scenario (ransomware, phishing-led account takeover, or a third-party data breach are the three most common in 2026 audits)
- A notetaker or recording tool to capture decisions and gaps in real time
- Your incident response plan, contact list, and any relevant vendor SLAs printed or shared on-screen
- A compliance platform like OneClickComply to log the exercise as evidence against your ISO 27001 or SOC 2 control set
The steps
1. Pick a scenario that matches your actual risk profile
Don't run a generic "hacker breaks in" scenario — pick the incident type most likely to hit your business. A SaaS company should simulate a compromised admin credential; a company handling customer payment data should simulate a third-party processor breach.
Write the scenario as a one-paragraph brief: what happened, what's been detected so far, and the time the incident was "discovered." Keep it to 150-200 words so the room can absorb it in under a minute.
Common mistake: picking a scenario so far-fetched nobody takes it seriously. Base it on a real incident type reported in your sector in the last 12 months.
2. Assign roles before the room starts talking
Name who plays incident commander, who represents legal, who represents comms, and who represents engineering or IT. In a small company, one person may hold two roles — say so out loud at the start.
This stops the exercise collapsing into a group discussion where the loudest voice runs the whole thing. Real incidents fail this way too.
Common mistake: letting the facilitator also play incident commander. The facilitator needs to stay outside the scenario to inject new information and keep time.
3. Inject the scenario in stages, not all at once
Release the brief, then wait. After 10-15 minutes, add a new development: "the attacker has now exfiltrated 4,000 customer records" or "your MSP confirms the access point was a stale API key." Stage three or four injects across the full session.
This mirrors how real incidents unfold — information arrives in pieces, not as a complete picture. It also exposes whether your team over-commits to an early theory and ignores contradicting evidence later.
Common mistake: giving the team the full picture upfront. That tests reading comprehension, not incident response.
4. Force a containment decision within the first 30 minutes
Ask the room directly: "Do you isolate the affected system now, or gather more data first?" Make them commit to an answer and a timestamp.
This is the single most revealing moment in most tabletop exercises — teams often can't agree who has the authority to pull a system offline. If that's unclear in a simulation, it's unclear in a real incident.
Common mistake: letting the group debate indefinitely without forcing a decision. Real attackers don't wait for consensus.
5. Test the notification chain, not just the technical response
Ask who needs to be told, and by when: customers, regulators, insurers, the board. Under UK GDPR, a reportable breach needs notifying to the ICO within 72 hours of discovery — walk through whether your team even knows that clock exists.
Most tabletop exercises reveal gaps here before they reveal gaps in the technical response. Legal and comms readiness is usually weaker than engineering readiness.
Common mistake: treating notification as an afterthought at the end of the session instead of a live decision point during it.
6. Debrief immediately, while memory is fresh
Spend the last 20 minutes of the session — not a separate meeting next week — capturing what worked, what stalled, and what surprised the room. Ask each role to name one thing they'd do differently.
Waiting even a few days loses the detail that makes the debrief useful. The exercise's value lives almost entirely in this debrief, not in the roleplay itself.
Common mistake: skipping the debrief because the session ran long. Cut the scenario short before you cut the debrief.
7. Turn findings into logged, owned actions
Every gap identified needs an owner and a date, not a vague "we should look into this." Log each action against the relevant control — this is the evidence an auditor actually wants to see.
This is where a compliance platform earns its keep. OneClickComply logs the exercise, the findings, and the remediation actions against your ISO 27001 or SOC 2 control set automatically, so the audit trail exists the moment the session ends.
Common mistake: writing findings in a shared doc that never gets reviewed again. If it's not tracked to closure, an auditor will treat the exercise as incomplete.
Troubleshooting
- Nobody wants to commit to a decision during the exercise. Set a hard 5-minute clock per decision point and force a call — indecision itself is the finding you report.
- The scenario feels too easy and the team "solves" it in 20 minutes. Inject a complication mid-session: a key person is "unreachable," or the initial fix turns out to be wrong.
- Different departments blame each other during the debrief. Reframe every finding as a process gap, not a person gap — "the escalation path wasn't documented" instead of "IT was slow."
- Findings get logged but never actioned. Set a 30-day review date at the end of the debrief and assign a single owner to chase it.
- The exercise takes place but produces no auditor-ready evidence. Log the scenario brief, timestamps, decisions, and remediation actions as you go rather than reconstructing them afterwards.
- Leadership doesn't attend and the exercise loses authority. Run at least one annual session with a senior leader in the incident commander seat.
Tools and resources
- A written incident response plan (the object being tested)
- A scenario brief and inject schedule, drafted in advance
- A notetaker or recording tool for the debrief
- OneClickComply to automate evidence logging for ISO 27001, Cyber Essentials, and SOC 2 requirements tied to incident response testing
- Your organisation's contact list for legal, comms, insurers, and any relevant regulators
What to do next
Run the exercise once, fix the findings, then schedule the next one for six months out — a tabletop exercise loses value fast if it's a one-off. Pair it with a review of your written incident response plan itself; most teams discover the plan needs rewriting more than the team needs retraining.
Frequently asked questions
One last thing
The most useful tabletop exercises aren't the ones where the team "passes" — they're the ones that expose a broken notification chain or an unclear containment decision before a real attacker does. If your last exercise produced zero findings, run it again with a harder scenario; a clean result usually means the scenario was too easy, not that your team is ready.