SOC 2 Availability Without a Second Data Center: Meeting A1 on a Single Site

SOC 2 availability asks a company to meet the availability commitments it makes to customers, and the criteria (A1.1, A1.2 and A1.3) name no second data center, load balancer or automatic failover. A company running in one data center meets them by stating its uptime, RTO and RPO commitments, then showing capacity monitoring, backup and recovery infrastructure, and recovery tests that meet those numbers.

In one SOC 2 audit that included Availability, the client ran production in a single facility with no high-availability pair. Its recovery design was a documented, tested manual procedure to stand up a replacement server quickly, and that procedure met the availability objectives the company had stated. The auditor's first request was evidence of a second region, failover and load balancers. The answer was an explanation of the design against the criteria, in terms an auditor can test.

What Do the SOC 2 Availability Criteria Require?

The SOC 2 availability criteria are three additional criteria in the AICPA Trust Services Criteria, and each one ends with the same test: meeting the entity's objectives.

• A1.1: 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.
• A1.2: The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data backup processes, and recovery infrastructure to meet its objectives.
• A1.3: The entity tests recovery plan procedures supporting system recovery to meet its objectives.

The objectives are the company's own. The AICPA description criteria ask the system description to state the principal service commitments and system requirements, and for Availability those are the uptime, RTO and RPO the company promises. The full list of Trust Services Criteria covers the common criteria that apply alongside A1.

Does SOC 2 Availability Require High Availability or a Second Data Center?

SOC 2 availability is met by a recovery design that meets the stated commitments, and high availability is one such design among several. The A1.2 point of focus closest to a second site, Implements Alternate Processing Infrastructure, reads: Measures are implemented for migrating processing to alternate infrastructure in the event normal processing infrastructure becomes unavailable. A tested procedure that rebuilds the service on replacement hardware from offsite backups can serve as that measure.

Points of focus are guidance for evaluating a criterion, and a criterion can be met without a control for every point of focus. The other nine A1.2 points of focus cover environmental threats and alerts, data backup and offsite storage.

SOC 2 Availability Criteria Mapped to Single-Site Evidence

The table below maps each SOC 2 availability criterion to the evidence a company in one data center can produce.

Facility-level power, cooling and fire suppression are the colocation provider's controls. Under the carve-out method, the system description names the facility as a subservice organization and the annual review of its report becomes your evidence; the guide to SOC 2 vendor management for data centers covers that review. Backup tooling, offsite transfer and restore cadence for on-prem systems are covered in the SOC 2 backup and disaster recovery guide for on-prem.

How One Bare-Metal SaaS Company Meets a 15-Minute RPO on a Single Site

One bare-metal SaaS company we work with meets a 15-minute RPO from a single site with three mechanisms:

• Binary log backups every 15 minutes plus a daily full backup, streamed to object storage. Point-in-time recovery from the last full backup and the binary logs gives the 15-minute RPO.
• Append-only backups for critical data paths, so backups already written stay intact even if a production host is compromised.
• Process supervision that restarts failed services within about a minute, which handles routine process crashes and keeps the rebuild procedure for hardware or site loss.

Each mechanism produces evidence on its own: backup job logs for A1.2, supervisor restart logs and alerts for monitoring, and restore tests for A1.3.

How to Word a SOC 2 Availability Commitment

A SOC 2 availability commitment states an uptime target, a measurement period, an RTO and an RPO that the company has tested. The same numbers belong in customer contracts or SLAs, the system description and the business continuity plan.

Check the numbers against each other before publishing them. A 99.5% quarterly target allows about 10.8 hours of downtime per quarter, so one full 4-hour recovery fits inside it. A 99.9% monthly target allows about 43 minutes, which a manual rebuild is unlikely to meet. Set the RTO from a measured recovery test plus a margin for staff call-out and troubleshooting.

How to Explain a Single-Site Availability Design to a SOC 2 Auditor

A single-site availability design is easiest to explain to a SOC 2 auditor as a chain from commitment to evidence. In the single-site audit where the auditor asked for a second region and load balancers, the explanation covered four points:

1. The commitment. The organization had defined its availability requirement and documented it.
2. The risk. The risk assessment recorded the availability risks and the recovery approach chosen for each.
3. The design. A documented manual procedure stands up a replacement server and restores the service from backups.
4. The test. A dated test of that procedure showed it met the stated availability objectives.

That chain gives the auditor something to test against A1.2 and A1.3. A request for load balancers and a second region tests one particular design; the criteria test whether the chosen design meets the stated objectives. Raise the design at the planning meeting, before fieldwork, so the auditor's test plan matches it. The SOC 2 risk management guide for hybrid and on-prem environments covers how to record the risk and the decision.

What a SOC 2 Recovery Test Record Contains

A SOC 2 recovery test record is the evidence auditors sample for A1.3, and it needs enough detail to compare results to the RTO and RPO. A complete record contains:

• Test date, scenario (for example, loss of the primary database server) and systems in scope
• Participants and the person who approved the results
• Backup used, with its timestamp
• Start time, service-restored time and the measured recovery time against the RTO
• The last recovered transaction time and the measured data loss against the RPO
• Integrity and completeness checks: row counts, checksums or application smoke tests (point of focus A1.3-2)
• Issues found, follow-up tickets and the plan or runbook changes made

The guide to SOC 2 evidence collection on-prem covers producing dated evidence for systems a GRC platform cannot read.

When a Second Data Center Is Worth It for SOC 2 Availability

A second data center is worth it when customers or the RTO demand one, and SOC 2 Availability becomes simpler to add once it exists. With two data centers and failover, most of the Availability work is evidence of replication and failover tests. With one, the work shifts to commitments, recovery testing and evidence.

Plan a second site when:

• Customer contracts require geographic redundancy or a named second region.
• The RTO approaches zero, or the uptime target allows minutes of downtime per month.
• The risk assessment ranks loss of the facility as high for your location or provider.
• Recovery tests keep exceeding the RTO, after the faster rebuild options are used up.

Until then, a single site with offsite backups and a tested rebuild can meet the criteria. The CC9.1 business disruption guide covers the risk mitigation side, and the CC7.5 incident recovery guide covers recovery after security incidents.

SOC 2 Availability on a Single Site Comes Down to Commitments, Tests and Evidence

SOC 2 availability rewards a company that promises what it can deliver and proves it. A written commitment, offsite backups and a dated recovery test that meets the RTO and RPO give an auditor what A1 asks for, and give customers an availability promise they can rely on in procurement reviews. The SOC 2 for bare metal and on-prem infrastructure page lists the other controls that change when you run your own hardware.

More on-prem SOC 2 guides: the full on-prem security program checklist, five things that slow down on-prem SOC 2 and Processing Integrity for compute providers.

Frequently Asked Questions

Does SOC 2 availability require high availability?

No. The SOC 2 availability criteria require recovery that meets the company's own availability commitments. High availability with automatic failover is one way to meet them. A documented, tested procedure to rebuild service on replacement hardware from offsite backups can also meet A1.2 and A1.3 when its measured recovery time and data loss are within the stated RTO and RPO.

Do we need two data centers for SOC 2?

SOC 2 works with a single data center. The Security criteria apply to the system wherever it is hosted, and the Availability criteria ask for backups, offsite storage, recovery infrastructure and tested recovery that meet your commitments. A second data center becomes necessary when customer contracts require it or the RTO is too short for a rebuild.

What RTO does SOC 2 require?

SOC 2 sets no RTO or RPO. The company defines them as part of its availability commitments and system requirements, and the auditor tests whether controls meet them. Set the RTO from a measured recovery test plus a margin, and use the same number in contracts, the system description and the business continuity plan.

What uptime percentage does SOC 2 require?

SOC 2 sets no uptime percentage. The company states its own target, such as 99.5% per quarter, in its commitments, and A1.1 capacity monitoring and A1.2 recovery controls support it. Check that one full recovery at the stated RTO fits inside the downtime the target allows for the measurement period.

Should we include Availability in our first SOC 2?

Include Availability in a first SOC 2 report when customers ask for it or contracts carry uptime SLAs. Many first SOC 2 reports cover Security only. Availability adds criteria A1.1 to A1.3, so the company needs written commitments, backup evidence and a recovery test before the observation period starts. The SOC 2 scoping guide covers the category decision.

How often must we test disaster recovery for SOC 2?

The Trust Services Criteria set no testing frequency for A1.3. In our experience, auditors expect at least one full recovery plan test per year, and many companies run backup restore tests quarterly. Test again after significant changes, such as new hardware or a facility move, and keep a dated record of each test.

Does our colocation provider's SOC 2 report cover the Availability criteria?

A colocation provider's SOC 2 report covers its facility controls, such as power, cooling, fire suppression and physical security, when its report includes them. Under the carve-out method, your report names the provider as a subservice organization. Servers, backups, recovery procedures and recovery tests remain your controls.

Is a tabletop exercise enough for SOC 2 A1.3?

A tabletop exercise supports A1.3 and works best alongside a technical restore. A1.3 includes a point of focus on testing the integrity and completeness of backup data, which requires restoring data and checking it. A strong record pairs an annual tabletop with restore tests that measure recovery time and data loss.