ISO 27001 A.8.14: Design redundancy around real failure conditions

What A.8.14 requires in practice

A.8.14 requires information processing facilities to have enough redundancy built in to satisfy availability requirements. Redundancy means spare or alternative capability, such as a standby system, a second network route or an alternative supplier, so a single failure need not stop an important service.

The control is measured against availability requirements, which the business has to define first. A service that can tolerate a day of interruption needs less than one that cannot tolerate a few minutes. The word sufficient matters: more redundancy is not automatically better, and too little leaves the business exposed. The organisation also has to consider how failures could affect both the main and the alternative arrangement at once.

Outputs include defined availability needs, redundancy matched to them and evidence that the alternative works when called upon. The control does not require duplicate hardware everywhere or a specific design. Sterling's teams often check shared dependencies, such as one power feed or one provider behind two connections, as a method for finding hidden single points of failure.

Start with the availability requirement

Identify the business service, the disruption it can tolerate and the consequences of losing particular components. Some services may justify rapid automatic transfer, while others can operate with an agreed manual recovery process. The decision should reflect business needs and applicable commitments rather than a technical preference alone.

Understand the complete dependency chain. An alternative application server may still rely on the same network, power supply, identity service or storage. Redundancy at one layer does not establish resilience at every layer. Describe which failure conditions the design addresses and which remain outside its intended protection.

Why redundancy matters to the business

When a key service stops, the cost is counted in missed deliveries, penalties, idle staff and customers who go elsewhere. Redundancy reduces that exposure, but only when it is designed around real failure conditions. Two connections that share a single physical route, or a standby system that nobody has switched to in practice, provide comfort without protection. Matching redundancy to the stated availability needs also controls cost, because the business spends where an interruption would hurt most. Clients with demanding service agreements want evidence that the supplier can survive a component failure. Auditors value a tested alternative because it shows availability is managed as a capability, not assumed from equipment lists.

How to implement A.8.14

Begin with how long each service can be unavailable and what the business loses when it is. Redundancy is then a way of meeting that need, not an end in itself.

1. Agree availability requirements for the important services with the people who depend on them.
2. Identify single points of failure, including shared power, network routes, suppliers, people with unique knowledge and common software.
3. Choose redundancy that fits each requirement, from a simple standby to an automatic alternative, and record why.
4. Plan how the alternative is activated, who decides and how information security is preserved while it is in use.
5. Test the changeover under realistic conditions, including the return to normal operation.
6. Act on findings, such as an alternative that cannot carry the real load, a changeover that needed unplanned manual steps or a security setting that was missing on the standby.
7. Revisit the design when services, suppliers or availability needs change, and record who accepted any remaining single point of failure.

Evidence an auditor expects for A.8.14

An auditor will look for redundancy that matches stated needs and has been shown to work. Typical evidence includes:

• the availability requirements for important services and how they were agreed;
• design records or diagrams showing alternative components and routes;
• records of tests or real events in which the alternative took over, with the observed result;
• observation of the standby arrangement and its configuration with the service owner;
• an interview about how a changeover would be decided and managed.

The strongest evidence is a test or genuine failure that shows how the alternative performed. A diagram of a second component is weaker than a record of it carrying real work.

Examine shared causes of failure

Illustrative IT example: two connections through one route

Illustrative manufacturing example: a standby scheduling service

A hypothetical manufacturer maintains a standby service for production scheduling. An authorised exercise transfers operation successfully, but staff cannot access the latest approved planning data through the alternative environment. The component is running, while the business function remains impaired.

The team reviews data availability, permissions and the sequence of activation, then repeats a representative operational check. It also confirms the alternative's capacity for the agreed minimum service. The result establishes whether planners can perform their required work, rather than relying on a technical indication that a server has started.

Plan activation and preserve security

Define how a failure is detected, who can initiate the transfer and whether activation is automatic or manual. Clarify the information needed to decide that the alternative should take over. An automatic mechanism still needs suitable configuration and monitoring; a manual process needs available, competent people and accessible instructions.

Maintain appropriate protection on the alternative. Infrequently used systems can drift behind current access, configuration or update requirements. Additional copies and synchronisation can also introduce confidentiality or integrity risks. Evaluate those effects when designing the arrangement instead of treating availability as the only security property that matters.

Test what happens during and after transfer

Plan tests within authorised boundaries and an acceptable operational risk. Relevant exercises can check detection, activation, usable service, data consistency and the return to normal operation. Where a live test would be unsafe, document what the chosen simulation establishes and which assumptions remain unverified.

Useful evidence includes the availability requirement, design rationale, dependency analysis, activation arrangements and test results. These are practical ways to demonstrate the control, not a prescribed set of forms. Record limitations and actions from a failed test; a report stating only that an exercise occurred does not establish its outcome.

Common failures include never using the standby environment, maintaining different security settings and claiming protection against software faults that affect both copies. Redundancy does not automatically correct a defect replicated across the design. Keep backup and restoration available for the different problem of recovering trustworthy information.

Evaluate the arrangement through ISMS performance review, particularly after architecture changes or revised customer commitments. A design that met last year's demand may no longer satisfy current availability needs, even if every component still reports a healthy status.