A SOC 2 auditor will not accept a business continuity plan that has never been tested. The AICPA Trust Services Criteria require you to test your recovery procedures, and a written plan sitting in a shared drive does not count. A BCDR tabletop exercise, a facilitated discussion where your team walks through a simulated disaster and makes the decisions a real incident would demand, is the most practical way for a lean team to produce that evidence.
This playbook takes a first-time GRC lead from zero to a completed, documented, audit-ready tabletop exercise in three weeks. It covers which Trust Services Criteria the exercise maps to, how to design a realistic scenario, how to run the session, and exactly which artifacts to hand your SOC 2 auditor. No prior exercise experience is assumed, and no external facilitator is required, though we will be honest about when hiring one makes sense.
The stakes are real. An untested disaster recovery plan is one of the most common sources of exceptions in SOC 2 reports that include the Availability category. The fix costs one afternoon of your team’s time plus the preparation around it. Few controls offer a better ratio of audit value to effort.
Understanding SOC 2 Requirements for BCDR Tabletop Exercises
Relevant Trust Services Criteria (A1.2, A1.3, CC7.5)
SOC 2 never uses the phrase “tabletop exercise.” What the AICPA Trust Services Criteria require is outcomes, and three criteria do most of the work here.
- A1.2 requires the entity to design, implement, operate, and monitor environmental protections, data backup processes, and recovery infrastructure. This is where your Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP) live.
- A1.3 is the one that forces the exercise: the entity tests recovery plan procedures supporting system recovery to meet its objectives. A plan with no test behind it draws an exception under A1.3.
- CC7.5 sits in the Common Criteria, which apply to every SOC 2 report regardless of category selection, and covers the activities an entity implements to recover from identified security incidents. Its points of focus contemplate periodic testing of incident recovery plans, which means even a Security-only report benefits from a documented exercise.
- CC9.1, on mitigating the risk of business disruption, reinforces the same expectation.
One nuance worth knowing: A1.2 and A1.3
A1.2 and A1.3 only apply if the Availability category is in your report scope. Most SaaS companies include it because customers buying uptime SLAs expect it. If Availability is in scope and your recovery plan has never fired, you have a finding waiting to happen.
Auditor Expectations for Tabletop Evidence
Auditors test whether the control operated, not whether a meeting happened. For a tabletop, that means they want a dated record showing a defined scenario, named participants, the decisions made, the gaps identified, and proof those gaps were remediated. An exercise that produced zero findings reads as theater, and experienced auditors treat it with suspicion. The strongest evidence package traces a straight line from exercise to finding to closed remediation ticket.
Frequency matters too. The Trust Services Criteria set no fixed interval, but annual testing is the floor auditors accept in practice, and your own policy language usually commits you to it. For a Type II report, the exercise must fall inside the observation period. An exercise run fourteen months before your audit window opened does not cover the period under examination.
Common Pitfalls First-Time GRC Leads Face
The same mistakes repeat across first audits. Teams run the exercise but never write the after-action report, leaving nothing to sample. They test a scenario their control language does not describe, such as discussing a ransomware response when their documented control promises an annual backup restoration test. They invite only the engineering team and skip the executives who would make the actual call on customer communication and legal notification. And they treat the exercise as a pass/fail event rather than a gap-finding tool, which produces defensive participants and an empty findings log.
Insider Note: In our audit readiness work, the single most common tabletop failure is a mismatch between the control description and the test performed. If your System Description says you “test backup restoration annually,” a discussion-based tabletop does not satisfy that sentence. Read your own control language before you design the exercise, and either run the technical restore alongside the tabletop or fix the control wording to match what you actually do.
Pre-Exercise Prerequisites
Required Documentation (BCP, DRP, Incident Response Plan)
You cannot test a plan that does not exist. Before week one begins, three documents need to be in a reviewable state:
- a Business Continuity Plan covering how the business keeps operating through a disruption,
- a Disaster Recovery Plan covering how systems and data are restored, and
- an Incident Response Plan (IRP) covering detection, escalation, and communication. They do not need to be perfect. Half the value of a tabletop is discovering where these documents are wrong, and a slightly stale plan produces a richer exercise than a freshly polished one. What matters is that each document names owners, defines Recovery Time Objectives (RTO)
- and Recovery Point Objectives (RPO) for critical systems, and includes current contact information.
If you have no plans at all, stop and write them first. A tabletop without underlying plans is a brainstorm, and auditors will not accept it as recovery plan testing.
Identifying Stakeholders and Participants
A SOC 2 tabletop needs decision-makers, not just responders. The core group is the engineering or infrastructure lead who owns recovery execution, the CTO or equivalent who owns the restore-versus-rebuild call, someone who owns customer communication, and whoever handles legal or contractual notification obligations. For a startup under 50 people, that is typically five to eight participants. Keep the room small enough that everyone speaks. Finance and HR can join larger exercises later; for a first exercise, they dilute focus.
Defining Scope, Objectives, and Success Criteria
Write the objectives down before designing anything else, and map each one to a Trust Services Criterion. Three objectives are the right number for a first exercise. For example: validate that the DRP’s escalation path reaches a decision-maker within 30 minutes (A1.3), confirm the team can articulate RTO and RPO for the production database without looking them up (A1.2), and test whether the customer communication template in the IRP fits a ransomware scenario (CC7.5). Success criteria should be observable in the room. “The team felt prepared” is not evidence; “the facilitator confirmed each inject reached a documented decision within the allotted time” is.
The 3-Week BCDR Tabletop Playbook Overview
Timeline at a Glance
| Week | Focus | Key Outputs |
|---|---|---|
| Week 1 (Days 1-7) | Planning and scenario design | Objectives mapped to SOC 2 controls, scenario script, injects, pre-read pack |
| Week 2 (Days 8-14) | Facilitation and execution | Completed exercise, decision log, raw findings, hot wash notes, participant feedback |
| Week 3 (Days 15-21) | Documentation and audit readiness | After-Action Report, remediation tracker with owners, updated BCP/DRP, packaged evidence |
Total time commitment: roughly 20 to 30 hours for the facilitator spread across three weeks, and two to three hours per participant. That is the honest cost of the DIY route. An externally facilitated exercise compresses your preparation time to near zero and starts at around $2,000, scaling with scope and the facilitator’s seniority. Axipro includes a facilitated tabletop exercise in its Achievement Plan, starting at $4,000 and covering full SOC 2 readiness, not just the exercise. For a startup’s first exercise, the DIY route works fine if someone owns it end to end. Hire out when executives will not take an internal facilitator seriously or when the exercise doubles as board-level assurance.
Roles and Responsibilities (Facilitator, Scribe, Observers, Participants)
Four roles make or break the session.
- The facilitator runs the scenario, delivers injects, and keeps discussion moving without answering the questions for the room.
- The scribe captures every decision, assumption, and gap in real time; this role cannot be combined with facilitating, because the facilitator is always one step ahead of the conversation.
- Participants play themselves, making the decisions their real role would demand.
- Observers watch without speaking and are optional, but inviting your auditor’s point of contact or a board member as an observer can pay dividends later.
As the GRC lead, you facilitate; recruit the scribe from anyone organized who is not a decision-maker in the scenario.
Tools and Templates You’ll Need
You do not need specialized software. A shared document for the scenario script, a timer, a decision log template, and a remediation tracker cover it. The best free starting point is the CISA Tabletop Exercise Packages library, which offers over 100 customizable packages with scenario manuals, discussion questions, participant feedback forms, and an After-Action Report template, all aligned to Homeland Security Exercise and Evaluation Program (HSEEP) conventions.
For deeper methodology, NIST SP 800-84, the Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities, remains the reference standard for structuring tests and exercises. If you track controls in a GRC platform or a spreadsheet, our free GRC workbook for SOC 2 and ISO 27001 controls includes the evidence and remediation tabs this playbook feeds into.
Week 1: Planning and Scenario Design
Day 1-2: Define Exercise Objectives Mapped to SOC 2 Controls
Start with your System Description and your control list, not with a scenario idea. Pull the exact control language covering continuity, recovery, and incident response, and write three objectives that test those words. This mapping is what turns a team-building session into audit evidence. Document the mapping in a one-page exercise charter: objectives, mapped criteria (A1.2, A1.3, CC7.5), scope boundaries, date, and participant list. That charter becomes page one of your evidence package.
Day 3-4: Build a Realistic BCDR Scenario (Ransomware, Cloud Outage, Data Center Failure)
Pick one scenario, not three. Realism beats drama: the scenario should involve your actual stack, your actual vendors, and a plausible trigger. A ransomware event hitting production, a primary cloud region outage, and the failure of a critical SaaS dependency are the three workhorses, and the sample scenarios later in this article give you starting scripts for each. Adapt a CISA CTEP situation manual rather than writing from scratch; it saves a day, and the discussion questions are field-tested. Resist the temptation to design a scenario your team will handle gracefully. The exercise exists to find gaps, and a scenario everyone aces produces an evidence package auditors find less credible.
Day 5: Draft Injects, Timelines, and Decision Points
An inject is a new piece of information dropped into the scenario mid-exercise: the backup restore is failing, a journalist emails, the attacker raises the ransom. Draft five to eight injects, each tied to a decision you want forced. Sequence them on a timeline covering a compressed incident, typically simulating 24 to 72 hours of real time inside a two-hour session. For each inject, note the decision it should trigger and which objective it serves. If an inject does not force a decision, cut it.
Day 6-7: Stakeholder Alignment and Pre-Read Distribution
Send participants a pre-read pack: the exercise charter, the relevant sections of the BCP and DRP, ground rules, and the date. Do not send the scenario. Participants who know the scenario rehearse answers, and rehearsed answers hide the gaps you are paid to find. This is also the week to lock the calendar. Getting a CTO and two executives into the same two-hour block is routinely the hardest task in the entire playbook, which is why it happens in week one and not week two.
Pro Tip: Book the exercise session
Book the exercise session and the hot wash debrief as a single calendar block with a hard stop. Teams that schedule the debrief "sometime next week" lose half the findings to fading memory, and the scribe's notes alone never capture why a decision felt uncertain in the moment.
Week 2: Facilitation and Execution
Day 8: Kickoff and Ground Rules
Open the session with ten minutes of framing before the scenario starts. State the objectives, the simulated timeframe, and the three ground rules that make tabletops work: this is a no-fault environment where gaps are the goal, participants act on the information in the room rather than inventing convenient facts, and decisions are made as they would be in reality, including saying “I don’t know who owns that.” Record attendance now, with names, roles, and the date. This attendance log is a required evidence artifact, and reconstructing it afterward from memory looks exactly as weak as it is.
Day 9-10: Running the Tabletop Simulation
Run the exercise as a single two-to-three-hour session inside this window. The facilitator reads the opening scenario, then delivers injects at the planned intervals, pushing with questions rather than answers: Who declares the incident? What does the DRP say happens next? Does our RTO survive this? Who tells customers, and when, and using what template? Let silence sit. The uncomfortable pause after “who has access to the backup encryption keys?” is the exercise doing its job. Keep one eye on the clock and skip injects before you rush the final decision points, because the end of the scenario, where restoration and communication decisions land, carries the most SOC 2 weight.
Day 11: Capturing Decisions, Gaps, and Action Items in Real Time
The scribe’s log is the raw material for everything week three produces, so give it structure in advance: a timestamped row per event, recording the inject, the decision made, who made it, what the plan said, and whether reality diverged from the plan. Divergence is not failure; it is the finding. Within 24 hours of the session, the facilitator and scribe should consolidate the log into a draft findings list, while the context is fresh, tagging each item as a plan gap, a tooling gap, a knowledge gap, or a decision-rights gap.
Day 12-14: Hot Wash Debrief and Participant Feedback
A hot wash is the immediate structured debrief, a term inherited from the Homeland Security Exercise and Evaluation Program. Run it for 30 minutes directly after the session or within a day. Ask three questions: what worked, what did not, and what surprised you. The surprises are where the best findings hide. Follow up with a short written feedback form to every participant covering both the scenario content and the exercise design itself; CISA’s participant feedback form template is a solid base. Auditors like seeing feedback forms because they show the exercise was treated as a process to improve, not a checkbox.
Week 3: Documentation, Remediation, and Audit Readiness
Day 15-16: Drafting the After-Action Report (AAR)
The After-Action Report is the document your auditor will actually read, so it earns two full days. Follow the HSEEP-derived structure used in CISA’s AAR/Improvement Plan template: an exercise overview with name, date, duration, scope, and participants; an analysis of each objective stating whether it was met and the evidence from the decision log; strengths observed; and areas for improvement with a root cause for each. Keep it to four to six pages. Write findings factually and without blame: “the escalation contact list contained two departed employees” lands better in an audit file than editorializing about ownership.
Day 17-18: Assigning Remediation Owners and Deadlines
Every finding in the AAR becomes a row in a remediation tracker with a named owner, a due date, a priority, and a status. Unowned findings are the fastest way to turn a good exercise into a bad audit, because an auditor who sees an open finding from eleven months ago with no owner now has evidence that your improvement process does not operate. Prioritize ruthlessly: fix anything touching RTO/RPO achievability or escalation paths within 30 days, and schedule plan-wording cleanups for the next document review cycle. Run the tracker wherever your team already tracks work, whether that is Jira, your GRC platform, or a spreadsheet.
Day 19-20: Updating BCP/DRP Based on Findings
Close the loop by revising the plans the exercise tested. Update contact lists, correct procedure steps that diverged from reality, adjust RTO and RPO figures that proved unachievable, and version the documents with a change note referencing the exercise. This single step satisfies the improvement expectation embedded in CC7.5 and demonstrates the plan-do-check-act cycle that frameworks like ISO 22301, the international business continuity management standard, formalize. If you ever pursue ISO 22301 alongside SOC 2, this same exercise and documentation trail does double duty.
Day 21: Packaging Evidence for Your SOC 2 Auditor
Assemble one folder, clearly dated, containing the exercise charter, the scenario script and injects, the attendance log, the decision log, the AAR, the remediation tracker, the participant feedback summary, and the before-and-after versions of the updated plans. Store it wherever your audit evidence lives and apply your normal retention rules; our guide to SOC 2 evidence retention requirements and timelines covers how long each artifact needs to survive. When fieldwork starts, you hand over one folder instead of excavating Slack threads, and that difference shapes how an auditor reads the rest of your program.
Worth Knowing: Auditors sample remediation
Auditors sample remediation, not just exercises. Expect a request like "show me finding 3 and the ticket that closed it." A tracker where at least the high-priority items show closure dates inside the audit period is worth more than a beautifully formatted AAR with every item still open.
Sample BCDR Tabletop Scenarios for SOC 2
Scenario 1: Ransomware Encrypting Production Systems
Opening: Monitoring alerts show mass file encryption on production servers at 2:40 a.m., and a ransom note demands payment within 72 hours.
Useful injects: backups are intact, but the last verified restore test was eight months ago; the attacker claims to have exfiltrated customer data, turning a continuity event into a breach with notification obligations; a key engineer is unreachable.
This scenario stresses the intersection of the DRP and the IRP, forces the restore-versus-negotiate decision, and tests whether anyone knows the actual recovery time of a full restore rather than the number written in the plan. It maps cleanly to A1.3 and CC7.5.
Scenario 2: Primary Cloud Region Outage
Opening: your primary cloud provider region, whether AWS, Azure, or GCP, suffers a multi-service outage with no estimated restoration time. Useful injects: the status page lags reality by 40 minutes; your failover region works but the database replica is 25 minutes behind, forcing an RPO decision with real data loss; a top customer invokes the SLA in writing. This scenario tests A1.2’s recovery infrastructure claims directly. Many teams discover mid-exercise that their “multi-region” architecture has a single-region dependency nobody documented, often DNS, a CI/CD pipeline, or an authentication provider.
Scenario 3: Key Vendor or SaaS Dependency Failure
Opening: a critical vendor, such as your payment processor, your email delivery service, or your single sign-on provider, announces a security incident and takes its platform offline indefinitely. Useful injects: the vendor’s breach may include your API credentials; customers are asking whether their data is affected; the contract’s termination clause requires 30 days’ notice. This is the scenario most startups skip and the one that increasingly matters, because it exercises vendor risk management (CC9.2 territory) alongside continuity, and third-party failure is now a leading cause of real-world outages. It also produces findings that improve your vendor due diligence process, evidence that serves multiple criteria at once.
Evidence Artifacts to Collect for SOC 2 Auditors
Auditors want a chain, not a pile. Each artifact below answers a specific question in their testing workpapers.
| Artifact | What It Proves | Audit Question It Answers |
|---|---|---|
| Exercise charter with control mapping | The test was designed against stated objectives | Was this recovery plan testing or just a meeting? |
| Scenario script and injects | The test had substance and realistic conditions | What exactly was tested? |
| Attendance log with names, roles, date | The right people participated, inside the period | Who performed the control, and when? |
| Decision log / meeting minutes | The plan was actually exercised against decisions | Did the control operate, not just exist? |
| After-Action Report | Results were analyzed and gaps identified | What did the entity learn? |
| Remediation tracker with owners and closure dates | Findings fed an improvement process | Were deficiencies corrected? |
| Updated BCP/DRP versions with change notes | The plans improved as a result | Is the continuity program a living cycle? |
| Participant feedback forms | The exercise program itself is evaluated | Is testing maturing over time? |
The first six are the core set; treat them as mandatory. Date every document, because for a Type II report the auditor must place the exercise inside the observation period, and an undated AAR triggers follow-up requests that slow fieldwork. The pattern auditors increasingly reject is a green checkmark in a compliance platform backed by nothing samplable; our breakdown of SOC 2 controls auditors reject even when your compliance tool says passing covers why the underlying artifact, not the dashboard status, decides the outcome.
Common Mistakes to Avoid as a First-Time GRC Lead
Five mistakes account for most weak first exercises.
- Running the exercise too close to the audit, with no time to remediate, means the auditor sees fresh findings and zero closures; run it at least a quarter before fieldwork.
- Designing for success rather than discovery produces a thin findings log that reads as theater.
- Skipping executive participation means the hardest decisions, customer communication, and legal notification among them go untested.
- Letting the facilitator also scribe guarantees the decision log misses the most important exchanges.
- And treating the AAR as optional converts three weeks of work into an undocumented meeting, which for SOC 2 purposes is the same as not having done it.
One more that deserves its own sentence: do not let the exercise expand into testing everything. A focused two-hour exercise with three objectives, fully documented and remediated, beats an ambitious half-day event whose follow-through dies in everyone’s inbox.
Important: Never backdate or reconstruct exercise documentation. If you ran a tabletop last year and kept nothing, run a new one now rather than assembling records after the fact. Auditors are professionally trained to spot evidence created at audit time, and a fabricated artifact puts your entire report at risk in a way one missing control never would.
Tabletop Exercise Checklist and Downloadable Template
Use this condensed checklist to track the playbook end to end.
- Confirm BCP, DRP, and IRP exist and name owners, RTOs, and RPOs
- Write three objectives mapped to A1.2, A1.3, and CC7.5
- Select one scenario and adapt a CISA CTEP situation manual
- Draft five to eight injects, each forcing a decision
- Assign facilitator and scribe; invite five to eight participants including executives
- Distribute the pre-read pack without revealing the scenario
- Run the exercise; record attendance and a timestamped decision log
- Hold the hot wash within 24 hours and collect feedback forms
- Draft the After-Action Report within two days of the session
- Log every finding in a remediation tracker with owner and due date
- Update the BCP/DRP and version the changes with a reference to the exercise
- Package all artifacts in one dated evidence folder
The structure above follows the same flow as our SaaS founder’s 6-week SOC 2 readiness plan, where the tabletop slots into the broader readiness timeline as a single owned workstream.
Conclusion: Turning Your First Tabletop Into a Repeatable Program
A first BCDR tabletop exercise, run on this three-week playbook, produces exactly what a SOC 2 audit needs: a mapped, dated, documented test of your recovery procedures with findings that visibly feed improvement. The second exercise is where the real return starts. Rotate scenarios annually, carry forward last year’s remediation tracker to show closure, and graduate toward functional testing, such as an actual backup restore or a failover drill, as the program matures. Teams that treat the tabletop as the first iteration of a continuity program, rather than an audit chore, end up with faster real-world incident response and an Availability section of their SOC 2 report that holds up under any customer’s scrutiny.
Frequently Asked Questions
How often should SOC 2 BCDR tabletop exercises be conducted?
At least annually. The Trust Services Criteria set no fixed frequency, but annual testing is the baseline auditors accept, and most companies’ own continuity policies commit to it. Teams with aggressive availability commitments or recent major infrastructure changes benefit from semiannual exercises.
Do SOC 2 Type I and Type II have different tabletop requirements?
The criteria are identical, but the evidence burden differs. A Type I report assesses control design at a point in time, so a documented plan and a scheduled testing process can suffice. A Type II report tests operation over the observation period, so the exercise must have actually occurred, with dated evidence, inside that window.
Who should participate in a SOC 2 BCDR tabletop exercise?
The people who would make real decisions in a real incident: the infrastructure or engineering lead, the CTO or equivalent, the owner of customer communication, and whoever handles legal and contractual notifications. Five to eight participants is the practical range for a first exercise, plus a dedicated facilitator and scribe.
Can a tabletop exercise replace a full DR test for SOC 2?
Sometimes, and this is where teams get caught. If your documented control says you test recovery procedures through an annual exercise, a well-documented tabletop satisfies it. If your control language promises backup restoration testing or failover testing, a discussion cannot evidence a technical restore, and you need the functional test as well. Your own control wording, not the framework, sets the bar.
What's the difference between a tabletop and a functional exercise?
A tabletop is discussion-based: participants talk through decisions against a scenario without touching systems. A functional exercise actually performs recovery steps, such as restoring a database from backup or failing over to a secondary region. NIST SP 800-84 treats them as complementary stages of one exercise program, and mature SOC 2 programs run both.
How long should a BCDR tabletop exercise last?
Two to three hours for the session itself, which is enough to simulate a 24-to-72-hour incident through five to eight injects. Shorter sessions rush the decision points that matter most; longer ones lose executive attention. The full effort, including planning and documentation, runs about 20 to 30 facilitator hours across three weeks.
What evidence do SOC 2 auditors look for in tabletop exercises?
A dated chain: the exercise charter with objectives mapped to criteria, the scenario and injects, an attendance log, the decision log, the After-Action Report, a remediation tracker showing owners and closures, and updated plan versions. Auditors sample the chain end to end, so a missing remediation record undermines an otherwise complete package.
