SOC 2 Business Continuity and Disaster Recovery Controls

Every SOC 2 report covers CC9.1, which asks the entity to identify, select, and develop “risk mitigation activities for risks arising from potential business disruptions.” A report that adds the Availability category also covers A1.1 to A1.3: capacity, backup and recovery infrastructure, and recovery testing. This guide shows how to tier systems from a business impact analysis, what a completed recovery-test record contains, and what capacity management means in practice. Whether to add Availability at all is a scope decision, covered in SOC 2 Trust Services Criteria.

Which SOC 2 criteria cover business continuity and disaster recovery?

Four criteria cover it. CC9.1 applies to every SOC 2 report. A1.1, A1.2, and A1.3 apply when Availability is in scope: A1.1 covers capacity, A1.2 covers environmental protections, backups, and recovery infrastructure, and A1.3 covers testing of recovery plan procedures. Our controls library maps them to BC-01 through BC-05.

The criteria set no recovery time or recovery point values, no test frequency, no business impact analysis template or number of tiers, no sample sizes, and no uptime figure. Your contracts, your risk assessment, and your auditor’s sampling set those.

The table wording paraphrases the AICPA 2017 Trust Services Criteria with 2022 revised points of focus. Points of focus are guidance, not requirements. The full library is on the SOC 2 controls list. Incident response and recovery from security incidents (CC7.4 and CC7.5) are covered in the SOC 2 security controls guide.

Reports use the 2017 criteria with the 2022 points of focus today. The AICPA’s draft revision, dated 27 October 2026, asks for comments by 15 January 2027. If issued as final, it applies to engagements beginning on or after 31 December 2027, with early implementation permitted. It is a proposal and can change. In the draft, CC9.1 has no counterpart in the common criteria. Its point of focus on planning for business-disruption risk moves to A1.3, “Resilience Capabilities”, and the insurance point does not appear. A1.1 stays A1.1. The 2017 A1.2 splits into A1.2, “Environmental Protections”, and A1.3, which takes backup and recovery, off-site storage, alternate processing and data recoverability. The 2017 A1.3 becomes A1.4, “Resilience & Recovery Testing”. For a Security-only report, the nearest common-criteria point is “Implements Incident-Recovery Plan Testing” under CC6.2, but the draft does not say how such a report would treat business-disruption planning, so ask your CPA firm.

Under the 2017 criteria, when Availability is out of scope, CC9.1 is the whole continuity question. The auditor looks for a continuity plan, an impact analysis, and a recorded decision on insurance. BC-05 covers losing key people, vendors, offices, or systems, a named successor or cross-trained backup for each critical role, and an annual review. The common gap is scope: the plan covers a data center outage but not the one engineer who knows how to deploy, or an outage at a critical vendor. Vendor risk itself falls under CC9.2, covered in SOC 2 vendor management requirements.

The business continuity plan (CC9.1) covers keeping the business running when people, vendors, offices, or systems are lost. The disaster recovery plan (A1.2 and A1.3) covers restoring systems and data. The first sets targets the second must meet: a continuity plan might require customer support back within four hours, and the recovery plan holds the technical steps, such as restoring the ticketing integration, that make four hours achievable. An Availability report needs evidence for both.

How do you set RTO and RPO tiers from a business impact analysis?

A business impact analysis (BIA) lists what the business does, what each process depends on, and what an outage costs over time. Group systems by how long customers and operations can wait, then give each group a recovery time objective (RTO, how long restoration may take) and a recovery point objective (RPO, how much data may be lost, measured in time).

Inputs come from customer contracts, dependency maps, and the risk register; the SOC 2 risk assessment template covers building one. The BIA supports CC3.1, CC3.2, and CC9.1.

Worked example: a 40-person SaaS company

The example assumes a B2B SaaS product on one cloud provider, a multi-zone production environment, a 99.9% monthly uptime commitment in customer contracts, and internal work done in vendor-hosted tools. The targets are examples, not benchmarks.

Tier 1 includes the tools that rebuild it. If recovering the database needs the deployment pipeline and a secrets store, those inherit the Tier 1 RTO. Otherwise the 4-hour target is a number nobody can meet.

Tier 1 must also match the contract. BC-02 in our controls library lists the common gap as recovery targets in customer contracts tighter than the architecture or backup schedule could deliver. A 99.9% monthly commitment allows about 43 minutes of downtime in a 30-day month, and a 4-hour disaster RTO is a separate promise, so check how each contract treats major incidents. The 99.9% figure alone does not mandate any recovery architecture.

Pick the architecture from the targets. The AWS whitepaper on disaster recovery options in the cloud describes four approaches, from backup and restore to multi-site active/active. It says backup and restore may be enough when a disaster means losing one data center for a well-architected, highly available workload, and points to pilot light, warm standby, or multi-site when a disaster means losing a Region or regulation requires more. It also notes that how often you back up sets the recovery point you can achieve. A 5-minute RPO therefore needs continuous log archiving, not a nightly snapshot.

What does a completed disaster recovery test record look like?

A completed record shows what was restored, how long it took against the target, how the result was checked, who ran it, and what was fixed afterward. Control BC-03 in our controls library asks for a dated test, results compared with recovery targets, and tickets for gaps found. This record is the Tier 1 database test from the table above.

Illustrative record. Names, ticket numbers, and figures are invented for the example.

An auditor can recompute this record. The target and the measured result sit side by side, the validation method is stated, and the one gap has a ticket that closed before sign-off. A record that reads “DR test conducted, systems recovered” gives none of that. BC-03 lists the matching common gap: backups run daily but nobody has restored one, so the plan’s recovery times are untested assumptions.

How often should you test recovery, and with what?

A1.3 asks the entity to test recovery plan procedures and sets no frequency. Document a schedule based on risk, recovery targets, customer commitments, and significant changes, and keep proof that you followed it. Our controls library uses an annual recovery test as the BC-03 baseline. Annual is a common policy choice, not an AICPA minimum.

The A1.3 points of focus describe the content of a plan test. Scenarios come from threat likelihood and magnitude, cover components and vendors that can impair availability, consider the loss of key personnel or vendors, and end with plan revisions based on the results. A1.3 also lists periodic testing of the integrity and completeness of backup data.

A tabletop exercise tests people and communication, and a technical test restores systems; the tier table pairs each tier with the one that proves it. For a tabletop, set a measurable objective, such as sending the first customer status update within 30 minutes of a declared incident. Base the scenario on your risk assessment: a cloud provider outage, ransomware, or losing the one engineer who can deploy. Have a facilitator run it and a scribe record decisions and gaps, then produce an after-action report with owners and due dates and link the tickets. For a technical test, record start and end times, as the record above does.

What does A1.1 capacity management require?

A1.1 says the entity “maintains, monitors, and evaluates current processing capacity and use of system components (infrastructure, data, and software) to manage capacity demand and to enable the implementation of additional capacity to help meet its objectives.” In practice you measure use of compute, storage, and database capacity; set thresholds; alert before limits are reached; review needs on a set cadence; and send growth through change management. The points of focus add that forecasts compare average and peak use with capacity and tolerances, and include what happens when a component that constrains capacity fails.

Control BC-04 in our controls library maps to this: dashboards with alert thresholds, plus capacity review notes or tickets recording the action taken, reviewed quarterly. Its common gap is dashboards with no thresholds, so nobody is alerted until customers notice slowdowns. Autoscaling covers part of the criterion. A1.1 also names data and software, so storage growth, database connections, and third-party limits still need an owner and a review record. Uptime itself is measured under BC-06 against what your contracts promise.

What evidence does an auditor sample for Type 1 and Type 2?

A Type 1 report tests design at a point in time: the management-approved business continuity and disaster recovery plans, the impact analysis with recovery targets, the risk assessment behind them, an incident response roster, and the backup configuration. A Type 2 report adds records across the observation period: backup job history with failures followed up, a recovery test dated within the period with results and tickets, and plan reviews after changes. The auditor chooses what to sample, including specific dates in the observation window. Keep backup job logs and alert handling for those dates, not only the annual test. Alert handling is in the CC7.2 row of SOC 2 security controls.

Compliance software that pulls backup logs and configuration from source systems makes the source and date clear; how to choose SOC 2 compliance software covers it. Without one, keep a running test log with named owners and timestamps. For how the documents fit together, see SOC 2 documentation. If you cannot build and test these plans before the audit window opens, SOC 2 readiness firms can help.