ISO 27001 Redundancy: The Essential 2026 Guide to A.8.14

ISO 27001 redundancy is the one Annex A control where the standard refuses to tell you how much is enough — and that is exactly why it fails audits. Annex A 8.14 asks you to build redundancy “sufficient to meet availability requirements,” which means the control has no fixed bar. The bar is whatever your own organization determined, which is why an auditor’s first question is never about your architecture. It is about the piece of paper that says what the architecture was supposed to achieve.

Most companies get this backwards. They buy a second server, or tick the multi-AZ box in a cloud console, and then try to work out afterwards what availability target that bought them. This ISO 27001 redundancy guide covers what A.8.14 actually requires, how it differs from the three controls people confuse it with, the four redundancy patterns and what each one leaves exposed, and the four records that close out the control in a certification audit.

What ISO 27001 redundancy actually requires under A.8.14

Annex A 8.14 is titled Redundancy of information processing facilities. It sits in the technological theme — one of the 34 technological controls in the 93 that ISO/IEC 27001:2022 lists across four themes (37 organizational, 8 people, 14 physical, 34 technological). In ISO/IEC 27002:2022 it carries the preventive control type and the availability property, and it belongs to the resilience security domain.

It is not a new idea. A.8.14 is the 2022 home of the 2013 control A.17.2.1, Availability of information processing facilities. The requirement did not change much; the guidance around it grew considerably, and it moved out of the old business continuity section into the technological controls. If you still hold a risk treatment plan written against the 2013 numbering, this is one of the mappings worth fixing.

The operative word in A.8.14 is sufficient. The control is conditional on an input you supply: your availability requirements. That makes ISO 27001 redundancy a derived control, and it has two practical consequences:

• You cannot be non-conformant for having “too little” redundancy in the abstract. You can only be non-conformant against your own stated requirement — or for never having stated one.
• If you never determined an availability requirement, the control is unauditable as written, and an auditor will raise the finding against the determination, not the hardware.

Like every Annex A control, A.8.14 is reached through your Statement of Applicability, which clause 6.1.3 makes mandatory. Excluding A.8.14 is defensible for an organization whose information processing genuinely tolerates extended outage — but write the justification before the audit, not during it.

Redundancy, backup and ICT readiness are four different controls

This is where most Statements of Applicability blur. Four controls touch availability, and reviewers of an ISO 27001 redundancy claim routinely evidence one with artefacts belonging to another. A backup report is not redundancy evidence, and a disaster recovery plan is not either.

Control	What it governs	The question it answers	Typical evidence
A.8.13 Information backup	Copies of data, retained and restorable	Can we get the data back?	Backup schedule, restore test records
A.8.14 Redundancy of information processing facilities	Duplicate processing capability, live or standby	Can the service keep running?	Architecture record, failover test record
A.5.30 ICT readiness for business continuity	Planning ICT against business continuity objectives	Do we have a plan, and does it match the BIA?	ICT continuity plan, exercise report
A.8.6 Capacity management	Enough resource for current and projected demand	Will we run out of headroom?	Capacity forecast, utilisation trend

The cleanest way to keep them apart: backup is about the past, capacity is about the future, redundancy is about right now, and ICT readiness is the plan that ties all three to the business impact analysis. Our separate guides to ISO 27001 backup, ISO 27001 ICT readiness and ISO 27001 capacity management cover each of the other three in full.

Determine the availability requirement before you buy anything

A.8.14 inherits its target from somewhere else, and there are only three legitimate sources for an ISO 27001 redundancy target.

The risk assessment. Clause 6.1.2 requires you to assess risks to confidentiality, integrity and availability. Availability risks that come out of that process with an unacceptable rating are the ones that justify redundancy spend. If every risk in your register is a confidentiality risk, your register is incomplete, and A.8.14 has nothing to be sufficient for.

Interested party requirements. Clause 4.2 picks up customer contracts, service level commitments and regulatory availability duties. A signed SLA promising a customer continuous service is an availability requirement whether or not anyone internally wrote it down as one.

The business impact analysis. If you run a business continuity programme, the BIA already states maximum tolerable downtime per activity, and RTO and RPO values derived from it. Reuse them. Two different downtime targets for the same system — one in the BIA, one in the ISMS — is a finding waiting to be written.

Write the output as a short table per in-scope service: service name, availability target, maximum tolerable outage, RTO, and the source of the number. That single table is what makes every later ISO 27001 redundancy decision defensible.

Four ISO 27001 redundancy patterns and what each one leaves exposed

Once the requirement exists, the pattern follows from it. These are the four standard options, with the failure mode each one does not address — because that gap is what your risk assessment has to accept explicitly.

Pattern	How it works	Realistic recovery	Relative cost	What it does not cover
Active-active	Two or more live nodes share load; loss of one is absorbed	Seconds, often unnoticed	Highest	Logical faults — bad config or corrupt data replicates instantly to both sides
Active-passive (hot standby)	Standby runs, kept in sync, promoted on failure	Seconds to minutes	High	Silent replication failure; the standby is only as current as the last successful sync
Warm standby	Infrastructure exists and is patched, but is not serving traffic	Minutes to hours	Moderate	Configuration drift between the two environments
Cold standby or spares	Spare hardware, images or reserved capacity, built on demand	Hours to days	Lowest	Anything with an RTO shorter than the build time; supply lead times on parts

Note the pattern in that last column. ISO 27001 redundancy protects brilliantly against component failure and barely at all against the failures that actually take modern services down: a bad deployment, a mistaken deletion, an expired certificate, or ransomware encrypting both halves of a synchronous pair at the same time. Those need backup, change management and immutability — which is precisely why A.8.14 is written as one control among several and not as the availability answer on its own.

Cloud does not inherit your ISO 27001 redundancy obligation

The most common ISO 27001 redundancy evidence pack is a screenshot of a cloud provider’s uptime commitment. It is the wrong artefact, for three reasons.

First, an uptime percentage is not a redundancy design, and the arithmetic is less generous than it looks. A 99.9% monthly commitment permits roughly 43 minutes of unavailability in a 30-day month; 99.99% permits roughly four. If your stated maximum tolerable outage is 15 minutes, a 99.9% service level does not meet your requirement even when the provider fully honours it.

Second, provider redundancy is only engaged by how you deploy. A single instance in a single availability zone sits on a highly redundant platform and is not itself redundant. The platform’s resilience is available to you; it is not applied to you by default. The record an auditor wants is your deployment decision — zones used, replication mode, failover trigger — not the provider’s marketing page.

Third, where you do rely on a provider’s resilience, that reliance is a supplier matter governed by A.5.19 to A.5.22, and the service agreement needs to actually say what you are depending on. Handle it as part of your ISO 27001 supplier assessment rather than as a redundancy control.

The four records that close out A.8.14

A.8.14 is not clause 7.5 documented information, so the standard does not name a mandatory document for it. In practice, four records answer every question an auditor asks about ISO 27001 redundancy:

• The availability requirement. Per service: target, maximum tolerable outage, RTO, and where the number came from. Without this the control has no yardstick.
• The design record. What redundancy exists for each of those services, which pattern it follows, and which single points of failure remain accepted. One page and a diagram is plenty.
• The test record. Dated evidence that failover was actually exercised, who ran it, how long recovery took, and the measured result against the target. This is the record most organizations cannot produce.
• The review trigger. Evidence that redundancy was reconsidered when something changed — a new service, a migration, a capacity increase. Change management is the natural hook.

Treat the test record as the control’s centre of gravity. Untested failover has a long history of not working on the day: the standby that was never promoted, the DNS entry with a 24-hour cache, the certificate installed on the primary only. An annual, scripted, timed failover test with a written result turns A.8.14 from an assertion into evidence, and it is the single cheapest improvement most ISMS programmes can make here.

When the test fails, that is a good outcome, not a bad one — provided you raise it through your nonconformity process and close it. A test record showing a failure and a correction is stronger evidence of a working ISMS than a clean record with no test behind it.

ISO 27001 redundancy and NIST CSF 2.0

If you report against both frameworks, A.8.14 lands in the Protect function’s Technology Infrastructure Resilience category. Two subcategories carry it: PR.IR-03, “Mechanisms are implemented to achieve resilience requirements in normal and adverse situations,” and PR.IR-04, “Adequate resource capacity to ensure availability is maintained.” PR.IR-03 is the direct counterpart to A.8.14; PR.IR-04 corresponds more closely to A.8.6 capacity management. PR.IR-03’s predecessor in CSF 1.1 was PR.PT-5, which named failsafe, load balancing and hot swap as its examples — useful if you are migrating an older crosswalk. The full framework is published free by NIST, and remember that CSF 2.0 carries no certification, so it informs your control set rather than replacing it.

Frequently asked questions

Can we exclude A.8.14 from our Statement of Applicability?

Yes, if you can justify it. The ISO 27001 redundancy test is whether any in-scope service has an availability requirement that component failure would breach. An organization whose only processing is office productivity work, with a tolerance for a day of outage, has a reasonable case. Write the justification against the availability determination, and expect it to be read.

Is a second server enough to satisfy ISO 27001 redundancy?

Only if your stated availability requirement is met by what that second server actually delivers, and you have tested the switchover. A powered-off spare in the same rack, on the same power feed, with no tested promotion procedure, satisfies nothing — it is a cold standby, and it should be documented as one.

How often should failover be tested?

ISO/IEC 27001 sets no interval for A.8.14; any frequency you see quoted is convention, not a requirement. Annually is the common baseline, aligned with your continuity exercise, with an additional test after any material architecture change. Set the interval yourself, record the reasoning, and then meet it — a missed self-imposed interval is a finding.

Does A.8.14 apply to SaaS we only consume?

The redundancy itself is the provider’s to build, but the availability requirement and the decision to accept their resilience are yours. For consumed SaaS, A.8.14 evidence usually takes the form of a documented reliance decision plus the supplier controls in A.5.19 to A.5.22, rather than an architecture of your own.

Does redundancy replace backup?

No, and treating it as a substitute is the most expensive mistake in this area. Synchronous redundancy replicates corruption and deletion as faithfully as it replicates good data. A.8.13 and A.8.14 are separate controls because they answer separate questions.

Where to start

Build the availability requirement table first, because it is the input every ISO 27001 redundancy decision reads from. Until each in-scope service has a stated target with a traceable source, no amount of infrastructure will close A.8.14, because there is nothing for the redundancy to be sufficient against. Then record the design, run one timed failover test, and file the result.

If you would rather not draft the underlying documents from scratch, the ISO 27001 Toolkit ships 165 editable Microsoft Office templates for $99, including the Statement of Applicability, risk assessment and treatment documents, and the backup and availability policies that A.8.14 depends on. For the wider control set, our guide to the 93 ISO 27001:2022 Annex A controls maps where redundancy sits among the other 92.