Technology due diligence exists to answer one question: does the technology support the price you are about to pay? Everything else in the report is evidence for that answer.
The discipline gets confused with three adjacent things. It is not an IT audit, which checks controls against a standard. It is not a security assessment, though security is one of its inputs. It is not a code review, though someone will read the code. It is a commercial exercise conducted through a technical lens, and a report that forgets this ends up as forty pages of accurate observations that change nothing.
What does technology due diligence actually cover?
Six areas carry almost all the value.
Architecture and its fit to the plan. Not whether the architecture is elegant — whether it can take the volume, the geographies, the product variations and the customer count that the investment case assumes. A monolith serving a stable domestic business is not a finding. The same monolith in a buy-and-build thesis that needs six acquisitions integrated onto one platform is the whole deal.
Total cost of ownership. Run cost, licences, cloud, and the contractors who turn out to be load-bearing. This is where the first year of most plans quietly disappears. Sellers manage EBITDA into a process by deferring maintenance, letting support contracts lapse and leaving headcount unfilled. All of that is real money the buyer inherits, and none of it appears as a liability.
Technical debt, with a price on it. A list of complaints from the engineering team is not a finding. The finding is: this item costs €X a year to leave alone, €Y to fix, and it blocks the following three things in the plan. Debt that annoys engineers but blocks nothing can wait five years.
The team. Who actually holds the knowledge, and how concentrated is it? A company where two people can explain the billing logic has a valuation problem that no documentation exercise will fix before close. Then: what does the team cost at current market rates rather than at the rates on the payroll, and does the leadership scale to the organisation size the plan implies.
Security, data and compliance. The part that converts into an indemnity, a warranty or a price chip. Where personal data sits, who has access, what the incident history looks like, and whether the certifications the company claims are current.
Separability, for carve-outs. If the asset is leaving a parent, what genuinely detaches, what needs a transitional services agreement, how long that agreement has to run, and what both sides will charge for it. Carve-out technology costs are underestimated more reliably than any other line in this work.
When does a technology diligence change the outcome?
Most of the time it confirms what the deal team already suspected and the deal proceeds. That is a reasonable result, not a wasted fee — the alternative is underwriting a technology estate on the management presentation.
It changes the outcome in four recognisable situations.
The first is when the investment case depends on a technology capability that does not exist yet. The model shows a subscription line starting in year two; the platform has no billing, entitlement or metering. That is eighteen months and a team, not a feature.
The second is buy-and-build. Integration cost is the most systematically underestimated number in private equity technology, because it is invisible until the second acquisition, and by then the thesis is committed.
The third is an AI claim. This is where diligence goes wrong most often right now. There is a large difference between a company that owns a model, improves it on proprietary data and has a defensible feedback loop, and a company that sends prompts to a third-party API and prices the markup into its gross margin. The second is not worthless. It is worth a different multiple, and it carries a supplier concentration risk that belongs in the report.
The fourth is founder concentration. When the founder is also the architect, the only person who understands the system, and is leaving at close, the technology risk and the people risk are the same risk.
What does it cost, and how long does it take?
| Dimension | Typical shape |
|---|---|
| Duration | Set against the exclusivity window, commonly two to four weeks |
| Access needed | Code repository, cloud billing, architecture documentation, key technical staff, contracts with material vendors |
| Output | A short report leading with the answer, a priced risk register, and a hundred-day plan |
| Who reads it | The deal team and the investment committee, not the CTO |
Fees vary too much by scope and geography for a published figure to be useful. The more important variable is whether the scope is cut to the questions that can still change your decision. A diligence that answers everything and arrives after the bid is worth less than one that answers three things on time.
What separates a useful report from a thorough one
A useful technology diligence leads with the answer. The first page says whether the technology supports the case, what it will cost to make it support the case, and what would make you walk. Everything after that is evidence.
It puts money against findings. “Significant technical debt” is not actionable. “€1.4m over two years to replace the order management system, which blocks the international expansion in year two” is.
It takes a position. An adviser who lists risks without ranking them has transferred the judgement back to the reader, which is the part they were being paid for.
And it converts into a plan. The diligence findings and the hundred-day plan should be the same document with two sections, because the deal team that read the first one is the group that has to fund the second.
Frequently asked
Is technology due diligence only for software companies? No. Any business where technology carries operations — retail with a supply chain, insurance with underwriting systems, logistics, healthcare — has technology risk material to the price. Software businesses need the deepest version, but they are not the only ones that need it.
Can the management team’s own CTO provide this? They can provide the input, not the assessment. A CTO describing the estate they built is giving you a defence, not a diligence. Their view belongs in the process as one of the sources.
What is the difference between buy-side and vendor-side technology diligence? Buy-side answers whether you should pay this price. Vendor-side prepares the technology story before a process begins, so a buyer’s adviser does not discover something in week two that resets the negotiation. Vendor-side is cheaper and usually earns more.
Should the diligence adviser also run the post-deal work? Often yes, and the objection to it is weaker than it looks. The person who found the problem already has the context, and the plan arrives faster. The thing to guard against is an adviser who sizes the problem to fit the remediation engagement they want to sell next.