ISO 27001 A.8.13: Information Backup

ISO 27001 A.8.13 requires that backup copies of information, software, and systems are maintained and tested against an agreed backup policy. It is a Technological control (A.8), and the action teams often get flagged on is testing restores: backups that run every night but have never been restored satisfy the letter of a backup schedule and fail the intent of the control.

What is ISO 27001 A.8.13?

ISO 27001 A.8.13 Information backup governs keeping recoverable copies of information, software, and systems, and testing that those copies restore. Paraphrasing the intent attributed to ISO/IEC 27001:2022, Annex A: the organization defines a backup policy that sets what is backed up, how often, and how long copies are retained, then takes and tests backups in line with that policy so information can be recovered after a loss, corruption, or ransomware event.

ISO 27001 A.8.13 is a technological control, but it turns on an operating discipline rather than a single product. The standard does not name a backup tool or a storage medium. What it asks is that backups are scoped deliberately, run reliably, protected from the same events they are meant to survive, and proven to restore. The restore proof is what separates a real backup capability from a scheduled job that produces files nobody has ever recovered from.

How do you implement A.8.13?

Implementing ISO 27001 A.8.13 is a sequence a team can follow regardless of where the infrastructure lives, and the last step is the one auditors weight most.

1. Write the backup policy first. Define the scope (which data, software, and system images are in), the backup frequency, and the retention period, and align each to a recovery point objective (RPO). An RPO of four hours means backups at least every four hours; a nightly-only schedule means the real RPO is 24 hours regardless of what the policy claims. The policy is the reference every later step and every auditor works from.
2. Automate the backups and alert on failure. Backups that depend on someone remembering to run them fail silently. Schedule them, and wire failure alerts to a named owner, because backup jobs often fail without anyone noticing. A job that alerts only on success hides the run that did not happen.
3. Encrypt backups and store copies off-site. Encrypt backup data at rest and in transit so a stolen copy is not a breach, and keep at least one copy in a location independent of production. A fire, flood, or extended outage at the primary site must not take production and its backups at the same time.
4. Protect backups from ransomware with immutability. Store at least one copy as immutable or air-gapped so ransomware that reaches production storage cannot encrypt or delete the recovery copy. Object lock, write-once media, and separate credentials for the backup system are the mechanisms that keep a recovery copy trustworthy when the primary environment is compromised.
5. Regularly test restores. Restore a real backup to an isolated environment on a schedule, verify the recovered data is complete and usable, and record how long it took. This is the step that converts a backup job into a backup capability, and it is the evidence A.8.13 turns on. Everything above is preparation; the restore test is the proof.

Steps 3 through 5 implement meaningfully differently in cloud and on-prem environments. Decisions like copy placement, credential separation for the backup system, and immutability are structural, the kind of choices a security architecture review examines. The two subsections below cover each environment.

In cloud environments

Cloud environments implement A.8.13 through managed backup services, configured deliberately and evidenced through configuration exports and job history:

• Managed backup services (for example AWS Backup or Azure Backup) centralize backup policy, scheduling, and retention across resources, and produce the policy-to-job evidence auditors sample.
• Cross-region replication places a recovery copy in a second region so a regional outage does not take backups with production.
• Immutable object storage with object lock gives a ransomware-resilient copy that cannot be deleted or modified for a defined retention period.
• Managed encryption through the provider's key management service secures backup data at rest, with keys held separately from the workloads being protected.
• Automated snapshots of databases and volumes provide point-in-time recovery within the RPO the policy sets.
• Restore testing into an isolated account or VPC validates that snapshots and backups recover as expected, with the restore duration recorded to validate the recovery time objective (RTO).

On-prem / self-hosted

On-prem environments reach the same outcomes through backup software and physical media that produce their own evidence. The SOC 2 backup and disaster recovery for on-prem guide covers the full implementation; the shape is:

• Backup software (Veeam, Commvault, Bacula, or scripted rsync/rclone jobs) handles database, VM-level, and file backups on a defined schedule with failure alerting.
• Off-site transfer to a second facility, a geographically separate office, or cloud storage keeps a copy independent of the primary site.
• Air-gapped or tape copies rotated to secure off-site storage give a recovery copy that is disconnected from the network and immune to ransomware that encrypts network-accessible storage.
• Encryption of backup media so a lost or stolen tape or drive does not become a disclosure.
• Application-aware backups that quiesce databases to a consistent state rather than capturing them mid-transaction.
• Restore testing to a non-production server, with the duration and verification recorded, on a quarterly cadence.

Cloud vs on-prem at a glance

What evidence demonstrates A.8.13?

Evidence for ISO 27001 A.8.13 is paired: an artifact showing backups exist and are configured to policy, plus a record showing they restore. Teams that export job history and configuration evidence automatically from the backup platform, rather than screenshotting dashboards each audit, spend far less time here; that evidence-automation approach is what GRC engineering covers.

How does A.8.13 map to SOC 2?

ISO 27001 A.8.13 is a Full overlap with SOC 2 A1.2 and A1.3. A.8.13 covers both maintaining and protecting backups, which maps to A1.2 (data backup processes and recovery infrastructure), and testing restoration, which maps to A1.3 (recovery plan testing). Organizations with an existing SOC 2 program scoped for Availability can reuse the same backup and restore evidence for the ISO 27001 certification audit with no adaptation.

A1.2 and A1.3 are Availability category criteria rather than Common Criteria controls, so the overlap only exists when the SOC 2 scope includes the Availability Trust Services Category. A Security-only SOC 2 does not produce A.8.13 evidence, because backup and recovery testing fall outside the Common Criteria. The SOC 2 to ISO 27001 control mapping covers the full crosswalk, including how the Availability criteria map across A.8.6, A.8.13, A.8.14, A.5.29, and A.5.30.

Related controls

ISO 27001 A.8.13 belongs to the availability family of the Technological theme and pairs closely with three neighbouring controls. A.8.14 Redundancy of information processing facilities covers keeping systems available through redundant components, which is distinct from A.8.13: redundancy keeps a running system up, while backup recovers information after it is lost. A.5.29 Information security during disruption covers maintaining security while operating in a degraded state, and A.5.30 ICT readiness for business continuity covers the structured ICT continuity plan that A.8.13 backups feed into. The ISO 27001 certification guide is the hub for how these controls fit into a full ISMS.

Part of Truvo's control-by-control ISO 27001 Annex A reference series. Start from the ISO 27001 certification guide for the full picture. If you are implementing A.8.13 as part of an effective security program and want a second set of eyes on the backup and restore design, Truvo offers scoping calls.

Frequently Asked Questions

What is ISO 27001 A.8.13?

ISO 27001 A.8.13 Information backup is a Technological control in Annex A of ISO/IEC 27001:2022. It requires that backup copies of information, software, and systems are maintained and tested in line with an agreed backup policy that sets scope, frequency, and retention. It covers taking backups, encrypting and storing them off-site, protecting them from ransomware, and regularly testing that they restore. It is not new in the 2022 revision.

What evidence satisfies A.8.13?

A.8.13 evidence is paired: a configuration artifact plus a restore record. Auditors expect a backup policy stating scope, frequency, and retention, backup job logs showing consistent success across the period, restore test records with date, scope, duration, and verification, and configuration showing encryption, immutability, and off-site or cross-region storage. The restore test record is what demonstrates the backups recover rather than merely running.

How do you implement A.8.13 in the cloud versus on-prem?

Cloud implementations use managed backup services, cross-region replication, immutable object storage with object lock, provider key management, and automated snapshots, with restore testing into an isolated account. On-prem implementations reach the same outcomes with backup software, off-site transfer, air-gapped or tape copies, encrypted media, and application-aware backups, with restore testing to a non-production server. The controls are equivalent; the evidence looks different.

Why is restore testing the most important part of A.8.13?

Because a backup that has never been restored is an untested assumption. Backup jobs can complete successfully while producing files that are corrupt, incomplete, or unrecoverable, and the only way to know is to restore one. A scheduled restore test to an isolated environment, at least quarterly, verifies the data recovers and measures how long it takes, which validates the RTO. A backup program with clean job logs but no restore evidence is a common A.8.13 gap.

How is A.8.13 different from A.8.14 redundancy?

A.8.13 recovers information after it is lost, corrupted, or encrypted; A.8.14 keeps a system running through redundant components so it does not go down in the first place. Redundancy protects availability of a live system; backup protects recoverability of information. A replicated database that mirrors a bad delete to its replica is redundant but not backed up, which is why A.8.13 and A.8.14 are separate controls that a program needs both of.

How does A.8.13 map to SOC 2?

A.8.13 maps to SOC 2 A1.2 and A1.3 as a Full overlap. A1.2 covers backup processes and recovery infrastructure, while A1.3 covers testing recovery plan procedures, so restore-test records map to A1.3 specifically. Both are Availability category criteria, so the overlap only applies when the SOC 2 scope includes the Availability Trust Services Category. Backup policy, job logs, immutability configuration, and restore-test records produced for A1.2 and A1.3 satisfy A.8.13 without adaptation. A Security-only SOC 2 does not cover backup and produces no reusable A.8.13 evidence.