ISO 27001 Annex A 8.14: Redundancy of Information Processing Facilities
Imagine this: It is Black Friday, or perhaps just a busy Tuesday morning. Your main server decides to quit. The screen goes black. Silence. How much money are you losing every minute that system is down?
This is exactly the nightmare that ISO 27001 Annex A 8.14 is designed to prevent. While many controls in the standard focus on keeping bad guys out, this one is all about keeping your lights on. It is the spare tire in the boot of your car; you hope you never need it, but you are stranded without it.
Let’s strip away the jargon and look at what this control actually requires, how to implement it without breaking the bank, and what auditors are really looking for.
Table of contents
What is Annex A 8.14?
In simple terms, Annex A 8.14 requires you to identify your information processing facilities (servers, networks, cloud applications) and ensure they have enough redundancy to meet your availability requirements. It is a preventive control. Unlike a backup, which helps you restore data after a disaster, redundancy is designed to keep the system running during the failure.
The standard definition can be found in full on ISO27001.com, but the essence is straightforward: Do not put all your eggs in one basket. If one component fails, another should automatically (or quickly) take its place.
Redundancy vs. Backup: What is the Difference?
It is easy to confuse the two, but the distinction is critical for your audit.
Backup is about data recovery. If you accidentally delete a file or a server gets corrupted, you go to your backups to restore that specific point in time. It takes time to restore, and usually, there is some downtime involved.
Redundancy is about continuity. It is having two internet lines so if one is cut, the other keeps traffic moving. It is having a secondary power supply, or a mirror of your server in a different geographic region. The goal of redundancy is to ensure that users barely notice—or don’t notice at all—that a failure occurred.
How to Implement Redundancy
You cannot (and should not) make everything redundant. Buying two of everything is a quick way to bankrupt your IT budget. Instead, follow a logical process to decide where to invest.
1. Start with a Business Impact Analysis (BIA)
You need to know what is critical before you can protect it. Conduct a BIA to identify which systems are vital for your daily operations. If your email server goes down, can you survive for an hour? A day? A week?
This assessment gives you your Recovery Time Objectives (RTO). If a system has an RTO of “zero” or “minutes,” it needs high redundancy (like active-active failover). If the RTO is “24 hours,” you might not need expensive redundant hardware sitting idle.
2. Design the Architecture
Once you know what needs saving, look at your architecture. Redundancy applies to several layers:
- Hardware: Do your servers have dual power supplies? Do you have RAID storage so a single disk failure doesn’t cause data loss?
- Network: Do you rely on a single ISP? If your office internet cuts out, is there a 4G/5G failover or a secondary line?
- Cloud: Just because it is in the cloud doesn’t mean it is safe. Are you using multiple Availability Zones (AZs)? If the “East US” region goes down, does your application automatically spin up in “West US”?
3. Implement Alerts
Redundancy is useless if you don’t know the primary system has failed. You need monitoring tools that alert you immediately when a component goes offline. If your primary firewall dies and the secondary takes over, you need to know instantly so you can fix the primary one before the secondary fails too.
The “Gotchas”: Common Implementation Mistakes
When implementing Annex A 8.14, organisations often stumble on a few common hurdles. Avoiding these will make your life much easier during an audit.
Mistake #1: Configuring It but Never Testing It
This is the most common audit failure. You have paid for a secondary internet line, but does it actually work? When was the last time you pulled the plug on the primary line to see if the traffic switched over?
Auditors want to see evidence of testing. You need logs or reports showing that you simulated a failure and the redundant system worked as expected. “Schrödinger’s Backup” is not an acceptable strategy.
Mistake #2: Ignoring Legal Obligations
Redundancy often involves replicating data to a secondary location. If that secondary location is in a different country, have you checked the data sovereignty laws? ensure that your redundancy strategy complies with GDPR or other relevant privacy regulations. You don’t want to solve an availability problem only to create a legal one.
Mistake #3: Treating Shadow IT as “Not My Problem”
If your marketing team relies entirely on a third-party SaaS tool that you don’t manage, what happens if that tool goes offline? While you can’t control the vendor’s servers, you can control your vendor selection. Ensure your critical suppliers have their own redundancy measures in place (check their SLAs and SOC 2 reports).
What Will the Auditor Check?
When the auditor arrives, they aren’t just going to take your word for it. They will look for:
- Documentation: A clear list of critical systems and the redundancy measures applied to them.
- Test Records: Dated evidence of failover tests.
- SLA Reviews: Proof that you have checked the redundancy capabilities of your cloud providers and critical suppliers.
- Change Management: Evidence that when you changed your infrastructure, you updated your redundancy plans accordingly.
Conclusion
ISO 27001 Annex A 8.14 isn’t about buying expensive duplicate hardware for the sake of it. It is about understanding what keeps your business alive and ensuring those specific heartbeats don’t stop. By focusing on your critical assets, testing your failovers regularly, and documenting the results, you turn redundancy from a theoretical concept into a practical safety net.
