Knowledge Concentration Is a Business Risk, Not Just an HR Question

Ask which system is most critical to the business and you’ll get a confident architectural answer. Ask which single person’s absence would hurt the business most, and watch the room go quiet — because everyone knows the answer, and almost nobody has done anything about it, because naming it feels like an accusation rather than a risk assessment.

Knowledge concentration is a genuine business risk, structurally identical to the vendor concentration risk I write about elsewhere, and it’s treated with a fraction of the seriousness — not because it’s less consequential, but because the risk lives in a person rather than a contract, and organisations are far more comfortable auditing contracts than colleagues.

Where it actually accumulates

Knowledge concentrates for entirely understandable reasons. The person who built a critical system originally still understands it best, and it’s genuinely faster for them to fix the next issue than to explain the fix to someone else — a completely rational short-term choice, repeated often enough, that produces a long-term structural dependency nobody explicitly decided to create. The person who’s been at the organisation longest accumulates institutional context — why a decision was made, which workaround exists for which known issue, which vendor relationship actually depends on a personal rapport rather than a contract — that was never written down because writing it down felt unnecessary while that person was still there to ask.

None of this is a character flaw in the individuals involved. It’s what happens by default, absent a deliberate counter-effort, in any organisation where speed is rewarded and documentation is not — which describes most organisations, most of the time. The people at the centre of this concentration are usually the last to see it as a risk, because from where they sit it just looks like being useful.

Why this is a business risk, not an HR question

The instinct is to file this under retention or succession planning, which understates it. A business that cannot operate a critical system, maintain a critical vendor relationship, or make a critical decision without one specific person available has a single point of failure exactly as real as an unsegmented network or a single-region cloud dependency — the fact that the point of failure is a person rather than a server doesn’t make the risk smaller, and in some ways makes it larger, because a person can leave with far less warning than a data centre typically fails.

It also compounds during the exact moments a business most needs resilience: an acquisition due-diligence process that asks directly which capabilities depend on named individuals, a regulatory audit that asks who else could answer a specific question if the primary contact were unavailable, an actual departure that happens on someone else’s timeline, not the organisation’s. Knowledge concentration is invisible until precisely the moment it becomes catastrophically visible, which is the same failure signature as every other single-point-of-failure risk on this site.

What surfaced during one due-diligence process

A digital-assets firm preparing for acquisition discovered, during the buyer’s technical due diligence, that its entire custody-key-management process existed in the working knowledge of one engineer who had built it three years earlier and never fully documented it since — not out of secrecy, simply because the system worked and nobody had ever been forced to write it down. The buyer’s technical team asked, reasonably, what would happen to key-management continuity if that engineer left during the transition period. The honest answer, in the room, was uncomfortable silence followed by a hastily assembled documentation sprint that should have happened two years earlier. The acquisition proceeded, but the valuation conversation shifted, and the fix — cross-training a second engineer, properly documenting the process — took six weeks under deal pressure that would have taken two weeks done calmly, well before anyone outside the company was asking.

What actually reduces it, deliberately

The fix isn’t a mandate to document everything, which produces documentation nobody maintains and nobody trusts. It’s identifying, specifically, the two or three areas of genuine concentration risk — not a comprehensive audit of every employee’s knowledge, but a targeted look at where a single person’s unavailability would actually hurt — and addressing those deliberately: pairing a second person into a critical vendor relationship, requiring a decision log for the handful of decisions that actually matter rather than all of them, cross-training on the specific systems where dependency is currently narrowest. This is the same discipline behind designing an engagement for eventual handover, applied continuously rather than only at an engagement’s end — because the risk doesn’t wait for someone to be leaving before it starts costing the business its resilience.

Reducing this risk deliberately, over the course of an engagement, is exactly what designing for your own replacement is about.

Identifying where knowledge concentration risk actually sits — not everywhere, but in the two or three places it genuinely matters — is exactly the kind of risk mapping a technology control assessment is built to surface, before it’s tested by an unplanned departure.