A.8.14 ISO 27001

ISO 27001 A.8.14: Redundancy of information processing facilities

What This Control Requires

Information processing facilities shall be implemented with redundancy sufficient to meet availability requirements.

In Plain Language

Single points of failure are ticking time bombs. A single power supply, a single database server, a single internet connection - when it fails (and it will), everything that depends on it goes down. This control is about building enough redundancy into your infrastructure that component failures do not become service outages.

Redundancy works at multiple levels: component-level (redundant power supplies, RAID storage), system-level (clustered servers, load-balanced applications), site-level (multiple data centres, cloud availability zones), and service-level (multiple internet connections, failover telecoms). How much you need at each level depends on how critical the system is.

Not everything needs five-nines availability. The key is matching your redundancy investment to your actual business requirements. Over-engineering costs money; under-engineering costs uptime. Let your business impact analysis and RTOs drive the architecture decisions.

How to Implement

Start with your business impact analysis. Map RTO and availability requirements to specific redundancy architectures. Systems needing near-zero downtime require active-active configurations. Systems with more forgiving RTOs can use active-passive or standby setups.

Build component-level redundancy into all critical infrastructure. Redundant power supplies in servers and network gear. RAID configurations for storage (RAID 1, 5, 6, or 10 depending on your performance and resilience needs). Redundant NICs with link aggregation. Redundant cooling in data centres. These are baseline measures - not having them is asking for trouble.

Add system-level redundancy for critical applications. Deploy database clusters with automatic failover. Use load balancers across multiple application server instances. Set up web server farms with session failover. Configure intelligent DNS failover for internet-facing services.

Build network redundancy. Get internet connections from at least two diverse providers. Deploy redundant core switches and routers. Implement redundant WAN links between sites. Use dynamic routing protocols that automatically reroute traffic around failures.

For cloud environments, use availability zones and regions properly. Spread critical workloads across multiple availability zones. Configure auto-scaling to absorb load when instances fail. Leverage cloud-native load balancing and failover services. For your most critical services, consider multi-region deployment.

Test failover regularly. Run planned failover tests at least annually for each redundant system. Verify that automatic failover actually works and meets your RTO targets. Document results and fix problems. Consider chaos engineering approaches to stress-test resilience in complex environments.

Evidence Your Auditor Will Request

Redundancy architecture documentation for critical systems
High availability configuration records for servers, databases, and networks
Failover test records showing tested failover and recovery times
Business impact analysis mapping availability requirements to redundancy design
Cloud availability zone and region deployment configuration

Common Mistakes

Critical systems have single points of failure without redundancy
Redundancy is implemented but failover has never been tested
Redundancy architecture does not align with business availability requirements
Network connectivity relies on a single provider or single physical route
Cloud deployments are within a single availability zone without cross-zone redundancy

Related Controls Across Frameworks

Framework	Control ID	Relationship
SOC 2	A1.2	Equivalent
NIS2	Art.21(2)(c)	Related

Frequently Asked Questions

Does every system need redundancy?

No, and it would be a waste of money to try. Redundancy should be proportionate to the business impact of downtime for each system. Your customer-facing platform that generates revenue every minute it is up? Yes, comprehensive redundancy. An internal reporting tool that people use once a week? A solid backup and recovery plan with a longer RTO is probably fine. Let the business impact analysis guide the investment.

What is the difference between high availability and disaster recovery?

High availability keeps things running through component and system redundancy, usually within the same site or region, with automatic failover measured in seconds or minutes. Disaster recovery gets you back up after a major failure - typically involving a different site or region, with longer recovery times measured in hours. You need both. HA handles the everyday failures (a server dies, a disk fails). DR handles the catastrophic scenarios (a data centre floods, a whole cloud region goes down).

Track ISO 27001 compliance in one place

AuditFront helps you manage every ISO 27001 control, collect evidence, and stay audit-ready.

Start Free Assessment