Is Your Engineering Ready for Technical Due Diligence?
What investors and acquirers actually ask about delivery, security, key systems and documentation, and a 90-day plan to be ready before the questionnaire lands.
Executive brief
- Technical due diligence is a test of evidence, not of confidence. Investors and acquirers want proof that your team can ship the roadmap behind the valuation, that customer data and IP are protected, and that nothing critical lives in one person's head.
- Reviewers cluster their questions into four areas: how you deliver software, how you handle security, which systems the business can't run without, and whether any of it is written down.
- How fast you answer is itself a signal. A team that produces deploy history, an access list and a restore-test record in an afternoon looks very different from one that needs three weeks.
- The surprises that hurt deals are usually about ownership and single points of failure: cloud accounts in a contractor's name, one engineer who does every release, copyleft code in the core product.
- Ninety days is enough to close the cheap, high-signal gaps, build a small evidence pack, and rehearse the hard questions. It is not enough to rebuild an architecture, so be honest about what you can't fix and write it down.
What technical due diligence actually tests
When an investor or acquirer commits real money, someone has to answer a simple question: will this engineering organisation deliver what the business plan assumes, and is anything lurking that changes the price? That someone is usually a third-party firm or a fractional CTO working from a questionnaire, a handful of interviews, access to a few systems and a set of automated scans.
They don't expect perfection. Most of them have seen hundreds of companies and know what a normal one looks like. What they're listening for is the gap between what you claim and what you can show.
Speed matters more than founders expect. If the request for deploy history or a production access list takes a week to fulfil, the reviewer concludes you don't have the data, or that you do and it's embarrassing. Either way the questions get sharper.
| Area | What they ask | Evidence that works | What shakes confidence |
|---|---|---|---|
| Delivery | How often do you ship, how long does a change take, what happens when a release fails? | CI/CD history, DORA-style metrics, a recent rollback | Manual deploys by one person, no rollback story |
| Security | Who has production access, where do secrets live, what do you know about your dependencies? | Access review, scan reports, pen test summary, SBOM | Shared credentials, secrets in repos, unknown licences |
| Key systems | What can't the business run without, and who can fix it? | Architecture diagram, backup restore log, on-call history | Single points of failure, one indispensable engineer |
| Documentation | Could a new team operate this? | Runbooks, onboarding doc, decision records | "It's all in our heads" |
Delivery: can you ship, and can you prove it?
Reviewers translate delivery into risk. A team that ships small changes often, recovers quickly and rarely breaks things can plausibly hit a roadmap. A team that does a nerve-wracking release every six weeks probably can't, whatever the slide deck says.
The four measures from the DORA research programme (deployment frequency, lead time for changes, change failure rate and time to restore service) have become the common vocabulary here. You don't need to be an elite performer. You need to know your numbers, and the trend should point the right way.
They'll also ask the unglamorous questions. How many people can deploy to production? Is there a staging environment that resembles production? What happened in your last bad release, and what changed afterwards? That last one is a favourite, because a specific, honest story about a failure tells a reviewer more than a clean dashboard.
- Deploy history for the last 6 to 12 months, exported from the pipeline, not reconstructed from memory
- A written description of the release process, including rollback
- Branch protection and review rules, with evidence they're actually enforced
- The last two or three incidents, with what you changed because of them
- Test coverage where it matters, and an honest note on where it doesn't exist
Can you tell an outsider, within one working day and using only exports from your own tooling, how many production deployments you made last quarter and how many of them needed a hotfix or rollback?
Security: access, secrets, dependencies and licences
Security questions in diligence are rarely exotic. Nobody expects you to have a threat model for nation-state attackers. They want to know whether the basics are in place and whether anyone checks.
Access control comes first. Who can touch production, who can read customer data, how quickly is access removed when someone leaves, and is MFA enforced or merely encouraged? A team that can produce a quarterly access review looks mature. A team that discovers a departed contractor still has an admin token during the interview does not.
Secrets come next, and reviewers will often scan for them before they ask. A key that was committed once and later deleted is still in the git history. Rotate it.
Then there's the supply chain. Reviewers want to know what open source your product contains, under which licences, and whether any of it is end-of-life or carries known vulnerabilities. The licence question is the one that changes deals. Strongly copyleft code (GPL or AGPL) compiled into a proprietary product, or a dependency with no licence at all, can turn into a remediation project or a price adjustment. An SBOM in SPDX or CycloneDX format, generated from your build, answers most of this in one document.
Finally, expect a request for your latest penetration test, plus a candid account of past security incidents. Having had an incident is normal. Having handled one with no record is not.
If a critical vulnerability is announced in a popular library tonight, can you say by tomorrow morning which of your shipped products contain it, and which version?
Key systems and key people
This is where reviewers look for fragility. They'll ask for an architecture diagram and then pick at it. Which component, if it failed at 3 a.m., would stop revenue? Who's on call for it? When was it last restored from backup, for real, not in theory?
Backups deserve their own mention. Plenty of companies have them and almost none have tested them. A restore test with a date and a log attached is one of the cheapest and most persuasive pieces of evidence you can produce.
People risk gets assessed the same way as system risk. If one engineer holds the only knowledge of the billing integration, or is the only person with the credentials to the build server, that's a single point of failure with a salary. Reviewers will ask directly. Answer directly, and if the answer is uncomfortable, show the plan to spread the knowledge.
Cost structure also surfaces here. Cloud spend per customer, how it scales, and whether you're locked into a vendor on terms that will bite after an acquisition. Nobody wants to discover in month three that the target's infrastructure bill grows faster than its revenue.
If your most senior engineer were unreachable for two weeks starting Friday, which systems could nobody else deploy, debug or restore?
Documentation: the part everyone postpones
Documentation is the area where small teams feel the most embarrassed and where a modest effort pays back most. Reviewers aren't grading prose. They want to confirm that the company, not a few individuals, owns the knowledge.
The minimum useful set is short: a current architecture diagram, a data flow diagram showing where customer data lives and moves, runbooks for your most common failures, an onboarding guide that a new hire could actually follow, and a record of the major technical decisions and why they were made. Add a disaster recovery summary and a one-page technical debt register, and you're ahead of most companies at your stage.
Stale documentation is worse than none, because it signals that nobody maintains it. Date everything. If a diagram is six months old, say so.
Pick a runbook at random and give it to an engineer who didn't write it. Can they resolve that incident without calling the author?
Red flags that quietly cost valuation
None of these are fatal on their own. They do get written into a report, and reports get read by people who control price and terms.
| Red flag | Why reviewers care | Typical fix |
|---|---|---|
| Cloud, repo or domain owned by a founder or contractor | The company may not control its own assets or IP | Transfer to company accounts, document the chain of title |
| One person performs every release | Delivery stops if they leave or fall ill | Automate the pipeline, train a second and third deployer |
| No tested restore from backup | Recovery is an assumption, not a capability | Run a restore, record it, schedule it quarterly |
| Copyleft or unlicensed code in the shipped product | Possible obligation to disclose source or rewrite | Licence scan, replace or isolate, get legal review |
| Secrets in repository history | Credentials may already be exposed | Rotate, then add secret scanning to the pipeline |
| End-of-life runtime or database | No security patches, upgrade cost hidden | Budget and schedule the upgrade, show the plan |
| CI is red and everybody ignores it | Tests don't protect anything | Fix or delete flaky tests, make the pipeline gate real |
The 90-day preparation plan
Ninety days is a realistic window if you start before the process does. It won't rebuild your architecture. It will let you close the cheap gaps, assemble evidence, and walk into the first reviewer call knowing the answers.
- 1
Days 1 to 14: Inventory what you own and who holds it
List every code repository, cloud account, domain, SaaS tool, app store account, certificate and third-party licence the product depends on. Next to each, write the legal owner and the people with admin rights. Anything registered to a founder's personal email, a former contractor or a corporate card nobody monitors gets moved into the company's name this month. It's dull work and it's where the ugliest surprises hide.
- 2
Days 15 to 30: Collect baseline evidence
Pull deploy frequency, lead time from merge to production, change failure rate and time to restore from your CI/CD and incident history. Export the production access list. Run a real restore from backup into a scratch environment and keep the log. You aren't trying to look good yet, only to find out what a reviewer would find.
- 3
Days 31 to 60: Close the cheap, high-signal gaps
Turn on MFA everywhere it's missing, rotate any secret that has ever touched a repo, enforce branch protection and required reviews, and add dependency and secret scanning to the pipeline. Generate an SBOM and a licence report for the shipped product. Fix or consciously accept anything flagged as copyleft, end-of-life or unmaintained.
- 4
Days 61 to 80: Write the minimum documentation and build the data room
Produce a current architecture diagram, a data flow diagram for customer data, runbooks for your top five incident types, a disaster recovery summary, and a one-page technical debt register with rough sizing. Put it all in one access-controlled folder with a clear index. Short and accurate beats long and stale.
- 5
Days 81 to 90: Run a dry-run diligence
Ask someone who hasn't seen your systems, an advisor, a fractional CTO or an outside firm, to send you a diligence questionnaire and interview your leads for two hours. Note every question that took more than a day to answer or made someone visibly uncomfortable. Fix those answers, then fix the stories behind them if there's time.
If you're closer than 90 days out, do the first two steps and the last one. Knowing your weak spots and rehearsing the answers beats polishing things that were never going to be asked about.
Where compliance fits in
Compliance frameworks aren't the point of technical diligence, but they shape the questions. Enterprise-focused companies get asked about SOC 2 or ISO 27001. Anything shipped into the EU market is increasingly asked about the EU Cyber Resilience Act, whose vulnerability reporting duties began applying in September 2026 and whose main product requirements follow in December 2027. Software bills of materials, vulnerability handling and secure update practices are exactly what that regulation expects, and they overlap heavily with what a diligence reviewer wants to see.
For a practical baseline on secure development practice, the NIST Secure Software Development Framework (SP 800-218) is a useful checklist, and the DORA research programme is the reference for the delivery metrics discussed above. For SBOM formats, see SPDX and CycloneDX.
Our related piece on SBOM and regulatory readiness is here: SBOMs and CVE Checks in Yocto Builds for the EU Cyber Resilience Act.
Frequently asked questions
How long does technical due diligence usually take?
It varies with deal size and who is running it, but two to six weeks from first request to final report is common. The engineering review itself is often only a few days of interviews, document review and automated scans. Most of the elapsed time is waiting on answers, which is why a prepared evidence pack shortens the whole process.
Do we need SOC 2 or ISO 27001 before we raise or sell?
Not always. Early-stage rounds rarely require a finished audit, but later rounds and any company selling to enterprises will be asked about it. If you don't have a report, having a readiness assessment, a policy set and a credible timeline is much better than having nothing to show.
Will the reviewers read our source code?
In an acquisition, plan on it. In a venture round it's less common, but reviewers often run automated scans for secrets, vulnerable dependencies and licence issues, and may sample parts of the codebase. Assume anything in your repositories could be looked at.
Is technical debt a deal-breaker?
No, every real product has it. Debt that you can name, size and schedule reads as engineering maturity. Debt that you've never measured, or that gets discovered by the reviewer rather than disclosed by you, is what damages trust.
When does it make sense to bring in outside help to prepare?
Usually when the CTO is also the main developer, when nobody on the team has been through diligence before, or when the timeline is short enough that you can't afford to learn on the job. An outside review also gives you an honest read before an investor's reviewer gives you theirs.
What is the most common surprise in engineering diligence?
Ownership. Cloud accounts, repositories, domains and licences turn out to be held by an individual or a former contractor instead of the company. It's easy to fix if you find it early and awkward to fix in the middle of a closing process.
Raising or selling in the next two quarters?
If you want an honest read on your delivery, security and key-system risk before an investor's reviewer gives you theirs, talk to us. We'll tell you what we'd flag and what you can realistically fix in the time you have.
Talk to Stonetusker about diligence readiness
