Backup and Recovery for SOC 2

What this control should accomplish

Critical data, configuration, code, logs, and recovery instructions have protected copies that the team can locate and restore after deletion, corruption, compromise, or service failure.

How to implement Backup and Recovery

1. 1

   Define what must be recoverable

   Identify critical data stores, object stores, configuration, infrastructure definitions, code, artifacts, logs, keys or recovery dependencies, and runbooks for each service.

   You should end up with: Recovery asset inventory with owners

2. 2

   Set recovery targets

   Agree how much data loss and downtime the business can tolerate, then choose backup frequency, retention, replication, and restore methods that support those targets.

   You should end up with: Documented service recovery targets and backup design

3. 3

   Configure and protect copies

   Automate backups, encrypt them, restrict deletion and restore authority, and use separate administrative or failure boundaries where the risk justifies it.

   You should end up with: Backup jobs, retention, encryption, and access configuration

4. 4

   Monitor backup execution

   Alert on failed, missed, partial, stale, or unusually small backups and require an owner to investigate through resolution.

   You should end up with: Backup-health alerts and resolution records

5. 5

   Reconcile the inventory

   Compare expected recovery assets with active backup coverage and document exclusions, retired assets, and newly added systems.

   You should end up with: Periodic backup coverage reconciliation

6. 6

   Connect backups to restore testing

   Select representative copies for actual restoration and feed findings back into job configuration, runbooks, access, and recovery targets.

   You should end up with: Trace from backup copy to restore result and remediation

Evidence to keep, and what it should prove

Build the evidence set in three layers: what defines the control, who approved or reviewed it, and what proves it operated. Collect operating records when the work happens so they remain dated, attributable, correctly scoped, and traceable to the underlying activity.

Before sharing, remove unrelated personal or customer data, never expose passwords, tokens, or secret values, preserve enough source context to authenticate the record, and use the secure exchange approved for the engagement.

Which records should you prepare for the audit?

How an auditor may test this control

Use this checklist to prepare for procedures an auditor may perform. The exact steps and sample selection depend on your engagement scope and the service auditor's professional judgment.

• Confirm the intended control outcome

  Determine whether the control is designed to achieve this result: Critical data, configuration, code, logs, and recovery instructions have protected copies that the team can locate and restore after deletion, corruption, compromise, or service failure.

• Confirm ownership and operating cadence

  Compare the documented owner with the intended role (Operations Lead / Infrastructure Owner), then compare dated records with the stated cadence: Continuous for backups/monitoring; quarterly/annual testing as defined.

• Establish the complete audit record set

  Derive expected jobs from the period-effective backup inventory and schedules, reconcile them to immutable job histories by asset and expected time, and reconcile the recovery-asset population to current coverage; separately reconcile privileged backup audit events to authorized changes or reviews, preserving failed, missed, partial, and rerun jobs.

• Prepare the as-of-date evidence for a Type 1 engagement

  The current recovery-asset and backup inventory, active frequency, retention, access and protection configuration, current job-health state, and recent successful copies for each critical class at the review date.

• Prepare period evidence for a Type 2 engagement

  Every backup or replication run expected from the approved job schedules for each in-scope recovery asset during the review period, including completed, partial, failed, missed, cancelled, and rerun jobs, plus every scheduled coverage reconciliation and every privileged backup configuration, restore, download, or deletion event.

• Inspect the policy / design artifacts

  Documents that define the control, its scope, ownership, and expected way of working.

  • Inspect Backup inventory

    For each selected record, confirm it demonstrates Every critical recovery asset has an owner, backup or replication method, timing, retention, protection boundary, and most recent successful copy.

    • Recovery asset
    • Service and owner
    • Backup method
    • Frequency and retention
    • Storage or failure boundary
    • Latest successful copy

• Inspect the operating / technical evidence

  Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.

  • Inspect backup job success/failure logs

    For each selected record, confirm it demonstrates Expected backup and replication runs are recorded individually, with missed and failed jobs visible through accountable resolution.

    • Job and asset ID
    • Expected run time
    • Actual start and finish
    • Status
    • Copy or snapshot ID
    • Failure resolution

  • Inspect backup access logs

    For each selected record, confirm it demonstrates Backup configuration, restore, download, deletion, and privileged access are attributable and can be reviewed for unauthorized or risky activity.

    • Actor
    • Action
    • Backup resource
    • Timestamp
    • Source context
    • Result or review disposition

  • Inspect retention settings

    For each selected record, confirm it demonstrates Backup copies have configured retention, lifecycle, immutability or deletion controls that support documented recovery targets.

    • Backup policy or asset class
    • Frequency
    • Retention duration
    • Deletion or immutability setting
    • Effective date
    • Configuration owner

• Trace the control from design to operation

  Use the categories that apply to this control: connect any policy or design artifact to its approval or review record, then trace a selected operating record through execution, result, and any exception or remediation.

Common implementation and evidence gaps

• A successful backup job is treated as proof even though no one has restored the data.
• Production administrators can delete both the live system and every backup copy.
• Databases are covered, but configuration, SaaS records, artifacts, logs, or recovery instructions are not.
• New systems do not enter backup coverage until someone remembers to add them.
• Backup failures alert a mailbox but do not receive an accountable resolution record.

Before you call this control ready

• Can every critical recovery asset be tied to an active backup or documented alternative?
• Would one compromised production identity be able to destroy all recovery copies?
• Do failed and stale jobs create owned work through resolution?
• Do frequency and retention support the service's documented recovery targets?
• Can the team point to a successful restore from a representative current copy?

Trust Services Criteria references

These identifiers help you navigate related Trust Services Criteria. They do not reproduce the criteria or prove that this control fully addresses them in your environment.

• A1.2
• C1.1
• C1.2

Confirm final scope, mappings, and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.

Related controls to review next