Technology Due Diligence: The Sponsor's Guide

What Technology Due Diligence Actually Covers

The scope varies by provider and by target, but a competent engagement examines six areas.

• Product and architecture. Whether the system does what the company says it does, whether it scales to the growth case in the model, and what it would cost to get it there. For a platform acquisition intended to absorb bolt-ons, this includes whether the architecture can host acquired products at all.
• Code quality and technical debt. Maintainability, test coverage, dependency currency, and the accumulated cost of shortcuts. The output should be a remediation estimate, not an adjective.
• Infrastructure and cost. Hosting architecture, cloud spend and its trajectory, licensing, single points of failure, and disaster recovery capability that has actually been tested.
• Engineering organization. Team composition, concentration of knowledge, attrition, and whether the people who built the system are still there and intend to stay.
• Security posture. Control maturity, and, when scoped properly, whether the environment is currently compromised. These are different questions and most engagements only answer the first.
• Intellectual property and licensing. Code provenance, open-source license obligations, contractor assignment, and whether the company owns what it is selling.

The Scope Boundary Problem

This is the most expensive misunderstanding in the discipline, and no major published guide addresses it.

Four adjacent diligence workstreams are routinely confused with one another. Buyers purchase one and assume it included the others. It did not.

The overlaps produce double payment. The gaps produce uncovered risk, and the gaps are worse.

The most common failure: a sponsor commissions technology due diligence, receives a competent report on architecture and code, and assumes security was covered because the report contained a security section. That section usually assesses whether controls exist. It does not establish whether the environment is currently compromised, because compromise assessment is a distinct exercise requiring different access and different tooling.

The practical fix is to state the boundary explicitly in each scope of work, and to name which party owns the questions that fall between them. Ask every provider directly: what will you not look at, and what would I need to commission separately?

What Tech DD Usually Excludes

Even a thorough engagement typically leaves these out unless specifically scoped:

• External attack surface enumeration and exposed service discovery
• Dark web exposure of the target's credentials
• Active compromise assessment
• Testing of the controls a SOC 2 report asserts (reviewing the report is not testing the controls)
• Software composition analysis for open-source license obligations
• Penetration testing

Several of those are inexpensive relative to deal size and answer questions that matter more than code quality.

Cost and Timeline

Published guidance on this is thin, and the one commonly cited range, roughly $5,000 to $30,000, describes small engagements and misleads anyone scoping a platform deal.

Cost is driven by:

• Engineering headcount. The single best proxy for system complexity.
• Number of distinct products and whether they share a codebase.
• Architecture. A monolith is faster to assess than forty microservices with inconsistent ownership.
• Regulated data. Health, payment, or government data adds compliance workstreams.
• Target cooperation. A competitive process with a reluctant seller and limited access costs more and yields less.
• Whether security is genuinely in scope. Compromise assessment is additive.

A focused review of a small software company sits at the low end. A platform acquisition with multiple products, a large engineering organization, and regulated data runs materially higher, and a sponsor who budgets $25,000 for that engagement will receive a document rather than an assessment.

On timeline: two to four weeks of fieldwork is standard, plus scoping ahead of it and report production after. The constraint is rarely the provider. It is that diligence periods are set by deal dynamics, and a compressed exclusivity window forces the provider to sample rather than examine.

Getting Access

Sellers withhold the most informative artifacts until an LOI is signed, which means the LOI should specify them. Worth naming explicitly: read-only source code access, cloud console access, prior penetration test reports, incident history, the asset inventory, and a live walkthrough of the development lifecycle rather than a prepared demo.

If the seller refuses access to security artifacts, that refusal is itself a finding and should be recorded as one.

Platform Versus Bolt-On: Different Questions

Published guidance treats tech DD as one exercise. It is two, and conflating them produces the wrong scope.

For a platform acquisition, the thesis usually involves growth and often a roll-up. The questions that matter:

• Can the architecture absorb acquired products, or will every bolt-on run as a separate stack indefinitely?
• Does the engineering organization have the capacity to integrate while continuing to ship?
• Is there a credible technology leader, or does the sponsor need to recruit a CTO in year one?
• Will infrastructure cost scale linearly with revenue, or worse?
• Are the security controls a foundation the portfolio can standardize on?

For a bolt-on, the thesis is integration into something that already exists. The questions change:

• What does integration into the platform actually cost, in engineering months?
• What license and infrastructure spend becomes redundant, and when can it be eliminated?
• How entangled is the target's data with systems that are not being acquired?
• Does the target introduce security exposure into the platform's environment on day one of connection?

That last question is the one most often missed. Connecting an acquired company to the platform's network extends the platform's attack surface to include everything the target failed to secure. A bolt-on with weak identity controls becomes the platform's problem the moment the two environments are joined, and that connection frequently happens before anyone has assessed it.

Reading the Findings

Distinguishing Red Flags From Normal Ugliness

Every engineering organization looks bad under examination. Technical debt is universal. Documentation is always incomplete. Test coverage is rarely where anyone wants it. A diligence report that lists these as findings without calibration is not useful.

The calibration question is not "is this bad" but "does this threaten the thesis, and what does fixing it cost." A monolith with poor test coverage in a business whose plan is steady organic growth is a manageable liability. The same system in a business whose plan requires tripling release velocity is a thesis problem.

Findings worth escalating share a property: they are expensive or slow to fix relative to the hold period, or they represent a liability that already exists rather than a risk that might materialize.

Absence of Evidence Is a Finding

When a target cannot produce an asset inventory, has no record of security testing, and cannot say when it last restored from backup, the correct conclusion is not that those things are fine. An organization without evidence has not been managing the thing the evidence would document.

This is routinely under-weighted because it produces no specific finding to write down. It should be recorded plainly: the target could not evidence X, and the remediation estimate assumes the worst reasonable case.

Key Person Risk, Tested Rather Than Asserted

Most reports name key person risk as a category. Few test it. The tests that produce signal:

• Commit concentration. What percentage of the codebase was authored by how few people?
• Who holds root credentials, the domain registrar, the cloud tenant owner account, and the code signing keys?
• How deep is the on-call rotation, and how often does it escalate to one specific person?
• Is there any system only one individual understands well enough to change safely?

The output should feed retention package sizing rather than a bullet in a risk register. If two engineers hold the company together, their retention terms are a deal term.

Open Source and IP Provenance

Underweighted everywhere and occasionally existential. A software company selling a product built on copyleft-licensed components it has not complied with is selling something it may be obligated to disclose the source of. Contractor-written code without a valid assignment may not belong to the company at all. Code of uncertain provenance, an increasing concern as AI-assisted development becomes standard, raises questions nobody has fully settled.

A software composition analysis scan is cheap relative to deal size and answers a question that a code quality review does not ask.

From Finding to Deal Term

This is the section the published guidance does not write, and it is the reason to commission the work.

Quantify in the Right Currency

A finding becomes negotiable when it carries a number. The critical distinction is whether the remediation is a one-time cost or a permanent one, because the two are worth different amounts.

One-time capex (rebuilding a component, a migration, a security remediation program) is a below-the-line adjustment. The argument is for a purchase price reduction equal to the cost, or an escrow of that size. It does not touch the multiple.

Permanent opex (additional engineering headcount required indefinitely, structurally higher infrastructure cost, a compliance function the target lacks) reduces EBITDA. At a 10x multiple, $500,000 of permanent annual cost is a $5 million valuation issue, not a $500,000 one.

Sellers will argue every finding is one-time. Buyers should arrive with the distinction already drawn and evidenced, because it is worth an order of magnitude.

The Instruments

Findings reach the agreement through a small set of mechanisms:

• Purchase price adjustment. Cleanest where the remediation cost is quantifiable and undisputed.
• Escrow or holdback. Appropriate where the cost is probable but not yet certain. Size it against the estimate, with a release tied to remediation completion.
• Specific indemnity. The instrument for a known, identified liability, such as a prior incident or an open compliance failure. Sellers resist these because they survive the general cap.
• Representations and warranties. Standard coverage for the unknown, including compliance with applicable standards and the absence of known breaches.
• Closing condition. Reserved for findings that must be resolved before money moves.
• Retention packages. The instrument for key person risk.

The R&W Insurance Trap

Sponsors using representations and warranties insurance need to understand a mechanic that works against thorough diligence.

R&W underwriters exclude known issues. A finding identified in diligence and disclosed becomes an exclusion from coverage. A finding nobody looked for is not excluded, but it is also not covered if the underwriter concludes diligence was inadequate.

The resolution is not to look less carefully. It is to negotiate the identified finding directly into the agreement through an indemnity or escrow, rather than assuming the insurance will absorb it. Sponsors who discover this ordering after signing discover it expensively. Cyber and data privacy exclusions in R&W policies deserve specific attention, as they are common and broad.

When to Walk

No published guide states a disqualifying finding. A short list worth treating as near-disqualifying: a compromise the seller will not disclose or remediate, code the company cannot demonstrate it owns, a copyleft obligation attached to the core product, and a regulated-data compliance failure with an open regulator matter. Each is a liability of indeterminate size that transfers at close.

What the Report Should Contain

A useful deliverable serves four distinct readers and should be structured for them explicitly:

• The deal partner needs one page: thesis risks, the quantified number, and the recommended deal terms.
• The investment committee needs the finding, the evidence, and the mitigation, in a form that survives challenge.
• The future portfolio CTO needs the detail, because the report becomes the first draft of the 100-day plan.
• Lenders, where applicable, may require a reliance letter. Negotiate reliance up front; retrofitting it is difficult.

Reading a Vendor Diligence Report

In competitive processes, sellers increasingly commission their own technology diligence and distribute it. Such a report is useful and structurally incomplete. It was scoped by the party being examined, which means the scope itself is the finding to examine. Compromise assessment is almost never included. Cost estimates skew low. Read it for the architecture description, treat its conclusions as a starting position, and scope your own work around what it omitted.

Related Reading

• What is Cyber Due Diligence?
• What is M&A Cyber Due Diligence?
• What is a Compromise Assessment?
• What is Sponsor Cyber Liability?
• What is an SBOM?
• What is a Cyber Insurance Attestation?
• RTO and RPO: What the Numbers Commit You To

Marriott and Starwood: The Diligence That Did Not Look

Marriott acquired Starwood Hotels in 2016. In late 2018 it disclosed that the Starwood guest reservation database had been breached, with the intrusion dating to 2014, two years before the acquisition closed.

The essential fact for anyone scoping diligence: the compromise was present in the environment throughout the transaction. It was there during diligence, at signing, and at close. Marriott acquired an active intrusion along with the hotels, then operated the compromised system for roughly two years before discovering it.

The consequences landed on the acquirer. The UK Information Commissioner's Office issued a fine against Marriott, eventually settling at a figure substantially reduced from its initial notice. Marriott, not Starwood's former owners, faced the regulatory exposure, the litigation, the notification costs, and the reputational damage.

Two things follow for a sponsor.

First, control maturity assessment would not have found this. Reviewing policies, interviewing staff, and examining a security questionnaire establishes whether controls exist. It does not establish whether an adversary is present. Those require different work: threat hunting across the environment, examination of authentication and egress telemetry, and dark web review for exposed credentials.

Second, this is the clearest argument for the scope boundary discussion. A technology due diligence engagement examining architecture, code, and team would have been entirely competent and would have missed this completely, because it was not the question that engagement was asked.

The cost of asking is a fraction of one percent of a transaction of that size. The cost of not asking was borne by the buyer for years.