Business continuity and backup plan for SOC 2

Your cloud provider's resilience is not your continuity plan. What an auditor wants is your recovery objectives, your backup schedule, and proof you have restored something.

Last reviewed 2026-09-01Written by Jacob Masse, TrazTech Inc.

For a SOC 2 audit, a business continuity and backup plan has to state four things: recovery time and recovery point objectives per system tier, what is backed up and how often, how long backups are retained and where they live, and how you verify a restore actually works. The fourth is the one auditors ask for evidence of, and a configured backup with no tested restore is the most common gap on this control in a first audit.

If you run entirely on a public cloud, most of the classic continuity content does not apply to you. Delete the sections on alternate work sites, generator fuel and data centre failover. What replaces them is a plain statement of what you would do if a region became unavailable, if your database were corrupted, or if a key vendor went down for a day.

What recovery objectives should we commit to?

Tier your systems before you name any numbers. A single set of objectives applied to everything either makes your internal wiki as critical as your production database or lets your database inherit an undemanding target. Three tiers is enough.

The restore test, which is the control that matters

Backups are a configuration. A restore is a control, because it is the only one that proves the configuration works. Write into the plan that a restore is tested at least annually, name what gets restored, and keep a record with the date, who ran it, what was restored, where it was restored to, how long it took and whether the data was verified as correct.

The test does not have to be a full disaster simulation. Restoring the production database to a scratch environment, running a row count and a spot check of recent records, and writing down the elapsed time satisfies both the control and the point of the exercise. What it must not be is a screenshot of a backup job that succeeded, which is evidence of a backup, not of a restore.

Twice a year is better than once, since the first attempt in a new environment usually finds something: a missing permission, an unexpected duration, an encryption key nobody had documented. Doing it once at month eleven means finding that out the week before fieldwork. The timeline page covers where the point-in-time controls like this one sit relative to the observation window.

Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.

What continuity means when you own no hardware

Write your plan around four scenarios that can happen to a cloud company, and say what you would do in each. Cloud provider region failure: whether you fail over, and if you do not, say so and say what the customer impact would be. Data corruption or accidental deletion: point-in-time restore, which is the scenario most likely to occur. Loss of a critical vendor for a day, such as an authentication provider or a payment processor. And loss of key people, which for a small company is a real continuity risk and is worth a paragraph about documentation and shared access.

Be careful with the shared responsibility line. Your provider is responsible for the resilience of its infrastructure. You are responsible for the architecture you built on top, for your backups, and for your configuration. A plan that says "our cloud provider maintains 99.99% availability" and stops there is not a plan, and its accuracy is not something you can evidence anyway.

Does your draft contain these clauses?

0 of 8 done · Reset

• System tiers defined, with each in-scope system assigned to one.
• RTO and RPO per tier, matching what your configuration can actually deliver.
• Backup frequency, storage location and retention period, stated per tier.
• Backups encrypted, and held separately from the primary system.
• A restore test at a named cadence, with what gets restored and who signs it off.
• Named roles for declaring and coordinating a continuity event.
• Scenario responses for region failure, data corruption and vendor outage.
• An annual review date, and a link to the incident response plan for the overlap.

What gets a continuity plan turned into a finding?

"Backups are tested regularly." Cut it. Regularly is not a cadence, and the auditor will ask when the last test was. If the answer is that nobody has run one, the control fails on the spot. Write annually or semi-annually and then run it in the first quarter of the window.

A stated RPO your database cannot meet. The auditor pulls the backup configuration. Nightly snapshots against a one hour RPO is a written commitment contradicted by a screenshot, and it is embarrassing in a way a missing document is not.

Alternate site and pandemic sections inherited from the template. A plan describing a hot site and a battery room for a company with a dozen laptops tells an auditor the document was not written by anyone who works there. It does not fail a control by itself, but it changes how carefully everything else you hand over gets read.

Backups that live inside the blast radius. A backup stored in the same cloud account with the same credentials as production does not survive the scenario most likely to need it. Write down where backups live and how access to them differs, and check that a compromised production credential cannot delete them.

The policy templates page covers editing an inherited pack down to what you run, and the policy checklist will tell you whether you need continuity as a standalone document, which mostly depends on whether you have taken on the availability criterion alongside security.

Common questions