The cost of one person

Three hundred and twelve systems across forty firms of 30 to 600 people were inventoried between March 2024 and May 2026, across professional services, healthcare, software and financial services, to answer a question every firm interviewed agreed was a real risk and none could actually quantify: how many of our systems does exactly one person know how to run? A system entered the count when its loss for a week would be noticed by somebody outside the team running it. Capability itself was defined strictly — able to operate the system routinely, make a change to it, and recover it after a failure, all three required, not simply holding login credentials.

That distinction did most of the work. By access alone, most systems in the study looked adequately covered; by the stricter test, 134 of the 312 — 43% — had exactly one person who could actually run them, more than double the median estimate the sponsoring organisations gave of their own systems beforehand. Fifty-two systems had a second person with full credentials who, when asked directly, said they could not recover the system after a failure. Of the 134 single-operator systems, management was entirely unaware of 42 and had suspected but never confirmed a further 33 — meaning most of this risk was invisible to the organisations carrying it, not merely unmanaged.

Discovery mattered as much as existence. Only 22 of the 134 dependencies were found by somebody deliberately looking; the other 112 surfaced through a resignation, an internal audit, an incident, or an absence — each a moment when the organisation learned about the gap at the same time it had to deal with the consequence. The cost of that timing was stark: systems found through a planned inventory took a median of six working days to reach a second capable operator; systems found during an incident took seventy-one. Twenty-four dependencies surfaced specifically during due diligence for a sale, where eleven appeared directly in the buyer's report and at least four were cited in a price adjustment.

Concentration wasn't random. Bespoke internal tools had a single operator 79% of the time and data pipelines 71%, against 21% for core platform services and 29% for customer-facing applications — the inverse of visibility, since the systems everyone can see tend to have teams around them, while the ones built by one person because it was faster than asking are the ones nobody else can run. Risk registers, built around business criticality, largely missed this: of the 42 systems the organisation didn't know about at all, 31 sat in the three most concentrated categories.

The report's central operational finding concerns what actually fixes a dependency once found: writing documentation alone produced a second capable operator six months later in only 23% of cases, while having someone who hadn't built the system attempt a real task from that documentation — and correcting it where they got stuck — produced one in 84% of cases. The cheapest version tested, a single unassisted afternoon where a stranger attempted one real task while the original operator wasn't consulted, succeeded in nine of eleven cases. The report is explicit that this conclusion runs toward a service it sells, and states the countervailing finding — that the cheap version works nearly as well as the expensive one — as the reason to trust it anyway.