SOC 2 disaster recovery and business continuity: plan and test

For SOC 2, write a short business continuity and disaster recovery plan, make sure backups exist, run a recovery test at least once a year, and record what happened, including what failed. The plan matters less than a dated test that shows you can restore.

Where the criteria point

CC9.1 covers mitigating the risk of business disruption. If you add the Availability category, A1.2 covers environmental protections, backups and recovery infrastructure, and A1.3 covers testing recovery plan procedures. The criteria do not set an uptime number. Your own commitments set the bar.

What the plan should contain

Keep it to a few pages that someone can follow at 3 a.m.

• Scenarios: region outage, data corruption, ransomware, loss of a key vendor, loss of key staff.
• Recovery targets: how long you can be down and how much data you can lose, per system.
• Roles: who declares an incident, who leads recovery, who talks to customers.
• Steps: how to restore from backup, how to fail over if you can, and where the runbooks live.
• Communication: status page, customer email, internal channel, and a backup channel if chat is down.
• Contacts: vendors, auditors, legal.

Choose targets you can meet

Do not promise a tight recovery time unless you have tested it. Measure first, then commit. A realistic number you hit beats an ambitious one you never checked.

Run the test

A tabletop is a start. A real restore is better.

1. Pick a system, for example your main database.
2. Restore the latest backup into a separate environment.
3. Check that the data is complete and the application works against it.
4. Time each step.
5. Write down gaps: missing permissions, stale runbook, slow restore.
6. Open tickets for fixes and close them.

Repeat for other critical systems on a rotation. See also backup and restore testing evidence.

Evidence to keep

• The approved plan with a review date.
• Backup configuration and a record of successful runs.
• The test report with dates, timings and outcome.
• Tickets for remediation and their closure.
• Attendance or sign off from the people involved.

Common mistakes

• A plan that was never tested.
• Backups that exist but live in the same account and failure domain as production.
• Recovery steps that depend on a person who left.
• Skipping the vendor dependency question. If your cloud region fails, what is your plan?

A worked example

A small SaaS team keeps its main database in one cloud region with daily snapshots copied to a second region. They set a target of restoring within four hours with at most one day of data lost. In the test, an engineer restores last night's copy into a scratch environment, runs a data check against known counts, and starts the application against it. The restore takes longer than planned because a permission was missing. They fix the role, update the runbook and repeat a partial test the next week. The report records both runs, the timing and the fix. That story is stronger evidence than a flawless plan nobody has run.

Quick check

Sources

• SOC 2 Trust Services Criteria overview

Last reviewed: 19 October 2026.