What an incident response tabletop exercise is
An incident response tabletop exercise is a structured conversation. The people who would handle a real security incident sit around a table (or a video call), a facilitator describes a realistic scenario, and the group talks through what they would do, step by step, using your incident response plan. Nobody touches a production system. The point is to find out whether the plan, the contacts and the tools hold up before you need them.
A good tabletop answers questions a written plan can't: Does everyone know who leads? Can you actually reach the vendor's security team at night? Who decides whether to tell customers? Where are the logs, and how far back do they go? Most first exercises end with a list of small, fixable gaps, which is the result you want.
Why SOC 2 auditors look for one
The SOC 2 Trust Services Criteria expect you to respond to security incidents through a defined process (CC7.4) and to recover from them and learn from what happened (CC7.5). A written Incident Response Plan covers the "defined process" part. Auditors then commonly ask how you know the plan works, and for most small companies the honest answer is: they haven't had a serious incident yet. A tabletop exercise is the usual way to show the plan has been tested anyway.
What auditors tend to look for is simple: evidence that an exercise took place in the period they are reviewing, who took part, what scenario you used, what you learned, and that the lessons led to action. The exact evidence format and how they test it are up to your auditor, so ask early. If you are going for a Type 2 report, make sure the exercise falls inside your observation period.
How often: once a year is the common baseline for small teams. Run one sooner after a major change, such as a new cloud provider, a new incident lead, or a big rewrite of the plan.
How to run a tabletop exercise in about 90 minutes
1. Pick the participants and a facilitator
Invite the people who would respond for real, not the people who happen to be free:
- The incident lead named in your plan, and their backup.
- Engineering and operations: whoever would investigate, contain and restore.
- Leadership: someone who can make business decisions, such as taking a service offline.
- Communications: whoever talks to customers, and whoever handles legal or contractual questions.
Five to eight people is a workable size. Appoint a facilitator who runs the scenario and does not play a role in it, and a separate note-taker. The facilitator's job is to keep the discussion moving and to ask "who, exactly?" and "how would you know?" when answers get vague.
2. Choose a realistic scenario
Pick something that could plausibly happen to your company this year, based on your systems and your risk assessment. A scenario that is too exotic turns into a debate about whether it could happen at all. Rotate scenarios from year to year so you test different parts of the plan: detection one year, vendor coordination or customer communication the next.
3. Write the injects
An inject is a new piece of information the facilitator reveals partway through, the way a real incident unfolds. Two or three injects per scenario is enough for 90 minutes. Good injects make the situation worse or more ambiguous, force a decision, or bring in someone outside the room (a customer, a vendor, a regulator). Write them down in advance, along with the questions you want each one to raise.
4. Run the discussion
A simple agenda for a 90-minute session:
| Time | What happens |
|---|---|
| 0 to 10 min | Ground rules (no blame, no real systems, "we don't know" is a fine answer), the objectives, and the opening premise. |
| 10 to 30 min | First response: detection, triage, who is the incident lead, how the team gets together. |
| 30 to 50 min | Inject 1: containment and investigation decisions. |
| 50 to 65 min | Inject 2 (and 3 if time allows): escalation, recovery, and communication with customers, vendors and staff. |
| 65 to 80 min | Debrief: what worked, what was unclear, what was missing from the plan, contact lists or tools. |
| 80 to 90 min | Agree action items, each with an owner and a target date. |
Keep the plan open on screen during the exercise. When someone describes what they would do, ask whether the plan says the same thing. The differences are your findings.
5. Take notes as you go
The note-taker records decisions and who made them, open questions, and every moment the group got stuck. A rough timeline is useful too ("at inject 1 we decided to rotate keys; nobody knew who owned the CI account"). Tidy the notes within a day or two, while memories are fresh.
6. Capture gaps and action items
Turn every gap into an action with an owner and a date: update the on-call contact list, extend log retention, add a customer notification template, document how to revoke a vendor integration. Track them where your team already tracks work, and link them from the exercise notes.
7. Update the plan
If the exercise showed the Incident Response Plan is wrong or incomplete, change it, get the change approved, and make sure people know. An auditor reading next year's evidence will look for the loop: exercise, gaps, fixes, updated plan. See policy approvals and version control for keeping that history clean.
Five ready-to-use tabletop exercise scenarios
Adapt the names and systems to your own environment. Each scenario has a short premise and injects to reveal in order.
Leaked cloud credentials
Premise: A developer notices that a cloud access key was committed to a public code repository three days ago.
- Inject 1: A billing alert shows new compute instances running in a region you don't use.
- Inject 2: Access logs show the key was used to list and download from a storage bucket that holds customer exports.
- Inject 3: The key belongs to the account your production deploys use, so revoking it will stop deployments.
Ransomware on a laptop
Premise: A support team member reports that their files have been renamed and a ransom note is on the desktop.
- Inject 1: The laptop syncs a shared drive, and files in a shared team folder are now encrypted too.
- Inject 2: The browser on that laptop had active sessions to your admin console and your support tool.
- Inject 3: An email arrives claiming customer data was copied and will be published unless you pay.
Vendor breach notification
Premise: A SaaS vendor that stores customer support tickets emails to say an attacker accessed some customer tenants.
- Inject 1: The vendor confirms your tenant was affected, including attachments customers uploaded.
- Inject 2: One of your largest customers asks whether their data is involved and points to the notification clause in their contract.
- Inject 3: The vendor asks you to rotate your integration tokens, and nobody is sure who set up the integration.
Accidental public data exposure
Premise: A customer emails to say a link to a storage bucket containing a data export from your product is publicly accessible.
- Inject 1: Access logging on the bucket was off, so you can't tell who downloaded what.
- Inject 2: The export contains personal data, and someone asks whether you must notify customers or a regulator, and by when.
- Inject 3: A reporter contacts your company asking for comment.
Lost device
Premise: An engineer reports that their laptop was left in a taxi while traveling.
- Inject 1: Device management shows the laptop last checked in two days ago, and its disk encryption status is not reported.
- Inject 2: The engineer admits a copy of a production database was on the laptop for debugging.
- Inject 3: The device checks in from an unknown network before the remote wipe completes.
Tip: Keep at least one inject that tests communication rather than technology. Teams often contain the technical problem well on paper and then discover nobody owns the customer email.
What to record as evidence
Write the record so someone who wasn't there, such as your auditor, can follow what happened. Keep it with the rest of your audit evidence (see SOC 2 evidence collection):
- Date and duration of the exercise.
- Attendees and their roles, including the facilitator and note-taker, and anyone invited who didn't attend.
- The scenario and injects, as written before the session.
- Which version of the Incident Response Plan you exercised.
- Decisions made during the discussion, and who made them.
- Gaps found: in the plan, contacts, access, tools or logging.
- Action items, each with an owner and a target date, and later their status.
- Changes to the plan that followed, with the new approved version.
- Sign-off by whoever is accountable for the program.
Scheduling the tabletop in Confluence with Compliance in a Box
The hard part of an annual exercise is remembering it, then finding the evidence a year later. Compliance in a Box, an app for Confluence Cloud, includes Incident Response Tabletop as one of its SOC 2 recurring activities. It is annual by default and supports CC7.4 and CC7.5 in the app's controls mapping, alongside the Incident Response Plan policy.
- A procedure page. The activity has its own page in the compliance space, under Recurring Activities, with the objective, the procedure and the evidence to keep. Tailor it to your plan.
- An evidence page on schedule. Before each period is due, the app creates an evidence page under the activity page, with a checklist and a section for the scenario, the participants and the lessons learned. The SOC 2 activities start with 14 days of notice; a Compliance Admin can raise that with Edit schedule if you need more time to book everyone.
- An owner and approvers. Compliance Admins assign them under Settings > Owners & approvers. Only the owner and Compliance Admins can edit the evidence page. The owner gets reminders as Confluence tasks when the evidence page opens and as the due date approaches.
- Version-bound approval. The owner submits the completed page for approval from the Compliance byline item on the page. The approval is tied to the exact page version submitted; editing the page before it is approved cancels the submission. Self-approval is allowed but flagged, so pick an approver other than the owner if your auditor wants an independent review.
When the exercise leads to changes in the Incident Response Plan, edit the policy page in Confluence as usual. The policy shows Changes pending until the new version is approved, and if you mark the submission as a Material change, employees are asked to acknowledge the updated plan. The full workflow is in the Recurring activities chapter of the user guide, and the SOC 2 compliance calendar shows where the tabletop fits among your other recurring controls.
FAQ
How often should we run a tabletop exercise for SOC 2?
Once a year is the common baseline for small companies, and it is the default cadence in Compliance in a Box. Your auditor decides what is sufficient for your report, so confirm the frequency with them.
Does a real incident count instead of an exercise?
Some auditors accept a real incident that exercised the plan, if you reviewed it afterwards in the same way: timeline, decisions, lessons learned and follow-up actions. Ask yours before you skip the exercise.
Do we need an outside facilitator?
No. An internal facilitator who knows the plan and is willing to ask awkward questions is enough for most small teams. What matters is that the facilitator isn't also playing a key role in the scenario.
What if the exercise goes badly?
That is a useful result. A tabletop that finds gaps and fixes them is better evidence than one where everything went perfectly, because it shows the plan is being tested and improved.