What's Actually in a Technical Due Diligence Report (Sample Structure)

A technical due diligence report is the written output of a technology assessment run before an acquisition or investment. A useful one opens with an executive summary and a verdict, scores each technology area on a simple red-amber-green scale, lists every finding with its severity, remediation effort and estimated cost, separates deal-breaking red flags from fixable issues, and closes with a sequenced remediation roadmap, usually a 100-day plan.

This article walks through a sample report structure section by section, shows what a strong finding looks like on the page, and explains how deal teams turn the report into price, deal terms and a post-close plan. If you are commissioning one, it also gives you a checklist for judging whether the report you receive is good enough to act on.

What Is a Technical Due Diligence Report?

Technical due diligence (TDD) is an independent review of a company's software, infrastructure, security, engineering team and product. The report is what the investment committee actually reads. Engineers on the assessment team may spend weeks inside the codebase, but the deal team usually gets a short read-out and a document. Whatever is not in that document effectively did not happen.

That is why the structure matters as much as the analysis. A report that lists 140 observations in the order they were found is technically complete and practically useless. A report that tells the deal team which five issues change the price, which ten need a line in the integration budget, and which can wait is a decision tool.

At Sphere, the technical due diligence assessment is built around that second kind of report: a written findings report, a dollar-denominated risk register with remediation cost estimates, a 100-day post-close plan and an executive read-out for the investment committee or board.

What Does a Technical Due Diligence Report Include?

Most software TDD reports follow the same backbone, whatever the provider calls the sections. The table below is a sample structure, with the question each section answers and the person who reads it most closely.

1. Executive summary and verdict

The executive summary fits on one or two pages and leads with a verdict. "The platform can support the growth plan with targeted investment" is a verdict. "The platform has strengths and weaknesses" is not.

A good summary then gives the three to five findings that matter most, the total estimated remediation cost as a range, and any condition the deal should be subject to. It also says plainly whether the technology matches what management presented. If the pitch described a multi-tenant platform and the code shows a separate deployment per customer, that gap belongs on page one.

2. Scope, access and limitations

This short section protects everyone. It lists which repositories, environments and documents were reviewed, which people were interviewed, and what the assessors could not see. Limited access is common on competitive processes, and a report that hides it overstates its own confidence.

Read this section before the findings. A clean security rating means little if the team never had access to production configuration.

3. Scorecard and RAG ratings

The scorecard is the page that gets screenshotted into the investment memo. Each assessment area, such as architecture, code quality, security, infrastructure, SDLC and DevOps, engineering organization, product management and, increasingly, AI systems, gets a red, amber or green rating and a one-line rationale.

• Green: fit for the deal thesis; normal maintenance only.
• Amber: material issues with a known fix; budget and plan for them.
• Red: a risk that could change the valuation, the deal structure or the timeline if left unaddressed.

The ratings should be defined in the report and applied consistently. If two providers would rate the same codebase differently, the definitions are doing too little work.

4. Findings register

The findings register is the core of the report. Each finding is a row, not a paragraph of commentary, and each row carries the same fields so the deal team can sort and total them:

• Area and title: for example, "Security: unpatched critical vulnerabilities in production dependencies."
• Evidence: the file, service, configuration or metric that proves it, so the target cannot simply dispute it.
• Severity: critical, high, medium or low, tied to business impact rather than engineering taste.
• Business impact: what breaks, for whom, and when, in plain language.
• Remediation: the specific fix, not "improve security posture."
• Effort and cost: engineer-weeks or a cost range, plus the skills required.
• Timing: before close, in the first 100 days, or within the first year.

Sphere's reports express each finding in dollar terms, with a remediation cost estimate and a timeline, so the deal committee can act on numbers rather than engineering opinions. Even when exact cost is uncertain, a range is far more useful than an adjective.

5. Red flags vs. fixable issues

Every codebase has debt. The report's job is to tell the deal team which issues are a cost of doing business and which are a problem with the deal itself. Our guide to technical debt for business leaders covers the general idea; in a TDD report the distinction gets sharper because it drives negotiation.

6. Remediation roadmap and 100-day plan

The roadmap turns the findings register into a sequence. Pre-close items go first, often as conditions or specific seller commitments. Then the first 100 days: security fixes, key-person retention, access and governance changes, and the architectural work the growth plan depends on. Longer-horizon items, such as a platform migration, get a phase, an owner and a cost envelope.

The plan is most useful when the people who found the issues also wrote the sequence. At Sphere, the same specialists who run the assessment deliver the 100-day plan, so there is no handoff between diagnosis and execution. That continuity is also why the remediation figures in the plan line up with the costs in the findings register.

7. Appendices

Appendices hold the evidence: architecture diagrams as found (not as presented), dependency and licence scans, security scan summaries, test coverage reports, infrastructure cost breakdowns, interview notes and a glossary for non-technical readers. Most deal partners never open them. The acquirer's CTO and the integration team will, and they need to be able to trace every finding back to something concrete.

How Do Deal Teams Use a TDD Report?

The report earns its fee when it changes something on the term sheet or in the plan. In practice deal teams use it in four ways.

1. Price. Red-flag remediation costs are often deducted from the offer or used to justify holding the price where the seller wanted more. A costed register makes that conversation factual instead of adversarial.
2. Deal terms. Findings that cannot be priced cleanly, such as IP provenance gaps or an open security incident, are handled through specific representations and warranties, indemnities, escrow or conditions to closing. Counsel needs findings written precisely enough to draft against.
3. Integration and value creation. The operating partner uses the roadmap and 100-day plan to set the first-year technology budget, hiring plan and board milestones.
4. Financing and governance. Lenders, co-investors and boards increasingly expect an independent technical view. A clear scorecard is often the page that travels.

Speed matters too. In Sphere's Betr scalability and data protection diligence, the report gave a binary verdict on whether the platform could handle five times its load without a rewrite, along with a prioritized technical debt register and a CI/CD maturity score, and moved from report delivery to buyer Q&A in three days.

How Do You Tell a Strong TDD Report From a Weak One?

You will usually see a sample report before you sign an engagement letter. Ask for one, and test it against these questions:

• Is there a verdict on page one? If the summary hedges, the rest of the report will too.
• Is every finding evidenced? "We observed" should point to a file, a configuration or a metric, not an interview impression.
• Are findings costed? Severity without effort or cost forces the deal team to guess.
• Were findings validated with the target? Sphere pressure-tests every issue with the target or internal team before the final read-out, so nothing in the report is a surprise and nothing is easily rebutted.
• Does it separate deal issues from housekeeping? A flat list of 100 items buries the five that matter.
• Does it cover how the code was built, not just what was built? With AI coding assistants writing a growing share of production code, review coverage and provenance now belong in the report. Our piece on diligence for AI-generated codebases explains what to look for.

If you want to know what assessors check before they write anything, our software due diligence checklist lists the areas and the evidence to request, and the technical due diligence checklist for startups covers the earlier-stage version.

Can You Use a Technical Due Diligence Report Template?

A template is a good way to agree on structure with a provider, and the seven sections above work as one. It cannot replace the assessment. The value of the report sits in the evidence and the costing, and both come from engineers who have spent time inside the code and infrastructure.

Templates are most useful in two situations. Buyers use them to make reports from different providers comparable across a portfolio. Sellers use them to see their company the way a buyer will, which is the logic behind sell-side technical due diligence: run the same review on yourself before going to market and fix what you can.

For the remediation estimates themselves, the cost drivers are the same ones that drive any engineering budget: team seniority, scope, integration complexity and how much of the work can run in parallel. Our breakdown of what drives software development cost is a useful reference when you sanity-check the numbers in a roadmap.

For the full picture of scope, process and how to choose a provider, see our complete guide to technical due diligence and code audits.