The entity provides for data backup, recovery, and offsite storage

SOC 2 Availability criteria expect you to prevent extended downtime and limit data loss during incidents that affect systems, infrastructure, or people. TSC-A1.3 is one of the most operationally concrete requirements: you must back up, recover, and store backups offsite. That combination is deliberate. Backups without validated recovery are theater. Recovery without offsite storage fails during ransomware, cloud account compromise, or regional outages. Offsite storage without access control and retention discipline becomes a data sprawl risk.

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing this requirement is to convert it into a small set of exam-ready questions: What is “in scope”? What are our recovery objectives? Which backup methods do we use per platform? Where are backups stored, and is that location truly separate? How do we know restores work, and how often do we prove it?

This page gives requirement-level implementation guidance you can hand to Infrastructure, Security, and Application owners and then audit internally. It focuses on artifacts, evidence, and common failure modes SOC 2 auditors flag, based on the requirement wording in the AICPA Trust Services Criteria. ¹

Regulatory text

Requirement (TSC-A1.3): “The entity provides for data backup, recovery, and offsite storage.” ¹

Operator interpretation (what you must do):

1. Back up in-scope data and system configurations on a defined schedule that aligns to business recovery needs.
2. Store backups offsite in a way that remains available during primary-site failure and is resilient to common attack paths (for example, compromised admin credentials in the primary environment).
3. Be able to recover by restoring from backups, and demonstrate that capability with repeatable testing and evidence.

Auditors typically treat this as both a design requirement (you have a backup/recovery approach and roles) and an operating effectiveness requirement (it runs consistently, and restores succeed). ¹

Plain-English interpretation of the requirement

You need a backup program that answers four questions with evidence:

• What is protected? (systems, databases, object stores, endpoints, SaaS data, and critical configuration)
• How is it backed up? (method, frequency, retention, immutability where needed)
• Where is it stored? (offsite separation that survives the primary failure scenario)
• Can you restore? (tested recovery that meets your defined targets)

If you can’t prove restores, expect a control deficiency even if backups exist.

Who it applies to (entity and operational context)

This requirement applies to service organizations undergoing SOC 2 where Availability is in scope, and it is especially relevant if you:

• Host customer workloads or customer data
• Depend on cloud infrastructure (IaaS/PaaS), managed databases, or containers
• Operate production systems requiring continuity after ransomware, operator error, or outages
• Provide time-sensitive services where downtime or data loss creates contractual risk

Operationally, it touches:

• Infrastructure/Cloud Ops (backup platforms, storage, IAM, KMS)
• Security (ransomware resilience, access control, monitoring)
• Application and Data owners (what needs backup, restore runbooks)
• IT (endpoint backups if endpoints hold critical data)
• Third parties (backup providers, managed service providers, cloud providers)

What you actually need to do (step-by-step)

Step 1: Define scope and classify what must be recoverable

Create an inventory of in-scope systems and data repositories. Tie each to a service/process and data type (customer data, logs, configs, secrets, artifacts).

• Include “non-obvious” items: encryption keys (or key recovery strategy), infrastructure-as-code repos, CI/CD artifacts, SaaS platforms that are system-of-record.
• Decide what is explicitly out of scope and why (document it).

Deliverable: Backup & Recovery Scope Register (system, owner, environment, data types, dependencies).

Step 2: Set recovery objectives and minimum backup standards per tier

For each system, assign:

• RPO (Recovery Point Objective): maximum acceptable data loss window (your business decision).
• RTO (Recovery Time Objective): maximum acceptable time to restore service (your business decision).
• Backup frequency/retention: aligned to RPO and legal/contractual needs.
• Restore method: full restore, point-in-time restore, file-level restore, image restore, etc.

Keep it practical: tier systems (critical, important, supporting) and standardize targets per tier.

Deliverable: Recovery Objectives Matrix (system tier → RPO/RTO → backup method).

Step 3: Implement backups with secure configuration and monitoring

For each platform, ensure:

• Automation: scheduled backups or continuous replication where applicable.
• Coverage: databases, object storage, file systems, and configs. For SaaS, confirm whether you have native backup/export or a third-party backup.
• Encryption: in transit and at rest via platform controls.
• Access control: least privilege; separate backup admin roles from day-to-day operators where feasible.
• Monitoring/alerting: backup job success/failure alerts; storage capacity alerts; anomaly detection where available.

Operational check: If an attacker compromises a production admin, can they delete or encrypt your backups?

Deliverables: Backup configuration baselines, monitoring rules, and alert routes.

Step 4: Design “offsite” so it survives your likely failure modes

“Offsite” should mean separation from the systems being backed up. Common acceptable patterns:

• Separate cloud account/subscription/tenant for backup storage
• Separate region paired with restricted cross-account access
• Separate provider (where risk and complexity justify it)
• Offline or immutable storage options for ransomware resilience

Define “offsite” in your policy and document your separation design. If your offsite storage is still deletable by the same admin path as production, expect auditor pushback.

Deliverable: Offsite Storage Architecture Note (what is separate, how access is controlled, how deletion is prevented or constrained).

Step 5: Build recovery runbooks that match your real architecture

Create system-specific runbooks that include:

• Preconditions (credentials, break-glass, access approvals)
• Restore steps (commands/console steps)
• Dependencies (DNS, IAM, networking, keys)
• Validation (data integrity checks, service health checks)
• Communication steps (incident updates, customer comms triggers)

Deliverable: Recovery runbooks stored in a controlled repository with versioning.

Step 6: Test restores and retain test evidence

Plan restore tests that prove:

• You can restore data and service components
• You can meet internal recovery targets (or document gaps and remediation)
• Your runbooks are accurate

Tests can be tabletop plus technical restore, but you need at least periodic technical restores for key systems because TSC-A1.3 is about capability, not intention. ¹

Deliverable: Restore Test Reports (scope, date, operators, steps executed, results, issues, remediation tickets).

Step 7: Operationalize governance (ownership, exceptions, change management)

Define:

• Control owner and delegates
• Review cadence for backup job reports and failures
• Exception process (with time-bound remediation)
• Change management linkage (new systems require backup onboarding)

Tools like Daydream can help you keep the scope register, evidence requests, and restore test artifacts tied to the requirement, so audits don’t become a “find screenshots in Slack” drill.

Required evidence and artifacts to retain

Keep evidence aligned to “design” and “operate”:

Design artifacts

• Backup & Recovery Policy/Standard referencing backup frequency, retention, offsite definition, encryption, access control ¹
• Scope Register and Recovery Objectives Matrix
• Offsite storage design documentation (diagram + narrative)
• Runbooks and role assignments (RACI)

Operating evidence

• Backup job logs/reports (success/failure summaries)
• Alerting tickets/incidents for failed backups and remediation
• Access reviews for backup admin roles (or equivalent authorization evidence)
• Restore test reports and resulting remediation tickets
• Evidence of offsite replication/retention settings (screenshots, configs, or exported settings)

Auditor preference: time-stamped exports and tickets over one-off screenshots.

Common exam/audit questions and hangups

Expect variations of:

• “Show me the system list in scope and how you ensure new systems get backed up.”
• “Where are backups stored, and how is that offsite?”
• “Who can delete backups? Show IAM controls and any immutability settings.”
• “Provide evidence of restore testing for a production-relevant system.”
• “What happens if the primary cloud account is compromised?”

Hangups that slow audits:

• Offsite defined loosely (“another bucket”) without separation proof
• Restore tests are tabletop-only with no actual restore output
• Backups exist for databases but not for critical configuration (IaC, secrets, build artifacts)
• Evidence isn’t retained consistently across the audit period

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails in SOC 2	Avoid it by
Backups run, but no restore testing	No evidence you can recover 1	Schedule technical restores for tier-1 systems; store test reports
“Offsite” is same account with shared admin roles	Ransomware/account takeover deletes backups	Use separate account/tenant and tightly scoped cross-account access
Retention is undefined or ad hoc	Can’t show coverage and consistency	Set standard retention bands and document exceptions
Only production is covered	Config drift and missing non-prod dependencies block recovery	Back up critical configs and artifacts across environments as needed
Evidence scattered across tools	Audit becomes manual and error-prone	Centralize evidence collection and mapping (Daydream or your GRC system)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so don’t anchor your program on enforcement anecdotes.

Risk is still concrete:

• Availability risk: inability to restore service in an outage.
• Integrity risk: incomplete or inconsistent restores create data integrity issues.
• Security risk: backups become a ransomware target; weakly protected backups can be encrypted or deleted.
• Customer/contract risk: missed recovery expectations can trigger SLA penalties or escalations, even if not regulatory.

Treat backup and recovery as a resilience control with direct customer impact, then document it as a SOC 2 control with audit-ready evidence. ¹

Practical 30/60/90-day execution plan

Days 1–30: Get to “defined and scoped”

• Assign a control owner (Security or Infrastructure) and name system owners for top services.
• Build the Scope Register for all in-scope production systems and primary data stores.
• Define RPO/RTO tiers and map each system to a tier.
• Document what “offsite” means for your environment and choose a separation pattern.
• Draft/refresh Backup & Recovery Policy and standard.

Exit criteria: You can explain, on one page, what is backed up, where it goes, who owns it, and the recovery targets. ¹

Days 31–60: Implement coverage and offsite separation

• Remediate coverage gaps (missing databases, object stores, configs).
• Implement or tighten offsite storage separation and backup admin access controls.
• Turn on monitoring and route backup failures into ticketing with ownership.
• Write runbooks for tier-1 systems and at least one tier-2 system.

Exit criteria: Backups run on schedule, alerts create tickets, and offsite storage has documented separation and access controls.

Days 61–90: Prove recovery and make it auditable

• Execute restore tests for tier-1 systems; capture outputs and validation steps.
• Log issues as remediation tickets and re-test after fixes.
• Run an internal evidence review: can you produce artifacts across the period without recreating them?
• Implement a monthly control check: backup success review + exceptions log.

Exit criteria: You can hand an auditor a restore test report, the underlying logs, and the offsite configuration evidence without scramble time.

Frequently Asked Questions

What qualifies as “offsite storage” in a cloud environment?

Offsite means meaningfully separate from the primary environment’s failure and compromise paths. In practice, that often means a separate account/subscription/tenant or a separate region with tightly scoped cross-account access, documented as your standard. ¹

Do we need immutable backups to satisfy TSC-A1.3?

The text doesn’t mandate immutability, but auditors will pressure-test whether backups can be deleted or altered by the same admins who run production. If ransomware is a credible threat model for your service, immutability or strong deletion controls usually become the practical expectation. ¹

Are snapshots enough, or do we need full backups?

Snapshots can be part of the solution if they meet your RPO/RTO and you can restore reliably. Document the method per system, show retention, show offsite replication if needed, and prove restores with test evidence. ¹

How often do we need to test restores?

Set a cadence that matches system criticality and change rate, then follow it consistently. Auditors mainly care that restore testing is planned, repeatable, and evidenced for key systems across the audit period. ¹

What about SaaS platforms (CRM, ticketing, HRIS) that hold important data?

If the data is required to operate or meet customer commitments, include it in scope and document how it’s backed up or exported, and how you’d recover it. If you rely on the SaaS provider’s native resilience, document that dependency and retain evidence of your configuration and recovery approach. ¹

What evidence is strongest for SOC 2 operating effectiveness?

Time-stamped backup reports showing success rates, tickets for failures and remediation, restore test reports with validation outputs, and access control evidence for backup administration. Store them in a system that preserves history and ties artifacts to the control, which is where Daydream can reduce evidence-chasing. ¹

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control management

Footnotes

1. AICPA TSC 2017