Mapping Single Points of Failure

A single point of failure is any person, system, supplier, data store, or process step whose loss alone would stop or seriously degrade a service. Mapping them means tracing a service, looking for places where there is no alternative, no cover, and no workaround, and naming those places plainly. Every service has some. The purpose of the exercise is not to eliminate all of them, which is rarely possible, but to know where they are, to judge whether the risk is acceptable, and to decide what cover, redundancy, or workaround is worth building. A single point of failure that is known and owned is a managed risk. One that is unknown is simply a surprise waiting for an incident.

They hide in familiar places. A single person may hold the knowledge to operate a legacy system. A single system may process all transactions for a service, with no standby. A single supplier may provide the only route for a critical data feed. A single data store may hold the only current copy of customer records. A single network path may connect a site to the outside world. They also hide in combinations: two systems that appear independent may run on the same platform, and two teams that appear separate may both depend on the same specialist. Mapping must therefore look for shared supports, not only for obviously solitary components, because shared supports are single points of failure in disguise.

Work through the service map link by link and ask, for each one, what happens if this link fails and nothing else does. If the service stops, and no workaround exists, that link is a single point of failure. Record it as such, with its owner and its impact. Then ask the harder question: what happens if this link and its supposed alternative fail together, because they share a platform, a supplier, or a location? That second question reveals common-mode failures, where redundancy exists on paper but not in practice. The map should show alternatives alongside the links they are meant to cover, so that a false alternative is visible rather than assumed.

Each single point of failure deserves a decision, not merely a label. The options include building an alternative, arranging cover, creating a manual workaround, accepting the risk with eyes open, or redesigning the service so the dependency is less central. The right choice depends on the impact of failure, the cost and feasibility of cover, and the tolerance the firm has set for the service. What matters is that the decision is recorded, owned, and revisited when the service changes. A single point of failure with no decision attached is not managed. It is merely documented, and documentation alone does not keep a service running.

They reappear because services evolve. A workaround that once provided cover may be retired when a system is upgraded. A second supplier may be dropped to simplify operations. A team may lose its deputy through attrition. A data copy that once provided a fallback may stop being updated. Each change can quietly recreate a single point of failure that the map had previously resolved. The remedy is to check for single points of failure whenever the service changes, not only during a periodic review. A change that removes an alternative should be treated as a resilience decision in its own right, with the same ownership as the original mapping.

Test by failing one link at a time in rehearsal and observing whether the service really continues. Announce that a person is unavailable, a system is down, or a supplier is unreachable, and ask the team to demonstrate the alternative rather than merely assert that one exists. Demonstrations expose gaps that assertions hide: a standby system that has not been tested, a deputy who lacks access, or a workaround that depends on the very system that has failed. Under DORA in the EU and under FCA and PRA policy in the UK, the ability to show that a service can withstand disruption is central, and a rehearsed alternative is the strongest form of that showing.