Most teams have backups. Fewer have restored from them on purpose, timed the restore, and checked that what came back was complete. Until you do, you know the backup job ran. You do not know the data is recoverable.
Auditors know this, which is why backup evidence that stops at "the job succeeded" rarely satisfies them for long. The control they want to see is the restore test: a recorded, repeatable demonstration that you can get data back within the time you have promised.
This article covers what the frameworks require, how to decide what to back up, how to keep backups out of reach of the incident you are planning for, how to run and record a restore test, and how to monitor backups between tests.
What the frameworks require
ISO 27001:2022 Annex A 8.13 requires backup copies of information, software, and systems to be maintained and regularly tested in line with an agreed backup policy.
SOC 2 addresses backups directly in the availability criteria: A1.2 covers backup processes and recovery infrastructure, and A1.3 covers testing recovery plan procedures. If your report covers security only, backups usually still appear as part of how you meet CC7.5 (recovering from incidents) and CC9.1 (risks from business disruption). Should you include availability in your SOC 2 covers whether to add the category.
The HIPAA Security Rule requires a data backup plan at 45 CFR 164.308(a)(7)(ii)(A) and a disaster recovery plan at (B), both required, and lists testing and revision procedures at (D) as addressable. See our HIPAA overview for the wider rule.
NIST SP 800-53 Rev. 5 CP-9 covers system backup, CP-4 contingency plan testing, and CP-10 system recovery and reconstitution.
GDPR Article 32 lists the ability to restore availability of and access to personal data in a timely manner after an incident among the measures to consider, alongside regular testing of security measures.
Decide what to back up, and how often
Start with an inventory of data stores in scope: production databases, object storage, file systems, search indexes that cannot be rebuilt from source, and queues that hold state. For each, record two targets.
Recovery point objective (RPO). How much data you can afford to lose, expressed as time. If the RPO is one hour, you need a backup or replication point at least every hour.
Recovery time objective (RTO). How long you can take to restore service. This is what the restore test measures.
Then look beyond the obvious stores:
Configuration and infrastructure code. Rebuilding an environment needs more than data. If infrastructure is defined in code, source control is part of your recovery path.
SaaS systems. Source control, document storage, and ticketing hold data you would need after an incident. Check what the provider backs up for you and what they leave to you; provider terms often leave recovery of your data with you.
Keys and secrets. Encrypted backups are useless without the keys. Make sure the keys needed to restore are themselves recoverable.
Keep backups out of the incident's reach
A backup must survive the event that makes you need it. Plan for at least these:
Accidental deletion of a table, bucket, or account.
A compromised administrator who deletes production and then the backups.
Ransomware that encrypts anything reachable from an infected system.
Loss of a region or a provider outage.
The defenses follow from the threats:
Store backups in a separate account or project, with different administrators from production. A single compromised identity should not be able to reach both.
Make backups immutable for their retention period, using write-once or object-lock features where your platform supports them.
Keep a copy in another region, and consider whether you need one outside your primary provider.
Turn on deletion protection for backup vaults and production databases.
Encrypt backups, and restrict who can use the keys.
The old rule of three copies, on two kinds of storage, with one off-site, is still a useful check on whether your design has a single point of failure.
A restore test is the control
A restore test is a deliberate recovery of real backup data into an isolated environment, followed by checks that the data is complete and usable, timed against your RTO.
A good test has five steps:
Pick the backup. Choose a specific backup by date, not the most recent one by default. Over a year, test different data stores and different ages.
Restore it to an isolated environment. Never over production. Use the documented runbook, so the test also tests the runbook.
Verify it. Row counts or object counts against the source at backup time, application-level checks such as loading a known record, and integrity checks where available.
Time it. From starting the restore to having usable data. Compare with the RTO.
Record it and clean up. Write the record, then delete the restored copy, because it holds production data in a non-production environment.
Frequency should follow risk. Testing each critical data store at least once a year is a common floor, with more frequent tests for the systems your customers depend on most. Whatever you choose, write it in the backup policy and meet it.
What the restore test record should contain
An auditor will ask for the record, and a ticket saying "restore test passed" is not enough. Keep:
- Not done:
Date, the person who ran it, and the reviewer
- Not done:
The data store and the specific backup restored, with its timestamp
- Not done:
The environment it was restored into
- Not done:
The verification checks run and their results
- Not done:
Start and end times, and the comparison with the RTO
- Not done:
Any problems found, with follow-up tickets
- Not done:
Confirmation the restored copy was deleted
System-generated output, such as restore job logs and query results, is stronger than a written summary of the same facts. Types of audit evidence and which is strongest explains why.
Monitor backups between tests
Restore tests are periodic. Backup failures are not. Between tests, watch for:
Failed backup jobs, alerted to an owner rather than logged silently
New data stores without backups configured, which appear whenever an engineer creates a database outside the standard templates
Retention changes that shorten how long backups are kept
Changes to immutability or deletion protection settings
A backup restore is also a natural part of a recovery exercise. If you run a tabletop exercise on a ransomware scenario, pair it with a technical restore test so the discussion and the mechanics are both tested.
Personal data in backups
Backups of personal data are still personal data. Retention periods for backups should appear in your retention schedule, and access to backups should be as restricted as access to production. How data subject erasure requests apply to data held in backups is a question with no single answer across jurisdictions; settle your approach with counsel and document it.
How TrustLynce helps
TrustLynce continuous monitoring runs control checks against the cloud systems you connect and routes failures to their owners. Evidence collection gathers configuration evidence from those systems on a schedule, timestamped and attributed, so backup settings are recorded across the period alongside your restore test records.