Information Security Management
Backup Policy: What ISO 27001 Control 8.13 Requires and How to Write One That Works
A backup policy says what is backed up, how often, where the copies go, how long they are kept, who can restore them, and how you know a restore would actually work. ISO 27001 requires it under Annex A control 8.13, and it is one of the controls most exposed by the shift to cloud, because most small businesses now assume their SaaS providers are doing it for them, and most of the time they are only half right.
The complete toolkit, every policy, template and record you need. Free, no commitment
This guide covers what the control requires, the questions a backup policy has to answer, what cloud providers do and do not do for you, how to set recovery objectives you can meet, and the procedure template from our toolkit.
Free data backup and recovery procedure (Word)
The toolkit document for this control is a procedure rather than a policy, because that is the level at which backup needs to be written down: the schedule, the types, the locations, the software, the verification, the retention, the recovery steps, the recovery time and point objectives, access control, encryption and logging. It has placeholders for each so you record what you actually do.
It is one of the standard operating procedures in the free ISO 27001 toolkit, which also has the business continuity and disaster recovery plan it supports.
What control 8.13 requires
Control 8.13, information backup, says that backup copies of information, software and systems shall be maintained and regularly tested in accordance with the agreed topic-specific policy on backup. Three things to notice:
- Information, software and systems. Not just files. Configuration, the applications themselves, and the systems they run on. If you lost the server, could you rebuild it?
- Regularly tested. A backup that has never been restored is a hope, not a control. The auditor will ask when you last tested a restore and what the result was.
- A topic-specific policy. The control itself names the policy, so this is one you cannot fold into something else.
The control sits with 5.30 (ICT readiness for business continuity) and the business continuity controls; the backup policy is what makes the recovery plan possible.
The questions the policy has to answer
- What is backed up? Everything the business would need to recover: file storage, email, databases, application data, system configuration, code repositories, and the SaaS data you are responsible for. Tie this to the asset inventory.
- How often? Set by how much you can afford to lose. Daily is the floor for most business data; hourly or continuous for transaction systems; weekly may be fine for archives.
- Where? At least one copy away from the system it protects, and at least one copy that an attacker who has your admin credentials cannot delete. The 3-2-1 rule (three copies, two media, one off-site) is still the sensible default, with “one immutable” added since ransomware.
- How long? Backup retention is separate from data retention. Backups cycle out (30 to 90 days is typical); if you need something kept for years, that is an archive, not a backup. See the data retention policy.
- How protected? Encrypted at rest and in transit; access restricted to named administrators; MFA on the backup console; logs kept.
- How tested? A restore test on a schedule (quarterly is common), covering a file, a mailbox and a full system at least annually, with the result recorded.
- How recovered? The steps, the order, who does it, and the recovery time objective (how long it may take) and recovery point objective (how much data may be lost) for each system.
- Who is responsible? For running it, checking it, testing it, and for each cloud service, for confirming what the provider does.
What cloud providers do and do not do
This is where small businesses most often get caught.
| Service | What the provider does | What you still have to do |
|---|---|---|
| Microsoft 365 / Google Workspace | Keeps the platform running; retains deleted items for a limited period (typically 30 to 93 days depending on the item and settings) | Longer retention, point-in-time restore of a mailbox or SharePoint site, protection against a malicious admin or a sync-and-delete: usually a third-party backup product |
| SaaS applications (CRM, accounts, HR) | Backs up its own platform for its own disaster recovery; may or may not offer you a restore | Check the contract and the settings; export regularly if there is no customer restore; record the answer in the cloud service register |
| Cloud infrastructure (AWS, Azure, GCP) | Provides the backup tools and durable storage | Configure and run them: snapshots, cross-region copies, immutability, and test the restore. Nothing is backed up by default |
| Managed service provider | Whatever the contract says | Read the contract; ask for the restore test report |
The policy should state, for each service, which side of the line the backup responsibility falls on. A one-line entry per service in the cloud service register does it.
Setting recovery objectives you can meet
RTO and RPO are the two numbers that turn a backup policy from a description into a commitment. Set them per system, not for the business as a whole, and set them honestly.
| System | RPO (data loss tolerated) | RTO (time to recover) | What that means for backup |
|---|---|---|---|
| Email and file storage | 24 hours | 8 hours | Daily backup with a tested restore process |
| Line-of-business database | 1 hour | 4 hours | Hourly snapshots or log shipping; a rehearsed restore |
| Customer-facing application | 15 minutes | 2 hours | Replication plus snapshots; a documented failover |
| Archive and historical records | 1 week | 5 days | Weekly backup is enough |
If the RTO says four hours and the last test took two days, change the number or change the process. An auditor is far more comfortable with an honest 48 hours that you have demonstrated than a theoretical 4 hours you have not.
Testing: the part that proves the control
A restore test does not need to be dramatic. A workable programme for a small business:
- Monthly: restore a single file and a single mailbox item; confirm the backup job reports are being checked.
- Quarterly: restore a full mailbox or SharePoint site, or a database, to an alternative location, and verify it.
- Annually: rebuild one system from backup as if it had been lost, timed against its RTO, and write up what went wrong.
Keep the records: date, what was restored, how long it took, result, actions. That log is the evidence for the “regularly tested” half of the control, and the thing most audits find missing.
Mistakes I see most at audit
- Never tested. The commonest finding against 8.13. Backups run every night; nobody has restored anything since they were set up.
- Cloud assumed. “It’s in Microsoft 365” offered as the backup policy.
- Same credentials. The backup console uses the same admin account as everything else, so a compromised admin can delete the backups along with the data.
- No off-site or immutable copy. All copies on the same network, reachable by ransomware.
- Retention confused with archive. Backups kept for seven years because somebody thought that was the data retention rule.
- RTO and RPO absent. The policy describes backups and never says what recovery is expected to achieve.
Where to go next
Backup supports business continuity, so the next document is the recovery plan that uses it. The data retention policy covers how backup retention and data retention fit together, and the cloud security policy covers the register where each provider’s backup responsibility is recorded. For the full control set see the Annex A guide and the controls list; other policy guides are on the ISO 27001 policies hub. For help getting an ISMS to certification, our ISO 27001 consultancy service covers the technical controls with you.
Frequently asked questions
Does ISO 27001 require a backup policy?
Yes. Control 8.13 requires backup copies of information, software and systems to be maintained and regularly tested in accordance with a topic-specific policy on backup. It is one of the few controls that names the policy it expects.
How often should backups be tested for ISO 27001?
The control says regularly and leaves the frequency to you. A common programme is a monthly single-item restore, a quarterly restore of a mailbox, site or database, and an annual full system rebuild timed against its recovery objective, with each test recorded.
Does Microsoft 365 count as a backup?
Only partly. Microsoft keeps the platform running and retains deleted items for a limited period, but that is not a backup under your control: it does not protect against a malicious administrator, a sync-and-delete, or the need to restore to a point in time beyond the retention window. Most businesses add a third-party backup for Microsoft 365 and record Microsoft’s responsibilities in the cloud service register.
What are RTO and RPO?
Recovery time objective is how long a system may take to recover after a loss. Recovery point objective is how much data, measured in time, may be lost. They are set per system and determine how often you back up and how you restore. The policy should state them and the tests should measure against them.
How long should backups be kept?
Backups are for recovery, so they usually cycle out after 30 to 90 days. Anything that must be kept for years is an archive and belongs in the data retention schedule, not the backup rotation. Keeping backups indefinitely creates a data protection problem rather than solving one.
ISO 27001 Online Course + Full Toolkit
Stop guessing. Follow a proven step-by-step process.
“Highly recommended for anyone looking to understand ISO 27001, whether attempting it on your own or even using a consultant.“
Verified customer review
£285
Instant access
✓ Full toolkit included ✓ Learn as you build ✓ 12-month access ✓ 6 hours of video ✓ Call + email support
Author Background
This article was written by Alan Parker, an ISO 27001 consultant and founder of Iseo Blue Limited. He helps UK SMEs achieve certification in 90 days or less, often without a dedicated security team or a large budget.
With over 30 years in IT governance and information security, Alan works with software companies, IT service providers, managed service providers, and professional services firms across the UK, Europe, and internationally.
Qualifications: Certified ISO/IEC 27001:2022 Lead Auditor,
ITIL v3 Expert, ITIL v4 Bridge, PRINCE2 Practitioner. Named IT Project Expert of the Year (2024, UK). Alan writes in plain English for busy teams who need to get things done.
Connect on LinkedIn or Bluesky, or explore his free ISO 27001 tools and templates at iseoblue.com. B.Sc (Hons) Information Systems, CISMP certified.
