What Is Technical Due Diligence In A Software Acquisition?

Every acquisition of a software business rests on one assumption: that the software works, the seller owns it, and it can carry the growth in the model. Technical due diligence tests that assumption before the money moves.

It is the only part of a deal where somebody opens the code. Search for the software due diligence meaning and you get definitions that are accurate and useless in equal measure.

Buyers want something narrower. What gets examined, who does the examining, what the UK rules require, and what happens to the price when the answers come back badly.

The market is not making this easier. ONS figures released on 1 September 2026 recorded 130 completed domestic acquisitions of UK companies in the second quarter of 2026, worth £4.2bn, against 241 in the same quarter of 2025.

Thinner markets make buyers slower to forgive and sellers less able to bluff. Here is what actually happens in the room, and what software technical due diligence should produce at the end of it.

What Does Technical Due Diligence Examine?

A technical due diligence review covers six areas: code quality, system architecture, security and compliance, intellectual property and licensing, the engineering team, and scalability against the growth plan. Every finding is graded for severity and costed for remediation.

The output is a risk register with money attached to each line. That is the only form a deal team can act on.

Area	What the reviewer looks for	Common red flag
Code quality	Test coverage, defect density, static analysis results, commit history	No automated tests around the billing logic
Architecture	Coupling, single points of failure, ability to scale the growth plan	One shared database every service writes to
Security	Open CVEs, patching cadence, access control, incident history	Production credentials committed to the repository
IP and licensing	Ownership chain, contractor assignments, open source obligations	Copyleft code inside a proprietary product
The team	Key person dependency, attrition, contractor mix, documentation	One engineer who understands the pricing engine
Scalability and cost	Infrastructure cost per customer, headroom, vendor lock-in	Cloud bill rising faster than revenue

Code Quality and Technical Debt

Reviewers run static analysis across the whole repository. SonarQube is the usual starting point, alongside dependency scanners and a read of the git history to see how the code has been maintained rather than how it looks today.

Tooling gives a baseline, not a verdict. A high issue count on a ten-year-old codebase generating £4m of recurring revenue may be tolerable, and a clean report on a system nobody can deploy without a manual runbook is not.

What separates a useful review from a scan is whether the reviewer can tell the difference. That judgement comes from having run software delivery rather than only audited it.

Architecture and Scalability

The question is not whether the architecture is fashionable. It is whether it can carry the customer numbers in the buyer’s model without a rebuild.

Reviewers look for shared databases, synchronous chains that fail together, and infrastructure cost that rises faster than revenue. A per-customer cost curve going the wrong way is a valuation issue, not an engineering one.

Where the answer is that the platform cannot scale, the remediation is usually a legacy modernisation programme with a cost and a timeline attached, which is far more useful to a deal team than an adjective.

Intellectual Property and Open Source Licences

This is where deals die quietly. Most modern products are assembled rather than written, and the question is whether the seller owns what they assembled.

Permissive licences such as MIT and Apache 2.0 are rarely a problem. Copyleft licences are, because combining GPL code with a proprietary product can create an obligation to publish your own source when you distribute it.

The problem is getting worse, not better. Black Duck’s 2026 Open Source Security and Risk Analysis report examined 947 commercial codebases and found 68% contained open source licence conflicts, up from 56% the year before and the highest rate it has recorded.

Security and Compliance

The reviewer checks known vulnerabilities against the National Vulnerability Database, along with patching speed, who holds production access, and whether an incident went undisclosed.

The same Black Duck study found 87% of audited codebases carried a known vulnerability and 78% a high-risk one, with a mean of 581 vulnerabilities per codebase, more than double the previous year.

Certification shortens the argument. A current ISO/IEC 27001 certificate or a SOC 2 Type II report tells a buyer an external auditor has already tested the controls.

Neither proves the software is secure. Their absence in a business selling to enterprise or public sector buyers raises an obvious question about future sales, and Cyber Essentials is the minimum most UK public sector procurement expects.

Where the review finds real exposure, price the fix rather than the fright. A scoped programme of application security work gives the deal team a number, and a warning without a number gives them nothing to negotiate with.

The Engineering Team

Code is transferable. People are not.

Reviewers interview the engineers, map who understands what, and look for the parts of the system that depend on a single individual staying. Those single points of knowledge turn into retention packages, earnouts and deferred consideration at the negotiating table.

How Does a Reviewer Grade What They Find?

Findings are graded on what they threaten rather than how untidy they are: critical means ownership or continuity is in doubt, material means a costed remediation the buyer will fund, and monitor means a known issue with no deal consequence.

No competitor publishes a grading scheme, and it is the part that turns a technical report into a negotiating position.

Grade	What it means	How the deal team treats it	Example
Critical	Ownership, legality or continuity of the product is in doubt	Condition to close, specific indemnity, or withdrawal	Copyleft code in the core product; no contractor IP assignments
Material	A real cost the buyer will carry, and it can be quantified	Price adjustment or escrow against the costed figure	£400k to re-platform a component that cannot scale
Structural	Ongoing cost that changes the run rate rather than a one-off	EBITDA adjustment, which the multiple then magnifies	Three extra engineers needed permanently to keep the system running
Monitor	Known, bounded, no deal consequence	Goes into the 100-day plan, not the price	Ageing but supported framework version with an upgrade path
Noise	Tooling output with no business meaning	Excluded from the report	Static analysis warnings in generated or vendor code

Why Severity Matters More Than Issue Count

A scan will happily return nine thousand findings on a healthy codebase. Counting them tells a buyer nothing, and grading them tells a buyer what to do.

The distinction between material and structural is the one that moves the most money. One is a cheque, the other is a permanent change to the earnings the buyer is paying a multiple for.

What a Good Report Actually Contains

• A ranked risk register with a grade, an owner and a cost against every line.
• A remediation plan sequenced into the first 100 days after completion.
• A clear statement of what was not examined, and why.
• Evidence appendices a warranty negotiation can actually cite.

A review that ends at completion has done half its job. The remediation roadmap is the reason the buyer commissioned it, and it should survive into the integration plan.

Who Runs Technical Due Diligence and What Does It Cost?

Buy-side technical due diligence is commissioned by the acquirer, most often a private equity or venture capital firm, a corporate development team or a trade buyer, and delivered by an independent engineering firm. UK fees run from around £10,000 on a small deal to £150,000 or more on a large enterprise transaction.

Deal value	Typical fee	Typical duration	Usual depth
Under £1m	£10,000 to £25,000	2 to 3 weeks	Code sample, architecture review, licence scan
£1m to £10m	£25,000 to £60,000	3 to 5 weeks	Full repository scan, team interviews, security review
Over £10m	£60,000 to £150,000+	4 to 8 weeks	Multi-system review, infrastructure testing, remediation costing
Pre-LOI red flag	£5,000 to £10,000	2 to 5 days	Dealbreakers only, usually credited against the full engagement

As a share of deal value that lands well under 1%, and on larger transactions a small fraction of that. Set against a purchase price built on a multiple of earnings, it is cheap insurance.

Why Independence Matters

A buyer’s own engineers could do the work, but they carry an incentive. The deal team wants the deal, and nobody enjoys being the reason it stops.

An independent reviewer has no position on whether the transaction happens. If your organisation has no in-house technical leadership to interpret the findings, a fractional CTO can sit on your side of the table while the review runs.

Ask who will actually do the work before you engage anyone. Reviewers who have built and run production software read a codebase differently from auditors who have not.

Vendor Due Diligence, and When It Pays

Sellers commission it too. Vendor due diligence, run before the business goes to market, finds the problems while there is time to fix them and takes the surprise out of the buyer’s report.

It typically costs less than a buy-side review of the same business, because scope is narrower and access is unrestricted. What drives technical due diligence costs sets out where the money goes in each case.

Commission an independent technical due diligence review

When in the Deal Does the Tech DD Process Happen?

The tech DD process runs after heads of terms are agreed and inside the exclusivity period, typically a 30 to 60 day window before exchange. Larger buyers often commission a short red flag review before the letter of intent to decide whether to bid at all.

The Sequence That Works

• Pre-LOI: a two to five day red flag review, usually documentation and interviews only, with no code access.
• Heads of terms signed, exclusivity begins, data room and repository access granted.
• Weeks one to two: code scanning, architecture review, licence and dependency analysis.
• Weeks two to four: engineer interviews, infrastructure review, remediation costing.
• Report delivered to the deal team, findings fed into the sale and purchase agreement negotiation.
• Post-completion: the remediation roadmap becomes the first 100 days of the technology plan.

Why Earlier and Later Both Fail

Earlier than heads of terms is rarely possible, because sellers will not open a repository to a buyer who has not committed to a price range.

Later is worse. By then the buyer has spent legal fees and acquired an emotional stake in completing, which is the worst possible moment to receive bad news about the code.

Competitive processes push exclusivity toward the shorter end of 30 days, and complex multi-system targets often need an extension. Agree the technical workstream timetable before exclusivity starts, not after.

What Do the Findings Do to a Deal?

Findings do one of four things: cut the price, push risk into warranties and indemnities, add conditions the seller must satisfy before completion, or end the deal. How a finding lands depends on whether it is a one-off cost or a permanent one.

Finding	What it usually means	Typical deal outcome
Copyleft code in the proprietary product	Ownership of the product is in question	Specific indemnity, escrow, or walk away
No contractor IP assignments	The seller may not own parts of the code	Condition to close: get the deeds signed
Undisclosed security incident	A trust problem as much as a technical one	Renegotiation or withdrawal
Heavy technical debt, costed	Known spend rather than a mystery	Price reduction matched to the remediation cost
Single-engineer dependency	Value walks out if that person leaves	Retention package, earnout, deferred consideration
Architecture cannot support the plan	The growth model is not deliverable	Revised model and a lower multiple
Target is in a notifiable NSI sector	Regulatory approval is required before completion	Condition precedent and a longer timetable

One-Off Costs Versus Permanent Costs

One-off remediation, say £400,000 to re-platform a legacy component, is usually treated as a debt-like item and comes off enterprise value close to pound for pound.

A permanent cost is different. If the review shows the business needs three more engineers indefinitely just to keep the system running, that hits earnings, and earnings get multiplied.

At 8x, £250,000 of extra annual cost is a £2m valuation problem. That arithmetic is why sellers should find structural issues before a buyer does.

The Mechanisms Buyers Actually Use

• Price chip: the headline consideration reduces by the costed remediation figure.
• Escrow or retention: part of the consideration is held back against a defined risk crystallising.
• Specific indemnity: the seller carries a named risk in full, outside the general warranty cap.
• Condition precedent: something must be fixed or obtained before completion happens at all.

Which one applies is a negotiation, and the costed report is what decides it. A finding described without a number becomes a warranty, and a finding with a number becomes a price.

What Actually Ends Deals

Most findings do not kill transactions. They move money and risk around, which is what they are for.

The reviews that end deals almost always involve ownership or honesty rather than code quality. A buyer can fix bad code, sometimes by taking the codebase over with a new team, and cannot fix a seller who did not mention the breach.

What UK Rules Apply to a Software Acquisition?

The National Security and Investment Act 2021 requires mandatory clearance before completing an acquisition of a company active in 17 sensitive areas, including artificial intelligence, data infrastructure, communications and quantum technologies. Completing without approval makes the transaction legally void.

Every competitor guide on this subject is region-neutral or American. For a UK deal this is the section that matters most, and it is the one most likely to be missed.

The National Security and Investment Act 2021

Mandatory notification is triggered by acquiring shareholdings or voting rights crossing 25%, 50% or 75% in a qualifying entity active in one of the 17 notifiable sectors. There is no turnover or market share threshold, so a very small startup is caught.

Point	What applies
Sectors most likely to catch a software deal	Artificial Intelligence, Computing Hardware, Communications, Cryptographic Authentication, Data Infrastructure, Quantum Technologies
Other notifiable sectors	Advanced Materials, Advanced Robotics, Civil Nuclear, Critical Suppliers to Government, Defence, Energy, Military and Dual-Use, Satellite and Space, Suppliers to the Emergency Services, Synthetic Biology, Transport
Trigger	Shareholding or voting rights crossing 25%, 50% or 75%, or rights to pass or block resolutions
Thresholds	None. Turnover and market share are irrelevant
Effect of completing without approval	The transaction is legally void
Civil penalty	The higher of 5% of worldwide turnover or £10m, plus daily-rate penalties
Criminal exposure	Up to five years imprisonment and director disqualification for up to 15 years

The penalty maxima sit in section 41 of the Act. Work out early whether the target’s activity falls inside a notifiable area, because the answer changes the completion timetable rather than the price.

The sector definitions are narrower than their names suggest, so read the notifiable acquisitions guidance against what the target actually does. A product that merely uses a third-party AI API is not automatically in scope.

Data Protection Exposure and Undisclosed Breaches

A target that suffered a personal data breach had 72 hours to report it to the ICO. Ask directly whether any reportable breach has occurred, and get the answer in writing.

An undisclosed incident is the finding most likely to end a transaction, because it is evidence about the seller rather than the software. Where the target holds sensitive data, commission a separate software security assessment alongside the review.

Merger Control and Sector Regulators

UK merger control is voluntary, but the Competition and Markets Authority can call a deal in after completion. CMA merger guidance is worth a read where the buyer already holds share in the same market.

Sector regulators add their own gates. Fintech targets bring FCA change in control approval, and health targets bring clinical safety standards, each with a timetable of its own.

Who Owns the Code, and How Do You Prove It?

Ownership is proved by a chain of documents, not by possession of the repository. A buyer needs signed IP assignments from every contractor, employment contracts with IP clauses, and confirmation that the entity being bought is the entity that owns the code.

This is the most common cause of a condition to close on a UK software deal. It is also the cheapest thing in this article to fix in advance.

The Chain of Title a Buyer Needs to See

Work created by an employee in the course of employment generally belongs to the employer, and work created by a contractor generally does not unless it was assigned in writing. The Intellectual Property Office guidance on ownership of copyright works is the plain-English version of that rule.

Then check the corporate side. A Companies House search should confirm that the trading entity, not a dormant holding company nobody transferred the assets out of, is the one being sold.

Contractors, Offshore Developers and Founder Code

• Offshore agencies: check the assignment sits with the individual developers as well as the agency.
• Freelancers paid through personal service companies: the assignment must come from the company that was paid.
• Founder code written before incorporation: assign it to the company explicitly, however obvious it seems.
• Former employees who contributed after leaving: a single unassigned commit can taint a module.

None of these is difficult to resolve six months before a sale. All of them are expensive to resolve during exclusivity, with a lawyer and a buyer watching.

Open Source Obligations and When They Actually Bite

Copyleft obligations generally attach on distribution rather than internal use, which is why some SaaS products carry GPL components without a problem. The AGPL is the variant written to close that gap, so check the specific licence rather than the family, using an SBOM as the starting point.

Produce the bill of materials in a standard format so the buyer’s tooling can read it. SPDX and CycloneDX are the two that reviewers expect.

How Do You Diligence an AI Product?

Establish first whether the target owns a model, a data asset, or a prompt sitting on somebody else’s API. Then price the three risks that follow: training data rights, code provenance, and concentration on a single model vendor.

Almost no due diligence guide covers this yet, and a growing share of software targets now describe themselves as AI companies.

Is It a Model or a Wrapper?

A thin wrapper over a public API is a product decision, not an asset. It can still be a good business, and it should not be valued as proprietary technology.

Ask what would survive if the underlying provider doubled its prices or withdrew the model. Where the answer is a workflow and a dataset rather than weights, the value sits in the custom AI layer the target built on top.

Related: Custom AI Software Development: The Secret to Scaling Your Business

Training Data Rights and Code Provenance

If the target fine-tuned a model, ask what it was trained on and whether they had the right to use it. Customer data used for training without a contractual basis is a live liability, not a feature.

Ask separately about AI-assisted coding. Generated code can carry licence contamination that no dependency scanner will catch, so the question is whether the team has a policy and any record of it.

Model Cost and Vendor Concentration

Inference cost per customer belongs in the same analysis as cloud cost per customer. A gross margin that only works at current token prices is a structural finding, not a monitor item.

Check whether an abstraction layer exists between the application and the provider. Where decisions about people are automated, ask how the target explains them, because explainable AI is now a compliance requirement rather than a nicety.

How Should a Seller Prepare for Technical Due Diligence?

Run the review on yourself first, ideally six to twelve months before going to market. Sellers who arrive with an SBOM, signed IP assignments, current architecture documentation and a known list of open vulnerabilities hold their price far better than those who let the buyer’s team discover those things.

None of this is about presenting a perfect system. Buyers do not expect one, and a founder who claims there is no technical debt tells an experienced reviewer something unhelpful about themselves.

The 90-Day Preparation Sequence

Window	What to do	Why it matters
Days 1-15	Generate an SBOM, identify every licence, flag copyleft components	Licence conflicts take the longest to fix and kill the most deals
Days 15-45	Collect and sign IP assignment deeds for every contractor, past and present	The most common condition to close on a UK software deal
Days 30-60	Patch known vulnerabilities, document what remains and why	An honest open list beats a surprise every time
Days 45-75	Update architecture diagrams so they match what is deployed	Diagrams that do not match production undermine everything else
Days 60-90	Write deployment and onboarding documentation, remove single points of knowledge	Key person risk converts directly into deferred consideration

The Data Room Checklist

• A software bill of materials with every dependency and its licence identified.
• Signed IP assignment deeds for every contractor and developer, past and present.
• Confirmation from Companies House filings that the trading entity owns the IP.
• Current architecture diagrams that match what is actually deployed.
• A patching record and an honest list of open vulnerabilities.
• Evidence of ISO 27001, SOC 2 or Cyber Essentials where customers expect it.
• Documentation good enough that a new engineer can deploy without asking the founder.

What to Fix and What to Disclose

Fix anything that threatens ownership, and disclose almost everything else. A costed, disclosed problem is a negotiation, and an undisclosed one is a trust event.

Fixing a copyleft problem takes weeks when you find it yourself. It takes a lawyer, an indemnity and a price cut when the buyer finds it during exclusivity, and by then a code rescue is being priced into your valuation rather than planned by you.

Buyers reward sellers who already know what is wrong. That is also what a clean integration looks like afterwards, as in our work with Composite Legal Expenses, where the technology plan was understood before anyone owned it.

Related Guides

Related: Software Technical Due Diligence Costs Explained

Related: What Is a Software Security Assessment?

Related: What Are the Signs That a Software Project Is in Trouble?

Related: What Is Legacy Software Modernisation?

Related: What Should Be in a Software Development Contract?

Related: What Are the Stages of the Software Development Life Cycle?

Frequently Asked Questions