What is the bus factor in software development, and how do you calculate it?

The bus factor is a security metric representing the minimum number of team members who must suddenly disappear or be incapacitated before a project or business completely stalls; it is calculated by mapping critical system dependencies to specific key-holders and identifying the smallest group whose loss would halt operations.

The term comes from the morbid question: "What happens if your lead developer gets hit by a bus?" If only one person knows how to deploy the codebase, your bus factor is 1. If two people need to disappear before operations stall, your bus factor is 2.

A bus factor of 1 is a ticking time bomb. It means a single person's death, illness, departure, or even a vacation can bring your entire business to a halt.

Calculate your startup's risk score with our interactive Bus Factor Calculator.

How to calculate your startup's bus factor

Calculating your bus factor requires mapping every critical system to the people who can operate it:

Step 1: List critical systems • Code deployment pipeline • Database administration • DNS and domain management • Payment processing (Stripe, PayPal) • Cloud infrastructure (AWS, GCP, Azure) • Customer support tools • Email and communication systems • SSL certificate renewal • Monitoring and alerting

Step 2: For each system, list who has access and knowledge Who can deploy code? Who has AWS root credentials? Who knows the database schema? Who can access the Stripe dashboard?

Step 3: Find the minimum cut For each system, the bus factor is the number of people who, if removed, would leave zero capable operators. Your overall bus factor is the minimum across all systems.

For example, if 3 people can deploy code but only 1 person has the Stripe admin credentials, your bus factor is 1 — because losing that one person halts your ability to process payments.

Use our Bus Factor Calculator to automate this assessment.

How to reduce your bus factor from 1 to 3

1. Document everything Create runbooks for every critical operation. Not wikis that go stale — living documents that are tested quarterly. Include screenshots, exact commands, and escalation procedures.

2. Share credentials securely Use a client-side encrypted conditional delivery (ZeroLatch) to store encrypted copies of all critical credentials. Configure automated release to co-founders or designated emergency contacts after a verified inactivity period. This ensures that even if a key person disappears, their credentials are automatically delivered to someone who can use them.

3. Cross-train systematically Assign every critical system a primary and secondary owner. The secondary must perform the operation at least quarterly to maintain proficiency.

4. Automate deployments CI/CD pipelines reduce the bus factor for deployments by making the process repeatable without specific human knowledge. If your deployment requires "Bob's laptop and Bob's SSH keys," your bus factor is 1.

5. Use shared password management Move from individual password stores to team-based password managers with emergency access policies. ZeroLatch can serve as the automated emergency access layer that triggers when a team member is unreachable.