A technical due diligence report is a list of findings, and findings tend to end in one of three outcomes: you fix it before close, you disclose it and schedule the fix, or you accept it. You pick the outcome with deal-side facts (what you'd have to represent, what the other side can walk away over), not with how much the code embarrasses you. This guide starts the day the report lands. It's written for founders and CTOs, and it's practitioner judgment, not legal advice. Your counsel confirms the drafting.
What a technical due diligence report contains
There's no standard format. TechCXO describes an investor dashboard, key findings and granular recommendations, and says a good provider should deliver within two to three weeks for most situations. Sphere's technical due diligence page says it ranks findings by severity, business impact, remediation effort and cost, adds a dollar-based remediation estimate and a 100-day post-close plan, and says most full-stack assessments are delivered within four weeks.
Expect some mix of these sections:
| Section | What it tells you |
|---|---|
| Executive summary | The reviewer's overall read, usually what the investor reads first |
| Findings | Each issue, with evidence from the code, contracts or interviews |
| Severity and business impact | How badly each issue could hurt the deal or the product |
| Remediation effort | What fixing it takes, in time or cost |
| Recommendations or plan | Suggested order of work, sometimes a post-close plan |
Check which of those your report has. If severity is missing, you'll add it yourself in step 3 below. For what reviewers look at before they write any of this, see what a review checks before it starts.
How to triage the findings in your report
1. Turn the report into a finding list
Copy every finding into one sheet, one row each, in your own words. In our experience, reports can bury small findings inside one paragraph and repeat a big one in several sections. One row per underlying problem keeps you from fixing the same thing twice or missing one.
2. Sort each finding into fix, disclose or accept
Papermark, a practitioner blog, says findings usually end up as a price adjustment, a post-close budget or a closing condition. DFIN adds that significant issues may justify renegotiating valuation or indemnities. Use that to sort, with this rule of thumb (judgment, not law):
- Fix before close when the defect blocks a clean representation, such as a missing assignment of contractor code or copyleft code in the shipped product.
- Disclose, with a scheduled fix, when the cost is bounded and you can put an owner and a date on it, such as dependency upgrades, missing tests on a payments flow or undocumented systems.
- Accept when it's untidy code and nothing else. Papermark's view is that messy code alone rarely moves price.
Our rule of thumb, not law: if you can't tell which bucket a finding belongs in, treat it as fix-before-close until counsel says otherwise.
3. Give each finding a severity, an owner and a date
Add four columns: severity (high, medium, low, on a scale you define in one sentence), a named owner, a due date, and an engineer-weeks estimate. The estimate is yours. Nobody outside your team knows how long your codebase takes to change, and an invented number gets caught in the follow-up call. Add a fifth column for how you'll prove it's fixed, such as a signed document, a scan result or a merged pull request.
4. Decide who does the work
Match each owner to the finding. Your internal team knows the code but is also shipping product. The original contractor knows the code best and may be the only one who can sign the assignment. An outside senior engineer or fractional CTO is the option when nobody internal has the time or the seniority. In our experience, most remediation needs a mix. The legal items go to counsel, and the code items go to whoever can finish before the deal's clock runs out.
5. Send the plan back, then verify
The other side wants to see that you've read the report and have a path. Group your rows the way Papermark does: fixed before or immediately after close, fixed within the first year, and acceptable as they are. Then ask for a re-check. DFIN says diligence should include follow-up assessments that confirm the fixes, so offer evidence for each closed item before they ask.
Remedies by finding type
Five finding types come up most often in the sources we read on code built by agencies, contractors or AI tools.
| Finding | Remedy | Who does it |
|---|---|---|
| Contractor code, no signed assignment | Signed confirmatory assignment covering past work | Founder with counsel, and the contractor |
| Copyleft or licence issue | Remove, replace or isolate the component, or relicense | Engineering, with counsel |
| Security gap | Fix auth, payments and customer data first; patch; rotate secrets | Engineering |
| AI-generated code provenance | Record tools and terms, document human review, disclose | CTO with counsel |
| Bus factor, undocumented systems | Named owners, runbooks, retention agreement | CTO and the contractor |
Contractor code with no signed assignment
Under US law, 17 U.S.C. 204(a) says a transfer of copyright ownership isn't valid without a signed writing. Paying an invoice isn't, on its own, that writing. The fix is a confirmatory assignment from each contractor or agency that covers work already delivered, signed before close. Papermark describes the usual outcomes as the seller obtaining the assignments or an escrow. For the clause wording and the position under European rules, see the clause that assigns contractor code.
If a contractor can't be found or refuses to sign, treat it as a disclose item and ask counsel how to word it. That's judgment, not a rule.
Copyleft and licence findings
Take AGPL-3.0. Section 13 of the GNU licence says that if you modify the program and let users interact with it remotely over a network, you must offer those users the source of your modified version. A SaaS product built on a modified AGPL component can fall under that; counsel confirms. Section 8 covers reinstatement after you stop violating. The licence comes back provisionally, and permanently if the copyright holder doesn't notify you within 60 days of the violation ending. It also comes back permanently if the holder's notice is the first you've had from them and you cure within 30 days of receiving it.
The practical remedies are to remove the component, replace it, isolate it (for example as an unmodified, separate service), where counsel confirms the isolation holds, or ask the owner for a different licence. Counsel confirms which one holds up. Papermark treats copyleft as the finding most likely to need legal remediation, and a closing condition to replace it is a typical outcome.
Security findings
Fix in this order: anything touching authentication, payments or customer data, then dependency patches, then secret rotation. If the product was built fast with AI tools, in our judgment the usual suspects are missing access rules and keys in the repo, and the row-level security and secrets audit walks through both.
AI-generated code provenance
A reviewer can ask which parts of the codebase an AI tool generated, with which tool, under which terms, and whether a human edited the result. Have counsel tell you how copyright applies to your situation. How copyright applies to AI-generated code is an open question to manage with counsel, so treat it as a risk.
What you can do now: keep a record of the tools and their terms, document where engineers reviewed and changed generated code, and scan for licence matches using whatever your tooling supports. When the report asks, disclose what you know rather than asserting something you can't back up.
Bus factor and undocumented systems
Name one owner per system. Write runbooks and architecture decision records for the top few, starting with whatever only one person understands. If that person is a contractor, put a retention or retainer agreement in place. Papermark says key-person dependence is usually answered by a retention agreement and rarely by a price cut.
What this means for your close
You have three decisions and a deadline set by the deal, not by your roadmap. First, which findings are title defects (assignments, licences) that you fix before close, because those change what you can truthfully represent. Second, which go into a costed plan with owners and dates that you hand over with your response. Third, who does the work in the weeks before close.
In our experience, that third decision is where teams stall. Your engineers are already carrying the roadmap, and the original contractor may have moved on. If nobody on your team can own remediation at the pace the deal needs, bring in a senior engineer or a fractional CTO for the length of the process. That's judgment, but a closing condition you could have met is a poor reason to lose time.
If your report flagged a single point of failure, start with this knowledge-transfer plan for a single point of failure. For more on this stage, see our Startup CTO guides.
Hiring help for remediation through HighCircl
Remediation is senior work with a deadline. HighCircl matches senior engineers in 72 hours, from seven European countries (Poland, Hungary, Slovakia, Serbia, Slovenia, Romania and Spain). Engineers pass four vetting stages run by senior engineers, and about 1 in 10 applicants make it through. There's no recruitment fee, and the 20% margin on top of what the engineer earns is capped and shown upfront. For someone to own the plan, HighCircl also places fractional CTOs, part-time senior technical leaders from across Europe.
FAQ
What is a technical due diligence report?
It's the reviewer's written output after examining your code, architecture, security, licences and team. It lists findings, usually with severity or business impact, and recommendations or a remediation plan. Formats vary by reviewer, which is why you should build your own finding list before you respond.
Can I fix findings after the deal closes?
Sometimes. Papermark describes a post-close budget as one of the three usual outcomes, with a first-year bucket in its remediation plan. Which findings qualify is a negotiation, and judgment says title defects like a missing assignment are the ones the other side will want fixed first. Ask counsel what your documents allow.
Should I tell the investor about problems the report didn't find?
Judgment, not law: yes, before you sign any representation that the problem would make untrue. A known issue disclosed with a plan is a line item. A known issue found later is a trust problem and possibly a breach of a warranty. Ask counsel how to word it.
How long do I have to respond?
The deal sets the clock, not a source. For scale, DFIN says a review may last several weeks inside a longer M&A timeline, TechCXO says a good provider should deliver within two to three weeks for most situations, and Sphere says most full-stack assessments are delivered within four weeks. Ask the other side for their closing date on day one and work back from it.