Cloud backup and disaster recovery
An auditor does not accept that backups exist. They accept a dated restore test, from a backup that ransomware or a bad administrator could not have deleted.
Cloud backup that passes an audit has four parts: a written policy stating what is backed up, how often and for how long; backups stored so that the people and credentials that run production cannot delete them; a copy in a second region, which for Canadian residency means the other Canadian region; and at least one documented restore test in the audit period. Most companies have the first and the third. The second and fourth are where findings come from.
What needs backing up?
| Asset | Method | Typical retention |
|---|---|---|
| Production databases | Automated backups with point-in-time recovery, plus scheduled copies to a backup vault | 7 to 35 days PITR, 30 to 365 days copies |
| Object storage with customer files | Versioning plus cross-region replication or backup | 30 to 90 days of versions |
| Infrastructure configuration | Infrastructure as code in version control | Indefinite |
| Secrets and keys | Secret manager replication, key deletion protection | Per policy |
| Stateless compute | Nothing; rebuilt from code and images | Not applicable |
Immutable backups
Ransomware and compromised administrator accounts delete backups first. The controls that stop that:
- AWS. AWS Backup vault lock in compliance mode, with backups copied to a vault in a separate account.
- Azure. Recovery Services vault immutability, soft delete and multi-user authorization for destructive operations.
- Google Cloud. Backup and DR service backup vaults with enforced retention, or bucket lock on exported backups.
Cyber insurers now ask about immutable or offline backups by name, so this control earns its keep outside the audit too.
Recovery objectives
- Recovery point objective (RPO)
- How much data you can afford to lose, measured in time. Point-in-time recovery gets most databases to minutes.
- Recovery time objective (RTO)
- How long you can be down. Restoring from backup in another region takes hours; a warm standby takes minutes and costs more.
Write both down per system and make sure your customer contracts do not promise better. An RTO of four hours in a contract and a restore that has never been timed is a finding waiting to happen.
The restore test
- Pick a production database backup from a recent date.
- Restore it to an isolated environment, in the DR region if that is your plan.
- Check the data: row counts, a known recent record, application start-up against it.
- Record the date, who did it, the backup used, the time it took and the result.
- Tear it down and fix anything that did not work.
Once a year is the minimum an auditor accepts. Twice a year, or after any major architecture change, is better. The record from step four is the evidence.
Keeping disaster recovery in Canada
If customers require Canadian residency, backups and replicas count. Use ca-west-1 on AWS, Canada East on Azure, or the second Google Cloud Canadian region as the recovery location. The Canadian regions guide covers the pairings and service gaps.
Does SOC 2 require backups?
SOC 2 Availability criterion A1.2 addresses backup and recovery directly, and CC7.5 covers recovery from incidents in every SOC 2. In practice every auditor expects backups and a restore test, whether or not Availability is in scope.
Are cloud provider snapshots enough?
Snapshots in the same account and region protect against accidental deletion of a resource, not against account compromise or a regional outage. Copy them to a separate account or vault with immutability and to a second region.
How often should we test restores?
At least annually for the audit, and ideally every six months or after a significant change. The test has to be recorded with date, scope and result to count as evidence.
Need a backup and DR design that holds up?
Firms in the network set up immutable backups and run the first restore test with you.
Get matched