Technical Diligence Should Be Trying to Break the Thesis

The job of technical diligence is not to admire the target’s controls. It is to find the technical facts capable of breaking the investment thesis before.

The answer

Diligence that merely describes the technology estate protects the process, not the investment. The work should identify the technical assumptions carrying the thesis and attempt to falsify them.

Most technical diligence asks whether the target is reasonably secure. That is not the question the transaction needs answered. The target can be below an abstract maturity standard and still be an excellent acquisition at the right price and sequence. It can also present a clean control environment while containing one architectural constraint that makes the investment thesis impossible. Technical diligence should be trying to break the thesis.

Begin with the value-creation claims

Write the thesis as testable statements. Examples:

  • The buyer can integrate customer and operating data within six months.
  • The product can scale into a regulated market without fundamental redesign.
  • Automation can reduce operating cost while maintaining required control.
  • The target can separate from the seller by the transition-services deadline.
  • The platform can support acquisition-led growth without multiplying fragility.
  • The company’s proprietary data and software are transferable and defensible.

Then ask what technical fact would make each statement false, materially slower or more expensive.

Attack the assumptions, not the presentation

Management presentations naturally describe the intended system. Diligence must observe the operating system. Sample live configurations. Trace a real customer or transaction workflow. Compare asset inventories to network and identity evidence. Restore a backup. Inspect administrator and service-account use. Examine how exceptions are handled after hours. Reconcile product claims with code, infrastructure and deployment history. The objective is not to catch management in a lie. It is to find the distance between designed process, documented process and actual process.

Look for asymmetric facts

The best diligence finding is not the longest list. It is the fact with a disproportionate effect on price or execution.

  • A core product depends on software the target cannot lawfully or practically transfer.
  • One founder holds the only usable signing keys and operational knowledge.
  • Customer isolation is implemented by convention rather than architecture.
  • The data required for the growth thesis is incomplete, unprovenanced or contractually restricted.
  • A critical system cannot be recovered within the business tolerance.
  • The target’s security model collapses when joined to the buyer’s identity layer.
  • A key vendor requires a replacement timeline longer than the planned separation period.

These facts are decision objects. They should be connected immediately to valuation, structure and integration.

Use evidence ladders

A confident interview answer is not equivalent to operating evidence. Rank the support for each material claim.

  • Level 1: assertion by management or adviser.
  • Level 2: policy, diagram, contract or procedure.
  • Level 3: current system export, configuration or log.
  • Level 4: observed workflow or technical test.
  • Level 5: repeatable outcome under adverse conditions.

Not every claim needs level five. The required evidence should follow the consequence. A minor tool can be accepted through documentation. A recovery capability central to the thesis should be demonstrated.

Diligence the change, not only the target

The transaction itself creates risk. New ownership changes identity, network connections, data flows, vendors, reporting and authority. A target that is stable alone may become unsafe during integration. Model the proposed future state. Identify where trust boundaries disappear, where two weak controls become one larger weakness and where the buyer’s standard tooling conflicts with the target’s operation. This is why a conventional snapshot can be misleading. The question is not only “what is the risk today?” It is “what risk does our plan create?”

Make the report executable

A useful diligence output separates findings into transaction decisions:

  • Accept and price: the risk fits the return and requires no special structure.
  • Contain at close: ownership may transfer, but integration or access is gated.
  • Correct before close: the exposure cannot safely or legally transfer in its current state.
  • Structure: use covenant, escrow, indemnity, transition support or retained responsibility as appropriate.
  • Rebuild the plan: the thesis remains viable but the sequence, budget or timing changes.
  • Stop: the evidence breaks a core value-creation claim beyond an acceptable range.

Each recommendation should name the evidence, owner, deadline and validation method.

Preserve independence under pressure

Diligence teams are surrounded by momentum. Fees, reputation, deadlines and executive attention all favour completion. Technical specialists can be pushed into producing a risk rating that sounds precise while the decisive uncertainty remains unresolved. State uncertainty directly. Distinguish unavailable evidence from acceptable evidence. Explain what could not be tested and what conclusion therefore cannot be supported. A caveat buried in an appendix will not protect the investment committee from a false headline.

The final deliverable is a sharper decision

The purpose of adversarial diligence is not pessimism. It is to protect conviction from facts that have not yet been confronted. If the thesis survives serious attempts to break it, the buyer can move with greater speed and specificity. If it does not survive, the work has created value before capital and control cross the boundary. That is the standard: not a technically impressive report, but a better transaction decision.

Sources

  1. NIST: Cybersecurity Framework 2.0NIST: Cybersecurity Framework 2.0

    Primary authority

  2. NIST SP 1305: Cybersecurity Supply Chain Risk ManagementNIST SP 1305: Cybersecurity Supply Chain Risk Management

    Primary authority

  3. FINMA: Risk Monitor 2025FINMA: Risk Monitor 2025

    Primary authority

Adam J. De CollibusFounding Partner, Svperior / Systems Engineering
Ross BelhommePartner, Svperior / Legal

Jonathan P. De Collibus

Jonathan co-founded Svperior in 2014 and leads its cyber practice. His work sits where adversarial pressure, technical architecture, and consequential decisions meet, with experience across clinical, financial, public-sector, and private-client systems where confidentiality, continuity, and technical correctness carry material consequences.

Cyber strategy / Adversarial assessment / Security architecture / Private systems

Need to apply this to a specific situation?

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

Send private inquiry