Annex A 8.13: Information Backup

Annex A 8.13 focuses on one outcome: you can recover required information within an acceptable time after deletion, corruption, outage, or attack, because backups exist and restores work. For most audit and customer diligence teams, “we have backups” is meaningless unless you can show three things: what is backed up (scope), that backups actually run (execution evidence), and that you can restore (test evidence). This control becomes a fast failure point during ISO 27001 certification, SOC 2 mapping, incident response reviews, and third-party risk assessments because it touches production systems, endpoints, and SaaS data that is easy to overlook.

For a CCO, GRC lead, or security owner, the quickest path is to treat backups as an operational control with a control card: named owner, defined trigger events (new systems, major changes), step-by-step runbook, exceptions, and an evidence bundle per cycle. That structure is also how you avoid the most common breakdown: teams buy a backup tool, but cannot prove coverage for crown-jewel data or cannot demonstrate a successful restore under time pressure ¹.

Regulatory text

Framework reference: ISO/IEC 27001:2022 Annex A control 8.13 (Information Backup) ¹

Provided excerpt (summary-level): “ISO/IEC 27001:2022 Annex A control 8.13 implementation expectation (Information Backup).” ¹

Operator interpretation (what you must do): You must implement a managed backup capability for information, aligned to business needs and risk, and be able to demonstrate it works. In practice, auditors will expect documented backup requirements (scope, frequency, retention, security), implemented backup jobs, monitoring/alerting, and periodic restore testing with results and follow-up actions ¹.

Plain-English interpretation of the requirement

Backups are your safety net. Annex A 8.13 expects you to:

• Identify information that must be recoverable (systems and datasets).
• Back it up on a defined schedule.
• Protect backups from unauthorized access and tampering (especially relevant for ransomware).
• Prove restore capability through testing and retained evidence ¹.

Who it applies to

Entity scope: Any organization implementing ISO/IEC 27001, especially service organizations that process, store, or transmit customer or regulated information ².

Operational contexts where auditors probe hardest:

• Production systems supporting revenue or customer delivery.
• Cloud infrastructure (IaaS/PaaS) where snapshots exist but governance is unclear.
• SaaS platforms holding critical business records (ticketing, CRM, finance, HR) where “backup” might mean export, replica, or vendor-native features.
• Endpoints used by privileged admins or engineering teams (local data, credentials, scripts).
• Third-party managed services where the provider claims backups but you never validated restore paths.

What you actually need to do (step-by-step)

1) Create the “backup control card” (design the control)

Document a one-page control runbook that answers:

• Objective: Recover required information after loss/corruption.
• Owner: Named accountable role (not a team).
• In-scope assets: Systems, databases, file stores, SaaS datasets, and configuration state (for rebuilds).
• Cadence: How often backups run per tier of criticality.
• Retention: How long backups are kept and where.
• Restore targets: Practical RTO/RPO targets that the business signs off on (avoid numbers you cannot meet; document the decision).
• Security requirements: Encryption, access control, separation of duties, immutability or write-once controls where feasible.
• Trigger events: New systems, major data model changes, migrations, onboarding a third party with hosted data.
• Exceptions: What is excluded and why, plus compensating controls.

This aligns with “control card” discipline expected in mature ISO programs ².

2) Classify systems into backup tiers (scope with intent)

Create a short tiering table that ties business criticality to backup requirements. Example structure:

• Tier 0 (Crown jewels): Customer data platforms, identity systems, production databases.
• Tier 1: Internal business-critical apps, finance systems.
• Tier 2: Non-critical collaboration spaces, low-impact services.

Then map each production system and key SaaS dataset to a tier, with an owner and a backup method.

3) Define backup methods per platform (make it real)

For each platform, define the method and boundary:

• Databases: Native backups, managed service snapshots, or backup agent. Clarify point-in-time restore vs periodic full.
• File/object storage: Versioning, replication, and/or backup copy. Document deletion protection.
• Virtual machines/containers: Image backups, persistent volume snapshots, and infrastructure-as-code repositories for rebuild.
• SaaS: Exports, API-based backups, third-party backup tools, or documented reliance on provider capabilities. If you rely on the provider, capture contractual and administrative evidence that the capability exists and is configured.

4) Secure backups against compromise (ransomware lens)

Minimum operational expectations auditors look for:

• Tight access: limit who can delete backups or change retention.
• Separate credentials and MFA for backup admin roles.
• Encrypt backup data and manage keys with defined ownership.
• Protect against overwrite/tamper with immutability features where available.
• Separate backup logs from production logs if feasible, so an attacker cannot erase both.

5) Implement monitoring, alerting, and failure handling

A backup that fails quietly is not a control. Define:

• What constitutes failure (job failure, missed run, corruption, storage capacity warnings).
• Who gets paged or ticketed.
• Response SLAs (internal), escalation, and how reruns are performed.
• How you document break/fix and recurring issues.

6) Test restores and record outcomes (the audit decider)

Run restore tests that reflect real recovery:

• Restore a dataset to a non-production environment.
• Validate integrity and usability (not just “the file exists”).
• Capture actual steps taken, blockers, and time-to-restore observations.
• Track remediation to closure when tests fail.

If you only do tabletop exercises, treat them as supplemental, not a substitute for technical restore tests.

7) Operationalize with recurring health checks

Run a recurring review that answers:

• Did all backups run as scheduled?
• Any changes to asset inventory that require new coverage?
• Any restore tests due or overdue?
• Any exceptions expiring?

This is where teams often use a GRC workflow tool. Daydream is a natural fit if you want the control card, evidence bundle definition, and remediation tracking in one place without building spreadsheets that drift out of date ².

Required evidence and artifacts to retain

Keep an “evidence bundle” that an auditor can verify without interpretive work:

Design evidence

• Backup policy/standard (backup scope, tiers, retention, security requirements).
• Backup control card (owner, cadence, triggers, exceptions).
• System-to-tier mapping and asset inventory excerpt showing coverage.

Operating evidence

• Backup job configurations (exported settings) or admin console screenshots with timestamps.
• Backup execution logs/reports showing successful runs across the audit period.
• Monitoring/alerting rules and sample alerts/tickets with resolution notes.
• Access control list for backup admins and evidence of periodic access review.

Restore evidence

• Restore test plan and schedule.
• Restore test results (what restored, where, validation performed, issues found).
• Remediation tickets and closure evidence for failed tests.

Third-party evidence (if applicable)

• Contract/SLA clauses or provider attestations describing backup and retention responsibilities.
• Your configuration proof (feature enabled, retention set) and restore procedure.

Common exam/audit questions and hangups

Auditors and customers tend to ask:

• “Show me your backup scope. Which production systems are excluded, and who approved that?”
• “How do you know backups succeeded last month? Show logs and alert handling.”
• “When did you last test a restore for the production database?”
• “Who can delete backups, and how do you prevent a compromised admin from wiping them?”
• “How do backups work for SaaS where the vendor says they handle it?”

Hangups usually come from unclear boundaries: infrastructure team assumes app team handles it, and app team assumes “cloud snapshots” are enough.

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating snapshots as a full backup strategy.
   Avoid it by documenting recovery objectives and validating restores end-to-end, not only snapshot creation.

2. Mistake: No inventory mapping, so coverage is guessed.
   Avoid it with a living system-to-tier map and a trigger that requires backup onboarding at system launch.

3. Mistake: Backups are protected by the same admin plane as production.
   Avoid it with separated roles, strong authentication, and immutability features where available.

4. Mistake: Restore tests are “planned” but not performed.
   Avoid it by scheduling restore tests like any other control, collecting results, and tracking remediation.

5. Mistake: SaaS data is ignored.
   Avoid it by listing business-critical SaaS datasets and selecting a defined approach (export, third-party backup, or documented provider reliance plus configuration evidence).

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement actions.

Risk-wise, backup failures convert a manageable incident into prolonged downtime, data loss, contract breaches, and disclosure obligations depending on jurisdiction and data type. Auditors treat backup and restore capability as a practical resilience measure, not a paperwork exercise ².

A practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Assign the backup control owner and publish the control card.
• Build the system inventory and tiering map, including SaaS datasets.
• Document backup methods and boundaries per system (who does what).
• Turn on failure alerting and route to a tracked queue.

Day 31–60 (close coverage gaps)

• Implement missing backup jobs for in-scope systems.
• Lock down backup admin access (least privilege, MFA, separation where feasible).
• Define retention and immutability settings per tier.
• Create the minimum evidence bundle checklist and an evidence repository structure.

Day 61–90 (prove restore capability and make it sustainable)

• Execute restore tests for highest-criticality systems first.
• Record results, open remediation items, and validate closure.
• Run the first formal control health check and capture outputs.
• Add trigger checks to change management (new system cannot go live without backup onboarding).

Frequently Asked Questions

Does Annex A 8.13 require immutable backups?

The control expectation is reliable recovery and protected backups, not a single mandated technology ¹. Immutability is a common way to reduce tampering risk; document your approach and show it works.

Are cloud provider snapshots enough to meet the requirement?

Sometimes, but only if you can show governance (scope, retention, access control) and successful restore testing for the systems that rely on snapshots. Treat snapshots as one method within a documented backup standard, not an assumption.

How do we handle SaaS applications where the provider claims they back up data?

Define responsibility in a RACI: what the provider does, what you configure, and what you test. Keep evidence that the capability exists and is enabled, plus your restore/export procedure.

What evidence is strongest in an ISO 27001 audit for backups?

Restore test records, backup success/failure reports over time, and tickets showing how failures were handled. Configuration screenshots help, but auditors usually prioritize proof of operation and recovery.

How often should we test restores?

Set a restore testing cadence based on system criticality and change rate, then document it and follow it consistently. Auditors react poorly to “ad hoc” restore testing that cannot be shown on a calendar with results.

Who should own this control: IT, Security, or GRC?

Assign one accountable owner who can compel action across infrastructure and application teams. GRC can govern and collect evidence, but the owner must be able to ensure backups run and restores get tested.

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index

2. ISO/IEC 27001 overview