Single point failures are the dependencies your organization cannot lose and cannot replace in time. The Cybersecurity and Infrastructure Security Agency (CISA) has a precise single point of failure definition, and it is worth starting there, because most organizations look for these failures in the wrong places.
They look in the data center. The worst ones are usually in the org chart, the vendor list, and the building lease.
The CISA single point of failure definition
CISA does not keep a one-line glossary entry for the term, but two of its published assessment guides define it plainly.
CISA’s External Dependencies Management (EDM) Assessment guidance (April 2020) says:
“A single point of failure means that a single disruption or interruption involving an external entity would cause a failure or significant disruption of the critical service.”
It adds an example: “a supplier that is the sole source of a critical service or critical asset, and for whom there is no substitute readily available (i.e., on standby or actively operating in parallel).”
The Public Safety Communications Network Resiliency Self-Assessment Guidebook, published by the Department of Homeland Security’s Emergency Communications Division and hosted by CISA, defines it this way:
“A key dependency, such as a single line of service from a single service provider, or other single source of componentry or connectivity which, if lost or damaged, could result in a system failure”
Put the two together and you get a working definition for any business: a single point of failure is one person, place, system, or supplier that a critical service depends on, with no substitute ready, so that losing it stops the service.
Two words in CISA’s language matter most. “Critical” means you don’t hunt for every dependency, only the ones under services the business cannot do without. “Readily available” means a backup on paper doesn’t count. If the alternative takes three weeks to stand up and the service can only be down for one day, you still have a single point of failure.
Where single points of failure hide
We plan for four consequences of disruption: loss of your people, your facility, your technology, or a critical third party. Single points of failure live in all four. On Managing Uncertainty, Episode 106, I framed the question this way: “Is there a single point of failure in one geography, one facility, one piece of software, one server, or one person?”
People
The engineer who is the only one who knows how to restore the billing system. The executive whose approval every payment over a threshold requires. The business continuity program run by one person. These are the most common single points of failure we find, and the least documented, because nobody puts “Dana knows how this works” in a system inventory.
Crisis teams have them too. If the one person who knows what was decided in the last ransomware tabletop exercise leaves, so does the decision. I wrote about that in Your Crisis Decision History Is a Single Point of Failure.
Facilities
One distribution center that ships everything. One plant that makes the product nobody else can make. One headquarters where every critical team sits on the same floors. Remote work removed this risk for many office teams, and some return-to-office plans are quietly putting it back.
Technology
Technology single points of failure are rarely the server everyone worries about. They are the shared services underneath everything else: identity and single sign-on, DNS, the network circuit, the cloud region.
Amazon’s own summary of the February 28, 2017 S3 outage in its Northern Virginia (US-EAST-1) region is the clearest example I know. A team member running an established playbook entered one input incorrectly and removed more servers than intended. Then AWS found it could not update individual service statuses on its own Service Health Dashboard, because the dashboard’s administration console depended on S3. The tool built to tell customers about the outage depended on the thing that was down. AWS later changed the console to run across multiple regions.
I’ve sat in BIA interviews where one systems engineer called losing Active Directory “no big deal,” and the head of systems engineering named Active Directory and single sign-on as the two failures that would put them “in a world of trouble.” The business leader in the room said he could just work from home. He couldn’t. Working from home ran through the same sign-on.
Third parties
This is CISA’s focus, and for good reason. The sole-source supplier, the business process outsourcer that handles half your transactions, the one software platform that runs operations.
The trap is the redundancy you think you bought. CISA’s Cyber Resilience Review resource guide on external dependencies describes organizations that sign contracts with multiple telecommunications providers “only to discover that all of their traffic is over the same physical line, or that an unknown third party supports all of these providers.” The same guide warns that cost cutting can eliminate the vendors that provided redundancy, “leaving one vendor as the single point of failure.”
Two vendors on one circuit, or one cloud region, or one subcontractor, are one vendor.
| Old View | New View |
| Single points of failure are an IT problem | Single points of failure are a business problem in four places: people, facilities, technology, and third parties |
| A second vendor means redundancy | A second vendor on the same line, region, or subcontractor is the same vendor |
| Eliminate every single point of failure | Eliminate the ones under critical services, and formally accept the rest |
| Find them once, during the BIA | Look again every time a vendor, system, or key person changes |
How to find single points of failure
You don’t need a new methodology. You need to ask the right questions of the right people, in this order.
- Start with what is critical. Your business impact analysis tells you which services the business cannot lose, and for how long. That is CISA’s “critical service.” If you don’t have a current BIA, start there; our guide to the business impact analysis walks through it.
- Map what each critical service depends on. For each one, list the people, facilities, technology, and third parties it needs. Then ask what those depend on. The second layer is where shared identity, shared circuits, and shared subcontractors show up. Our IT disaster recovery guide covers dependency mapping in more detail.
- Ask the people who actually do the work. Executives know what is important. The people closest to the work know what it depends on. Ask them: “If you were out for a month, who would do this?” and “What would stop you on Monday morning?”
- Test every “we have a backup.” For each alternative, ask how long it takes to activate and whether anyone has ever done it. Compare that with how long the service can be down. If the backup is slower than the tolerance, it is not a backup.
- Check for common modes of failure. Look for two “independent” options that share a building, a power feed, a cloud region, a carrier, or a person.
- Look again after every change. A vendor consolidation, a reorganization, a retirement, or a cloud migration can create a new single point of failure overnight.
How to fix single points of failure
You will not eliminate all of them, and you shouldn’t try. When you protect everything equally, you’re protecting nothing well. CISA’s EDM guidance makes the same point: single points of failure have to be “identified and managed as risks (i.e., formally accepted, mitigated, transferred, monitored, etc.).” For each one that sits under a critical service, pick a response.
- Eliminate it. Add real redundancy: a second site, a qualified second supplier, a second region, a diverse circuit that takes a different physical path. This costs the most, so save it for the services the business truly cannot lose.
- Reduce it. For people, cross-train a second person and write down what only one person knows. For processes, document a manual workaround. For vendors, know who your fallback is and what it takes to switch, even without a contract.
- Transfer it. Contract terms, notification requirements, and insurance won’t keep the service running, but they shape who pays and how fast you hear about a problem.
- Accept it, in writing. Some single points of failure cost more to fix than the disruption they could cause. That is a legitimate business decision, as long as the right executive makes it knowingly and it is recorded.
Then exercise it. A recovery strategy nobody has run is an assumption. Your biggest single point of failure probably doesn’t work for you, so bring your critical vendors into the exercise. Our third-party exercises are built for exactly that.
FAQs About Single Point Failures
What is an example of a single point of failure person?
A person becomes a single point of failure when a critical service stops without them. The classic examples are the only technician who can run a key piece of equipment, the only administrator with access to a critical system, and the manager whose approval every decision requires. The fix is a trained backup and written-down knowledge, tested by actually letting the backup do the work.
What is a single point of failure process?
A process becomes a single point of failure when every unit of work runs through one step, one site, or one system with no alternative. A supply chain that ships everything through one distribution center is the common example. If that center floods, the whole flow of goods stops. The fix is a second path, or a documented workaround that has been tested.
What are single point of failure attacks?
Attackers look for the dependency that takes the most down with the least effort. Identity systems, a single internet connection, a shared software provider, and backup systems are favorite targets because one compromise disrupts everything that relies on them. Treat every shared service that many critical services depend on as both a single point of failure and a priority for security controls.
What is a single point of failure strategy?
It is a deliberate decision, for each single point of failure under a critical service, to eliminate, reduce, transfer, or accept it. A good strategy starts from the BIA, assigns each decision to a named owner, records the accepted risks, and is revisited whenever a vendor, system, or key person changes.
Every organization has single points of failure. The resilient ones know where theirs are.
Keep Going
A few ways to go deeper if this was useful.
- Read more. Resilience, crisis management, and continuity writing at Bryghtpath Insights, or the structured Ultimate Guide to Business Continuity.
- Find your dependencies. Our Business Continuity services start with the business impact analysis that shows what your critical services depend on.
- Get a maturity score. Our Resiliency Diagnosis® is a standards-based review that produces a maturity score and a prioritized roadmap.
- Talk to us. Set up a call to think through your program with us.
