A.8.14 Redundancy of information processing facilities | ISO/IEC 27001:2022 Annex A Reference

Control objective

This control requires that information processing facilities (servers, storage, network equipment, power, communication links, data centers) be implemented with redundancy sufficient to meet the availability requirements of the services they support, so the failure of a single component does not cause a service outage. It calls for defining the availability target of each critical business service, duplicating components accordingly, and regularly verifying that automatic/manual failover actually works. Redundancy is not merely adding hardware: it must remove single points of failure (SPOF) and be designed and tested so that switchover procedures and spare capacity can carry the real load.

Key checkpoints

Are availability requirements (target availability, RTO) defined per critical service, and is the redundancy scope based on them?
Have single points of failure across servers, storage, network, power, and links been identified and removed/mitigated?
Are the redundancy scheme (active/active, active/standby, clustering, load balancing) and the failover procedure documented?
Is failover/failback tested regularly to confirm it actually works, and are the results fed back into improvement?
Has capacity been sized and verified so the redundant configuration can carry both normal and failure-time load?
Are the status, synchronization, and switchover events of redundant components monitored, with alerts on anomalies?

Implementation guidance

Assign an availability tier to each service based on business impact analysis, and design the redundancy level (component, site, data center) to match the tier.
Assess single points of failure across servers, storage, networks, power, and links. Choose fault-tolerant RAID levels or replication for storage needs; account for the fact that RAID 0 provides no redundancy.
Select synchronous/asynchronous replication for RPO and consistency needs and verify data state after switchover. Replication can propagate deletion, corruption, or malicious changes, so provide independent backups and point-in-time recovery under A.8.13.
Document automatic failover triggers/thresholds, the manual switchover procedure, and the failback procedure, and clarify responsible roles.
Run failure-injection/switchover tests with approved scope, operational impact assessment, stop criteria, and recovery procedures. Measure switchover time, data loss, and performance, recording untested scope and improvements.
Combine geographically distributed redundancy (for wide-area disasters) with local redundancy according to risk and cost, and include physical infrastructure (power/cooling/links) in the review.
Monitor health checks, replication lag, and switchover events of redundant components, and periodically check configuration/firmware version consistency.

Related controls and attributes

Evidence

Per-service availability requirements and redundancy design (including architecture diagrams)
SPOF analysis/removal records and infrastructure diagrams (server/storage/network/power/link)
Failover/failback procedures and role definitions
Redundancy switchover test plans/result reports (including switchover time and data-loss measurement)
Data replication settings and replication-lag/consistency check records
Redundancy status monitoring dashboards/alert settings and event logs
Capacity sizing basis and load-test results

Nonconformity examples

Only some equipment is made redundant without defined availability requirements, while other layers such as power/links remain in a single configuration, leaving SPOFs.
Redundancy is configured but failover has never been tested, so switchover fails during a real incident.
The standby node lacks capacity/performance, so the service cannot run normally after switchover.
Replication lag is not managed, causing data loss/inconsistency after switchover.
Redundant components run different configuration/firmware versions, causing malfunction at switchover.
There is no monitoring/alerting on redundancy status, so a degraded state (one side already failed) goes unnoticed.
Availability requirements call for resilience to site failure or wide-area disaster, yet redundancy exists only within the same data center/same power feed, so such an event brings everything down at once.