Controls4 May 2026 7 min read

SOC 2 Backup Controls: RTO, RPO, and Evidence

Build SOC 2-compliant backup controls. Define RTO and RPO, configure automated AWS backups, test restoration, and collect the evidence auditors need for availability criteria.

Key Takeaways

SOC 2 Availability criteria A1.2 requires that capacity and backup processes meet defined RTO and RPO commitments.
AWS Backup provides centralized backup management for RDS, EC2, S3, DynamoDB, EFS, and more.
Backup restoration must be tested at least annually — untested backups don't satisfy A1.2.
Backup retention should be at least 30 days for production databases.
Cross-region or cross-account backup copies protect against regional outages and ransomware.

In this guide

Backup Controls and SOC 2 Availability
Defining RTO and RPO
AWS Backup Configuration
Cross-Region and Cross-Account Copies
Backup Restoration Testing
Backup Evidence Checklist

Backup Controls and SOC 2 Availability

If your SOC 2 report includes the Availability trust service category, backup controls are a direct requirement. Even if you only report on Security, backup is relevant to CC9.1 (business continuity) and is expected as a best practice control.

The AICPA Availability criteria A1.2 requires: "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." Backup and recovery are not optional — they are a defined criterion.

Defining RTO and RPO

Recovery Time Objective (RTO) is the maximum time the system can be unavailable after a failure. Recovery Point Objective (RPO) is the maximum amount of data loss acceptable (measured in time — e.g., RPO of 1 hour means backups must be at most 1 hour old).

Define your RTO and RPO in your system description and backup policy. Typical values for B2B SaaS: RTO of 4-8 hours for a complete regional outage, RPO of 1-24 hours depending on data criticality. Ensure your backup frequency and retention support your RPO — daily backups can't achieve an RPO of 1 hour.

For RDS with Point-in-Time Recovery (PITR) enabled, your RPO is 5 minutes (the frequency of transaction log backups). PITR allows restoring to any second within the retention period. This is the gold standard RPO for relational databases.

AWS Backup Configuration

AWS Backup provides centralized, policy-driven backup management for all major AWS services. Create a backup plan: AWS Backup console > Create backup plan > Start from template or build new.

Configure backup rules: backup frequency (daily, hourly), backup window (time of day), lifecycle (move to cold storage after X days, delete after Y days), and enable backup vault lock for immutable backups. Create a backup vault with customer-managed KMS encryption.

Assign resources to the backup plan: select by tag (recommended — tag all production resources with "Backup: true"), or by resource type. Apply the plan to RDS instances, EC2 instances (EBS volumes), S3 buckets (versioning as backup), DynamoDB tables, and EFS file systems.

Enable the backup vault lock feature to prevent deletion of backups within the retention period — this protects against ransomware that targets backup deletion.

Cross-Region and Cross-Account Backup Copies

Backups stored only in the same region as production are vulnerable to regional outages — an AWS regional failure could affect both production and backups simultaneously. Configure cross-region copy in your backup plan to copy backups to a secondary region.

Cross-account backup copies provide even stronger protection: a ransomware attack or insider threat that compromises your primary account cannot access backups in a separate AWS account with separate IAM credentials. Configure a dedicated backup account with no production access, and copy critical backups there daily.

AWS Backup Vault Lock in the backup account prevents any IAM principal — including root — from deleting backups before the retention period expires. This is the highest level of backup protection and demonstrates a mature CC9.1 business continuity program.

Backup Restoration Testing

A backup that has never been tested is not a control — it's a hope. SOC 2 auditors expect evidence that backups were actually tested during the audit period. Perform a restoration test at least annually; quarterly is better for critical databases.

The test procedure: restore the most recent automated backup of your production database to a new, isolated instance in a non-production environment. Verify data integrity (row counts, sample queries, application connectivity test). Measure the time from initiating restoration to confirming data integrity — this is your actual RTO. Document the results: restoration date, backup date used, time to restore, data integrity result.

For a complete DR test, also restore your application stack (not just the database) and verify end-to-end functionality. This tests your full RTO including application recovery, not just database recovery.

Backup Evidence Checklist

(1) Backup policy document defining scope, frequency, retention, and RTO/RPO commitments. (2) AWS Backup plan configuration screenshot. (3) Backup vault contents showing recent backups with ages and types. (4) Cross-region copy configuration. (5) Backup vault lock configuration (if enabled). (6) Restoration test record: test date, backup used, restoration time, data integrity verification, tester name. (7) AWS Backup compliance report showing all protected resources and job success rates.

Frequently Asked Questions

Does RDS automated backup satisfy the backup requirement, or do we need AWS Backup too?

RDS automated backups satisfy the RDS backup requirement. AWS Backup is valuable when you need to centralize backup management across multiple resource types (RDS, EC2, DynamoDB, EFS), enforce backup policies via tags, create cross-account copies, and generate compliance reports. For a simple single-database environment, RDS automated backups configured directly are sufficient.

How long should we retain database backups for SOC 2?

SOC 2 doesn't mandate a specific retention period — your own RTO/RPO commitments and regulatory requirements drive this. Best practice for B2B SaaS: 30 days hot (immediate restore), 90 days warm (1-day restore from cold storage), 7 years archival (for regulatory purposes). Configure RDS backup retention to 30-35 days.

Do S3 versioning and S3 Replication count as backup controls?

S3 versioning satisfies the backup requirement for S3 buckets — you can recover any overwritten or deleted object. Enable versioning on all production S3 buckets. S3 Cross-Region Replication can satisfy the cross-region copy requirement if configured with replication time control. Both should be documented in your backup policy.

What if our restoration test fails?

A failed restoration test is valuable information — it means you found the gap before a real disaster did. Document the failure, identify the root cause, fix the backup configuration or restore procedure, and run the test again. Record both the failure and the successful re-test. This demonstrates a mature, problem-solving backup program.

Is daily backup sufficient, or should we do continuous backup?

This depends on your RPO. If your RPO is 24 hours, daily backup is sufficient. If your RPO is 1-4 hours, you need more frequent backups or PITR. RDS PITR achieves a 5-minute RPO with no additional configuration complexity. For most B2B SaaS companies, PITR-enabled RDS with daily automated backups provides excellent coverage.