A copy you have never restored is a hope, not a backup

This is why a database with a live replica in another zone still needs backups. If someone drops a table, the replica drops it a moment later. Control 8.13 covers the point-in-time copy; control 8.14 covers the spare capacity. Most organisations need both, sized to the availability their customers and their own recovery objectives demand.

• Production data stores: databases, object storage, file shares holding customer or business records.
• Configuration and code: infrastructure definitions, repositories, secrets vault exports where the design allows it.
• SaaS data: email, documents and CRM records; many SaaS providers protect their platform, not your deleted items.
• Things needed to restore: encryption keys, credentials for the backup system and the runbook itself, kept somewhere a disaster cannot also reach.

Frequency and retention are policy decisions. The deciding question is how much data you can afford to lose, often called the recovery point objective, and how long you must keep older copies for legal, contractual or investigation needs. Write both into a backup policy per data class so the schedule can be traced to a reason.

Attackers who gain administrator access often go for the backups first. Two protections make that harder. Immutability means a copy cannot be changed or deleted until its retention ends, even by an administrator. Separation means the backups sit in a different account, tenant or location, under different credentials, so one compromise does not reach both. Encrypt backups, and protect the keys as carefully as the data; a backup you cannot decrypt is lost.

• Different credentials. Production administrators cannot delete backups.
• Different location. A separate region, account or provider, matched to the risks you are covering.
• Locked retention. Copies are protected from deletion for their retention period.
• Key access. The keys needed to restore are available after the disaster you are planning for.

An auditor will look past the dashboard of green backup jobs and ask when you last brought something back. A good restore test record names the system, the backup used, who ran it, how long it took, how the restored data was checked, and anything that went wrong. Problems found in a test are a good result, as long as they are fixed and the fix is recorded.

1. 01

   Plan

   Choose the system and the backup to restore.

   What happens

   • Pick a system on a rotation
   • Agree success criteria

   You get

   • A test plan with a named owner

   Good practice

   • Covers critical systems over the year

   Watch for

   • Always restoring the same easy file

2. 02

   Restore

   Bring it back somewhere safe.

   What happens

   • Restore to an isolated environment
   • Time the restore

   You get

   • Timings against the recovery objective

   Good practice

   • Uses the documented runbook

   Watch for

   • Restoring over production

3. 03

   Verify and record

   Prove the data is whole and usable.

   What happens

   • Check record counts or open the application
   • Log issues as tickets

   You get

   • A dated record the auditor can sample

   Good practice

   • Fixes tracked to closure

   Watch for

   • A pass with no description of the check

Redundancy under 8.14 gets tested differently: by failing over. Switching traffic to the standby zone, or removing a node from a cluster on purpose, shows the spare capacity works. Record those exercises the same way. For how a SOC 2 auditor samples recovery tests, see the SOC 2 page below rather than repeating it here.

• Backup and recovery tests that satisfy SOC 2Designing a test an auditor can sample and trust.
• Continuity and ICT readinessRecovery objectives and tests, and what an auditor samples.

• Backup policy. Scope, frequency, retention, location and protection per data class.
• Job history. Successful runs across the period, and how failures were handled.
• Restore test records. Dated, with verification and follow-up.
• Redundancy design. Which components are duplicated, and the failover test results.

• Treating replicas as backups. Corruption reaches every replica. A point-in-time copy is still needed.
• Silent job failures. Nobody notices a backup has failed for weeks until the day it matters.
• Keys stored with the data. A single compromise or outage takes both.
• Forgetting SaaS. Business records in collaboration tools are often outside the backup plan.
• Redundancy that shares a failure. Two servers on one power feed or in one zone are less redundant than they look.

Sources: ISO/IEC 27001:2022 Annex A controls 5.30, 8.13 and 8.14 (cited by number and name only); NIST SP 800-34 Rev. 1 on contingency planning; NIST SP 800-53 Rev. 5, Contingency Planning (CP) family, including system backup. Comparisons and examples are our own.