Redundancy of information processing facilities
Purpose
Build enough redundancy into information processing facilities to meet availability requirements.
How to meet this control
In short: Implement redundancy to meet availability requirements.
- Step 01Map availability requirements per service and design architecture to match, for example multi-AZ databases for critical workloads
- Step 02Deploy critical services across multiple availability zones or regions with load balancing and automated failover
- Step 03Use redundant network paths and, where justified, multiple connectivity or hosting providers to avoid single points of failure
- Step 04Provision redundant power, storage and compute, and replicate data to a geographically separate location
- Step 05Configure health checks and alerting that trigger failover and notify the on-call team
- Step 06Test failover regularly and confirm the redundant components hold the same security level as primary ones
Tip: Multi-AZ/region or failover for critical services.
What ISO 27002 says to cover
Reference points from the ISO/IEC 27002:2022 guidance for this control. Use them to check the steps above cover everything relevant to you.
- ›Identify availability requirements and design architecture with matching redundancy
- ›Duplicate facilities and plan procedures to activate redundant components
- ›Ensure redundant components provide the same security level as the primary ones
- ›Put alerting in place to detect failures and trigger failover
- ›Use multiple suppliers, redundant networks and geographically separate mirrored data centres
- ›Use redundant power supplies and parallel software instances with load balancing
- ›Duplicate hardware components such as CPUs, disks, firewalls and switches
- ›Test failover and account for integrity and confidentiality risks the redundancy introduces
Audit evidence to keep
- - Architecture diagram showing multi-zone or multi-region redundancy
- - Failover or high-availability configuration for a critical service
- - Health check and failover alerting configuration
- - Failover test record showing the system recovered successfully
- - Availability requirements mapped to the redundancy design
Common mistakes
- - Testing that backups exist but not that restore works
- - Setting recovery targets that the architecture cannot meet
- - Leaving backup access wider than production access
Owner, cadence, and proof
Assign one accountable owner for A.8.14. Review this control at least annually, after related incidents, and whenever the underlying process, supplier, system, office, or legal obligation changes. The control is audit-ready when the owner can show the policy or procedure, the latest operating evidence, the latest review, and any open exceptions with due dates.
Policy templates for this control
Use these starting documents to turn the control into evidence. Adapt each template to your scope, systems, legal obligations and actual operating process.