Control Definition
The organization must maintain backup copies of information, software, and systems in line with an agreed topic-specific policy on backup, and must test those backups regularly. What is copied, how often, and how long copies are retained all follow from that policy, which in turn reflects the business's recovery and retention requirements.
Control Objective
To enable recovery of data, software, and systems after loss, corruption, ransomware, or facility failure — within the limits the business has agreed it can tolerate.
What This Really Means
A backup that has never been restored is hope, not a control. That single sentence captures how auditors read A.8.13: the control is not "do backups exist" but "can you demonstrably get your information back". Everything else — schedules, tools, storage tiers — is plumbing in service of that one outcome.
The control deliberately anchors backup to an agreed topic-specific policy, because the right answers are business decisions, not IT defaults. For each system, the data owner decides how much loss is survivable (which sets backup frequency and your recovery point objective), how fast it must come back (which shapes technology choice), and how long copies must be kept (which comes from operational need plus legal retention). The policy records those decisions, names what is in scope, and — just as importantly — what is deliberately excluded and why. A backup regime inherited from whatever the tool shipped with is the most common silent failure in this control.
Architecture matters because backups are now a primary target, not just a safety net. Modern ransomware playbooks locate and encrypt or delete backups before detonating, so the classic 3-2-1 pattern (three copies, two different storage technologies, one off-site) needs a 2020s amendment: at least one copy should be immutable — object-lock or WORM storage — or genuinely offline, and the backup platform should sit behind its own credentials and access boundary so a compromised domain admin account cannot reach it. Backups also concentrate your most sensitive data in one place, so they are encrypted, with keys managed separately from the copies they protect.
Then the heart of it: restoration testing with documented results. Auditors will accept many architectures, but they will not accept a backup program whose last verified restore was "never". Periodic test restores — sampled files monthly or quarterly, a full system or database at least annually — with a dated record of what was restored, by whom, how long it took, and what went wrong, are the evidence that turns a backup schedule into a working control. One more trap worth naming: SaaS data. Microsoft 365, Google Workspace, and most SaaS platforms replicate data for their availability, not for your mistakes — recovering from your own deletions, sync errors, or malicious insiders is usually your responsibility under the shared responsibility model, and your backup policy must say how you handle it.
Why It Matters
When prevention fails — and the rest of Annex A exists because sometimes it does — backup is the control that decides whether you have an incident or an extinction event. Ransomware crews understand this perfectly, which is why backup repositories are attacked first and ransom economics are calculated against the victim's ability to restore. An organization with immutable, tested backups negotiates from strength or does not negotiate at all; one without them is choosing between paying and closing.
The quieter failures are just as expensive. A backup scope that drifted away from reality means the new production database was never enrolled. An untested restore fails at 2 a.m. on a dependency nobody documented. A retention setting silently shorter than a legal obligation surfaces during litigation. Each of these is discovered at the worst possible moment unless the control forces the discovery earlier.
Weak or untested backups expose the organization to:
- •Ransomware leverage – attackers who encrypt or delete reachable backups remove your only alternative to paying, and online same-credential backups are reachable
- •Unrecoverable data loss – deletion, corruption, or failed migrations become permanent when the "backup" turns out to be incomplete or unrestorable
- •Recovery slower than the business survives – restores that technically work but take days blow through recovery time objectives and contractual SLAs
- •Compliance and legal exposure – lost records breach retention obligations, and lost personal data can constitute a notifiable breach under privacy law
- •Single-basket concentration risk – an unencrypted backup repository is the most valuable single object an attacker can exfiltrate
Regional Compliance Context
India. A destructive incident rarely stays a private matter: ransomware attacks and data breaches sit within the incident categories that CERT-In requires India-connected organizations to report within 6 hours of noticing, so your restore timeline and backup evidence become part of the regulatory record. Under the DPDP Act 2023, data fiduciaries must apply reasonable security safeguards, and the DPDP Rules notified in 2025 frame these to include measures for continued processing when availability or integrity is compromised — in practice, maintained and tested backups of personal data. RBI-regulated entities should expect supervisors to probe tested recovery capability against documented recovery objectives, not just backup schedules.
Implementation Guidance
Write the Topic-Specific Backup Policy from Business Requirements
Run a short recovery conversation with each system and data owner: how much data loss is survivable (recovery point objective), how quickly must service return (recovery time objective, aligned with A.5.30), and how long must records be kept. Capture the answers as the backup policy: scope, frequency, retention, storage locations, encryption requirements, and named ownership. Tool defaults are not a policy.
Map Backup Scope Against the Asset Inventory
Reconcile the backup scope with your asset register: servers, databases, file stores, configuration and infrastructure-as-code, endpoint data where it holds unique information, and SaaS data. Record explicit exclusions with a one-line justification each. The reconciliation, repeated periodically, is what stops scope drifting as systems change.
Engineer to 3-2-1 with an Immutable or Offline Copy
Keep three copies of important data on two different storage technologies with one off-site. Make at least one copy immutable (object lock / WORM) or genuinely offline so ransomware with admin credentials cannot reach it, and place the backup platform behind separate credentials with MFA — never joined to the same identity domain it protects.
Encrypt Backups and Separate the Keys
Encrypt backup data in transit and at rest, following your cryptography rules under A.8.24. Store keys in a key management system separate from the backup repository, and include backup keys in your key lifecycle procedures — a lost key converts every backup it protects into noise, so key recovery deserves the same testing as data recovery.
Monitor Jobs and Treat Failures as Tickets, Not Noise
Alert on failed and missed jobs, review failures daily, and route them into your ticketing system with an owner and a deadline. Track a backup success-rate metric over time. Silent, repeated job failures that nobody investigated is among the most common audit findings against this control.
Test Restoration on a Fixed Cycle and Document Every Test
Restore sampled files or objects monthly or quarterly, and perform at least one full system or database restore annually, measuring elapsed time against the recovery time objective. Record date, scope, performer, result, duration, and issues found — a five-line record per test is sufficient, but it must exist. Fold larger restore exercises into your ICT continuity tests under A.5.30.
Manage Retention End-of-Life and Secure Disposal
Apply the retention schedule to backups themselves: expired copies are securely deleted in line with A.8.10, backup media leaving service is sanitized or destroyed, and legal holds override deletion where litigation or investigation requires it. Backups kept forever are a liability under privacy law, not extra safety.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.8.13:
Documentation
- Topic-specific backup policy defining scope, frequency, retention, encryption, and ownership
- Backup schedule or configuration export from the backup platform matching the policy
- Restoration test records with dates, scope, performer, measured duration, and outcomes
- Backup failure alerts and the tickets showing investigation and resolution
- RPO/RTO definitions per system, traceable to a business impact analysis or continuity plan
Interviews
- Infrastructure or IT operations engineer on how backup failures are detected, escalated, and resolved
- CISO or IT manager on how backup scope, frequency, and retention decisions were made and reviewed
- Application or data owner on whether the configured RPO actually reflects what the business can lose
Observations
- Live backup console showing job status, last successful runs, and failure alerting
- A demonstrated restore of a sample file or system, or artifacts of a recent documented restore test
- Immutability or offline configuration and the separate credential boundary protecting the backup platform
Practitioner Insights
The first question I ask against this control is not "show me your backup schedule" — it is "show me the last restore you performed and what it proved". A pattern I see across audits: dashboards full of green job ticks and not one documented restoration test, which means nobody actually knows whether the control works. That gap is exactly where certification auditors, and increasingly cyber insurers, dig hardest. Treat every restore test as a dated record with scope, result, and measured time — five lines is enough, but they must exist.
In startup audits the most common backup finding is not a failed job — it is the unexamined assumption that "the cloud handles it". Microsoft 365, Google Workspace, and most SaaS platforms replicate your data for their availability, not for your mistakes: a deletion or a malicious sync propagates everywhere in minutes, and native recycle bins have short windows. Read the shared responsibility model for each platform, decide deliberately — native retention settings, a SaaS backup tool, or scheduled exports — and write the decision down. A documented decision survives an audit; an assumption does not.
Common Challenges & Solutions
Challenge
Backups run for years, but nobody has ever performed or documented a restore.
Solution
Put restoration tests on the calendar, not on goodwill: sampled file restores quarterly, one full system or database restore annually. Keep the record lightweight — date, scope, who, duration, result, issues — so the habit survives busy quarters. The first few tests will fail in instructive ways; that is the point of doing them before an incident does.
Challenge
Ransomware encrypts or deletes the backups along with production, because they were online and reachable with the same credentials.
Solution
Add an immutable copy (object lock / WORM) or a genuinely offline copy to the architecture, and isolate the backup platform behind its own identity boundary with MFA — separate accounts, no domain join to the environment it protects. Alert on backup deletion and retention-policy changes, which are the attacker's first moves.
Challenge
SaaS data is assumed to be the vendor's problem, so nothing in Microsoft 365, Google Workspace, or the CRM is recoverable beyond the recycle bin.
Solution
Review the shared responsibility position for each SaaS platform holding important data. Then choose per platform: extended native retention settings, a third-party SaaS backup service, or scheduled exports to storage you control. Document the choice and its rationale in the backup policy so the auditor sees a decision rather than a gap.
Challenge
Backup scope drifts — new systems launch without backup enrollment and nobody notices until one of them fails.
Solution
Make backup enrollment a mandatory checklist item in change and release management (A.8.32) for any new system or data store. Reconcile backup coverage against the asset register quarterly and alert on agents that stop reporting. Drift is inevitable; undetected drift is the finding.
Challenge
Restores technically succeed but take far longer than the business can survive when tried at production scale.
Solution
Measure full-restore duration at realistic data volumes at least annually and compare it to the agreed RTO. Fix what the test exposes — restore sequencing, bandwidth ceilings, dependency order, missing infrastructure-as-code — or renegotiate the RTO honestly with the business. Where the gap is structural, the answer is usually redundancy (A.8.14) for the top tier rather than faster tape.
