Tech due diligence finds what your pitch deck left out

The demo went well and the term sheet is on the table. Then their diligence team asks for access to your repository, every open-source component and its license, your last pen-test report, your incident log, and a straight answer on who runs production if two engineers quit tomorrow.

That's tech due diligence: a review of your code, licenses, security, architecture and team before the money moves. Its findings don't have to kill a deal to cost you. They rewrite the terms: a lower price, money held in escrow, an indemnity you sign, fixes due before closing. Our read: run the same review on yourself first, and you control that story.

What does tech due diligence actually check?

A seed investor may ask a few questions; a buyer may pay a third party to scan your code. The questions land in five areas: licenses, vulnerabilities, inherited breaches, architecture and people. Each can become a deal term.

In a March 2026 M&A white paper, Black Duck, which sells code audits for acquisitions, says license problems tend to bring demands for buyer protections, fixes before closing, escrows, price cuts or delay.

Do your open-source licenses conflict?

Black Duck's 2026 Open Source Security and Risk Analysis (OSSRA) covers 947 commercial codebases its audit team reviewed between November 2024 and October 2025, for M&A transactions, regulatory compliance and internal risk assessments. 68% contained license conflicts, up from 56% a year earlier. Counted by transaction in that white paper, 94% of the deals it audited had license conflicts. That's vendor research on software-heavy companies averaging over 1,000 open-source components per codebase: direction, not your odds.

Self-check:

• Generate a software bill of materials (SBOM) from your build, in a machine-readable format such as CycloneDX or SPDX.
• Run a license scan. Flag copyleft licenses such as the GPL or AGPL, which can require releasing your own source depending on how you ship, and any code with no license.
• Find code that skipped your package manager: copied libraries, pasted snippets, AI suggestions.
• If you ship AI features: which models, under which licenses, and what data trained or fine-tuned them, including whether customers agreed.

The SBOM alone puts you ahead: the same paper says most targets can't produce one easily, and when they do, it's "rarely accurate and never complete." For software products sold in the EU it's already law: the Cyber Resilience Act, in force since 10 December 2024, requires manufacturers to draw one up, covering at least top-level dependencies, from 11 December 2027. Hosted software mostly falls outside it; an EU-facing buyer will ask anyway.

How many known vulnerabilities ship with your product?

The same OSSRA data found known vulnerabilities in 87% of codebases, high-risk ones in 78% and critical ones in 44%, with an average of 581 per codebase, up 107% in a year. A diligence team doesn't expect zero. It expects you to know your number.

Self-check:

• Run a dependency scan, patch critical and high findings, and write down why the rest can wait.
• Have your latest pen-test report and remediation status ready.
• State your SOC 2 status exactly. It's an attestation, not a certification: a Type I report looks at control design on one date, a Type II tests whether they worked over an observation window of months. If you're mid-window, say so. If you haven't started, get audit-ready long before the data room opens.

Which breaches and data obligations come with the company?

Buy a company and you buy its incidents, including the ones nobody has found. Starwood's systems were compromised in 2014, Marriott bought Starwood in 2016, and the attack went undetected until September 2018. In an October 2020 penalty notice, the UK Information Commissioner's Office fined Marriott £18.4 million for failures after GDPR took effect in May 2018. The ICO made no finding on acquisition-time diligence, but wrote that the need for diligence on data operations "is not time-limited or a 'one-off' requirement," and that adequate diligence would have included reviewing monitoring and logging.

Deal terms move too. After agreeing in July 2016 to sell its operating business to Verizon, Yahoo disclosed two large data breaches. The February 2017 amendment cut the price by $350 million, to about $4.48 billion, split certain breach-related liabilities, and excluded the breaches when judging closing conditions. A mega-deal, not your benchmark, but the breach history ended up in the contract.

Self-check:

• A written incident log: date, what was exposed, who was notified, what changed.
• A data map: which personal data you hold, where it lives, which laws apply (GDPR, LGPD, LOPDP). The practical GDPR steps cover most of it.
• Signed data processing agreements with processors.
• Logging and monitoring that would catch an intruder, with alerts someone reads.

Will your architecture carry the plan in your deck?

Your deck says four times the customers in two years. Diligence asks whether the system and the cloud bill survive that. You won't fix most of it before closing, so bring an honest estimate of what it costs.

Self-check:

• Cost to serve per customer, by quarter. If it rises as you grow, explain why.
• The first component that breaks at four times today's load, and what replacing it costs.
• Legacy modules nobody wants to touch, listed with an owner and a plan.
• Code quality, especially AI-assisted code: the AI-code audit covers what to check.
• Deck metrics: ARR, churn and net revenue retention should reconcile with billing and the warehouse. If producing them takes three days, your numbers don't match yet.

What happens if two people leave?

People risk isn't in the code, so it's easy to skip, and it's the finding a buyer can't fix after closing.

Self-check:

• Who can deploy to production, and who holds the cloud root account, the domain registrar and the signing keys. One name per item is a finding.
• Signed IP assignment agreements from every employee and contractor who wrote code. Have counsel check them country by country.
• Runbooks for deploys, rollbacks and on-call that someone outside the founding team has used.

When should you run the review on yourself?

We'd start three to six months before the raise or the sale. The small fixes take weeks: swapping a conflicting library, patching criticals, writing the incident log, collecting IP assignments. The big ones, like a database at its ceiling, won't be fixed in time, but you can explain them with a plan and a cost, and an explained issue negotiates better than a discovered one. Black Duck, which sells those audits, gives sellers the same advice: get the code audited in advance.

Put it in a short disclosure memo for the data room: what you found, what you fixed, what's left and what it costs. The diligence call then starts with your answers, not their surprises.

Advisory runs the review and writes the data-room narrative. Build checks architecture, scale and code quality. Secure covers vulnerabilities, SOC 2 status and breach history. Data reconciles the deck with the warehouse, and AI covers model and data provenance. Five practices, one piece of work. The DGTL Readiness Index scores all eight in a paid Discovery engagement. See the framework.

Related: The bill for AI-written code → · SOC 2 without the pain → · Fractional CTO, CMO and CISO →