Technology due diligence has a credibility problem. Not because the discipline is flawed — but because the way it is frequently practised falls well short of what the name implies.

A conversation with the engineering team. A review of the architecture documentation. A high-level assessment of the tech stack. A report that confirms the platform is “broadly fit for purpose” with some caveats.

This is not technology due diligence. It is a surface-level review that creates the appearance of assessment without the substance of it. And the risks it misses are precisely the ones that surface post-close — when the acquirer has no recourse and no leverage.

Here is why most TDD misses the real risks — and what rigorous assessment actually requires.

The Documentation Gap

The first and most fundamental problem is that most TDD is based on what the target chooses to share — documentation, architecture diagrams, management summaries — rather than on independent access to the underlying systems.

Documentation describes how a platform was designed to work. It does not describe how it actually works. The gap between the two is where the most consequential risks live: the shortcuts that were taken under delivery pressure, the components that never matched the original design, the integrations that work in ways nobody has fully documented because the engineer who built them left eighteen months ago.

Without direct access to the codebase, infrastructure, and engineering team — and the expertise to assess what you find there — you are not conducting due diligence. You are reading a prospectus.

The Expertise Problem

Even when direct access is granted, the quality of the assessment depends entirely on the expertise of the people conducting it. Technology due diligence requires a specific combination of skills that is rarely found in a single generalist reviewer: software architecture expertise, code quality assessment capability, infrastructure and DevOps knowledge, security assessment skills, and the commercial judgment to translate technical findings into deal-relevant terms.

Informal assessments — conducted by a CTO in the investor’s network, or by a generalist consultant who happens to have a technical background — frequently reflect whatever the assessor knows best. A backend engineer scrutinises the codebase but misses the infrastructure exposure. A security specialist identifies vulnerabilities but does not assess the engineering team stability. A generalist covers everything at a surface level and misses the depth needed to find what matters.

The risks that most consistently go undetected are not obvious ones. They require specific expertise to identify — and commercial judgment to prioritise.

What Gets Missed: Security

Security is one of the most consistently underassessed areas in technology due diligence — and one of the most consequential when it goes wrong.

The problem is not that security is ignored. It is that it is assessed at the wrong level. A TDD that asks whether the platform has security certifications and checks for known CVEs in dependencies is conducting a compliance review, not a security assessment.

Genuine security due diligence examines the platform across every layer: security architecture and authentication design at the application level; vulnerability identification and secure coding practices at the code level; network exposure, access controls, and patch management at the infrastructure level; and access governance, offboarding processes, and incident response capability at the organisational level.

In regulated sectors — financial services, healthcare, legal — security gaps translate directly into regulatory liability, customer attrition, and reputational damage. They also transfer to the acquirer at close, unconditionally, unless identified and addressed in deal structuring beforehand. A security assessment that misses a material vulnerability is not just incomplete — it is actively misleading, because it creates confidence where caution is warranted.

What Gets Missed: AI

As AI businesses become an increasing proportion of technology M&A deal flow, the limitations of traditional TDD frameworks are becoming more acute. Most conventional due diligence methodologies were not built to assess AI systems — and applying them to AI targets leaves material risks entirely unexamined.

The most common blind spot is the distinction between genuine proprietary AI capability and a thin wrapper around a third-party foundation model. A business that has built prompt engineering on top of GPT or Claude looks technically impressive from the outside. It is fundamentally different — in defensibility, in risk profile, and in valuation — from a business with proprietary training data, fine-tuned models, and genuine AI research capability. Most TDD frameworks cannot make this distinction reliably.

Beyond architecture, AI businesses carry data-specific risks that sit outside the scope of conventional assessment: training data that was scraped without appropriate licensing, personal data used in training without a valid legal basis, datasets that embed biases creating exposure under the EU AI Act. These are not edge cases. They are systematic risks in a market that has moved faster than the due diligence frameworks designed to assess it.

AI talent concentration amplifies all of the above. When the institutional knowledge of how a model was built, trained, and can be extended resides in two or three individuals, the acquirer’s exposure to their departure is not just an HR risk — it is a capability risk that can render a core part of the acquired value permanently inaccessible.

The Right Approach

Rigorous technology due diligence requires four things that most informal assessments lack: direct access to the codebase and infrastructure; a structured, repeatable framework that covers every risk dimension consistently; genuine expertise across architecture, code quality, security, and engineering team assessment; and the commercial judgment to translate findings into deal-relevant terms.

It also requires intellectual honesty — the willingness to report what the evidence shows, not what makes the transaction easier to complete.

At VeryDiligent, our engagements are designed around all four. We provide independent, expert-led technology due diligence — covering architecture, codebase quality, security, infrastructure, engineering team, and AI-specific risk — delivered within your deal timeline and structured to inform both deal pricing and post-close planning.

Contact us today to discuss your upcoming transaction.

Related reading: A 4-Layer Model for Assessing Technical Risk | AI Startups Are Harder to Diligence Than You Think | Cybersecurity Due Diligence: The New Dealbreaker