ISO 27001 Annex A 8.14: redundancy that survives a failover test

The due-diligence questionnaire asks how your platform survives a failed server. Your answer is "we're in AWS", and the deal waits for something firmer. This guide shows how to meet ISO 27001 Annex A 8.14, redundancy of information processing facilities, with duplication sized to business need and proved by failover tests.

It is written for technical leaders, heads of security and IT operations managers at regulated service providers and scale-ups of 25 to 250 people. You need customer-facing services that stay up and evidence an auditor accepts, without an enterprise budget.

What does ISO 27001 Annex A redundancy of information processing facilities require?

Annex A 8.14 asks that critical services keep running when a disk, link or availability zone fails, because a duplicate was already in place. It is a preventive control carrying availability alone. Its closest neighbours are backup (A.8.13) and ICT continuity planning (A.5.30), and the boundaries between the three matter at audit.

The duplication has to be proportionate. The business decides what availability each service needs, so duplication is never a blanket exercise. It also has to be real. Standbys must be as current and secure as the primaries, alerting must announce a failover, and tests must prove the switch works before an outage runs the test for you.

The difference is timescale and purpose:

• Redundancy (A.8.14) keeps a service up through a component failure, with seconds or minutes of disruption.
• Backup (A.8.13) gets data back after loss, on a timescale of hours.
• ICT readiness for business continuity (A.5.30) plans how ICT keeps the business running through full disruption. Redundancy supplies much of that plan's machinery.

Because Annex A 8.14 carries availability alone, it can look simple. Duplication creates side risks to the other two properties, though. Replication errors can spread corruption, and a weakly secured standby weakens confidentiality, so the design has to answer for both.

Which information processing facilities fall in scope of Annex A 8.14?

Information processing facilities cover every system, network path and utility a critical service depends on. That means servers and cloud compute, managed database clusters, network links and firewalls, plus the office connectivity and power that stay on-premise. The scoping method is to trace one critical service end to end and list each single, un-duplicated link.

Start from a service, not an asset register. Pick the one customer-facing system the business cannot lose and follow a request from the customer to the data and back. At each hop, ask:

• Compute: does it run on one instance or in one zone?
• Database: is it a single node, or a managed cluster with automatic promotion?
• Network: is there one load balancer, one firewall, one internet line?
• Supporting services: do DNS, power and the office link that engineers use to operate the service have a spare?
• People: does one engineer hold the only working knowledge of the passwords?

Every link you find goes on a list. The business impact analysis in the next section then ranks the fixes, so the list shortens by priority rather than guesswork. Repeat the trace for each critical service.

How do you set availability targets that justify redundancy?

Set availability targets with a lightweight business impact analysis: rank services by how long the business survives without them, then assign a recovery-time and data-loss target to each tier. Those targets justify what you duplicate and what you deliberately leave single, preventing both under-provisioning and multi-region gold-plating.

A business impact analysis is lighter than the name suggests. For a 50-person firm it is a workshop and a spreadsheet. The steps run in this order:

1. List the services that customers and revenue depend on.
2. Rank them by tolerance: how long can each be down before contracts, regulators or renewals suffer?
3. Set two targets per tier: a recovery time and an acceptable data loss.
4. Map each tier to a pattern: multi-zone for the critical tier, a documented manual procedure for internal tools, nothing extra for the rest.

UK regulators expect this discipline. FCA PS21/3 Building operational resilience requires banks, insurers, payment firms and other firms in its scope to map important business services and test that they can stay within impact tolerances. Firms outside that scope can borrow the same method and gain a defensible answer to a client's questionnaire.

The yardstick cuts both ways. It exposes under-provisioning, such as a customer portal on a single server. It also blocks over-engineering: multi-region active-active for a firm whose honest tolerance is a few hours burns money and complexity the analysis never asked for. Do the analysis once and reuse it for A.5.30 continuity planning.

Does running in the cloud satisfy Annex A 8.14 on its own?

No. Under shared responsibility, the cloud provider supplies zones, load balancers and replication. A workload deployed into one availability zone is still as fragile as a single server. NCSC Cloud Security Principle 2 recommends building high-availability architecture across multiple data centres within one provider; configuring that is your job.

The NCSC Cloud Security Principle 2: Asset protection and resilience explains why. Providers usually define service level agreements per service, not for the whole platform, so the contract may not offer the availability you need. The NCSC says redundancy in your own architecture can close that gap. Read the SLA for each service you depend on, because the one you assumed covers your database may not.

The trap is assumed resilience: everything in one availability zone, one internet line into the office, behind one firewall nobody dares reboot. Auditors know the pattern, and they check for it.

A diagram shows what you meant to build. The cloud console shows what you built.

The pattern that closes the gap has three parts:

• Compute in at least two availability zones, so losing one zone leaves capacity serving customers.
• A load balancer with health checks in front, removing unhealthy targets without a human.
• Database replication with automatic promotion, using the managed failover your provider offers.

For most firms this is a design decision, not a large spend. In a cloud-native estate, moving the critical tier to multi-zone with tested failover is typically two to four weeks of engineering. Multi-region is the expensive tier, and only a business impact analysis target that demands it justifies it.

What redundancy do physical and on-premise estates need?

Physical and on-premise estates need a second path wherever one failure would sever the site. That means a second internet provider on a diverse route, paired firewalls and network devices, dual power supplies, and a UPS where equipment matters. Pair that with enough capacity that one surviving unit can carry the full load.

Each pattern answers a specific single point of failure:

• Internet: a second provider on a physically diverse path, because two contracts sharing one route fail together.
• Network devices: paired firewalls and switches, so one failed box does not cut the office off.
• Power: dual power supplies on critical equipment, with a UPS behind them. Larger sites add a generator.
• Storage: RAID or replication, so a single disk failure does not take the volume down.

Capacity management under A.8.6 is the quiet dependency. A standby that cannot carry the full load is redundancy in name only. Recheck the headroom whenever demand grows, in the cloud as well as on-premise.

Keep the contract with the second internet provider next to the topology diagram, since both are evidence. For cloud-first firms the remaining physical estate is small, so this list is usually short.

How do you stop a standby rotting or failing silently?

Hold every standby to primary standard (same patch level, same hardening, same monitoring) and alert when redundancy is consumed. A stale standby fails when called or becomes an attacker's easier way in. A node that dies while its twin silently absorbs the load leaves you running without a spare.

Parity fails through routine habits. A patch window covers the primary pool and skips the passive node. A hardening baseline is applied at build and never rechecked. A standby is left out of monitoring because it carries no traffic. Hold the standby to the primary on four fronts:

• Patch level: identical, confirmed by comparison rather than memory.
• Hardening: the same baseline and the same endpoint protection.
• Monitoring: the same agents and the same log forwarding.
• Configuration: the same settings, with drift treated as a defect.

Alerting on consumed redundancy is a separate job from alerting on outage. A dead node whose twin absorbs the load causes no outage, so uptime monitors stay green. Configure health monitoring to page someone when redundancy is consumed. Running unprotected then becomes a tracked state with an owner instead of an unknown.

Lock down the switching gear as well. DNS records, load balancers and replication settings can take everything down in one bad change. Protect admin access to them with least privilege and MFA, as you would for any crown jewel.

How do you run and evidence a failover test?

Run failover tests on a schedule, preferably in production during a quiet window. Kill a node, watch the takeover and time it against the target recovery time, then record the result and fix what surprised you. The test record, with timings and findings, is the evidence auditors weight most.

Production beats staging because a staging pass proves the staging environment. Where the tolerance does not allow a production test, say so in the record and explain what you used instead. The method is five steps:

1. Pick the target and the window: one component of one critical service, agreed with its owner.
2. State the expectation: the recovery time from the service's tier in the business impact analysis.
3. Kill the node, link or zone and watch the takeover.
4. Time it against the target, noting errors and data lag.
5. Record and fix: findings, an owner, a fix date and a retest.

A standby that has never carried production load is a spare part, not redundancy.

The record is what the auditor reads: schedule, method, measured switchover time against target, findings and the fixes that followed. An overdue test, or a test whose findings nobody actioned, reads as weak evidence.

Failover that exists only on the diagram is discovered broken during the real outage it was built for. A scheduled test turns that discovery into a ticket on an ordinary Tuesday.

What will an auditor ask about ISO 27001 Annex A 8.14?

Expect the auditor to pick one critical service and walk its path for an un-duplicated link. They then ask for the console view behind your diagram, the latest failover test report and a standby's patch state. A critical service with an unmitigated single point of failure and no accepted-risk decision grades major.

The questions start with the business and move to the technology. Prepare answers to these:

• Which systems can the business not operate without, and where is the analysis that says so?
• Which single points of failure have you accepted, and who signed off?
• What did you kill in your last failover test, how long did takeover take, and what did you fix?
• You are in the cloud: show that production spans more than one zone.
• How would you know if a redundant component had failed and its partner was carrying everything?
• Who can change DNS or the load balancer, and what protects that access?

Deliberate single points of failure are allowed. Write the decision down: the service, the tier that justifies it, the risk accepted and the name of the person who signed. That record separates a managed gap from an unmitigated one.

Grading follows certification-body practice:

• Major: a business-critical service with a known, unmitigated single point of failure and no accepted-risk decision, or failover that has never been tested.
• Minor: an overdue test, a standby lagging on patches, or an out-of-date topology diagram.
• Pattern: repeated minors can add up to a major.

How can you automate Annex A 8.14 evidence with Terraform and pipeline tests?

Automate the evidence by treating resilience as infrastructure. Terraform holds multi-zone placement, health checks and replication settings. A scheduled policy check fails when someone removes redundancy from a critical service, and pipeline jobs run failover tests and write results to the evidence store. Drift and consumed-redundancy alerts open tickets.

Each layer produces one artefact an auditor asks for:

• Architecture-as-code assertions. The repository records the intended design, and the policy check fails loudly if a critical service quietly loses its second zone.
• Failover tests as pipeline jobs. The kill-a-node test runs on a calendar, and switchover time, errors and data lag land in the evidence store. Think chaos engineering, sized for a 50-person firm.
• Redundancy-consumed alerting. Monitoring separates "service down" from "spare in use", and the second condition opens a ticket automatically.
• Parity watch. A scheduled diff of patch and configuration state between primaries and standbys raises a ticket on drift.

At this scale the result is a resilience posture that proves itself. The auditor's sample becomes a query against records that already exist, and an engineer who removes a zone meets a failed check instead of a finding months later.

Frequently asked questions