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

Frequently Asked Questions

What is technology due diligence?

The pre-close examination of a target company's technology: the product and its architecture, code quality and technical debt, infrastructure and its cost trajectory, the engineering organization, security posture, and intellectual property provenance. The purpose is to establish what the acquirer is buying, what it will cost to own, and what liabilities transfer at close. For a sponsor, its value is measured by whether findings convert into deal terms rather than by the thoroughness of the document.

How much does technology due diligence cost?

Cost is driven by engineering headcount, the number of distinct products, architectural complexity, whether regulated data is involved, how cooperative the target is, and whether security is genuinely in scope. The commonly cited $5,000 to $30,000 range describes small engagements and misleads anyone scoping a platform acquisition, where multiple products, a large engineering organization, and regulated data push cost materially higher. Budgeting at the low end for a complex target purchases a document rather than an assessment.

How long does technology due diligence take?

Two to four weeks of fieldwork is typical for a mid-market target, plus scoping beforehand and report production afterward. The binding constraint is usually the diligence period rather than the provider: a compressed exclusivity window forces sampling instead of examination. Where the timeline is tight, it is better to narrow scope deliberately and say what was not covered than to spread the same hours across everything.

What is the difference between technology, IT, cyber, and IP due diligence?

Technology DD asks whether the product works and will scale, covering architecture, code, and the engineering organization. IT DD asks what running the business costs, covering corporate systems, ERP, and licensing. Cyber DD asks whether the environment is secure and whether anyone is already inside. IP DD asks whether the company owns what it is selling, covering code provenance, open-source licensing, and contractor assignment. Buyers routinely commission one and assume it included the others. The overlaps cause double payment and the gaps leave risk uncovered, so the boundary should be stated explicitly in each scope of work.

Does technology due diligence include a security assessment?

Usually a limited one, and rarely the part that matters most. Most engagements assess whether security controls exist and appear reasonably mature. Very few establish whether the environment is currently compromised, because compromise assessment requires different access, different tooling, and a different skill set. A target can have satisfactory controls and an adversary present simultaneously. If that question matters, and after Marriott's acquisition of Starwood it should, it must be scoped explicitly.

How do diligence findings affect the purchase price?

Through several instruments, depending on the finding. A quantifiable, undisputed remediation cost supports a purchase price adjustment. A probable but uncertain cost supports an escrow or holdback, ideally released on remediation completion. A known, identified liability such as a prior incident supports a specific indemnity, which survives the general cap. Unknown risk is covered by representations and warranties. The critical analytical step is separating one-time capex, which argues for a price reduction, from permanent opex, which reduces EBITDA and is therefore worth the multiple.

How do you quantify technical debt for a deal model?

Convert remediation into a dollar figure, then classify it. One-time work such as a rebuild, migration, or remediation program is a below-the-line capex adjustment and argues for a price reduction equal to its cost. Permanent cost such as additional engineering headcount required indefinitely, structurally elevated infrastructure spend, or a compliance function the target lacks reduces EBITDA and therefore costs the multiple. At a 10x multiple, $500,000 of permanent annual cost is a $5 million issue. Sellers argue everything is one-time, so buyers should arrive with the distinction drawn and evidenced.

How does R&W insurance treat diligence findings?

Underwriters exclude known issues, which creates a counterintuitive dynamic: a problem identified in diligence and disclosed is typically carved out of coverage, while one nobody looked for is uncovered anyway if the underwriter concludes diligence was inadequate. The resolution is not to diligence less thoroughly but to negotiate identified findings directly into the agreement through indemnity or escrow rather than expecting the policy to absorb them. Cyber and data privacy exclusions in R&W policies are common and broad, and warrant specific review.

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.