Key Person Dependency Risk in IT: An Owner's Guide

Key person dependency risk in IT is the exposure a business carries when a critical system — the ERP, the scheduling application, the custom software the operation runs on — is understood by exactly one person. If that person resigns, retires, gets sick, or simply stops answering the phone, the business doesn't lose an employee; it loses the ability to change, fix, or even fully operate a system it depends on every day. This guide is written for the owner, CEO, president, or COO of a mid-market company — the person who wakes up at 3 a.m. remembering that only Bob can touch the order system, and Bob is 61. By the end you'll be able to measure this risk in one afternoon, know the four moves that remove it, and understand why fixing it stopped being a seven-figure project.

The One-Person System: What Key Person Dependency Looks Like in IT

Key person risk exists in every function — the rainmaker in sales, the founder who holds every client relationship. The IT version is different in one important way: the dependency attaches to a system, not just a role. When a salesperson leaves, you can hire and rebuild. When the only person who understands your warehouse system leaves, the system keeps running — silently, unmaintained, unchangeable — until the day it doesn't. You cannot hire someone who already knows why the invoice module crashes on the last day of the quarter and which of the three fixes actually works.

The risk is widespread and well documented: research collected by Monitask's business glossary cites a 2023 SHRM finding that 72% of companies have at least one employee whose sudden departure would significantly impact operations, with replacement costs running 100–300% of annual salary. But at mid-market companies — where there's rarely a CIO, an engineering team, or anyone whose job is to notice — the one-person system typically wears one of three faces:

1. The veteran employee. Twenty years in, "keeps the system running" grew into the job. Nothing is written down because nothing ever needed to be — Bob was always there. Every workaround, quirk, and password lives in one head that will retire one day.
2. The one outside guy. A contractor or tiny local firm built the system years ago and has maintained it ever since — capably, affordably, and entirely alone. He's not an employee, so no offboarding process captures what he knows, and no succession plan covers him.
3. The vendor's last man. The company that built your custom software shrank, was acquired, or dissolved — and support now depends on whichever former employee still answers email. When even that last thread breaks, you're in the territory of our owner's guide to a software vendor going out of business. This is the doorway to a related but distinct problem — a vendor charging ransom-grade fees for a frozen product — that our guide to software maintenance costs that are too high maps in full.

Software engineers have a blunt name for this measurement: the bus factor — how many people would have to be hit by a bus before nobody left could maintain the system. A study of 133 popular software projects found 65% had a bus factor of 2 or lower. Those were active projects with professional maintainers. The custom system running a mid-market warehouse since 2011 almost always sits at exactly 1 — and sometimes, once the contractor drifts away, at zero.

How One Person Ends Up Holding the Business

Nobody decides to create a one-person system. Like most mid-market software problems, it accumulates — through four forces that are each individually reasonable:

• Convenience hardens into dependency. Bob fixed it once, so Bob got called next time, so Bob became "the person for that system." What starts as efficiency during a busy quarter is a structural dependency by the end of the year.
• Documentation is never the deliverable. The system was bought or built to run the operation, not to be explained. "Write down how this works so a stranger could take over" costs money and delivers nothing visible, so it lost to every other priority, every time.
• Knowledge concentrates where nobody's watching. Passwords, admin rights, vendor logins, the "don't run the export while the backup is going" folklore — it all pools with whoever touches the system most, because distributing it takes deliberate effort no one was assigned.
• The gaps belong to nobody. The veteran who understands the old system is usually also the human bridge between it and everything around it — the person who re-keys, reconciles, and remembers. That's the same structural orphan we describe in our guide to systems that don't talk to each other: the space between systems has no owner, so it gets staffed informally, by the most irreplaceable person you have.

Notice what's missing from that list: bad intent. The occasional employee does hoard knowledge as job security, but most one-person systems are built by loyalty, not leverage — Bob never asked to be a single point of failure. Which is why the fix is never "deal with Bob." It's changing what the business depends on.

What It Costs Before Anything Goes Wrong

The trap with this risk is that it appears to cost nothing. The system runs. Bob shows up. No invoice arrives for "dependency." But the meter is running in four ways an owner can actually price:

• Hostage pricing, internal edition. When one person is irreplaceable, ordinary negotiations aren't ordinary. The raise, the schedule, the pushback that never comes — the market price of indispensability gets paid quietly, year after year.
• Change stops being an option. Every improvement that touches the one-person system waits in a queue exactly one person long. Owners routinely defer growth projects for quarters because "we can't risk touching that system right now." That deferral has a dollar value; nobody writes it down.
• The risk is now priced by outsiders. Cyber-insurance underwriters ask who maintains and patches your critical systems; a one-person answer reads as an unmanaged risk. And if a sale or investment is anywhere in your future, PE due diligence teams hunt specifically for single points of failure — visible key person dependencies discount the valuation of an otherwise healthy business.
• A slow leak of resilience. Every year the veteran gets closer to retirement and the system gets further from anything a newcomer could learn. CIOs across the industry are watching decades of institutional IT knowledge walk out the door as the boomer generation retires — and enterprises at least have teams to absorb some of it. A mid-market company with one Bob absorbs none.

Then there's the day it stops being theoretical: the resignation with two weeks' notice, the health event with none, the contractor who stops replying. What follows compresses all the deferred cost into a few weeks — emergency consultants reverse-engineering an undocumented system at emergency rates, while changes freeze and the operation holds its breath.

Measure It in One Afternoon: The Bus-Factor Audit

You don't need a technical background to measure this risk — you need a list and five questions. Sit down with whoever is closest to your systems (the IT manager, the office manager, your MSP) and build one row per critical system: ERP, accounting, warehouse, scheduling, quoting, the customer-facing site, and every custom tool the operation touches daily.

For each system, first ask the bus-factor question in its business form: "If the person who maintains this were unreachable for 90 days, who could safely make a change to it?" "Safely" is the load-bearing word — plenty of people can log in; the question is who could fix or change it without fear. One name means a one-person system. "Nobody, since the vendor left" is worse.

Then check five facts. Every one is verifiable by a non-technical owner, because each is a yes/no about possession, not technology:

#	The question	Why it matters
1	Do we hold the source code? For custom software: current code, in a company-controlled account — not only on the developer's laptop or in the vendor's repository.	This single fact separates "hard week" from "rebuild from scratch."
2	Does documentation exist that a stranger could use? Not a user manual — a description of how the system works, where it runs, and its known quirks.	The difference between a two-week handover and a six-month archaeology project.
3	Are the credentials in a company vault? Admin passwords, server access, domain registrar, vendor accounts — in a password manager the company controls.	Locked-out is the fastest, dumbest version of this crisis, and the cheapest to prevent.
4	Do we know where and how it runs? The server under the desk, the cloud account on a personal card, the nightly job on Bob's PC — written anywhere?	Systems have been lost to an office move, an unpaid personal card, and a rebooted "mystery server."
5	What does the contract actually say? For outside maintainers: is there a contract, does it grant you code and data, is there a source-code escrow if the vendor fails?	The relationship works on goodwill until the day it works on paper. Check the paper first.

Score each system: five yeses with a bus factor of 2+ is green — move on. A bus factor of 1 with the facts mostly in hand is yellow — fixable with process. A bus factor of 1 with source code missing, nothing documented, and credentials in one head is red: that system deserves attention this quarter, because every month of delay raises the price of the eventual exit. This inventory takes one afternoon, and it's the same first move we recommend for every software decision in our mid-market modernization guide — dollars and risk on one page before anything gets bought.

Breaking the Dependency: Four Moves, in Order

The ranking pages on this topic all prescribe the same generic quartet — document, cross-train, plan succession, buy insurance. Fine advice for key person risk in roles. For one-person systems, the sequence matters more than the list, because the early moves protect you while the later ones need time. In order:

Move 1 — Secure the assets this week

Before any process improvement: get possession. Source code into a company-controlled account. Credentials into a company password vault with a second authorized holder. Backups verified — actually restored once, not assumed. Domains, cloud accounts, and vendor contracts into company ownership, off personal cards and personal emails. This move needs no cooperation beyond an ask, costs nearly nothing, and converts the worst scenarios (locked out, code gone) into merely bad ones.

Move 2 — Document while the knowledge is friendly

Every month the veteran is still there is a month the knowledge can be captured on good terms — and this is the step where the economics quietly changed. Documenting a system used to mean weeks of the one person's scarce time, which is why it never happened. Today, AI systems read code the way people read text: given a codebase, they generate accurate first-draft documentation — what the system contains, how its parts connect, where the risky corners are — in days, with the veteran reviewing and correcting rather than writing from scratch. (The engineering-side version of this practice is our guide to legacy system documentation with AI.) The goal is a description good enough that a competent outsider could take over in weeks — which is also exactly what makes Move 4 cheap.

Move 3 — Create the second person

Bus factor 1 becomes bus factor 2 through deliberate redundancy: a second employee cross-trained on routine operations, or a second firm under contract that has actually touched the system — not a name in a binder, but someone who has made at least one real, supervised change. Pair it with two standing rules that stop the risk from regrowing: no critical system has one credential holder, and documentation review is part of every system change, so the writeup never drifts out of date again.

Move 4 — Rescue the system that's past process fixes

For the red rows — the fragile custom core with no source, no docs, and one aging head — process improvements aren't enough, because there's nothing yet to cross-train anyone into. That system needs a legacy software rescue: a deliberately small engagement that recovers full control — source code located or lawfully recovered, documentation generated and verified, credentials secured, a second party (the rescuing team) now able to safely change the system. Rescue is not a rewrite; it's the recovery of ownership, after which every bigger decision — keep, modernize, or replace — can be made calmly, on your timeline, by any partner you choose.

What about key person insurance? Be clear about what it buys: a payout, not continuity. It's designed for revenue-critical people — the founder, the rainmaker — where money genuinely cushions the loss. A check does not document your warehouse system, and no insurer restores a bus factor. For one-person systems, the premium is better spent on Moves 1 through 4, which remove the risk instead of pricing it.

Why Fixing This Stopped Being Expensive

Owners have understood this risk for years. The honest reason it stayed unfixed: every real remedy was priced like a luxury. Documentation consumed the scarce expert's time, a second maintainer meant a second salary, and seriously rescuing the fragile system was a six-to-seven-figure project — so the rational move was to cross fingers and be extra nice to Bob.

AI-assisted delivery changed the input costs across all three. Reading and documenting a codebase, building the safety net that makes change safe, doing the heavy construction of a rescue — this is precisely the work a compact senior team directing AI coding agents now does in a fraction of the traditional hours, with humans reviewing everything that matters. It's the model Snowman Labs runs as an official partner of Cognition, Replit, and Hud, under published operating standards: a first production milestone in 2 weeks, a 40–60% target reduction in time to market, across 400+ delivered projects rated 4.9/5 on Clutch over 32 verified reviews — the same team enterprises like Volvo, Renault, Scania, iFood, and B3 trust, working at mid-market scale through our custom software services for mid-market companies. The practical consequence: taking a system from "only Bob understands it" to "documented, secured, and safely changeable by a second party" is now a weeks-long, five-figure engagement — an insurance premium that, unlike insurance, ends the risk.

One more thing this changes: the conversation with Bob. When the fix was expensive, the unspoken plan was to lean on the veteran to the very end — a plan he could feel, one that made every documentation request sound like a replacement plot. When the fix is fast and the goal is explicit — nobody should be trapped as a single point of failure, including you — veterans are usually the most relieved people in the room.

FAQ

What is key person dependency risk?

It's the exposure a business carries when critical knowledge, access, or capability is concentrated in one individual, so their departure, illness, or retirement would materially disrupt operations. In IT the dependency attaches to systems: one person is the only one who can safely maintain software the business runs on — which makes the risk quieter, and the eventual failure more expensive, than a role vacancy.

What is the bus factor?

The bus factor is how many people would have to disappear before nobody left could maintain a system — engineering shorthand for measuring knowledge concentration. A bus factor of 1 means a single point of failure; 2 means one thin backup; 3 or more is genuine resilience. Research on software projects found 65% sit at 2 or lower — and undocumented custom business systems typically sit at exactly 1.

How do you reduce key person dependency in IT?

In order: secure the assets (source code, credentials, backups, accounts) into company control; document the system while the knowledgeable person is available — AI-assisted documentation has cut this from months to days; create a real second maintainer through cross-training or a second contracted firm; and for fragile systems with no code or docs, run a rescue engagement that recovers full control. Standing rules — no single credential holder, documentation updated with every change — keep the risk from regrowing.

Does key person insurance cover IT key person risk?

Key person insurance pays the business a benefit if a named critical person dies or becomes disabled — a financial cushion, useful for revenue-critical roles like founders. It does nothing for continuity: no payout documents a system, recovers source code, or creates a second person who can maintain the software. For one-person systems, spend the effort on removing the dependency rather than insuring its cost.

What should be documented before a key IT employee retires?

Enough that a competent outsider could take over in weeks: what the system does and how its parts connect, where it runs, every credential and account it depends on (moved into a company vault, not just listed), known quirks with their reasons, and the calendar of things that must happen (renewals, jobs, backups). Then have the successor — even a temporary outside firm — make one supervised change before the retirement date: it's the only test that proves the documentation works.

What if the only person who understands our system is an outside contractor?

Treat it with more urgency than an employee dependency, because no notice period protects you. Confirm contractually that you own the source code and data and can receive them on request; get current copies delivered into company-controlled accounts now, not at termination; put credentials in your vault; and introduce a second party to the system while the relationship is good. If the contractor has already gone quiet — or the firm no longer exists — that's a rescue situation, and it should happen before the system next needs a change, not after.

The Business Should Survive Bob's Vacation

Key person dependency in IT is the risk that costs nothing every month and everything on the wrong day — and it never fixes itself, because the system keeps working right up until the trigger event nobody scheduled. The exit isn't heroic: one afternoon to find your one-person systems, one week to secure the assets, weeks — not years, not seven figures — to document, create a second pair of hands, and rescue what's genuinely fragile. At the end, the veteran is still your most valuable expert; the business just no longer depends on the contents of one head. Find out what your software really costs you →