Technical Diligence Needs a Kill Question

A long risk register can obscure the one dependency, exposure or control failure capable of invalidating the investment thesis.

The answer

Diligence reports are rewarded for coverage. Deals are changed by concentration. The team may catalogue patching, policies, architecture, privacy, vendors and incidents while never asking the question that could end the transaction.

Diligence reports are rewarded for coverage. Deals are changed by concentration.

The team may catalogue patching, policies, architecture, privacy, vendors and incidents while never asking the question that could end the transaction. The result is comprehensive description without underwriting judgement.

What is a kill question?

It is the unresolved question whose adverse answer would make the buyer stop, reprice, restructure or fundamentally change integration. It must connect a technical fact to the investment thesis.

Examples: Can the company legally and technically continue using the data that trains its core product? Can the platform operate without the founder’s private credentials? Will change of control terminate the licence on which revenue depends? Is the target already compromised? Can the business separate from its parent inside the stated timeline?

A kill question disciplines evidence

It forces the team to identify what must be proven, who possesses the evidence and when uncertainty becomes a commercial decision. It also prevents the final report from hiding a decisive unknown among dozens of medium findings.

The position

Every technical diligence mandate should state its kill question in the first week and update it as evidence changes. There may be more than one, but there should never be none. The final report should answer it in the first page: resolved, adverse or still uncertain—and what that means for the deal.

If no technical fact could change the transaction, either the workstream is unnecessary or the team has not understood the investment thesis.

Sources

  1. NIST — Cybersecurity Supply Chain Risk ManagementNIST

    Primary authority

  2. FINMA Risk Monitor 2025FINMA Risk Monitor 2025

    Primary authority

Ross BelhommePartner, Svperior / Legal

Adam J. De Collibus

Adam co-founded Svperior and leads systems engineering from requirements through implementation. His work connects architecture, implementation, deployment, and operating discipline across complex environments where failure must be anticipated and technical capability must remain dependable under pressure.

Systems engineering / Technical architecture / Production operations / Operating resilience

Need to apply this to a specific situation?

Send us the initial context. If the matter fits, we will respond directly.

Send private inquiry
Technical Diligence Needs a Kill Question