The riskiest part of your system isn't the code. It's the one person who can still explain it.
42 percent of what a company knows lives only in employees' heads, not in any document. That's not a culture problem - it's a single point of failure nobody put on the risk register.
A number most risk registers miss
Panopto's Workplace Knowledge study found that 42 percent of what a company knows exists only inside individual employees' heads - not in a wiki, not in a ticket, not in anything a colleague could open without asking first. Run that math on a team of ten and one resignation letter can take a real slice of what the business understands about itself out the door, with no warning and no undo.
It doesn't look like risk while it's still there
Nobody sets out to become the single point of failure. It happens by accretion - a workaround here, a client quirk remembered instead of logged, a reason for a weird setting that made sense eighteen months ago and was never written down because it didn't need to be, the person who knew was sitting right there. The same study found US knowledge workers lose 5.3 hours a week waiting on information from someone else or rebuilding something that already existed - just not anywhere they could reach it.
Writing it down isn't automatically the fix
Most companies respond to this by asking people to "document more," and most documentation efforts fail anyway, because they capture the what and skip the why. A wiki page that says what a setting does is useless the day someone needs to know why it was set that way, under what condition it's safe to change, and what broke the last time someone tried. The knowledge worth keeping isn't the current state, it's the reasoning that produced it - and that only gets captured if someone asks for it at the moment the decision gets made, not six months later during a rushed handoff.
The ACS approach
We attach the reasoning to the work itself - decisions live as comments on the ticket that caused them, not in a separate document someone has to remember to update. When a project moves between us and a client's own team, the handoff includes why things were built the way they were, not just a tour of the code. A system that only one person can explain isn't finished, no matter how well it runs today.