Zum Hauptinhalt springen
CENEDRIL WIKI
DE
Annex A · Technological Control

A.8.14 — Redundancy of Information Processing Facilities

Updated on 4 min Reviewed by: Cenedril Editorial
A.8.14 ISO 27001ISO 27002BSI INF.2

The primary database server fails at 2 AM. The failover database — supposedly in hot standby — has not replicated for three days due to a silent synchronization error. The recovery takes twelve hours instead of the expected fifteen minutes. A.8.14 requires that redundancy is planned, implemented and tested — because untested redundancy is indistinguishable from no redundancy.

The control ensures continuous operation by requiring organizations to identify availability needs and implement appropriate redundancy — from duplicate components to geographically separated systems.

What does the standard require?

  • Identify availability requirements. Determine the availability targets for each business service and underlying system.
  • Implement appropriate redundancy. Deploy redundant components (power supplies, network links, storage) or entire systems (active-passive clusters, multi-site deployments) based on availability targets.
  • Enable failover. Define whether failover is automatic or manual, and document the failover procedure.
  • Test redundancy regularly. Verify that failover works as expected through scheduled tests.
  • Maintain security parity. Redundant systems must have the same security controls as primary systems.

In practice

Conduct a business impact analysis. For each business process, determine the maximum tolerable downtime and the required availability percentage. This drives your redundancy decisions: a 99.99% target demands fundamentally different architecture than 99%.

Implement redundancy at every layer. Eliminate single points of failure: dual power supplies, redundant network paths, clustered servers, replicated databases, multi-zone cloud deployments. Map your architecture and identify every component where a single failure causes an outage.

Automate failover where possible. Manual failover introduces delay and human error. Use load balancers, database replication with automatic promotion and cloud availability zones with auto-failover. Reserve manual failover for scenarios where automatic switching carries too much risk.

Schedule and document failover tests. Simulate failures (pull a network cable, stop a database node, fail a cloud zone) and verify that the system recovers within the expected timeframe. Document every test: date, scenario, expected outcome, actual outcome, corrective actions.

Typical audit evidence

Auditors typically expect the following evidence for A.8.14:

  • Availability requirements — documented targets per system, derived from business impact analysis (see IT Operations Policy in the Starter Kit)
  • Redundancy architecture — documentation showing redundant components and failover paths
  • Failover test records — documented test results with timing and findings
  • Uptime reports — actual availability metrics compared against targets
  • Security parity evidence — proof that redundant systems have equivalent security controls

KPI

Percentage of critical processing facilities with tested redundancy measures

Measured as a percentage: how many critical systems have documented redundancy and a failover test completed within the last 12 months? Target: 100%.

Supplementary KPIs:

  • Actual availability vs. target availability per critical system
  • Mean time to failover (measured during tests)
  • Number of unplanned outages caused by single points of failure

BSI IT-Grundschutz

A.8.14 maps to BSI modules for redundancy and business continuity:

  • INF.2 (Data Centre) — redundancy requirements for data centre infrastructure: power, cooling, network connections.
  • DER.4 (Emergency Management) — business continuity planning that drives redundancy requirements.

Sources

Frequently asked questions

Does every system need redundancy?

Only systems whose availability requirements justify the investment. Define availability targets per system (e.g., 99.9% uptime) based on business impact analysis. Systems with low availability requirements may not need redundancy beyond regular backups.

Is cloud auto-scaling redundancy?

Auto-scaling addresses capacity, but availability requires multi-zone or multi-region deployment. A single cloud availability zone can fail entirely. True redundancy means your application continues operating when an entire zone or region goes down.

How often should failover be tested?

At least annually for all redundant configurations. For critical systems, semi-annual or quarterly tests are recommended. Every test should be documented, including failover time, data consistency verification and any issues encountered.