Cabo Advisory

← Insights··Updated

Technology due diligence: what the data room won't tell you

A data room is a curated narrative. The evidence is the exhaust — commit history, deployment logs, cloud invoices, dependency manifests. Three things changed at once in 2025–26: AI-assisted coding started inflating output while degrading stability; "AI-powered" became a representation a buyer may have to defend; and EU law began treating software as a product with reporting clocks. Technology diligence is now a legal, financial and commercial exercise, not a code review.

Every data room tells the same story. There is an architecture diagram, a SOC 2 report, a roadmap, an IP assignment schedule, a table of open-source licences and a slide that says "AI-native". All of it was assembled by the seller, for the buyer, in the weeks before the process opened. None of it is false, necessarily. But none of it is evidence in the sense that a court, an auditor or an engineer would recognise: it is a description of the system, written by the party being paid for it.

The data room is a story, not a system

Three recent cases show what a curated narrative can survive. In 2021 JPMorgan Chase paid $175 million for Frank, a student-finance start-up whose founder claimed 4.25 million users when the real number was roughly 300,000; she "approached an outside data scientist and hired him to create the synthetic data set" that passed the buyer's checks. She was convicted in March 2025 and sentenced in September 2025 to 85 months, with restitution of more than $287 million.1 In January 2025 the SEC charged Presto Automation, which had marketed a voice-ordering product as eliminating human order-taking, over its failure to disclose that its pilot "required a human agent to enter the orders approximately 70% of the time".2 And in May 2025 Builder.ai, which had raised more than $450 million from investors including Microsoft and Qatar's sovereign fund, entered insolvency proceedings — six years after the Wall Street Journal had reported that it "used human engineers rather than AI for most of its coding work".3

What the three have in common is not fraud; it is that in each case the checks relied on material the target had prepared. The alternative is to ask for the exhaust: the artefacts a company generates by operating, which it does not curate and would find expensive to fake.

Read the exhaust, not the deck

Five artefacts do most of the work, and all five can be requested before the letter of intent.

Twenty-four months of version-control history. Commit history shows who actually builds the product. One practitioner's rule of thumb is that "one person authoring more than half the commits to revenue-critical services" is a key-person finding, whatever the org chart says.4 It also shows whether the roadmap in the information memorandum matches what engineering has been doing; sprint history against the deck is the cheapest fiction detector in the process.

Deployment and incident logs from the target's own tooling. The DORA research programme's four key metrics — deployment frequency, lead time for changes, change failure rate and failed-deployment recovery time — are the closest thing engineering has to audited accounts, provided they are pulled from the CI/CD and incident systems rather than reported on a slide.5

Eight to twelve quarters of cloud invoices, against revenue. Cloud cost is a gross-margin line, and gross margin is what a revenue multiple prices (see below).

Dependency manifests and a file-level scan of the code. Black Duck's 2026 Open Source Security and Risk Analysis, covering 947 commercial codebases, found that 87% contained at least one open-source vulnerability, 78% contained high-risk vulnerabilities, 68% had licence conflicts (up from 56% a year earlier) and 92% contained components four or more years out of date. Seventeen percent of components entered codebases outside standard package managers, which is why a manifest alone misses copyleft exposure.6 The baseline matters: findings are near-universal, so the diligence question is never "are there findings" but "which are material, and what does remediation cost".

The customer-facing contracts, read against the product. Service levels, data-use terms and AI feature descriptions promised to customers are the representations the target has already made to the market. Part 6 of this series deals with what those terms should say; here the point is that a target that has over-promised to its customers has already created the liability the buyer will inherit.

The AI-coding paradox: faster and more fragile

The most important change in the underlying evidence base is that AI-assisted development has decoupled output from quality, and the research on it has matured quickly.

DORA's 2024 report — the programme has surveyed more than 39,000 professionals over a decade — found that 75.9% of respondents relied on AI in some part of their daily work — and that a 25% increase in AI adoption was associated with an estimated 1.5% reduction in delivery throughput and a 7.2% reduction in delivery stability.5 Its 2025 report finds that 90% of respondents now use AI at work, that the relationship with throughput has turned positive, but that "AI adoption does continue to have a negative relationship with software delivery stability", with 30% of respondents reporting little or no trust in AI-generated code.7 Veracode tested more than 100 large language models and found that "45% of code samples failed security tests and introduced OWASP Top 10 security vulnerabilities into the code", with Java the worst at 72%.8 GitClear's analysis of 211 million changed lines between 2020 and 2024 found copy-pasted code rising from 8.3% to 12.3% of changed lines while refactoring-associated changes fell from 25% in 2021 to under 10% in 2024.9 Stack Overflow's 2025 survey of developers found 84% using or planning to use AI tools, 46% actively distrusting their accuracy, and 45.2% reporting that debugging AI-generated code is more time-consuming.10

For a buyer, the practical consequence is a change in which metric to believe. Rising deployment frequency is no longer evidence of engineering health on its own; it can be evidence of AI-assisted volume with the bill deferred. The only AI-productivity claim worth pricing is a rising deployment frequency with a flat or falling change-failure rate and stable rework — which is exactly why the logs, not the slide, are the artefact to request.

Certificates are scope statements

A SOC 2 report in the data room answers a narrower question than most deal teams assume. A Type I report describes the design of controls at a point in time; a Type II report tests operating effectiveness over a period. The report covers a defined system, for a defined period, with sub-service organisations either included or — more commonly — carved out, and with an opinion that may be qualified, adverse or disclaimed. The questions to ask are whether the period ends recently enough to matter (and whether a bridge letter covers the gap), which sub-processors are carved out, what the exceptions and complementary user-entity controls say, and whether the opinion is clean.11 An ISO/IEC 27001 certificate is similarly a statement about a scope and a Statement of Applicability, not about the whole company. Neither document tells you whether the controls it describes have ever stopped an attack.

The cautionary case is Change Healthcare. Acquired by UnitedHealth for about $13 billion in October 2022, it was breached in February 2024 through a remote-access portal that "did not have multifactor authentication", with ransomware deployed nine days later;12 by January 2025 UnitedHealth put the cost for 2024 at about $3.1 billion.13 Verizon's 2025 Data Breach Investigations Report records that third-party involvement in breaches doubled to 30% and that exploitation of vulnerabilities was the initial vector in 20% of breaches.14 A buyer that relied on the assurance report in the data room owns the control gap the report did not cover. Part 3 of this series sets out the questions a board should be asking about that inheritance once the deal has closed.

"AI-powered" is now a representation you may have to defend

Almost every technology deal now carries an AI claim. Bain reports that "almost half of tech deals had some AI component" in 2025, up from about one in four in 2024.15 Regulators have started treating the claim as a statement of fact. The SEC's March 2024 settlements with Delphia ($225,000) and Global Predictions ($175,000) were for advertising AI-driven investing that did not exist; the Presto action in January 2025 was brought under provisions that included the securities-law disclosure-controls rule, which means that after closing the buyer's controls are the ones on the line.216 The FTC's "Operation AI Comply", launched in September 2024, added five consumer-protection actions, including a $193,000 settlement with DoNotPay over its "robot lawyer".17

Two disciplines follow. The first is to test the product against its own marketing copy and its customer contracts — not against the demo — and to write the AI representations to the gap that emerges. Practitioners now recommend AI-specific warranties (rights to the training data, originality of the models, absence of known bias or misuse), interim covenants restricting changes to data and model practices between signing and closing, and special indemnities for known AI risks.18 The second is to ask the question Bain's diligence practice asks first: does AI revolutionise, transform or merely augment the target's business model? Across more than 300 companies Bain analysed, fewer than 10% faced the first.19 A buyer paying an "AI-native" multiple for an "augmentation" business has mispriced the asset before any warranty is drafted.

Software is a product now: the regulatory clock the seller isn't modelling

The third change is legal, and its dates fall inside any hold period that starts in 2026.

The Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024. Its reporting obligations for manufacturers of products with digital elements apply from 11 September 2026 — an early warning within 24 hours of becoming aware of an actively exploited vulnerability or severe incident, a full notification within 72 hours, and a final report within 14 days or one month depending on the case — and its main obligations apply from 11 December 2027.20 The Act expects manufacturers to be able to produce a software bill of materials; ENISA's 2026 survey of 334 organisations found that 43% said the CRA had "significantly accelerated" their SBOM investment, but also that 39% never and a further 39% rarely receive SBOMs from suppliers, and only 29% use them for vulnerability identification and patching.21 A target that cannot generate and act on an SBOM has a compliance programme to fund before its next product release.

The Product Liability Directive (Directive (EU) 2024/2853) must be transposed by 9 December 2026 and applies to products placed on the market after that date. Stand-alone software is a product; cybersecurity vulnerabilities and the failure to supply security updates can constitute a defect; and the directive introduces disclosure-of-evidence rules and presumptions of defectiveness that shift the burden towards the manufacturer.22 "We stopped patching that version" becomes a product-liability fact pattern, not an engineering choice.

The AI Act, as amended by the Digital Omnibus on AI (Regulation (EU) 2026/1744, in force from 27 July 2026), now applies its high-risk obligations to Annex III stand-alone systems from 2 December 2027 and to Annex I product-embedded systems from 2 August 2028, while most of the Article 50 transparency obligations kept their 2 August 2026 date.23 The delay is a cash-flow deferral, not a risk removal: it lands in the middle of a five-year hold.

The diligence consequence is that technical debt has become legal debt with a due date. The remediation programme — SBOM tooling, vulnerability-handling processes, update commitments, AI documentation — belongs in the model as capital expenditure, dated.

Follow the money: two accounting tells

Two lines in the financials say more about the technology than the technology section of the report.

The first is capitalised development cost. Under IAS 38 an entity may capitalise development spend only when six criteria are met, including technical feasibility and the probability of future economic benefit; under US GAAP most research and development is expensed, with separate regimes for internal-use software and software to be sold.24 Ask for the capitalisation rate over eight quarters and a sample of what was capitalised. A rising rate with a flat feature count usually means maintenance and bug-fixing are being carried as an asset. McKinsey's survey of CIOs found that 10 to 20 percent of new-product technology budgets are diverted to resolving tech-debt issues, and that tech debt "amounts to 20 to 40 percent of the value of their entire technology estate before depreciation";25 Stripe's survey of developers and executives put the average developer's time on technical debt at 17.3 hours a week.26 The capitalisation line is where that time is hidden.

The second is cloud cost of revenue. Andreessen Horowitz's analysis of public software companies found contractually committed cloud spend averaging 50% of cost of revenue, with repatriation running at "one-third to one-half the cost of running equivalent workloads in the cloud".27 The point for a buyer is not that repatriation is always right — it consumes engineering capacity that competes with the roadmap — but that cloud cost growth "moves the multiple rather than the price, because it corrects gross margin" — as the same advisor puts it, a five-to-ten-point margin correction on a business valued on revenue changes value more than any one-off remediation the technical report will find.4

Turning findings into terms

The multidisciplinary point is that a single diligence finding is simultaneously a code fact, a contract clause, a P&L line and a customer-retention risk, and the deal needs a channel for each. Four channels exist. One-off remediation — a security programme, a licence clean-up — goes to price. Recurring economics — cloud cost, sustained tech-debt spend — go to the multiple, through margin. Contingent exposures — copyleft contamination, inherited security debt, the AI representations — go to escrow, specific indemnities or warranty-and-indemnity insurance. Delivery risk — the roadmap, the integration, the key engineer — goes to earn-outs and holdbacks, and Part 4 of this series explains why most engineering metrics make poor earn-out triggers.

Before the letter of intent, ask for five things: read access to version control for the last two years; exports from the deployment and incident tooling; the cloud invoices; a file-level software composition scan run against the repositories rather than a questionnaire; and the customer contracts with the AI and service-level clauses marked. A seller who cannot provide them is telling you something. A seller who can has given you the only diligence material in the process that was not written for you.

Related reading in this series

Disclaimer

This article is general commentary for professional readers. It is not legal, tax, financial, accounting or technical advice, does not address the circumstances of any particular transaction, and does not create an advisor–client relationship with Cabo Advisory SL. Regulatory application dates, market data and enforcement positions are stated as at the date of writing and change; verify the current position in the relevant jurisdiction and take advice before acting.

Notes and sources

Footnotes

  1. U.S. Attorney's Office, Southern District of New York, "Startup CEO Charlie Javice Sentenced To 85 Months In Prison For $175 Million Fraud", U.S. Department of Justice, 29 September 2025. https://www.justice.gov/usao-sdny/pr/startup-ceo-charlie-javice-sentenced-85-months-prison-175-million-fraud ↩

  2. Cooley PubCo, "SEC charges 'AI-washing' at Presto Automation", 30 January 2025. https://cooleypubco.com/2025/01/30/sec-charges-ai-washing/ ↩ ↩2

  3. The Register, "Builder.ai coded itself into a corner – now it's bankrupt", 21 May 2025. https://www.theregister.com/2025/05/21/builderai_insolvency/ ↩

  4. Leslie Sakal, "The Technology Due Diligence Red Flags That Kill Deals", BD Emerson, 26 July 2026. https://www.bdemerson.com/article/technology-due-diligence-red-flags ↩ ↩2

  5. Google Cloud / DORA, Accelerate State of DevOps Report 2024. https://dora.dev/research/2024/dora-report/2024-dora-accelerate-state-of-devops-report.pdf ↩ ↩2

  6. Black Duck, "2026 OSSRA Report: Open Source Vulnerabilities Double as AI Soars" (summary of the 2026 Open Source Security and Risk Analysis report, 947 codebases across 17 industries), 25 February 2026. https://www.blackduck.com/blog/open-source-trends-ossra-report.html ↩

  7. Google Cloud, "Announcing the 2025 DORA Report" (State of AI-assisted Software Development), 23 September 2025. https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report ↩

  8. Veracode, "Insights from 2025 GenAI Code Security Report", 30 July 2025. https://www.veracode.com/blog/genai-code-security-report/ ↩

  9. GitClear, "AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones", 2025. https://www.gitclear.com/ai_assistant_code_quality_2025_research ↩

  10. Stack Overflow, "AI — 2025 Stack Overflow Developer Survey", 2025. https://survey.stackoverflow.co/2025/ai ↩

  11. Linford & Company, "SOC Review Guidance: How to Read SOC 1 & SOC 2 Reports". https://linfordco.com/blog/soc-review-guidance-soc-1-soc-2-reports/ ↩

  12. Matt Kapko, "Change Healthcare, compromised by stolen credentials, did not have MFA turned on", Cybersecurity Dive, 30 April 2024. https://www.cybersecuritydive.com/news/change-healthcare-compromised-credentials-no-mfa/714792/ ↩

  13. Healthcare Dive, "Change Healthcare cyberattack affects 190 million, UnitedHealth says" (reporting UnitedHealth's 2024 cost of about $3.1 billion), January 2025. https://www.healthcaredive.com/news/change-healthcare-cyberattack-affects-190-million-unitedhealth/738351/ ↩

  14. Verizon, "Verizon's 2025 Data Breach Investigations Report: Alarming surge in cyberattacks through third-parties" (news release), 23 April 2025. https://www.verizon.com/about/news/2025-data-breach-investigations-report ↩

  15. Bain & Company, "M&A in Software: Five Secrets to Creating Real Value When Acquiring AI Assets", 27 January 2026. https://www.bain.com/insights/software-m-and-a-report-2026/ ↩

  16. White & Case, "New Settlements Demonstrate the SEC's Ongoing Efforts to Hold Companies Accountable for AI-Washing", 22 March 2024. https://www.whitecase.com/insight-alert/new-settlements-demonstrate-secs-ongoing-efforts-hold-companies-accountable-ai ↩

  17. Federal Trade Commission, "FTC Announces Crackdown on Deceptive AI Claims and Schemes" (press release), 25 September 2024, https://www.ftc.gov/news-events/news/press-releases/2024/09/ftc-announces-crackdown-deceptive-ai-claims-schemes ; Mintz, "FTC Launches Operation AI Comply with Five Enforcement Actions Involving AI Misuse", 3 October 2024, https://www.mintz.com/insights-center/viewpoints/54731/2024-10-03-ftc-launches-operation-ai-comply-five-enforcement ↩

  18. Marc Kenny, "Managing Legal Risks in M&A Transactions with Targets Using Artificial Intelligence (AI)", Squire Patton Boggs, September 2025. https://www.squirepattonboggs.com/en/insights/publications/2025/09/managing-legal-risks-in-ma-transactions-with-targets-using-artificial-intelligence ↩

  19. Bain & Company, "New Diligence Challenge: Uncovering AI Risks and Opportunities", 27 October 2025. https://www.bain.com/insights/new-diligence-challenge-uncovering-ai-risks-and-opportunities/ ↩

  20. European Commission, "Cyber Resilience Act", https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act ; European Commission, "Cyber Resilience Act – Reporting obligations", https://digital-strategy.ec.europa.eu/en/policies/cra-reporting (Regulation (EU) 2024/2847, arts. 14, 24(3) and 71(2)). ↩

  21. ENISA, SBOM Adoption State of Play – 2026 Survey Results and Analysis, June 2026. https://www.enisa.europa.eu/publications/sbom-adoption-state-of-play-2026 ↩

  22. Directive (EU) 2024/2853 on liability for defective products, arts. 2, 4, 7, 9, 10, 11(2)(c) and 22, https://eur-lex.europa.eu/eli/dir/2024/2853/oj/eng ; Gibson Dunn, "EU Product Liability Directive: Responding to Software, AI and Complex Supply Chains", 23 March 2026, https://www.gibsondunn.com/eu-product-liability-directive-responding-to-software-ai-and-complex-supply-chains/ ↩

  23. White & Case, "EU AI Omnibus enters into force, amending the AI Act", 4 August 2026 (Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force from 27 July 2026). https://www.whitecase.com/insight-alert/eu-ai-omnibus-enters-force-amending-ai-act ↩

  24. KPMG US, "R&D costs: IFRS Accounting Standards vs. US GAAP", 13 March 2025. https://kpmg.com/us/en/articles/2025/rd-costs-ifrs-accounting-standards-us-gaap.html ↩

  25. McKinsey & Company, "Tech debt: Reclaiming tech equity", 6 October 2020 (survey of 50 CIOs of financial-services and technology companies with revenue above $1 billion). https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-debt-reclaiming-tech-equity ↩

  26. Stripe and Harris Poll, The Developer Coefficient, September 2018. https://stripe.com/files/reports/the-developer-coefficient.pdf ↩

  27. Sarah Wang and Martin Casado, "The Cost of Cloud, a Trillion Dollar Paradox", Andreessen Horowitz, 27 May 2021. https://a16z.com/the-cost-of-cloud-a-trillion-dollar-paradox/ ↩