SOC 2 BCDR Tabletop Exercise: A 3-Week Playbook for First-Time GRC Leads
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
