In the transition from ISO 27001:2013 to the 2022 update, the way we talk about keeping the lights on has become much more sophisticated. If you are looking at your old Statement of Applicability (SoA) and trying to find where your redundancy requirements moved, they are now under Annex A 8.14: Redundancy of Information Processing Facilities.
While the previous standard had a general requirement for availability, the 2022 revision pushes organisations to move beyond “theoretical” resilience. It’s no longer enough to have a spare server gathering dust in a cupboard; the new standard expects a integrated, technical, and most importantly, tested approach to redundancy.
Table of contents
The Structural Evolution: From 17.2.1 to 8.14
In the 2013 version of the standard, redundancy was found in Control 17.2.1 (Availability of information processing facilities). It was tucked away in Domain 17, which focused on Information Security Aspects of Business Continuity Management.
In the ISO 27001:2022 update, the standard moved to a streamlined structure of four themes. Annex A 8.14 is now classified as a Technological Control. This is a significant shift. According to Hightable.io, moving this control from a “Continuity” category to a “Technological” one highlights that redundancy is now viewed as a primary technical safeguard that should be baked into your architecture, not just a plan you pull off a shelf during a crisis.
What is Annex A 8.14 Redundancy of Information Processing Facilities?
The core objective of Annex A 8.14 is to ensure that information processing facilities – your servers, networks, cloud instances, and even physical offices have enough redundancy to meet your availability requirements. It’s about ensuring that a single failure doesn’t lead to a total outage.
Redundancy in this context covers several layers:
- Hardware: Dual power supplies, RAID storage, and spare parts.
- Network: Multiple internet service providers (ISPs) or diverse routing paths.
- Software: Load balancers and failover clusters.
- Geography: Using different cloud regions or physically separate data centres.
Key Changes and New Requirements in the 2022 Version
If you are familiar with the 2013 version, you’ll notice that Annex A 8.14 is more prescriptive about how you achieve resilience. Here are the main changes:
- Expansion to Cloud Environments: The 2013 version was very hardware-centric. The 2022 update explicitly addresses modern cloud-native redundancy, such as using multiple Availability Zones (AZs) or multi-cloud strategies.
- Focus on Active Failover: There is a stronger push toward automated failover and load balancing. The standard wants to see that your systems can react to a failure in real-time without human intervention where possible.
- The Testing Mandate: This is a major area of auditor focus. While 17.2.1 implied testing, 8.14 makes it clear: redundancy that isn’t tested is just a “hope,” not a control. You must provide evidence of failover drills and test results.
- Integration with BIA: The standard now more clearly links redundancy levels to your Business Impact Analysis (BIA). You are expected to apply higher levels of redundancy to “Mission Critical” systems while accepting more risk for “Low Impact” ones.
The Role of Attributes in Annex A 8.14
A central feature of the 2022 update is the use of “Attributes.” For Annex A 8.14, these help you define the control’s purpose in your risk assessment. According to Hightable.io, these tags are vital for aligning with other frameworks like NIST or CIS:
| Attribute | Value for Annex A 8.14 |
|---|---|
| Control Type | Preventative |
| Information Security Property | Availability |
| Cybersecurity Concept | Protect |
| Operational Capability | Continuity |
Practical Steps for Compliance
Transitioning to the 2022 standard requires moving from “set and forget” hardware to “live and monitored” systems. Here is how to meet the new A 8.14 criteria:
- Define Your Criticality: Use your BIA to set specific Recovery Time Objectives (RTO). If a system needs to be up in minutes, it needs automated redundancy.
- Map Single Points of Failure: Look for “sneaky” single points of failure. You might have redundant servers, but do they all rely on a single power circuit or one network switch?
- Implement Monitoring and Alerts: You must be notified immediately when a redundant component fails. If your primary power fails and the secondary takes over, you need to know before the secondary also fails.
- Keep Evidence of Tests: Don’t just test; document it. Keep logs showing that you simulated a failure and the failover worked as expected.
Why the Change Matters
The shift to Annex A 8.14 reflects the “always-on” expectation of modern business. In 2013, a server going down for an hour was an annoyance; today, it’s a headline-worthy disaster. By categorising redundancy as a Technological Control, ISO 27001:2022 forces organisations to treat uptime as a core security feature rather than an afterthought of the IT department.
As Hightable.io points out, a successful audit of A 8.14 is about proving resilience. It moves your organization from a fragile state to a resilient one where hardware or network failures are absorbed quietly, without the customer ever noticing.
Final Thoughts on the Transition
The move from 17.2.1 to 8.14 is a positive step toward more robust, modern infrastructure. While the 2022 version requires more rigorous testing and more detailed documentation of your “failover logic,” the result is a much higher level of confidence in your business’s ability to survive a crisis.