Redundancy of information processing facilities

Plain-language summary

Building enough duplication into systems, networks, power and service providers that the failure of one component does not take down a service the business needs, with the level of redundancy set by agreed availability requirements rather than habit.

What the clause is really asking

Backup gets you back after a failure; redundancy keeps you running through it. The control asks you to identify the availability requirements for business services and the information systems behind them, then design and implement enough redundancy to meet them: duplicate components such as servers, storage, power supplies and network links; more than one supplier for critical connectivity; separate locations where the requirement justifies it; and failover that has been tested. Where redundancy cannot be built, other measures, usually backup and a recovery plan, must fill the gap. Redundancy brings its own risks: replicated systems copy corruption and ransomware encryption as faithfully as good data, and failover that is never tested often fails when needed. In South Africa, load-shedding and grid instability make power redundancy a practical question — UPS, generator or inverter capacity sized for how long systems must keep running — and fibre outages make a second internet link on a different route or technology more than a luxury. For cloud services, check that availability zones and service levels match your requirement.

What auditors look for

Auditors ask for the availability requirements of critical services and then for the design that meets them, looking for single points of failure: one internet link, one firewall, one server running the ERP, one power feed to the server room. They ask when failover was last tested, what happened and whether it was recorded. They check UPS and generator maintenance records and how long systems can run on battery. For cloud services they compare the provider's service levels and zone design with your stated requirement. The hard question: if your main internet link failed right now, what would stop, and for how long?

Typical evidence

Availability requirements per critical service, typically from the business impact analysis; architecture diagrams showing redundant components; single-point-of-failure analysis with decisions; failover test records with outcomes; UPS, generator and inverter capacity and maintenance records; contracts for secondary connectivity; cloud service-level agreements and zone or region configuration; records of incidents involving redundant components.

How to comply — recommendations

Take the critical services from your business impact analysis and write down how long each can be unavailable. For each, draw a simple diagram from user to data and mark every single point of failure: power, internet link, firewall, switch, server, storage, key supplier. Fix the ones that break the requirement — a second internet link on a different technology, a UPS or inverter sized for your outage profile, a second firewall in high-availability mode, cloud workloads across more than one zone — and accept the rest in writing. Test failover at least annually, for example by disconnecting the primary link out of hours, and record the result. Maintain UPS batteries and generators to a schedule.

Common nonconformities

Availability requirements never defined; single points of failure in critical services not identified or formally accepted; failover never tested, or tested without records; UPS batteries unmaintained or runtime unknown; a single internet link for a business that cannot operate offline; redundant links sharing the same physical route; cloud workloads in one zone despite high availability needs.

Resources for this clause

• ArticleISO/IEC 27001:2022 Annex A explained: the 93 controls in plain English, theme by theme, with the 114-to-93 map and the attribute tags
• ArticleThe Statement of Applicability, explained — what ISO/IEC 27001 clause 6.1.3 requires, the four ways an SoA fails Stage 1, and how to build one from the risk register
• ArticleISO/IEC 27001:2022 explained for people who already run ISO 9001: what is the same, what is new, and how to get certified
• Toolkit · $39Risk & SoA ToolkitScore your information security risks on a documented method, pick the Annex A controls that treat them, and the Statement of Applicability writes its own first draft — every justification citing the risks behind it.
• Toolkit · $29ISMS Metrics & Evidence TrackerThe three things an ISMS has to show after certification, in one workbook: measures with a live Green / Amber / Red status, management review minutes that cover every required input, and an evidence register that gives every control an owner, a rhythm and a due date.
• Free downloadAnnex A 93 Controls Quick ReferenceOne A3 page: all 93 Annex A controls in their four themes, the eleven new in 2022 flagged, and the ISO/IEC 27002:2022 attribute legend — the poster for the wall beside the Statement of Applicability.
• Free downloadISO 27001 Gap Analysis ChecklistWhere you stand against ISO/IEC 27001:2022 in one afternoon — the 30 management-system requirements and all 93 Annex A controls, scored, with owners, dates and a readiness figure that calculates itself.
• Free masterclass · ~27 minISO 27001 MasterclassYou already know four fifths of ISO 27001. Here is the other fifth — the risk method, the SoA, the 93 controls, the evidence rhythm, POPIA, and a 44-week path.
• Free appAudit ManagerPlan the programme, anchor each finding to its clause and drive the NC to closure.