UnixTime

Research Note

ISO 27001 A.8.13 - Information Backup

  • Updated Jun 17, 2026
  • Read 04 mins read
  • Status reviewed

The organization should make backup copies of important information, software, and systems, protect those backups, and regularly test whether they can actually be restored.

On this page

Requirement

Requirement lens

This control asks whether backup copies of information, software, and systems are maintained and regularly tested according to the backup policy.

“Backup copies of information, software and systems shall be maintained and regularly tested in accordance with the agreed topic-specific policy on backup.”

Plain-language meaning

The organization should make backup copies of important information, software, and systems, protect those backups, and regularly test whether they can actually be restored.

Backups are not useful if they are incomplete, unprotected, overwritten by ransomware, stored beside the original, unreadable, or never tested.

Why this matters

Backups protect integrity and availability when information or systems are lost, corrupted, deleted, encrypted by ransomware, or damaged. Backup frequency should match business need and risk. Critical systems may require real-time or very frequent backup, while lower-risk data may need less frequent backup.

Backups can also contain sensitive information and must be protected at least as well as the original data.

Implementation guidance

Implementer focus

Define what must be backed up, how often, where it is stored, how it is protected, and how restore success is tested.

1. Define backup scope and frequency

Use risk assessment, business continuity needs, recovery objectives, and asset criticality to decide:

Decision Practical question
Scope What information, software, systems, configurations, and keys need backup?
Frequency How often must backups run?
Copies How many copies are needed?
Location Where are backups stored?
Protection Are backups encrypted and access-controlled?
Retention How long are backups kept?
Restore test How often is restore tested?

2. Store backups safely

Backup copies should be stored separately from the systems they protect. Off-site, cloud, immutable, offline, or fireproof storage may be appropriate depending on risk and continuity requirements.

3. Protect backups like original data

Backups often contain full copies of sensitive data. Encryption, access control, logging, and secure handling should match the sensitivity of the backed-up information.

4. Test restores regularly

Backup success does not equal restore success. Restore tests should verify that files, applications, systems, and dependencies can actually be recovered without compromising live data integrity.

5. Manage long-term archives

Long-term archives may require old media readers, application versions, database software, encryption keys, documentation, and format knowledge. If the organization cannot read the archive later, the retention requirement has failed.

Audit guidance

Auditor focus

Test whether backups match business requirements, cover ISMS scope, are protected, and are regularly restored successfully.

Auditors should verify:

  • backup policy and procedures;
  • backup scope and frequency;
  • risk assessment and recovery requirements;
  • backup job success/failure records;
  • backup location and protection;
  • unique identification and logging of media;
  • restore test records;
  • corrective action for backup failures;
  • backup media lifecycle and disposal;
  • long-term archive recovery capability;
  • alignment with business continuity requirements.

Auditors should ask for restore test evidence, not only backup job success logs.

Evidence examples

Evidence quality

Strong evidence proves backups are complete, protected, restorable, and aligned with continuity needs.

Evidence What it proves
Backup policy Rules are defined
Backup scope/register Critical assets are included
Backup schedule Frequency is defined
Backup job logs Backups run and failures are visible
Restore test records Recovery works
Backup encryption/access records Backup data is protected
Off-site/immutable storage evidence Backups survive local incidents
Archive recovery records Long-term records remain readable
Corrective action records Failures are handled

Strong evidence

  • Backup scope maps to important information, systems, and software.
  • Backup frequency matches risk and continuity needs.
  • Backup failures are investigated and corrected.
  • Restore tests are performed and documented.
  • Backup copies are protected like original data.
  • Long-term archives can still be read.

Weak evidence

  • Backup jobs run but no restore tests exist.
  • Backup scope is unknown or excludes critical systems.
  • Backups are stored beside original systems.
  • Backups are not encrypted or access-controlled.
  • Backup failures are ignored.
  • Long-term archives cannot be read because media/software is obsolete.

Common failures

Implementation watchouts

A.8.13 fails when backup is measured by job success instead of restore capability.

Failure Why it matters
No restore testing Recovery is assumed, not proven
Backup scope incomplete Critical information cannot be recovered
Backup stored with original Same incident can destroy both
Weak backup access control Backups become data breach source
No ransomware resilience Backups may be encrypted or deleted by attacker
Long-term archive unreadable Retention obligations cannot be met
Backup failures ignored Gaps persist until a real incident

Exam traps

Exam focus

A.8.13 requires backups to be maintained and regularly tested. Backup logs alone are not enough.

Trap Correct interpretation
Backup success proves recovery Restore tests prove recovery
Backups are only data files Software, systems, configurations, and dependencies may also need backup
Backups need less protection than originals Backups often contain full sensitive data and need equivalent protection
Cloud means backups are automatic Cloud backup/snapshot strategy still needs scope, retention, testing, and protection
Archives are useful if retained They must remain readable with required software/media/key dependencies

KB-ready summary

Mentor takeaway

A.8.13 protects availability and integrity by ensuring important information, software, and systems can be restored. Strong evidence is restore evidence, not just successful backup jobs.

  • Define backup scope and frequency from risk and continuity needs.
  • Store backups separately and securely.
  • Protect backups like original data.
  • Test restores regularly.
  • Keep long-term archives readable.

Templates and checklists

  • Iso27001
  • Iso27002
  • Annex a
  • Technological controls
  • Backup
  • Availability
  • Audit

Note Metadata

Aliases: A.8.13, Information Backup, Backup

Source: 05 Annex A Technological Controls/A.8.13 Information Backup.md

Control dependency map

How this control connects to work products

Generated from the static research graph. It shows navigation and evidence dependencies; it is not an audit conclusion.

12

links

Control

ISO 27001 A.8.13 - Information Backup
01

Requirement context

Primary control text, framework notes, or adjacent controls this note points to.

02

Implementation artifacts

Templates and working records that help operate the control.

03

Evidence required

Evidence packs and proof records that support auditability.

04

Audit checks

Audit questions, checklists, or review material connected to the control.

05

Risk treatment

Risk records and ISO 27005 material this control mitigates or supports.

Graph-sourced resources

Templates and evidence

Implementer templates

Working artifacts for control owners and operators.

Auditor evidence packs

Evidence collections and audit-facing verification material.

Risk treatment artifacts

Risk records, mappings, and treatment-supporting references.