Single point of failure definition
A single point of failure is one person, system, process, or dependency whose unavailability can interrupt an entire important operation because no effective alternative or backup exists. In knowledge work, it often appears when only one employee can explain, access, approve, or perform a critical task.
Where single points of failure hide
They appear in one-person approvals, privately held customer relationships, sole administrator accounts, undocumented specialist processes, and spreadsheets only one employee understands. A backup named on an organization chart does not remove the risk unless that person has the knowledge, access, authority, and practice to act.
The dependency may be technical or human; many operational failures combine both.
Single-point-of-failure example
One operations analyst runs a daily integration, holds the only production credential, and knows how to correct rejected records. A written schedule does not protect the process. The organization needs controlled backup access, a runbook covering exceptions, and a second analyst who has successfully completed the work.
Relation to key-person risk
A single point of failure describes the structural dependency. Key-person risk describes the business exposure created when that dependency is a person. One employee can also contain several single points of failure across access, expertise, relationships, and approvals.
Removing them reduces continuity risk during departures, absences, and ordinary operational disruption.
Frequently asked questions
What is a people-related single point of failure?
It is a dependency on one person for essential knowledge, authority, access, relationships, or task execution. If that person is absent or leaves, the work cannot continue at the required level.
How do you identify a single point of failure?
Trace each critical process and ask what happens if every person, system, approval, supplier, or credential in the chain becomes unavailable. Look for steps with no capable backup, alternative route, shared access, or recoverable record.
How do you remove a single point of failure?
Create a real alternative: cross-train a backup, distribute authority appropriately, use controlled shared access, document critical context, add system redundancy, and test whether the alternative works without the original dependency.