Backup policy ISO 27001 (A.8.13)
A backup policy under ISO 27001 records which data you copy, how often, where the copies are stored, how long you keep them, and how you test that restoring works. In ISO/IEC 27001:2022 , this is control A.8.13 “Information backup” from Annex A. The control requires that backups are taken and tested regularly in line with an agreed backup policy.
The Nationaal Cyber Security Centrum (NCSC, National Cyber Security Centre) advises a backup strategy based on your risks, using the 3-2-1 method, automation and regular restore tests. The backup policy is closely linked to your risk assessment and to business continuity, for which ISO 22301 sets out the recovery times.
Short answer: for ISO 27001 A.8.13 you need an approved backup policy, backups that run according to that policy, monitoring for failed backups, and demonstrable restore tests. The standard does not prescribe a fixed frequency or retention period. You derive these from how much data loss (RPO) and how much downtime (RTO) you can accept.
What must a backup policy under ISO 27001 contain?
ISO 27002:2022 provides the guidance for A.8.13. To turn this into a practical policy, record these components:
| Component | Question it answers | Example |
|---|---|---|
| Scope | Which systems and data are covered? | ERP, file server, Microsoft 365, customer database |
| Frequency | How often do you make a backup? | Database every hour, other systems daily |
| RPO | How much data can you lose at most? | Customer database: 1 hour |
| RTO | How quickly must the system be back? | Customer database: 8 hours |
| Retention period | How far back can you go? | 30 daily and 12 monthly copies |
| Location | Where are the copies stored? | Second data centre plus an offline or immutable copy |
| Security | Who can access them, and are they encrypted? | Encrypted, separate admin accounts with MFA |
| Monitoring | Who checks whether backups succeed? | Daily report to IT management |
| Restore test | How often do you test restoring? | Quarterly sample, annual full system |
RPO stands for Recovery Point Objective: the maximum data loss, measured in time. RTO stands for Recovery Time Objective: the maximum time until a system works again. The NCSC uses the same terms.
Example ISO 27001 backup policy
This example suits a small or medium-sized business with a SaaS accounting package, Microsoft 365 and its own customer portal in the cloud. Adjust the systems and figures to your own situation.
Backup policy Version 1.1, approved by the management board on 2 February 2026. Owner: IT manager. Part of ISO 27001 A.8.13.
1. Purpose. This policy ensures that we can restore business data after a failure, human error, ransomware or the loss of a location.
2. Principles. We follow the 3-2-1 method: at least three copies, on two different types of storage, with one copy in a different location. At least one copy is immutable or offline, so an attacker cannot delete or encrypt it.
3. Automation. Backups run automatically. Manual backups are only a temporary emergency solution.
4. Access. Only two designated administrators have access to the backup environment, using separate accounts with MFA. Backups are encrypted.
5. Monitoring. IT management checks the backup report every working day. A failed backup is resolved the same day or reported as an incident.
6. Restore test. Every quarter we restore a sample of files and mailboxes. Once a year we restore a complete system in a separate environment. We record the results in the restore test register.
7. SaaS services. For each cloud service, we record what the supplier backs up and what we must arrange ourselves.
8. Review. The policy and the table of systems are reviewed annually and after major changes.
Add a table to the policy with the agreements per system:
| System | Frequency | RPO | RTO | Retention period | Copies |
|---|---|---|---|---|---|
| Customer portal (database) | Every hour | 1 hour | 8 hours | 35 days | Cloud region A, cloud region B, immutable copy |
| Microsoft 365 (mail, OneDrive, SharePoint) | Daily | 24 hours | 2 working days | 1 year | Third-party backup tool, own storage |
| Accounting package (SaaS) | Supplier, plus monthly export | 24 hours | 3 working days | 7 years (exports) | Supplier, encrypted export in archive |
| Laptops | No local storage of business data | n/a | 1 working day (reinstallation) | n/a | Files are stored in OneDrive |
Restore tests: how to show that your backup works
A backup you have never restored is an assumption. For A.8.13, the auditor almost always asks about restore tests. Record every test in a simple register.
| Date | System | Type of test | Target RTO | Actual time | Result | Action |
|---|---|---|---|---|---|---|
| 15 January 2026 | SharePoint, Projects folder | File restore | 4 hours | 25 minutes | Passed | None |
| 20 April 2026 | Customer portal database | Full restore in test environment | 8 hours | 11 hours | Partly passed | Speed up restore script, retest in June |
The second row shows what makes a test valuable: it reveals a gap that you can close. An exceeded RTO is not a problem for the audit, as long as you link it to an improvement action.
Choose the system and the scenario
For example: “The customer database has been encrypted by ransomware.”
Restore in a separate environment
Restore the backup without affecting production. Measure the time from the start.
Check the content
Ask the system owner to check that the data is complete and usable.
Record the result and actions
Note the measured time, the deviation from the RTO and the improvement actions in the register.
What does the auditor ask for as evidence for A.8.13?
During an ISO 27001 audit, you can expect these questions:
- Show the backup policy and the table of systems, RPO and RTO.
- Show the backup reports from recent weeks. How were failed backups followed up?
- When was the last restore test, and what was the outcome?
- How is the backup protected against ransomware?
- What does your SaaS supplier back up, and what do you arrange yourself?
Common mistakes in a backup policy
Assuming the cloud backs up everything. Many SaaS suppliers protect their platform, not your data if it is deleted by accident. Read the terms and record what you do yourself. Include this in your supplier management.
Backing up to the same network. The NCSC warns that attackers deliberately encrypt backups during ransomware attacks. Separate the backup environment from production and keep an offline or immutable copy.
Never restoring. A green tick in the backup software says nothing about whether the data is usable.
No agreed RPO and RTO. Without those figures, you cannot justify why daily is enough.
Forgetting the retention period. You must keep tax-related data for years, but personal data no longer than necessary. Align the retention period with your GDPR agreements.
Backup and other ISO 27001 measures
A.8.13 does not stand alone. Redundancy (A.8.14) keeps a system running when a fault occurs, while the backup lets you go back in time. ICT readiness for business continuity (A.5.30) links your recovery agreements to your continuity plan. If you want to go further, ISO 22301 offers a complete framework for continuity.
More information
- Annex A: all 93 controls, including data protection A.8.10 to A.8.13
- Incident management: what you do when recovery is needed
- Vulnerability management and patching: prevent the need for a backup in the first place
- Asset register: the list of systems for which you arrange backups
- Business impact analysis and RTO: determining recovery times
- NCSC: what to do in a ransomware attack