Due Diligence Report: Key-Person & Tribal Knowledge Dependency
Measuring how much of a platform's operational resilience lives in one engineer's head and nowhere else.
Executive Summary
This audit quantified how much of the target's production recovery and operational knowledge existed only as undocumented tribal knowledge held by specific individuals, rather than in formal runbooks.
Findings
Recovery procedures for the platform's two most severe historical incident classes existed only in one senior engineer's working memory, with no corresponding written runbook.
Recommendation: Formally document recovery procedures before close; treat this as a condition of the deal, not a post-close cleanup item.
The deployment rollback process required manual steps known to a small subset of the engineering team, with no automated or documented fallback.
Recommendation: Automate and document the rollback path; verify it with a live rehearsal, not a written description alone.
Critical third-party infrastructure credentials were held informally by individual team members rather than in a managed secrets system.
Recommendation: Migrate to a managed secrets system with access logging prior to any team transition.
Conclusion
None of these findings were visible in the target's architecture documentation, which was accurate as far as it went. The risk was entirely in what the documentation did not say, which is precisely what a diligence process limited to document and interview review will miss.
Frequently Asked
How is key-person dependency risk actually measured?
By testing whether critical recovery and deployment procedures are formally documented and automatable, versus existing only in specific individuals' working knowledge.