We have all been there. You are in the middle of a critical transaction, a presentation, or a data upload, and suddenly—darkness. A server crash, a power outage, or a network failure brings everything to a grinding halt. In the world of information security, this isn’t just an annoyance; it is a business continuity disaster.
This is where ISO 27001:2022 Annex A 8.14 steps in. While other controls focus on stopping hackers or training staff, Annex A 8.14 is purely about keeping the lights on. It requires you to identify your information processing facilities (a fancy term for your critical tech stack) and build in enough redundancy to meet your availability requirements.
If you are wondering how to implement this without spending your entire budget on duplicate servers you might never use, you are in the right place.
Table of contents
What is Annex A 8.14?
The control is titled Redundancy of information processing facilities. In simple terms, it means you need to have “spares” for your critical components so that if one fails, another takes over immediately (or very quickly) to keep the business running.
Many people confuse this with Information Backup (Annex A 8.13). Here is the difference: Backups are for recovering data after it is lost. Redundancy is for maintaining operations while a failure is happening. Think of backups as a spare tire in your trunk, and redundancy as having a car with 8 wheels so you can keep driving even if one blows out.
Step 1: Identify What Actually Needs Redundancy
The biggest mistake organisations make is trying to make everything redundant. Redundancy is expensive. You do not need a failover cluster for the printer server in a satellite office.
To implement this correctly, you must start with a Business Impact Analysis (BIA). This will help you determine:
- RTO (Recovery Time Objective): How quickly must the system be back up?
- RPO (Recovery Point Objective): How much data can you afford to lose?
If a system has an RTO of “zero” or “minutes,” it needs redundancy. If the RTO is “24 hours,” you might be fine with just a good backup and restore procedure.
Step 2: Design Your Architecture
Once you know which systems are critical, you need to design redundancy into them. This usually happens at several layers:
Hardware and Infrastructure
If you are on-premise, this means avoiding Single Points of Failure (SPoF). Do your servers have dual power supplies? Do you have Uninterruptible Power Supplies (UPS) and a backup generator? If your office internet line is cut by a construction crew, do you have a secondary line from a different provider (e.g., a 5G failover)?
Network and Connectivity
For cloud-based organisations, redundancy is often about Availability Zones (AZs). If your application is hosted in AWS or Azure, ensure it is deployed across multiple zones. If “US-East-1” goes down, your application should automatically route traffic to “US-East-2.”
Application Logic
You generally have two choices for server redundancy:
- Active-Active: Two servers run simultaneously, sharing the load. If one dies, the other just takes 100% of the traffic.
- Active-Passive: One server runs the show. A second server sits idle (or in standby) and only wakes up if the primary fails.
Step 3: The “Set and Forget” Trap (Testing)
You can spend thousands on redundant firewalls and failover clusters, but if you don’t test them, they might not work when you need them. It is incredibly common for a “failover” to fail because of a configuration drift—perhaps a password was changed on the primary database but not the secondary one.
You must test your redundancy.
This doesn’t always mean pulling the plug on your live server during the day. You can perform scheduled failover tests during maintenance windows. ISO 27001 requires evidence that these tests happen. If you can’t prove you tested it, the auditor will assume it doesn’t work.
Step 4: Documentation
Compliance is ultimately about proving you are doing the right thing. For Annex A 8.14, you should have:
- System Architecture Diagrams: Showing where the redundancy exists.
- Test Schedules and Logs: Proof that you tested the failover and it worked (or that you fixed it if it didn’t).
- Vendor Agreements: If you rely on a SaaS provider, do you have an SLA that guarantees their redundancy?
If you are struggling to create the necessary policies or test logs, Hightable.io provides excellent ISO 27001 toolkits that include templates specifically for redundancy and availability management. Using these can save you hours of formatting and ensure you don’t miss the specific evidential requirements of the standard.
Common Pitfalls
The “Cloud” Assumption: Do not assume that just because you are “in the cloud,” you have redundancy. A single Virtual Machine in the cloud is just as vulnerable as a single physical server. You have to configure the redundancy (e.g., load balancers, auto-scaling groups).
Ignoring Dependencies: You might have redundant servers, but do they all rely on a single authentication service (like Active Directory)? If that one service goes down, your redundant servers are useless because nobody can log in.
Conclusion
Implementing ISO 27001 Annex A 8.14 is about building resilience. It moves your organisation from a fragile state—where one broken cable causes chaos—to a resilient state where failures are absorbed without the customer ever noticing. Start with your most critical assets, design out the single points of failure, and test it religiously.
