The backup that has to be there when you need it.
ISO 27001:2022 A.8.13 (information backup) is the control for recoverability: being able to get information, software, and systems back after a loss, a corruption, or a change that went wrong. In practice it comes down to deciding what needs backing up, keeping backups of it, protecting those copies, and actually testing a restore so you know recovery works. Recoverability is increasingly provisioned in code: a retention setting on a managed database, a snapshot schedule, a lifecycle policy. Which means it is a pull-request decision, and it can be switched off in one line.
The shapes the same control failure takes.
A.8.13 rarely breaks by someone deleting the backups. It breaks when a change quietly removes the ability to recover. The recurring shapes:
Automated backups are turned off
A retention period is set to zero, or a scheduled snapshot or backup job is removed, so a store that used to be recoverable now has no recent restore point.
Retention drops below the recovery window
A backup's retention is shortened (thirty days becomes one) so far that it no longer covers how long an incident can go unnoticed before you need to restore.
A new store ships with no backup
A database, bucket, or volume that holds real data is provisioned with no backup configured at all, so there is nothing to recover from if it is lost.
The restore is never verified
A step that tested or verified a restore is dropped, so backups keep being written but nobody knows whether they can actually be recovered, which A.8.13 expects you to test.
A backup is left unprotected
A snapshot or backup is made public, unencrypted, or shared too widely, so the backup copy itself becomes the exposure it was meant to guard against.
Automated backups switched off on the primary database.
A team wants to stop paying for automated backup storage on a managed Postgres during pre-launch, so a change sets the retention period to zero. The instance now has no automated backups and no point-in-time recovery from them. If data is lost or corrupted, recovery falls back to whatever else happens to exist (a manual snapshot, a separate backup tool), not this setting, and often there is nothing else.
resource "aws_db_instance" "primary" { engine = "postgres"- backup_retention_period = 7+ backup_retention_period = 0 # disables automated backups}Setting the retention period to zero disables automated backups and point-in-time recovery on the primary database, so a loss or corruption would have no recent automated restore point. A.8.13 (information backup) is about being able to recover, and it expects backups to be kept and tested. Keep a retention period that covers your recovery needs (or move the backups to a dedicated tool), rather than turning them off to save on storage.
Backup is checked against whether you can actually restore.
An auditor does not take 'we have backups' at face value; they look at whether backups exist for the systems that matter, are retained for the period your policy states, are protected, and, crucially, have been tested by an actual restore. A store with backups disabled, a retention shortened below the recovery window, or a new database stood up with none is the kind of gap that becomes a finding, and it usually arrived in a single change to the infrastructure config. The diff is the cheapest place to catch it.
A review, not your backup system.
heygrc flags changes that touch A.8.13 and cites the control so the fix happens in the pull request. It does not run your backups or test your restores. It catches the moment a change removes or weakens a store's ability to be recovered, at the diff.