ISO 27001 Control 8.13: Information Backup Requirements, Implementation, and Audit Guide

A ransomware attack encrypts your production environment and your backup server in the same stroke. Your team initiates a restore — only to discover the last successful test was eighteen months ago, and the backup files are incomplete. What should have been a four-hour recovery becomes a week of downtime. Control 8.13 exists because this scenario plays out far more often than most organizations admit.

What 8.13 Requires

ISO 27001 Annex A Control 8.13 requires organizations to maintain backup copies of information, software, and system images, and to test those backups regularly against a documented backup policy aligned to business recovery needs. The scope is broader than most teams assume — it covers not just files and databases, but operating system images, application configurations, and the infrastructure definitions needed to rebuild an environment from scratch.

The control has three non-negotiable elements. First, you need a written backup policy that defines what gets backed up, how often, where copies are stored, and how long they are retained. Second, backup execution must actually follow that policy — automated schedules, monitoring, and alerting that confirm jobs complete successfully. Third, you must test restores on a regular cadence and document the results, including time-to-restore and data integrity verification.

That third requirement is where most organizations fail. A green dashboard showing “backup completed” is not evidence of recoverability. Industry surveys consistently show that a significant share of IT professionals lack confidence that their backup solutions could actually protect critical assets during an incident. The control exists precisely because organizations routinely discover backups are corrupt, incomplete, or unreachable only after a disaster forces an actual restore attempt. This is why backup testing is a core component of any information security management system.

Why 8.13 Matters

Consider a mid-market financial services firm hit by ransomware on a Friday evening. The incident response team isolates affected systems within hours, but when they attempt restoration, they find three problems: backup copies were stored on the same network segment and were encrypted alongside production data, the offsite backup hadn’t run successfully in six weeks due to a misconfigured storage credential, and no one had performed a full restoration test in over a year. A recoverable incident becomes a catastrophic one — not because of the attack’s sophistication, but because the backup controls were never validated.

This is the risk class that 8.13 addresses: data loss, extended operational disruption, and cascading regulatory penalties. Backup failure doesn’t create a new category of risk — it amplifies every other risk by removing your ability to recover. A vulnerability that would cause a few hours of downtime with working backups can cause weeks of disruption without them.

The severity is high because attackers have learned to target backup infrastructure deliberately. Veeam’s 2024 Ransomware Trends Report found that 96% of ransomware attacks specifically target backup repositories, with 76% of those attempts succeeding — making backup compromise a standard part of the modern attack playbook rather than an occasional tactic.

What Attackers Exploit

Threat actors systematically probe for backup weaknesses before deploying ransomware. The most common failure modes they target include:

• Backups on the same network segment as production: Ransomware that achieves lateral movement encrypts backup storage alongside everything else. No network separation means no recovery path.
• No immutable or air-gapped copies: Without write-once storage or physically separated backups, attackers can modify or delete backup data after gaining administrative access.
• Shared backup credentials: When backup management accounts use the same domain admin credentials as the broader environment, a single compromised account gives attackers access to both production and backup systems.
• Untested restore procedures: Organizations don’t know their backups are corrupt, incomplete, or incompatible with current systems until they attempt a restore under pressure — the worst possible time to discover a gap.
• No backup of system configurations: Teams back up databases and files but not the operating system images, application configurations, or infrastructure-as-code definitions needed to rebuild the environment those files run on.
• SaaS data not backed up: Relying on a SaaS provider’s built-in retention is not a backup strategy. Provider retention policies serve the provider’s operational needs, not your recovery requirements, and can change without notice.

These failure modes map directly to MITRE ATT&CK technique T1490 (Inhibit System Recovery), which documents how attackers specifically target backup and recovery mechanisms to maximize the impact of destructive operations.

How to Implement 8.13

Implementation splits into two distinct workstreams: hardening your own backup infrastructure and verifying that your vendors maintain equivalent controls. Most organizations focus exclusively on the first and discover vendor backup gaps only during an incident that affects a third-party service they depend on.

For Your Organization (First-Party)

A compliant backup implementation follows a logical sequence, starting with understanding what you need to protect and ending with ongoing validation that your protection actually works.

1. Classify information assets and define backup scope. Identify every system, dataset, application, and configuration that supports business operations. Your backup scope must include data, software, system images, and infrastructure configurations — not just files and databases.

2. Set RPO and RTO per asset based on business impact analysis. Conducting a thorough cybersecurity risk assessment is the foundation for this step. A single recovery target for all assets is a common mistake. Your customer-facing transaction database likely needs a 1-hour RPO, while archived compliance records might tolerate 24 hours. Align each asset’s recovery targets to its actual business criticality.

3. Implement the 3-2-1 rule. Maintain three copies of critical data, across two different media types, with one copy stored offsite or air-gapped. This approach, recommended by CISA and aligned with NIST SP 800-53 CP-9, ensures that no single failure — hardware, network, or ransomware — can destroy all copies simultaneously.

4. Enable encryption for backups at rest and in transit. Backup copies are high-value targets for exfiltration. Use AES-256 encryption and manage encryption keys separately from the backup infrastructure itself.

5. Use immutable storage for at least one copy. WORM (Write Once Read Many) storage or object lock configurations prevent anyone — including compromised administrators — from modifying or deleting backup data within the retention period.

6. Schedule automated backups matching RPO targets. Manual backup processes introduce human error and scheduling gaps. Automated jobs should run at intervals that match or exceed the RPO defined for each asset class.

7. Perform full restoration tests quarterly and document results. Test restores must exercise the complete recovery process: not just file extraction but full system rebuild, application startup, data integrity verification, and time-to-restore measurement against RTO targets. Document every test including failures and lessons learned.

8. Secure the backup management plane. Use dedicated backup administrator accounts with MFA enforcement, separate from domain admin credentials. Role-based access controls should limit who can modify backup configurations, delete backup data, or access encryption keys.

9. Monitor backup job success and failure with alerting. A backup that silently fails for weeks provides false confidence. Automated monitoring should alert on job failures, missed schedules, storage capacity thresholds, and replication lag.

Common mistakes to avoid:

• Backing up data but not system configurations or infrastructure definitions
• Treating a green backup dashboard as proof of recoverability without testing actual restores
• Storing all backup copies on the same network segment or in the same cloud region
• Using domain admin credentials for backup management, creating a single point of compromise
• Treating cloud provider retention as a backup strategy
• Setting a single RPO and RTO for all assets regardless of business criticality

For Your Vendors (Third-Party Assessment)

Your organization’s recoverability depends on every critical vendor maintaining equivalent backup controls. An ISO 27001 vendor questionnaire provides a structured starting point. When assessing third-party backup practices, structure your evaluation around these areas:

Questions to ask:

• What is your backup frequency for customer data, and how does it align with contracted SLAs?
• Where are backups stored, and is there geographic separation from primary systems?
• Are backups encrypted at rest and in transit? Who manages the encryption keys?
• When was your last full restoration test, and what were the results?
• Do you use immutable or air-gapped storage for at least one backup copy?

Evidence to request:

• Current backup policy with scope, frequency, and retention definitions
• Most recent full restoration test report with dates and outcomes
• SOC 2 Type II report with backup controls in scope, or ISO 27001 certification covering Annex A 8.13

Red flags:

• “We use cloud, so backups are handled” with no specifics about frequency, retention, or testing
• No restoration test evidence or test dates older than 12 months
• Backup retention periods shorter than your contractual data retention requirements
• No geographic separation between primary and backup storage
• Inability to explain encryption key management for backup data

Verification beyond self-attestation: Request SOC 2 or ISO 27001 certification evidence that specifically covers backup controls. Ask for restoration test documentation with timestamps. Confirm that encryption key management is documented and that keys are not stored alongside the backup data they protect.

Audit Evidence for 8.13

Auditors evaluating 8.13 compliance look for documented proof that your backup controls are not just designed but operating effectively. The gap between “we have a policy” and “we can prove it works” is where most nonconformities occur.

The most common audit finding is organizations that can produce a backup policy but cannot demonstrate restoration testing. A policy without test evidence is a design control, not an operating control — and auditors are looking for both.

Cross-Framework Mapping

Control 8.13 maps directly to backup and recovery requirements across every major compliance framework. If your organization operates under multiple regulatory obligations, implementing 8.13 thoroughly covers a significant portion of your backup-related ISO 27001 compliance requirements elsewhere.

The NIST 800-53 CP-09 mapping is the strongest — both controls require backup execution, offsite storage, and restoration testing with nearly identical scope. SOC 2 and CPS 230 provide partial coverage because their backup requirements are embedded within broader availability and resilience controls rather than standing as dedicated backup-specific requirements.

Related ISO 27001 Controls

Control 8.13 does not operate in isolation. Backup effectiveness depends on, and supports, a network of related controls across the Annex A catalog. Understanding ISO 27002 implementation guidance for each related control helps ensure consistent coverage.

Frequently Asked Questions

What Is ISO 27001 8.13?

ISO 27001 Annex A Control 8.13 is the information backup control requiring organizations to maintain and regularly test backup copies of information, software, and system images in accordance with a documented backup policy. It ensures that data can be recovered following loss, corruption, or a security incident.

What Happens if 8.13 Is Not Implemented?

Without 8.13, organizations cannot reliably recover from data loss events — turning recoverable incidents into prolonged outages. Auditors will raise a nonconformity, and depending on the regulatory environment, the organization may face penalties under frameworks like DORA or sector-specific data protection requirements.

How Do You Audit 8.13?

Auditors review the documented backup policy, verify that automated backup schedules align with stated RPO targets, examine restoration test logs for evidence of regular testing, and confirm that backups are encrypted and stored in geographically separated or immutable locations. The key distinction is between design evidence (the policy exists) and operating evidence (the policy is followed and tested).

How UpGuard Helps

Backup gaps across your vendor ecosystem create breach exposure that internal controls alone cannot address. UpGuard’s Breach Risk product continuously monitors your third-party attack surface, identifying vendor security weaknesses — including backup and recovery gaps — before they become incidents.

Get started with UpGuard Breach Risk