Most companies preparing for an audit have a business continuity plan. Considerably fewer have evidence that they tested it, and almost none have evidence that the test found something. That last part is the one auditors weight most heavily: a business continuity testing record showing everything went perfectly is less convincing than one showing three problems and what you did about them.
The plan is not the deliverable. The documented outcome of exercising it is. Everything below is about producing that outcome without turning it into a two-week project once a year.
What the auditor is actually testing
If your SOC 2 includes the Availability category, the criteria explicitly cover recovery — backup processes, environmental protections, and testing of recovery plan procedures. If you selected only Security, backup and recovery still surface through risk assessment and through the availability commitments you make in customer contracts, but the testing requirement is less pointed. Worth checking which position you are in before scoping the work, because the answer changes how much of this an auditor will press on.
Either way, the questions are the same three. Does a plan exist and was it approved and reviewed during the period? Were recovery procedures actually exercised? And did the exercise produce a measured result you can compare against your stated objectives?
Three different activities that people call the same thing
Being precise here saves arguments later, because auditors will hold you to whichever one your description claims.
Backup restoration testing. You restore data from backup and verify it is usable. This is the narrowest activity and the cheapest to automate. It proves your backups work; it does not prove you can run your service somewhere else.
Disaster recovery testing. You bring the service up in an alternate environment or region, or fail over to standby infrastructure, and measure how long it takes and what breaks. This is the one that tests your architecture.
Business continuity exercise. A tabletop or simulation covering people and process — who declares a disaster, who talks to customers, what happens if the person who knows the failover runbook is unreachable.
Different auditors accept different combinations depending on your scope and risk profile, and a small SaaS company running a fully managed cloud stack has a genuinely different obligation from a company with its own hardware. What is not defensible is describing one activity in your system description and performing another.
Population completeness applies here too
It is less obvious than in access or change testing, but it exists in two places.
The systems your plan covers. If the plan says it covers all production systems and you tested one database, the auditor has evidence for one system and a claim about the rest. Either narrow the plan’s stated scope to what you test, or broaden the testing. The mismatch is what produces the exception.
The inventory of what is actually backed up. The primary application database is nearly always backed up. The things that get missed are the ones nobody thinks of as data: configuration stores, secrets managers, object storage buckets holding customer uploads, the analytics warehouse, CI configuration, and infrastructure-as-code state files. Reconcile your backup configuration against a list of your data stores pulled from the cloud provider rather than from memory. Anything in the second list and not the first is either a deliberate decision you should record or a gap.
The reason this matters in the same way it matters elsewhere: if the auditor selects a system to examine backup evidence for, they select from the population you supply. A population that quietly omits the unbackedup store gives false comfort to everyone, including you.
What a test record needs on it
A defensible test record contains:
- Date and duration, with start and end timestamps
- Scope — which systems, which data, which environment
- The objective stated in advance, including the recovery time and recovery point objectives you are testing against
- Method — full restore, failover, partial restore, or tabletop, stated plainly
- Participants and their roles
- The measured result — actual recovery time against RTO, actual data loss against RPO
- Verification — proof the restored data was correct, not just that the restore job reported success
- What went wrong — the issues encountered, however small
- Corrective actions with owners, due dates, and evidence of completion
- Sign-off by whoever your plan says owns it
The verification step is the one most often missing. A restore job exiting zero tells you the mechanism ran. Running a row count, a checksum, or a smoke test against the restored copy tells you the data is usable. Auditors increasingly ask how you knew the restore was good, and “the job succeeded” is a thin answer.
The RTO trap
Here is a self-inflicted exception worth avoiding. Your policy states a four-hour recovery time objective, because four hours sounded appropriately serious when someone wrote it. Your test measures eleven hours. You have now documented a failure against your own commitment, and if the same four hours appears in customer contracts, the problem is larger than the audit.
Set objectives you can meet, test against them, and tighten them as your architecture improves. An honest twenty-four hour RTO that you consistently beat is a stronger position than an aspirational four-hour RTO you miss. If a customer contract already commits you to something you cannot demonstrate, that gap is worth surfacing internally now rather than discovering it in an incident.
Failure modes
Testing into a vacuum. A restore into an empty scratch environment with no verification proves the backup file is readable and little else.
Cloud redundancy treated as a DR plan. Running across multiple availability zones is good architecture and it is not a tested recovery procedure. It also raises a separate question: your hosting provider is likely a subservice organization, and reliance on their controls comes with complementary controls you are expected to operate.
The single-engineer dependency. One person knows how to execute the failover, and they ran the test. A useful variation is to have someone else follow the runbook while the expert stays quiet. The gaps that exercise finds are the real ones.
Plan not reviewed in the period. The document was approved two years ago, references an office you have left and a phone tree of former employees. Reviewing and re-approving the plan annually is cheap and directly testable.
Corrective actions left open. The test found three issues, they were written down, and nothing happened. This converts a good test into evidence of a weak follow-through process.
No test at all, because the year was busy. There is no recovery from this one inside the period. If your window closes in three weeks and you have not tested, the exception is already written.
How often, and how to make it routine
Annual is the common baseline for a full exercise, with higher-criticality systems tested more often. Practice varies by firm and by the availability commitments you have made, so agree the expectation with your auditor rather than assuming.
The pattern that costs least is to split the work by frequency. Automate restore-and-verify as a scheduled job: restore the most recent backup into an isolated environment, run integrity checks, write the result and the elapsed time to a log or a ticket, and alert on failure. That produces continuous, system-generated evidence across the whole period, which is far stronger than a single annual screenshot, and it catches silent backup failures within days instead of within a year.
Then run one larger exercise annually using a fixed template so the write-up is a form to fill rather than a document to compose. Corrective actions go into the normal engineering backlog as tickets, where they get the same visibility as everything else.
What to do next
Answer one question honestly: if your primary database were unrecoverable this afternoon, how long would it take to serve customers again, and how do you know? If the answer comes from architecture diagrams rather than from a timestamped test, that is the work.
Then check your backup configuration against a list of every data store in your cloud account. The gap between those two lists is usually the most useful thing you will find this quarter.
Assurion performs SOC 2 examinations including the Availability criteria and can tell you during readiness whether your recovery evidence will support the commitments you have published.