ISO 27001 A.8.14 - Redundancy of Information Processing Facilities

Requirement

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

Plain-language meaning

The organization should design critical processing facilities so that a single failure does not create unacceptable downtime. Redundancy may involve duplicate equipment, clustered systems, failover sites, replicated storage, redundant network links, backup power, cloud availability zones, or geographically separate locations.

Redundancy is not automatically required for every system. It should be based on availability requirements, recovery time expectations, risk assessment, and business continuity needs.

Why this matters

Availability is part of information security. If critical systems cannot tolerate downtime, the supporting facilities must be resilient enough to meet that need.

Redundancy also creates new risks. Replicating data across sites, networks, or cloud regions can introduce confidentiality, integrity, latency, synchronization, cost, and operational complexity risks. Those risks must be assessed, not ignored.

Implementation guidance

1. Define availability requirements

Use business impact analysis, risk assessment, service requirements, and continuity plans to define:

2. Match redundancy to need

Examples of redundancy include:

• redundant servers or clusters;
• storage replication;
• redundant network paths;
• alternate data centre or cloud region;
• redundant power/cooling;
• load balancing;
• hot/warm/cold standby environments;
• replicated identity, logging, and backup services.

3. Assess risks introduced by redundancy

Redundancy can create extra risk through data replication over public networks, inconsistent data between mirrored systems, weak access control in standby environments, insecure cloud regions, or untested failover.

4. Test redundancy

Redundancy must be tested. A diagram or vendor statement is not enough. Failover tests, recovery tests, and actual incident records should show whether the redundancy meets requirements.

Audit guidance

Auditors should request:

• availability requirements;
• business impact analysis or continuity requirements;
• risk assessments for redundant architecture;
• redundancy architecture diagrams;
• failover and recovery test records;
• actual recovery time records after unplanned outages;
• compensating controls for gaps;
• supplier/cloud redundancy evidence where relevant.

The key audit question is not “is redundancy present?” It is “does redundancy meet the required availability level and has this been proven?”

Evidence examples

Strong evidence

• Redundancy is linked to RTO/RPO and service criticality.
• Critical dependencies are included.
• Failover tests prove recovery within target.
• Redundant locations and replication paths are risk-assessed.
• Compensating controls exist where full redundancy is not justified.

Weak evidence

• Redundancy is assumed because the service is in the cloud.
• No documented availability requirement exists.
• Architecture shows redundancy but no failover test exists.
• Standby environment is outdated or unprotected.
• Data replication risks are not assessed.
• Actual outage recovery times exceed requirements without action.

Common failures

Exam traps

Related controls and concepts

• A.8 Technological Controls MOC
• A.8.6 Capacity Management
• A.8.13 Information Backup
• A.7.11 Supporting Utilities
• A.5.29 Information Security During Disruption
• A.5.30 ICT Readiness for Business Continuity
• Risk Assessment
• Statement of Applicability
• Redundancy Requirements and Architecture Register
• Redundancy Failover Test Record
• Availability Requirement Mapping
• A.8.14 Audit Evidence Pack
• A.8.14 Audit Checklist

KB-ready summary

• Define availability requirements first.
• Select redundancy based on RTO/RPO and risk.
• Include dependencies such as network, power, storage, identity, and cloud services.
• Test failover and record actual recovery times.
• Assess risks introduced by redundancy.

Templates and checklists

• Redundancy Requirements and Architecture Register
• Redundancy Failover Test Record
• Availability Requirement Mapping
• A.8.14 Audit Checklist