We have all been there. That sinking feeling when a file you were working on vanishes into the digital ether, or worse, a server crash takes your entire customer database with it. In the modern threat landscape, where ransomware is more of a “when” than an “if,” your backup strategy is effectively your insurance policy.
This is where ISO 27001:2022 Annex A 8.13 comes in. It’s not just about copying files to a USB stick; it’s about ensuring you can actually recover your business when things go south. Let’s break down exactly how to implement this control without getting bogged down in unnecessary jargon.
Table of contents
What is Annex A 8.13?
In the official standard, this control is called Information Backup. Its purpose is simple: to provide protection against the loss of data. Whether it’s a cyber-attack, a physical fire, or just someone spilling coffee on a critical server, you need a way to get that data back.
The control requires you to maintain backup copies of information, software, and system images and test them regularly. It sounds straightforward, but the “devil is in the details”—specifically in defining what needs backing up and how often.
Step 1: Define Your Backup Policy
You cannot just “do backups” and hope for the best. An auditor will want to see a defined approach. You need a Topic Specific Policy for backups. This document should set the rules of engagement.
Your policy needs to cover:
- Scope: Which systems are critical? (Hint: It’s not just the file server; think about cloud services like Microsoft 365 too).
- Frequency: How often do we back up? Hourly? Daily? Weekly?
- Retention: How long do we keep the data? This is often driven by legal requirements (like keeping tax records for years) versus GDPR requirements (deleting data when no longer needed).
If you are starting from scratch and need a head start, Hightable.io offers comprehensive ISO 27001 toolkits that include these policy templates ready to go.
Step 2: Understand RPO and RTO
You can’t set a backup schedule without understanding two critical acronyms: RPO and RTO. These define your business’s appetite for risk.
Recovery Point Objective (RPO)
This asks: “How much data can we afford to lose?”
If your RPO is 24 hours, backing up once a night is fine. If you lose the server at 4 PM, you lose everything since last night, and the business accepts that. If your RPO is 15 minutes, a nightly backup is a compliance failure.
Recovery Time Objective (RTO)
This asks: “How long can we be offline?”
If your RTO is 4 hours, you need a backup solution that can restore your systems quickly. Tape backups stored in a vault across town might take 24 hours to retrieve and load, which would mean failing this objective.
Step 3: The 3-2-1 Rule
When implementing the technical side of Annex A 8.13, the gold standard is the 3-2-1 rule. It’s a simple concept that drastically reduces your risk of total data loss.
- 3 Copies of Data: Your live data plus two backups.
- 2 Different Media Types: Don’t keep both backups on the same hard drive. If that drive fails, you lose everything. Use a mix of local disk, NAS, or tape.
- 1 Offsite Copy: This is crucial. If your office burns down or gets flooded, your local backups will likely be destroyed too. Cloud backups are the most common way to satisfy this today.
Step 4: Protect Your Backups
Imagine if a hacker couldn’t get into your live database, so they stole your backup tapes instead. If those backups aren’t protected, you have just suffered a massive data breach.
Annex A 8.13 requires that backups are protected with the same level of security as the original data. In practice, this means:
- Encryption: Encrypt backups at rest and in transit. If a backup drive is lost or stolen, the data should be unreadable.
- Physical Security: If you use physical media (tapes/disks), lock them away.
- Immutability: Ransomware loves to encrypt backups too. Use “immutable” storage (WORM – Write Once, Read Many) where possible, so even if a hacker gets in, they cannot delete or encrypt your history.
Step 5: Testing (The Most Important Step)
This is where most organisations fail. You can have the best backup software in the world, but if you have never tried to restore a file, you don’t have a backup strategy—you have a hope strategy.
ISO 27001 explicitly requires you to test your backups. This doesn’t mean just looking at the log file that says “Success.” It means actually restoring data to a test location and verifying it opens.
Auditor Tip: Keep a log of your restoration tests. If you test your backups quarterly, document the date, what you restored, and the outcome. This is prime evidence for your audit.
DO IT YOURSELF
STOP SPANKING £10,000s on CONSULTANTS and ISMS ONLINE PLATFORMS
Common Pitfalls to Avoid
- Backing up corrupted data: If you don’t detect a virus for weeks, you might be backing up the virus. Ensure you have older retention points (e.g., monthly or yearly archives) so you can go back to a “clean” state.
- Forgetting the Cloud: Many people assume Microsoft or Google backs up their emails and files. Usually, they only guarantee platform availability, not data recovery if you accidentally delete something. Check your Shared Responsibility Model.
- Lack of Documentation: If the only person who knows how to restore the server is on holiday when the server breaks, you are in trouble. Document the restoration procedure step-by-step.
What Will the Auditor Look For?
When the external auditor comes knocking for Annex A 8.13, have these ready:
- Your Policy: A clear document stating your RPO, RTO, and backup schedule.
- Backup Logs: Automated reports showing successful backups over the last few months.
- Restoration Test Records: Proof that you have actually tested the system.
- Asset Inventory: Evidence that you have identified critical systems (linked to Annex A 5.9).
Conclusion
Implementing ISO 27001 Annex A 8.13 is about more than just compliance; it’s about business survival. By defining your requirements, securing your copies, and—most importantly—testing your ability to restore, you turn a passive IT task into a robust safety net.
If you need help structuring your documentation or defining your RPO/RTO, the resources and templates available at Hightable.io are an excellent place to start to ensure you aren’t reinventing the wheel.
About the author
Stuart Barker is a veteran practitioner with over 30 years of experience in systems security and risk management.
Holding an MSc in Software and Systems Security, Stuart combines academic rigor with extensive operational experience. His background includes over a decade leading Data Governance for General Electric (GE) across Europe, as well as founding and exiting a successful cyber security consultancy.
As a qualified ISO 27001 Lead Auditor and Lead Implementer, Stuart possesses distinct insight into the specific evidence standards required by certification bodies. He has successfully guided hundreds of organizations – from high-growth technology startups to enterprise financial institutions – through the audit lifecycle.
His toolkits represents the distillation of that field experience into a standardised framework. They move beyond theoretical compliance, providing a pragmatic, auditor-verified methodology designed to satisfy ISO/IEC 27001:2022 while minimising operational friction.
