You’ve got a 40-page technical due diligence report sitting in your inbox. It’s full of terms like “cyclomatic complexity,” “microservices architecture,” and “CI/CD pipeline maturity.” You’re a PE partner, a deal lead, or an investment committee member. You need to understand what this report is telling you about the deal and you need to understand it well enough to ask informed questions. You don’t need to become an engineer. You need to know which findings change the deal and which don’t.
I write these reports. Here’s how to read them.
The structure most DD reports follow and why it matters
Most technical due diligence reports from credible assessors follow a consistent structure: executive summary, followed by detailed findings across technology categories, followed by risk assessment and remediation recommendations. The structure exists because each section serves a different reader.
The executive summary is written for the investment committee. It translates technical findings into business impact: deal risks, remediation costs and integration timeline implications. If you read nothing else, read this section thoroughly. It should tell you three things: what are the material findings that affect the deal, what’s the estimated cost to remediate them and how do they affect the integration timeline.
If the executive summary doesn’t clearly state these three things, the report has a communication problem that you should raise with the assessor. A technical due diligence report that doesn’t translate findings into deal impact isn’t serving its purpose.
The findings that change deals versus the findings that don’t
Here’s the categorisation framework I use when presenting findings to investment committees. It separates the material from the merely interesting.
Deal-critical findings are ones that could change the decision itself: IP ownership gaps where the target company doesn’t cleanly own the technology you’re acquiring, security vulnerabilities that create regulatory liability or breach risk and architectural limitations that make the growth thesis technically impossible without significant re-architecture. These findings belong in the investment memo.
Price-adjustment findings are issues that don’t kill the deal but change the economics: technical debt that requires remediation investment before growth capex can be effective, infrastructure work needed to support the scaling assumptions in the financial model and team retention costs for key engineers whose departure would create operational risk. These findings translate to specific line items in the integration budget.
Integration-planning findings are issues that affect how you execute post-close but don’t change the price: deployment process improvements, monitoring infrastructure gaps, documentation deficiencies and development workflow modernisation. These are execution items that go into the 100-day plan.
When you’re reading the detailed findings sections, mentally categorise each finding into one of these three buckets. That categorisation is what turns a technical document into a deal document.
Technical terms translated to business language
I’m going to walk through the most common technical findings and translate them into what they actually mean for the deal. Keep this section as a reference when you’re reviewing reports.
“High cyclomatic complexity” means the code is complicated in ways that make it expensive to modify and risky to change. Business implication: new feature development will be slower and more expensive than the sell-side’s engineering estimates suggest, because every change requires navigating a tangled codebase.
“Low test coverage on critical modules” means the most important code in the system has no safety net. Business implication: bug fixes and feature changes in critical areas carry a real risk of breaking something else and nobody will know until customers report it. Remediation cost should be in the integration budget.
“Single point of failure in deployment” means one person or one system can prevent the product from being updated. Business implication: key-person risk that directly affects operational continuity. If that person leaves, the company temporarily loses the ability to ship updates or fix bugs.
“No CI/CD pipeline” means code changes go from development to production through a manual process. Business implication: deployments are slow, risky and dependent on specific people. Building automated deployment infrastructure is a prerequisite for the engineering velocity the growth plan assumes.
“Monolithic database architecture” means everything runs on one database. Business implication: the system has a scaling ceiling that will be hit before the growth plan’s volume targets. Re-architecting the database layer is a significant engineering project, typically six to twelve months, that needs to be budgeted.
“Hardcoded credentials” means security keys are written directly into the code rather than stored securely. Business implication: anyone who has ever had access to the code can potentially access production systems. This is a security risk and a compliance risk that needs immediate remediation.
“Vendor lock-in” means the system is tightly dependent on a specific third-party service with no easy way to switch. Business implication: that vendor has pricing power over your operating costs. If they raise prices, the switching cost is months of engineering work.
How to assess severity levels?
Most reports use severity classifications, critical, high, medium, low. Here’s how to interpret them in deal context.
Critical findings are ones where the assessor believes the finding materially changes the risk profile of the deal. These require investment committee attention and potentially deal structure adjustments such as escrow, indemnity, or price reduction.
High findings are significant issues that require remediation investment but don’t change the fundamental deal thesis. These belong as line items in the integration budget with specific cost estimates.
Medium findings are issues that need attention but won’t derail the integration if addressed within the first year. These go into the integration plan.
Low findings are improvement opportunities that the acquiring team should be aware of but that don’t require immediate action.
The distribution of findings across severity levels tells you something about the overall technology health. A report with no critical findings and a handful of highs describes a technology that needs investment but is fundamentally sound. A report with multiple critical findings describes a technology that may change the deal thesis.
The questions to ask after reading
Once you’ve read the report, here are the questions that demonstrate you’ve understood the findings and that will get you the most useful additional context from the assessor.
For each critical and high finding: “What’s the remediation timeline and cost estimate and how does that affect our integration plan?” This is the question that turns a technical finding into a financial input.
For architecture findings: “At what growth level does the current architecture hit its ceiling and what does the re-architecture cost to get past that ceiling?” This directly tests the growth thesis against the technical reality.
For team findings: “If the three highest-risk individuals leave during the integration period, what’s the impact on operations and the cost of replacement?” This gives you the key-person risk in financial terms.
For security findings: “What’s the regulatory exposure if these vulnerabilities aren’t addressed within six months of close?” This frames security findings as liability rather than engineering tasks.
Read also: Brain–Computer Interface Technology
What good reports look like versus what bad reports look like
Good reports quantify. Instead of “the code quality is poor,” they say “the maintainability index is 42 against an industry benchmark of 65 and bringing it to an acceptable level will require approximately 800 engineering hours.” You can do math with good findings.
Good reports prioritise. They don’t present 47 findings with equal weight. They tell you which five findings matter most for the deal and why.
Good reports connect technical findings to business outcomes. Every finding should answer the implicit question: “So what does this mean for the investment?”
Bad reports are comprehensive without being useful. They document everything without prioritising anything. They use technical language without translation. They present findings without remediation estimates. And they don’t connect the technology assessment to the deal thesis, leaving you to figure out what the findings mean for the investment on your own.
If you receive a report that’s technically thorough but business-disconnected, ask the assessor for a supplementary brief that maps each critical and high finding to a specific deal impact. That brief is often more valuable than the report itself.
