Availability is not achieved by hope.
It is achieved by designing systems that continue to operate when something fails.
Annex A 8.14 exists to ensure organisations build appropriate redundancy into information processing facilities, so services remain available despite component failure, disruption, or increased demand.
This control is about engineering resilience, not reacting to outages.

Annex A 8.14 of ISO 27001:2022 focuses on redundancy of information processing facilities.
At a practical level, this means:
The control does not require full duplication everywhere. It expects risk-based, proportionate redundancy aligned to business need.
Information processing facilities include:
When these fail without redundancy:
Annex A 8.14 ensures organisations design availability into systems, rather than relying solely on incident response or disaster recovery.
This control supersedes ISO 27001:2013 Annex A 17.2.1 and represents one of the most significant shifts in the 2022 revision.
A pragmatic approach to Annex A 8.14 typically includes the following elements.
Organisations should identify:
Not all systems require the same level of redundancy.
For critical systems, organisations should identify:
Single points of failure undermine availability by design.
Redundancy may be implemented through:
The level of redundancy should reflect:
Redundancy without justification creates waste.
Lack of redundancy creates outage.
Annex A 8.14 applies to both:
Cloud environments still require deliberate redundancy design.
Supplier concentration increases availability risk.
Organisations may consider:
Supplier diversity reduces systemic failure risk.
Where availability requirements justify it, organisations should consider:
Geographic redundancy supports resilience against widespread disruption.
Redundancy is only effective if systems:
Manual failover may be appropriate in some cases, but expectations should be clear and tested.
Redundant components should not be neglected.
Organisations should ensure:
Out-of-date redundancy often fails when needed most.
Untested redundancy is theoretical.
Organisations should:
Testing should occur during normal operations where possible, not only during incidents.
Annex A 8.14 strongly supports business continuity objectives.
Redundancy should align with:
Redundancy is preventative continuity.
Annex A 8.14 does not require:
It does require organisations to:
Most major outages occur where redundancy was assumed, not designed.
Availability failures are usually architectural, not accidental.
Annex A 8.14 is about keeping services running when components fail.
When redundancy of information processing facilities is implemented effectively:
Failure is inevitable.
Total outage is not.
Annex A 8.14 ensures organisations plan for failure — and continue operating anyway.
We can help you understand your actual security needs and even if we cant help we can point you in the right direction
Talk to a security expert today