Why this matters
SOC 2 tests whether your controls work. If availability is in scope, the auditor looks for a continuity plan, recovery targets and records from tests. A report that covers security only still expects incident recovery under the common criteria.
Business continuity covers people, office access, vendors and customer communication, beyond servers. A cloud region failure, ransomware or the loss of a lead engineer tests the same question: who decides what happens next, and in what order? A plan written only for the audit is easy to spot because no one has used it and no test records exist.
Your customers read the report. The plan should guide a real outage, so audit evidence comes as a byproduct instead of a scramble.
Before you start
Start with an inventory. List the systems inside the report boundary, the data stores they use, the third parties they call and the internal tools your team needs. Pull the architecture diagram and cloud account list. Give every item an owner.
Run a business impact analysis. For each service, ask what happens after one hour, one day and one week of downtime. Set a recovery time objective and a recovery point objective for each tier. Authentication and the core API need tight targets. The internal wiki can wait. Get the numbers signed off by the service owner.
Choose where the plan lives. It must be readable when SSO is down or the office is closed. Keep a printed copy or an offline vault. Name an incident commander, a communications lead, a technical lead and a scribe, plus a deputy for each role. Collect backup exports, vendor SOC 2 reports and contract terms for recovery support.
How to do it
Write the plan around scenarios, not a generic outline. Cover loss of a cloud region, data corruption, ransomware, a key vendor outage and loss of a critical person. For each scenario, state the trigger, the first three actions and the person who owns them.
Set the recovery sequence. Identity, networking and the data store come before reporting and internal tools. Document manual workarounds for the first hours, such as a static status page or read-only mode.
Document communications. Include an out-of-band channel that does not depend on the production identity provider, customer status page templates, vendor escalation numbers and a call tree. Keep the call tree current.
Design recovery to meet the targets. Use backups with tested restores, cross-region copies where the target demands it and infrastructure as code to rebuild. If a target cannot be met, record the gap and who accepts it.
- List in-scope systems and dependencies. Pull the systems, data stores, vendors and people that support each service in the report. Note the owner and the upstream dependency for each item. This list feeds the impact analysis.
- Set RTO and RPO per service. Ask each service owner what one hour, one day and one week of downtime means for the business. Turn the answer into a recovery time objective and a recovery point objective. Record the sign-off.
- Choose recovery methods that fit. Match each tier to backup restore, cross-region copy, infrastructure as code rebuild or a manual workaround. Write the expected recovery time for each method. If it cannot meet the target, note the gap.
- Assign incident roles and deputies. Name an incident commander, communications lead, technical lead and scribe. Give each role a deputy and a way to reach them offline. Put decision authority in writing.
- Write short scenario playbooks. Create a page for region loss, data corruption, ransomware, vendor outage and key person loss. State the trigger, first actions, recovery sequence and decision owner. Keep each playbook short enough to use under pressure.
- Document communications and vendor contacts. Set an out-of-band channel, customer status templates and vendor escalation numbers. Include who approves customer messages. Test the channel during the exercise.
- Run a tabletop and a restore test. Walk the team through one scenario and time the decisions. Restore one critical system to an isolated account and check the application. Compare both results with the plan.
- Log gaps and assign fixes. Turn every missing contact, failed restore and slow decision into a ticket with an owner and a date. Link tickets to the test record. Retest the fixed item.
- Review the plan on a schedule. Review the plan at least once a year and after major architecture or vendor changes. Update targets, contacts and recovery steps. Keep the old test records.
How to check it worked
Run a tabletop exercise at least once a year. Pick one scenario, gather the named roles and walk through the first four hours. The scribe records decisions, timestamps and missing information. The output is a list of fixes, not a pass or fail mark.
Test a real restore. Choose one critical system, restore its data to an isolated account and bring up the application. Measure the time from the go decision to a successful check. Compare that number with the RTO and RPO. Test a failover and DNS switch if the plan depends on them.
Keep an evidence pack for each test: the plan, attendee list, timeline, restore logs, screenshots and tickets for gaps. Auditors sample these records. A missed target with a dated corrective action and a retest looks better than a perfect plan with no proof.
Check vendor claims against their reports. Read the vendor SOC 2 report for subservice organizations and note whether controls are inclusive or carved out. Map the vendor recovery terms to your own targets. If the vendor cannot support your RTO, change the design.
Mistakes to avoid
A copied template with no impact analysis produces targets nobody can meet. If the plan says four hours but a restore takes a day, the test will expose it. Plans that name a team instead of a person also fail. Name an owner and a deputy, and give them authority to call a failover or notify customers.
A green backup job is not a recovery test. Backups can complete and still fail to restore, especially with databases, encryption keys and application consistency. Test the restore and the application check, rather than job status alone.
Do not store the plan only behind the identity provider it is meant to replace. Keep an offline copy. Do not assume a vendor's disaster recovery is your disaster recovery. Review the plan after any major architecture change, new critical vendor or failed test.
If you want outside help, the SOC 2 readiness assessment from Cloudverg is $7,500/month, fixed scope, three weeks, and includes a remediation roadmap with owners and dates. It is one option among hiring a consultant, using a compliance tool or running the work internally.
Frequently asked questions
What is the difference between a BCP and a DR plan for SOC 2?
A business continuity plan covers people, vendors, facilities, communications and the order of recovery. A disaster recovery plan focuses on technical systems and data. SOC 2 availability evidence often centers on DR tests, but the auditor may still ask for the wider continuity plan.
Does SOC 2 require a business continuity plan?
If availability is in scope, yes, as part of the availability criteria and the related recovery controls. A security-only report still expects recovery from incidents under the common criteria. The plan can be short, but it must be owned and tested.
How often should we test business continuity for SOC 2?
Run a tabletop at least once a year and restore a critical system on a regular schedule. Test again after major architecture changes, new vendors or a failed exercise. Keep dated records of each test and the fixes.