What Boards and CFOs Should Ask About Internal Software Risk

The Visibility Gap

Most boards and financial leaders have sophisticated approaches to evaluating traditional business risks: market risk, credit risk, regulatory risk, operational risk in manufacturing or logistics.

But when it comes to custom software systems—the increasingly critical infrastructure that runs modern business operations—visibility is often poor. Technical teams speak a different language, and the questions that would reveal risk aren't asked.

This gap is dangerous. Software failures can halt operations, compromise data, damage reputation, and destroy value. Yet many organizations don't know how exposed they are.

Questions That Reveal Real Risk

The following questions are designed to cut through technical jargon and reveal the actual risk posture of your software systems. They don't require deep technical knowledge to ask, but the answers will tell you a lot.

1. Who Can Deploy Our Application to Production?

Why it matters: Deployment capability is a critical single-point-of-failure risk. If only one person can push updates to production, your business is dependent on that person's availability for every bug fix, security patch, and emergency response.

Red flags: Only one name. Vague answers. "We haven't really thought about that."

Good answers: Multiple named individuals. Documented procedures. Recent verification.

2. When Did We Last Test Restoring From Backup?

Why it matters: Having backups is not the same as being able to restore from them. Untested backup systems fail when they're needed most.

Red flags: "We've never tested it." "I'm sure it works." "We did it a few years ago."

Good answers: Specific recent date. Named person who performed the test. Documented results.

3. Could a New Developer Understand Our System Within One Month?

Why it matters: This question reveals documentation quality and knowledge concentration. If understanding the system requires months of learning from the current team, knowledge is trapped in people's heads.

Red flags: Laughter. "It took me two years to figure this out." "The only documentation is the code."

Good answers: Reference to documentation. Confidence in transfer capability. Recent examples of successful onboarding.

4. What Happens If Our Lead Developer Leaves Tomorrow?

Why it matters: The direct question about single-developer dependency. The answer reveals how much operational risk is concentrated in one person.

Red flags: Visible discomfort. "We'd be in trouble." "That's why we can't let them leave."

Good answers: Named backup people. Documented procedures. Confidence in continuity.

5. Where Is the Documentation for Our Critical Business Logic?

Why it matters: Business logic—the rules that govern how your operations work—is often the hardest thing to recover when something goes wrong. If it only exists in code that one person understands, you're exposed.

Red flags: "It's in the code." "Sarah knows all of that." "We should document that someday."

Good answers: Specific locations. Named owners. Recent update dates.

6. How Would We Respond to a Security Incident at 3 AM on Saturday?

Why it matters: Security incidents happen at inconvenient times. The answer reveals whether you have actual incident response capability or just hope that problems occur during business hours.

Red flags: Silence. "We'd figure it out." "Call [single person's name]."

Good answers: Documented escalation procedures. Multiple contacts. Clear responsibilities.

7. What Would an Acquirer See in Technical Due Diligence?

Why it matters: Even if you're not planning to sell, this question forces honest assessment of technical risk. Acquirers look at documentation, bus factor, disaster recovery, and operational maturity. Their assessment is your real risk posture.

Red flags: "We'd need to clean things up first." "They probably wouldn't look too closely."

Good answers: Confidence in current state. Reference to existing documentation and procedures.

Interpreting the Answers

You don't need technical expertise to interpret these answers. Pay attention to:

Confidence level: Are answers given confidently and specifically, or vaguely and hesitantly?

Named resources: Are specific people, documents, and procedures referenced, or are answers abstract?

Recency: When was the last time capabilities were actually tested or documentation updated?

Redundancy: Is capability concentrated in one person, or distributed?

The Value of Independent Assessment

Internal teams often have blind spots about their own systems. They may genuinely believe their documentation is adequate when it isn't, or overestimate their disaster recovery capabilities.

Independent assessment—having someone outside the team evaluate documentation, test procedures, and identify gaps—provides valuable perspective. It also creates accountability for addressing issues that might otherwise be deprioritized.

Taking Action

If these questions reveal concerning gaps, the solution isn't necessarily hiring more developers or undertaking massive projects. Often, targeted investments in documentation, procedure validation, and knowledge transfer can dramatically improve risk posture.

The key is treating software continuity as an operational responsibility—something that requires ongoing attention, not just when problems arise.

Conclusion

Business leaders don't need technical expertise to understand software risk. They need the right questions and the willingness to ask them.

The questions above will reveal whether your organization's software systems are operationally mature or dangerously dependent on individuals. Armed with that knowledge, you can make informed decisions about where investment in continuity and resilience is needed.