Scale ScoreThe due diligence questionnaire
A due diligence questionnaire is the written request a buyer or investor sends to a company they are evaluating. It exists to gather, in one structured pass, everything a reviewer needs before deciding where to dig deeper. Done well it saves everyone weeks. Done badly it generates a mountain of documents nobody reads and misses the thing that mattered.
This guide covers the technology sections, which is where most of the effort lands and where most companies are least prepared.
How the document is structured
Questionnaires vary, but nearly all of them organise around the same blocks. A technology section typically sits inside a wider document that also covers finance, legal, commercial and HR.
| Section | What it is really asking |
|---|---|
| Product and architecture | What did you build, on what, and will it survive the next five years of the buyer's roadmap? |
| Development process | Can you ship changes predictably, or does every release require heroics? |
| Infrastructure and operations | What does it cost to run, what happens when it breaks, and have you ever tested that? |
| Security and compliance | Will this company pass the security reviews the buyer's customers will run on it? |
| Third-party and open source | Do you actually own what you think you own, and are the licenses compatible with commercial use? |
| Team | Who knows how this works, and what happens if they leave three months after close? |
What a strong answer looks like
Reviewers read a lot of these. Three things separate a response that builds confidence from one that creates more work:
- Specific beats reassuring. "We deploy roughly twice a week, automated, with a manual approval step for database migrations" is worth more than "we follow modern CI/CD practices." The second answer invites a follow-up; the first closes the topic.
- Name the weaknesses yourself. Every reviewer expects to find problems. A response that flags its own known issues, with a rough cost to fix, reads as competence. The same issue discovered later reads as concealment and puts every other answer in doubt.
- Show the artifact, not the assertion. An architecture diagram, an incident log, a dependency inventory. One real document is worth several paragraphs of description.
The mistake almost everyone makes
Questionnaires are usually answered by one person, typically the CTO or the most senior engineer, working alone under time pressure. That produces a document describing how the organisation is supposed to work.
The reviewer then interviews two engineers and hears something different. That gap does more damage than the underlying problem would have, because it calls the whole response into question.
The fix is cheap: ask several people the same questions independently, before you submit anything, and reconcile the differences yourself. Where accounts diverge is exactly where a reviewer will push, and you would rather find it first.
If you are sending one
A few things make the responses more useful:
- Ask for evidence, not opinions. "Attach your last three incident write-ups" produces better signal than "describe your incident response process."
- Score against a fixed framework so answers are comparable across targets. Free-form responses are almost impossible to compare six months later. The DevOps maturity model is a common structure for the delivery sections.
- Collect from more than one respondent. Same reason as above, from the other side of the table: the variance between answers is signal, and a single-respondent questionnaire throws it away.
- Keep it proportionate. A 400-question document sent for a small acquisition signals inexperience and delays everything. Ask what will change your decision.
Where to start
If you are preparing for a process, the technical due diligence checklist covers the same ground in the order a reviewer works through it. If you want to understand the wider process the questionnaire sits inside, start with technical due diligence.