Snapshots, backups & retention
Snapshots and backups are the copies of production nobody re-secures: a point-in-time clone of a disk, a database backup, a machine image, or a vault of recovery data that holds exactly what the live system holds, often long after the original has been hardened or deleted. In multi-cloud estates they multiply through automated schedules, one-off "before I change this" snapshots, cross-account copies for disaster recovery, and images baked for autoscaling — each one a full data payload that inherits its own permissions, its own encryption decision, and its own lifespan. The security question is not whether backups exist, but whether every copy is encrypted, scoped to the accounts that genuinely need it, retained on a deliberate schedule, and protected from being deleted or altered by the same credential that would be compromised in an attack. This sub-topic examines the copies specifically: how they are shared, keyed, retained, logged, and whether they could actually be restored when it matters. It is distinct from live-store encryption and public-bucket exposure because a backup can be perfectly configured at the source and still leak or vanish through the copy.
Overview
What this check looks like in practice
Snapshots and backups are full copies of production data — and they routinely inherit weaker controls than the source they came from. A disk snapshot shared to another account, an unencrypted backup, or an RDS snapshot marked public can expose everything the live system holds while drawing none of the attention. We follow the copies, checking that they are encrypted, scoped, and retained on a defined schedule rather than accumulating forever.
Why it matters
To an attacker, backups are the quiet path to the same data with a fraction of the monitoring — a shared snapshot or an exported image can be copied into an account you do not control and read at leisure, and unlike a live breach the disclosure leaves almost no trace in the systems you watch. To a ransomware operator, backups are the target before the encryptor runs: if the recovery copies can be deleted or overwritten with the same IAM permissions used to reach production, there is no recovery, only a ransom. To an auditor, backup and retention controls are where availability and contingency requirements are proven, and "we take snapshots" is not evidence — they want encryption on the copies, restricted sharing, an enforced retention schedule, immutability where the framework demands it, and proof that a restore has actually been tested. To a privacy or residency obligation, an unnoticed cross-region backup copy is a silent violation, because the data left its agreed geography without anyone approving the move. Getting the copies right is what turns "we have backups" into a defensible, recoverable posture.
What we assess
What we look for
- Snapshots, database backups, or machine images shared with other accounts, subscriptions, projects, or marked public — and whether the target accounts are ones you actually control
- Backup copies left unencrypted while the source volume or database is encrypted, or backups encrypted with a default provider key where a customer-managed key with a scoped key policy is required
- Absence of a defined retention or lifecycle policy — snapshots and backups accumulating indefinitely, or conversely expiring faster than the framework's minimum retention
- No immutability or logical air-gap: recovery copies that can be deleted or altered by the same principals that manage production, leaving nothing to restore after a ransomware or insider event
- Over-broad IAM permissions to delete, modify, or share backups and vaults, and missing MFA-delete or delete-protection on the recovery store
- Backups and images stored without access logging, or held in an unmonitored or unowned account where reads and copies would go unseen
- Cross-region or cross-account replication of regulated data to locations outside intended residency, driven by DR or global-copy settings nobody reviewed
- No evidence of a tested restore — backups whose recoverability has never been verified, and images with no record of what software or secrets were baked in
Across your clouds
AWS, Azure & Google Cloud
AWS
Check EBS and RDS/Aurora snapshot sharing settings and the 'public' flag, snapshot encryption tied to KMS customer-managed keys and their key policies, AMI sharing and encryption, and AWS Backup vaults with Vault Lock (compliance mode) plus backup-vault access policies to enforce and restrict deletion. Review RDS/EBS copy-to-region and cross-account backup copy jobs for residency, and CloudTrail for visibility into backup and restore activity — management events for snapshot copy, share, and restore operations, and (where enabled) EBS direct-API data events for block-level snapshot access.
Azure
Review managed-disk and snapshot access via role assignments and 'export'/SAS grants, snapshot and disk encryption with platform- or customer-managed keys through Key Vault, and Azure Backup using a Recovery Services or Backup vault with immutability policies, soft delete, and multi-user authorization (MUA) via Resource Guard. Check Backup vault geo-redundant storage and cross-region restore settings for data-residency exposure.
Google Cloud
Review persistent-disk and Compute Engine snapshot IAM and resource sharing, custom image sharing across projects, CMEK on snapshots and images via Cloud KMS, and Backup and DR Service (or snapshot schedules) with retention. Check Backup and DR backup vaults with locked/enforced retention where available, the storage location of multi-regional snapshots, and Cloud SQL automated-backup and export settings for scope and residency.
Example finding
Production backups can be deleted by the same role that runs the workloads, with no immutability or delete protection
Risk: A single compromised or over-privileged credential — the exact thing a ransomware operator or malicious insider goes after — can wipe or overwrite every recovery copy before or during an attack, turning a recoverable incident into total data loss with no clean restore point and no leverage against a ransom demand.
Fix: Separate backup-management permissions from workload permissions, enable vault immutability or locked retention (for example AWS Backup Vault Lock in compliance mode, Azure Backup immutability with multi-user authorization, or GCP Backup and DR locked retention), require MFA or multi-party approval for delete operations, and confirm recovery copies live in an account, subscription, or project the production identities cannot administer.
Remediation
How to close it
- 1 Inventory every copy — EBS/managed-disk/persistent-disk snapshots, database backups, and machine images — and record for each: owner, encryption key, who it is shared with, retention, and storage region.
- 2 Revoke public and unintended cross-account/cross-project sharing, then re-scope each shared copy to only the specific accounts that need it; confirm every copy is encrypted, and re-key regulated backups to a customer-managed key with a least-privilege key policy.
- 3 Define and enforce a retention and lifecycle policy per data class so copies expire on a deliberate schedule that meets — but does not needlessly exceed — the framework's minimum, and stop the indefinite accumulation of orphaned snapshots.
- 4 Make recovery copies tamper-resistant: enable vault immutability, locked retention, soft delete, and delete protection, and require MFA or multi-party approval so no single production credential can destroy the backups.
- 5 Separate duties and monitoring — hold backups in an account/subscription/project distinct from production, restrict backup delete/share/modify permissions to a dedicated role, and turn on access logging so reads and copies are visible.
- 6 Prove recoverability and residency: run and document a test restore for critical systems, and verify no backup or replica has crossed a contractual or legal data-residency boundary.
Questions
Aren't backups a good thing? Why would you flag them?
Backups are essential — the finding is never that you have them, it is how the copies are protected. A backup is a full copy of production data with its own permissions, its own encryption choice, and its own lifespan, and those routinely end up weaker than the live system. We flag copies that are shared too broadly, unencrypted, retained forever, or deletable by the same credential an attacker would compromise — the gaps that turn a safeguard into a liability.
What does backup immutability actually protect against?
Immutability (locked retention, WORM-style vaults, MFA or multi-party delete) protects against the case where an attacker or insider reaches your control plane and tries to destroy the recovery copies before or during an attack — the standard ransomware playbook. If backups can be deleted or overwritten with ordinary production permissions, they cannot be relied on when you most need them. Immutability helps ensure a clean restore point survives even a full account compromise, which is also what auditors increasingly expect to see.
Do you test whether our backups actually restore?
The assessment is read-only, so we do not run restores against your environment. We look for evidence that recoverability has been validated — restore-test records, documented recovery procedures, and configuration that supports recovery — and flag critical systems whose backups have never been proven to restore. An untested backup is a hope, not a control, and it is a common gap that only surfaces during a real incident or an audit.
See where you stand
A health check finds and prioritizes real exposure. It is not a certification or a promise you will never be breached — closing the findings is what changes your risk.
Related domain surfaces
The rest of what we assess
The same read-only assessment covers every domain — see what else it looks at.
