The One-Person Dependency: Measuring and Mitigating Key-Person Risk in Enterprise IT

The Org Chart Hides the Architecture

In many US enterprises, the most important diagram is not the network topology or the application map. It is the list of names in the operations runbook. A single engineer understands the batch schedule that closes the ledger. A contractor knows why the legacy middleware restarts every Sunday. A vendor account manager is the only person who can navigate the support escalation path for a revenue-critical platform. The organization calls this expertise. The risk committee should call it concentration.

Key-person risk is often treated as a staffing concern, something for human resources or the CIO's succession planning. That framing is too narrow. When a critical system depends on one person's memory, the enterprise has an undocumented dependency in its operating model. The exposure is financial, operational, and—in regulated industries—potentially a control deficiency.

Why Bus Factor Belongs in Risk Reporting

Bus factor is a simple concept: how many people would have to be unavailable before a process or system loses the knowledge required to operate it. A bus factor of one is a single point of failure made of people rather than hardware. It is easy to ignore because it does not fail on a schedule. It fails on the day the expert resigns, retires, takes medical leave, or moves to another team.

Boards already understand concentration risk in financial portfolios and supplier relationships. Key-person risk deserves the same treatment. If a platform supports revenue recognition, order fulfillment, payroll, or regulatory reporting, the loss of its only qualified operator is a business continuity event. It should appear in the risk register with an owner, a likelihood assessment, and a mitigation plan.

Measuring Exposure Without Pretending Everything Can Be Documented

The goal is not to document every system to the same depth. That is neither affordable nor useful. The goal is to identify where the absence of a single person would create unacceptable disruption and to reduce that exposure to a tolerable level.

A practical assessment can score each core platform on five dimensions. Use a simple one-to-three scale and review the results with both technology and business owners.

• Criticality: the business impact of a two-week outage or loss of operating knowledge.
• Knowledge distribution: the number of people who can perform the core operational tasks without assistance.
• Documentation quality: whether runbooks are current, tested, and specific enough to be used under pressure.
• Access concentration: whether privileged access, vendor contacts, or configuration knowledge sit with one individual.
• Vendor dependency: whether external support depends on a personal relationship rather than a contractual escalation path.

The output should be a register, not a scorecard. Each high-exposure system needs a named executive owner and a mitigation commitment. A score without an owner is just another report.

Practices That Reduce Exposure Without Fantasy

The first practice is paired operations. For every critical platform, at least two people should perform the core operational tasks on a rotation. This is not job shadowing. It is real execution, with the secondary operator making changes, running recoveries, and handling escalations while the primary expert observes. The purpose is to expose the gaps that documentation misses.

The second is tested runbooks. A runbook that has never been used during an incident is a hypothesis. Organizations should schedule periodic recovery drills and patch cycles in which the secondary operator follows the runbook without the expert's intervention. Every question the expert has to answer becomes a documentation improvement.

The third is vendor relationship redundancy. Contractual escalation paths should not depend on a single account manager. Enterprises should require named backup contacts, documented support procedures, and a quarterly review of the vendor's own key-person dependencies.

The fourth is exit discipline. When a key expert leaves, the organization should conduct a structured knowledge-transfer period, not a farewell lunch. The departing employee should update runbooks, walk a successor through recent incidents, and identify undocumented workarounds. This should be a condition of access removal, not an optional courtesy.

A Board-Ready Register

The final step is reporting. A quarterly key-person risk summary should tell the board three things: which systems have a bus factor of one, what mitigation is underway, and what residual exposure remains. The summary should avoid technical detail and focus on business services, financial exposure, and remediation dates.

This does not require a large program. It requires a decision that tribal knowledge is an asset with a concentration risk, and that the enterprise will manage it like any other dependency.

Conclusion

The single-threaded expert is not a villain and not a hero. They are a symptom of an operating model that has optimized for individual competence rather than organizational resilience. Enterprises cannot document everything, and they should not try. But they can identify where one person's departure would become a business problem, assign an owner, and build a second path to the knowledge. That is not bureaucracy. It is continuity.