TEAM-1 Tech Due Diligence

Tech Due Diligence TEAM-1: Bus Factor and Knowledge Distribution

What This Control Requires

The assessor evaluates the distribution of critical knowledge across the team, identifying single points of failure where the departure of one individual would significantly impact the organisation's ability to maintain, develop, or operate the technology.

In Plain Language

If one person walks out the door and takes irreplaceable knowledge with them, that is a material operational risk. Investors and acquirers care deeply about this because it directly threatens the continuity of the technology they are buying into.

We look at whether critical systems have documentation that lets others maintain them, whether deployments and operational procedures can be performed by more than one person, whether domain knowledge is shared through pair programming, code review, and documentation, and whether the CTO or a senior engineer is a single point of failure for critical decisions or access. We also check whether credentials and operational knowledge are institutionalised rather than living in one person's head.

The patterns we see most often: a single developer who built and exclusively maintains a critical system, a CTO who is the only person with production access or deployment credentials, a domain expert whose business logic knowledge is entirely undocumented, and a lone ops person who administers all cloud infrastructure. Each of these is a risk we will flag prominently.

How to Implement

Start with a bus factor assessment across the engineering team. For each critical system, process, and knowledge domain, map out who holds the knowledge, whether it is documented, whether at least one other person can step in, and what the impact would be if the primary knowledge holder left.

Address the gaps through deliberate knowledge sharing. Use pair programming or mob programming on critical systems. Rotate on-call and operational responsibilities so multiple people build hands-on experience. Run cross-training sessions where knowledge holders teach their colleagues. Write operational runbooks that any qualified team member can follow, and make sure at least two people have the credentials and know-how for every critical operation.

Spread code ownership broadly. Use CODEOWNERS files or similar mechanisms, but ensure every area has at least two owners. Require cross-team code review so reviewers develop familiarity with code outside their primary domain.

Institutionalise access and credentials. No production system should depend on credentials known to only one person. Use a shared password manager or secrets vault for critical credentials. Make sure cloud console access, database access, and deployment capabilities are available to multiple authorised team members.

If your team is large enough, rotate engineers between projects or systems periodically. Even temporary rotations of a single sprint working on a different system can meaningfully reduce bus factor risk.

Track bus factor as an explicit metric. For each critical system, record how many people could independently maintain, deploy, and troubleshoot it. Set a minimum threshold of 2-3 and create action plans for anything that falls below.

Evidence Your Auditor Will Request

Bus factor assessment identifying single points of failure
Knowledge sharing activities (pair programming, cross-training records)
CODEOWNERS or equivalent code ownership documentation
Evidence of shared access to critical systems and credentials
Operational runbooks enabling multiple team members to perform critical tasks

Common Mistakes

CTO or founder is the only person who can deploy to production
Critical system built and exclusively maintained by a single developer
No documentation for critical operational procedures; knowledge is tribal
Production credentials stored in one person's personal password manager
Domain knowledge for critical business logic exists only in one person's head

Related Controls Across Frameworks

Framework	Control ID	Relationship
ISO 27001	A.5.37	Related

Frequently Asked Questions

What is an acceptable bus factor?

For any critical system or process, the minimum is 2 - at least two people who can perform the function independently. For highly critical systems, aim for 3. A bus factor of 1 on anything critical is a red flag that will be highlighted prominently in any DD report.

How do we improve bus factor in a small team?

Small teams will always face bus factor challenges, but the risk can be meaningfully reduced through comprehensive documentation, pair programming, regular rotation of responsibilities, and deliberate cross-training. Even in a team of 3, making sure no single area depends on just one person is achievable if you are intentional about it.

Track Tech Due Diligence compliance in one place

AuditFront helps you manage every Tech Due Diligence control, collect evidence, and stay audit-ready.

Start Free Assessment