How to Implement ISO 27001 Annex A 8.14 Redundancy of Information Processing Facilities

How to Implement ISO 27001 Annex A 8.14

Implementing ISO 27001 Annex A 8.14 requires establishing robust Redundancy of Information Processing Facilities to prevent service interruptions. By designing failover mechanisms for power, network, and server infrastructure, organizations ensure continuous business availability and resilience against hardware failures or environmental outages.

ISO 27001 Annex A Redundancy of Information Processing Facilities Implementation Checklist

Use this implementation checklist to achieve compliance with ISO 27001 Annex A 8.14. Compliance requires distinct, tested hardware and software failover mechanisms, not just a policy document stating you “aim for 99.9% uptime”.

1. Establish RTO and Availability Requirements

Control Requirement: Information processing facilities must have sufficient redundancy to meet availability requirements.

Required Implementation Step: Consult the Business Impact Analysis (BIA) to determine the Maximum Tolerable Downtime (MTD) for critical assets. Hardcode these values into your Service Level Agreements (SLAs); if the business demands 99.99% uptime, you must architect for N+1 redundancy immediately.

Minimum Requirement: Defined RTO (Recovery Time Objective) values for every critical system, signed off by asset owners.

2. Identify Single Points of Failure (SPOF)

Control Requirement: Identify and eliminate single points of failure in the architecture.

Required Implementation Step: Conduct a physical and logical audit of the infrastructure diagram. Trace the path of a packet from the ISP to the database; if it passes through a single firewall, a single switch, or a single power supply unit (PSU), you must install a duplicate component.

Minimum Requirement: No critical service may rely on a single piece of hardware or a single cable.

3. Implement Network Connectivity Redundancy

Control Requirement: Ensure network availability persists during provider outages.

Required Implementation Step: Provision two distinct internet circuits from different physical carriers (e.g., fibre and 5G/microwave). Configure your edge routers (e.g., via BGP or SD-WAN) to failover automatically if the primary link detects packet loss or high latency.

Minimum Requirement: Physically separate entry points for cables into the building to prevent “backhoe fade”.

4. Configure Power Supply Redundancy

Control Requirement: Prevent power interruptions from causing immediate service loss.

Required Implementation Step: Install Uninterruptible Power Supplies (UPS) capable of sustaining the load for safe shutdown or generator spin-up. Ensure servers have dual Power Supply Units (PSUs), with each PSU cabled to a separate power circuit/PDU.

Minimum Requirement: Quarterly battery discharge tests on the UPS units.

5. Deploy High Availability (HA) Server Clusters

Control Requirement: Compute resources must failover transparently.

Required Implementation Step: Configure clustering at the hypervisor level (e.g., VMware vSphere HA, Hyper-V Failover Cluster). Ensure there is enough spare compute capacity (RAM/CPU) on the remaining nodes to absorb the workload if one host fails.

Minimum Requirement: N+1 capacity planning; running at 90% utilisation destroys redundancy capabilities.

6. Implement Storage Redundancy (RAID/Mirroring)

Control Requirement: Data availability must be maintained during disk failure.

Required Implementation Step: Configure RAID 1, 5, 6, or 10 on all physical server arrays. For SAN environments, configure synchronous replication between controllers. Replace “Pre-Fail” disks immediately upon alert, do not wait for total failure.

Minimum Requirement: Hot-swappable drives available on-site for immediate replacement.

7. Architect Cloud Availability Zones (AZ)

Control Requirement: Cloud resources must survive a data centre outage.

Required Implementation Step: Re-architect cloud deployments to distribute workloads across multiple Availability Zones (AZs) within a region. Use Load Balancers (e.g., AWS ALB, Azure Front Door) to route traffic away from an unresponsive zone automatically.

Minimum Requirement: Do not deploy single-instance VMs for critical production workloads.

8. Implement Application Load Balancing

Control Requirement: Application traffic must be distributed to prevent overload and handle node failure.

Required Implementation Step: Place web and application servers behind a Load Balancer (Reverse Proxy). Configure health checks that query a specific application response (not just a ping) to remove unresponsive nodes from the rotation instantly.

Minimum Requirement: Health checks must test the database connection, not just the web server port.

9. Perform “Pull the Plug” Failover Testing

Control Requirement: Redundant components must be proven to work in practice.

Required Implementation Step: Schedule a maintenance window to physically disconnect the primary cable, power source, or shut down the primary node. Measure the actual time taken for the secondary system to take over and verify no data corruption occurred.

Minimum Requirement: Annual live failover test; simulation or “tabletop” exercises are insufficient evidence here.

10. Monitor Redundant Systems Status

Control Requirement: Ensure the backup systems are healthy and ready to take over.

Required Implementation Step: Configure your monitoring system (e.g., Nagios, Zabbix) to alert on the status of the secondary device. Often, a secondary firewall fails silently months before the primary fails, leaving you with zero protection when you need it most.

Minimum Requirement: “Passive” or “Standby” nodes must be actively polled for health status.

ISO 27001 Annex A 8.14 SaaS / GRC Platform Implementation Failure Checklist

The disconnect between GRC dashboard compliance and technical redundancy reality.
Control Requirement The ‘Checkbox Compliance’ Trap The Reality Check
Single Point of Failure (SPOF) GRC tool asks: “Is redundancy implemented?” (Yes/No). You clicked “Yes” because you have two servers, but they are both plugged into the same power strip. One blown fuse kills everything.
Failover Testing Uploading a “Business Continuity Plan” PDF. The plan works on paper. In reality, the IP addresses on the failover unit were never updated, so the failover crashes the network.
Cloud Redundancy “We use the Cloud, so it’s redundant.” You deployed a single EC2 instance. When that hardware degrades, your app goes offline. Cloud is not magic; it requires architecture.
RAID Configuration “Servers have RAID.” The RAID controller battery died three years ago, forcing the cache to write-through, slowing the system, and risking data loss on power cut.
Network Diversity “We have two internet lines.” Both lines enter the building through the same conduit. A single construction accident cuts both cables simultaneously.
Monitoring Standby Green dashboard for “Firewall Status”. The dashboard only pings the active IP. The passive unit failed a firmware update last month and is currently bricked.
Capacity Planning “We have a failover cluster.” The primary node runs at 80% load. The secondary node is older hardware with half the RAM. It crashes instantly under the failover load.
ISO 27001 Toolkit

About the author

Stuart Barker
🎓 MSc Security 🛡️ Lead Auditor 30+ Years Exp 🏢 Ex-GE Leader

Stuart Barker

ISO 27001 Ninja

Stuart Barker is a veteran practitioner with over 30 years of experience in systems security and risk management. Holding an MSc in Software and Systems Security, he combines academic rigor with extensive operational experience, including a decade leading Data Governance for General Electric (GE).

As a qualified ISO 27001 Lead Auditor, Stuart possesses distinct insight into the specific evidence standards required by certification bodies. His toolkits represent an auditor-verified methodology designed to minimise operational friction while guaranteeing compliance.

Shopping Basket
Scroll to Top