How to Design Systems That Keep Working When Things Go Wrong
ISO 27001 Control 8.14 Redundancy of information processing facilities is about one thing:
When a critical system fails – hardware fault, power cut, cloud outage, attack – can you keep going without scrambling around in a panic?
Backups (Control 8.13) help you recover data.
Redundancy helps you stay online in the first place.
Control 8.14 expects you to design and operate your information processing facilities so that:
- A single failure doesn’t take out a critical service
- You understand what “available enough” really means for the business
- Redundant systems and components are properly implemented, monitored and tested
This guide walks through what ISO 27001 Control 8.14 is really asking for – and how to design practical, cost-sensible redundancy across on-prem, cloud and hybrid environments.
What ISO 27001 Control 8.14 Actually Requires
In plain English, ISO 27001 Control 8.14 – Redundancy of information processing facilities expects you to:
- Identify which services and systems must be highly available and what that means in practice
- Design and implement redundant architectures (no single points of failure where it really matters)
- Use appropriate failover, replication, and load balancing mechanisms
- Protect redundancy itself from becoming a security or integrity risk
- Regularly test and monitor that redundancy works as intended and meets your availability targets
It links directly to:
- Business continuity and disaster recovery
- Backup and restore (8.13)
- Supporting utilities (7.11), equipment siting (7.8), and network security
- Capacity management and change management
The goal: planned, proven resilience, not “we hope it’ll be fine”.
Step 1 – Work Out What Really Needs Redundancy
Redundancy is not free. ISO 27001 Control 8.14 doesn’t say “make everything bulletproof”; it says be deliberate.
Start with:
- Business Impact Analysis (BIA)
– Which services must stay up for the organisation to function?
– What happens if each service is down for 1 hour, 4 hours, a day, a week? - Define RTO and RPO
– RTO (Recovery Time Objective): how long can this service be unavailable?
– RPO (Recovery Point Objective): how much data loss is acceptable? - Identify critical dependencies
– Databases, directories, network links, power supplies, cloud services, third-party APIs.
– Remember that a “non-critical” component can still be a single point of failure.
From there, you can clearly say:
- “These systems need high availability + redundancy.”
- “These systems can rely on good backups + manual recovery.”
That is exactly the risk-based thinking ISO 27001 Control 8.14 is looking for.
Step 2 – Choose the Right Redundancy Model (Active/Active vs Active/Passive)
Redundancy isn’t one pattern. You’ve got a few main approaches – each with different cost and complexity.
Common patterns for ISO 27001 Control 8.14:
Active–Active
- Two or more instances all running at once, sharing the load.
- If one instance fails, the others keep processing.
Good for:
- High-volume, customer-facing services
- Scaling horizontally with load balancers
Considerations:
- More complex to design and test
- You must ensure data consistency and session handling across nodes
Active–Passive
- One primary system handles production; a secondary is on standby.
- Failover occurs if the primary fails.
Good for:
- Databases and systems where state is tricky
- Workloads where downtime must be short, but constant parallel operation isn’t needed
Considerations:
- You must keep the passive node in sync (replication, log shipping, snapshots).
- Failover logic (automatic vs manual) must be clear and tested.
N+1 / N-Way Redundancy
- Having one or more spare nodes (or capacity) for a cluster of systems.
- Common with virtualisation platforms and clustered services.
The important part for ISO 27001 Control 8.14: you can explain which model you’re using, for which systems, and why.
Step 3 – Implement Redundancy at Multiple Layers
Redundancy isn’t just “two servers instead of one”. You need to think about all the layers your service depends on.
Key layers to address:
1. Power and Utilities
- Dual power feeds to critical equipment where feasible
- UPS systems and backup generators for data rooms and key sites
- Redundant cooling where temperature control is critical
(See also your controls for supporting utilities – 7.11.)
2. Network and Connectivity
- Multiple ISPs or WAN paths for critical sites
- Redundant switches, routers, and firewalls in high-availability pairs
- Diverse physical routing where possible (no single cable run that can take everything out)
3. Compute and Storage
- Clustered or virtualised hosts for key workloads
- Storage redundancy (RAID, replicated storage, storage clusters)
- No single storage array that represents a hard single point of failure for critical data
4. Applications and Databases
- Application servers running in a farm/cluster behind load balancers
- Database replication, clustering, or managed HA features from your DB platform
- Clear separation of roles (e.g. primary for writes, replicas for reads)
5. Locations
- Separate data rooms or sites in the same region for local resilience
- Geo-redundancy across regions or data centres for disaster scenarios
- Awareness of data residency and sovereignty requirements if you go cross-border
For ISO 27001 Control 8.14, the key is that critical services don’t depend on any single fragile component – wherever it sits in the stack.
Step 4 – Use the Cloud Sensibly for Redundancy
Cloud can be brilliant for redundancy – but “we’re in the cloud, so we’re fine” is not a strategy.
For ISO 27001 Control 8.14 in cloud environments:
- Use multiple availability zones (AZs)
– Deploy critical services across at least two AZs in a region.
– Ensure load balancers and data stores are also multi-AZ. - Consider multi-region for very high criticality
– Replicate services and data to a secondary region for regional outage scenarios.
– Understand additional cost, latency, and data residency implications. - Be clear on provider responsibilities
– Infrastructure redundancy (power, cooling, racks) is usually the provider’s problem.
– Application and data redundancy is usually yours. - Multi-cloud – do you really need it?
– Multi-cloud redundancy can help with provider dependency, but it’s complex.
– For most organisations, strong multi-AZ/multi-region within one provider is more realistic.
The main thing: you can show how cloud architecture choices directly support the availability targets you defined earlier.
Step 5 – Secure and Govern Redundant Environments Properly
Redundancy doubles (or multiplies) your footprint. If you’re not careful, you…
- Double your attack surface
- Double your configuration mistakes
ISO 27001 Control 8.14 expects you to avoid making redundancy a security liability.
Good practice:
- Apply the same security controls to redundant systems as primaries
– Patching, hardening, access control, logging, monitoring.
– No “forgotten” standby servers with default passwords. - Control access consistently
– Use configuration management / Infrastructure as Code to keep environments aligned.
– Avoid configuration drift between sites or clusters. - Protect replication channels
– Encrypt traffic between primary and secondary sites or instances.
– Limit who can modify replication settings or access replicated data. - Watch costs and sprawl
– Periodically review whether every redundant component is still required.
– Remove or consolidate unused environments.
So when someone asks, “Is your DR environment secured to the same standard as production?”, the answer is a confident yes.
Step 6 – Monitor and Test Redundancy Regularly
Redundancy that’s never tested is a comforting diagram, not a control.
ISO 27001 Control 8.14 expects you to:
- Monitor health and failover readiness
– Use monitoring tools to track uptime, performance, replication status, and failover components.
– Alert on replication lags, failed nodes, or single points of failure re-appearing. - Test failover scenarios
– Planned failovers between nodes, data centres, or regions.
– Simulate the loss of a host, a network path, a storage array, or even a whole site (where feasible). - Include redundancy in your BC/DR exercises
– Prove that failover works and that the business processes still function afterwards.
– Record lessons learnt and adjust designs and runbooks. - Verify data consistency
– Ensure replicated databases and systems are consistent after failover.
– Check that transactions aren’t lost or duplicated beyond what your RPO allows.
This evidence – monitoring outputs, test reports, DR exercise results – is exactly what an ISO 27001 auditor will look for under Control 8.14.
Step 7 – Keep Redundancy Aligned with Changing Needs
Systems evolve, your business evolves, and so should your redundancy strategy.
To keep ISO 27001 Control 8.14 current:
- Review availability requirements periodically
– Changes in products, customer expectations, SLAs or regulations may change RTO/RPO.
– A system that used to be “nice to have” may have become business-critical. - Revisit architecture after major changes
– New platforms, major re-hosting, or large migrations (e.g. to cloud) should trigger a fresh look at redundancy.
– Ensure new dependencies don’t create sneaky single points of failure. - Track incidents and near-misses
– If you had an outage, ask: did redundancy work? Did it exist? Was it mis-configured?
– Feed that learning back into design and procedures. - Manage cost vs benefit
– High availability is expensive; not everything needs 24/7 resilience.
– Use your BIA to justify where you spend redundancy budget and where you don’t.
This keeps redundancy risk-based and intentional, rather than just “whatever we happened to build five years ago”.
Quick Implementation Checklist for ISO 27001 Control 8.14
Use this to assess where you stand:
- ISO 27001 Control 8.14 (Redundancy of information processing facilities) is covered in your BC/DR and infrastructure design standards.
- A Business Impact Analysis defines which systems need redundancy, with clear RTO/RPO.
- Critical services use appropriate redundant architectures (active–active, active–passive, clustering, etc.).
- Redundancy is implemented at multiple layers: power, network, compute, storage, applications, locations.
- Cloud deployments use multi-AZ and/or multi-region as appropriate, with clearly understood responsibilities.
- Redundant environments are secured and configured to the same standard as primary systems.
- Health, replication and failover status are monitored, with alerts for issues.
- Failover and recovery are tested regularly, including in BC/DR exercises, with documented outcomes.
- Redundancy designs are reviewed periodically and after major system or business changes.
- Cost and complexity of redundancy are balanced against business benefit – not everything is “Tier 1”.
Bringing It All Together
ISO 27001 Control 8.14 – Redundancy of information processing facilities – is about more than having “a spare server somewhere”.
If you:
- Understand which services truly need high availability,
- Design out single points of failure with sensible, layered redundancy,
- Secure, monitor and regularly test your redundant setups, and
- Keep the design aligned with your changing business and technology landscape,
you’ll have robust, auditable resilience – and you’ll be well-placed to demonstrate full compliance with ISO 27001 Control 8.14 while actually making your environment sturdier in the real world.
Explore the ISO 27001 Control Group Purposes