A due diligence questionnaire looks like a security questionnaire at first. Then you reach the section asking for audited financial statements, the one on your insurance coverage, and the one asking whether any director has been subject to regulatory action. It lands with the security team anyway, because the security team answered the last questionnaire.
A due diligence questionnaire, often called a DDQ, asks whether you are a viable, lawful, and resilient counterparty, not only whether your systems are secure. Most of it is outside the security team's knowledge. This article sets out what the sections usually cover, who should own each one, and how to handle the parts that cause the most delay: financial questions, continuity and exit, and the signed attestation at the end.
How a DDQ differs from a security questionnaire
Three differences matter in practice.
The scope is the whole company. A security questionnaire asks how you protect data. A DDQ also asks who owns you, whether you can pay your debts, what insurance you carry, and what happens to the buyer if you stop operating.
The buyer often has a regulatory reason to ask. Financial services firms in particular operate under outsourcing and third-party risk rules that expect documented due diligence before they rely on a provider. In the EU, financial entities that use ICT services are subject to DORA, covered in DORA explained for ICT service providers. The questionnaire is how the buyer builds the record their regulator will look for.
Answers are often attested. Many DDQs end with a statement, signed by an officer, that the answers are true and complete. That changes how carefully each answer needs to be written.
The usual sections, and who owns them
The section names vary, but the content is fairly consistent. Assign each section to the person who actually holds the facts.
| Section | What it asks | Owner |
|---|---|---|
| Corporate information | Legal entity, ownership, locations, headcount | Finance or legal |
| Financial standing | Financial statements, funding, solvency | Finance |
| Insurance | Cyber, professional liability, general liability coverage | Finance or risk |
| Legal and regulatory | Litigation, regulatory actions, licenses held | Legal |
| Compliance programs | Anti-bribery, sanctions screening, code of conduct, whistleblowing | Legal or people team |
| Business continuity | Continuity plan, recovery objectives, testing | Security and engineering |
| Subcontracting | Subprocessors, offshoring, dependence on key providers | Security and procurement |
| Information security | A condensed security section | Security |
| Privacy | Processing role, data processing agreement, transfers | Privacy or legal |
| Workforce and ESG | Environmental policy, modern slavery statement, labor practices | People team or operations |
The security team should own its sections and coordinate the rest. It should not write answers about insurance limits or litigation history, even when those answers seem easy to find. A guessed coverage amount in an attested document is a problem for the company, not only for the person who guessed.
Running one without the security team doing all of it
A process that works for most companies:
Split the questionnaire by section as soon as it arrives, and send each section to its owner with a deadline earlier than the buyer's.
Name one coordinator. Often that is someone in security or compliance, because they run the rest of the review. Their job is routing, consistency, and the final read, not writing every answer.
Reuse what exists. The security sections should come from your answer library. Corporate facts, insurance details, and compliance policies change slowly and are worth keeping as reusable answers too. Building a security answer library describes the structure, and it works for non-security facts with the same fields.
Collect the supporting documents once. Certificates of incorporation, insurance certificates, and policy documents are requested repeatedly. Keep current copies in one place with their dates.
Send the attestation to legal before anyone signs it.
Financial questions for private companies
Private companies are often reluctant to share financial statements, and early-stage companies may not have audited ones. Both are common and neither needs to stall the review.
Ask the buyer what they are trying to establish. Usually it is whether you will still be operating for the length of the contract. Then offer what you can: statements under NDA, a letter from your finance lead or accountant confirming financial standing, or a summary of how the company is funded. Some buyers will accept a substitute. Some have a fixed requirement for audited statements. If you do not have them, say so plainly and ask how they handle vendors in your position. They have usually seen it before.
Insurance questions are more straightforward. Have a current certificate of insurance ready, and make sure the person answering knows the difference between your cyber policy and your professional liability policy. Buyers often ask about both and sometimes require minimum coverage in the contract.
Continuity and exit questions
Regulated buyers ask two kinds of continuity question. The first is about your operations: do you have a business continuity plan, a disaster recovery plan, and stated recovery time and recovery point objectives? The second is about their exit: if the relationship ends, or you fail, how do they get their data back and move to another provider?
For the first, answer with what you have tested, not only what you have written. A recovery time objective with no restore test behind it is a target, and an experienced reviewer will ask when you last met it. If your recovery depends on a single cloud provider, say so. That dependence is the kind of concentration buyers are expected to understand.
For the second, describe the export mechanisms customers already have, the format of exported data, any transition assistance you offer, and how long you keep data after termination before deleting it. Under DORA, EU financial entities must have exit strategies for ICT services that support critical or important functions. DORA third-party risk and the register of information explains why that question is becoming more detailed.
Some DDQs also ask about concentration on your side: how many critical suppliers you depend on, whether any single provider could stop your service, and what you would do if it did. Answer with your actual dependencies and the mitigation you have, even when the mitigation is limited. Naming the risk plainly reads better than an answer that implies there is none.
The attestation at the end
Many DDQs end with a declaration that the answers are complete and accurate, signed by a named officer. Some add an obligation to notify the buyer of any material change to the answers.
Treat that page as a contract term, not a formality. Before signing:
- Not done:
Every section has been answered by its owner, not by the coordinator on their behalf.
- Not done:
Qualified answers keep their qualifiers. "Yes, for production systems" should not have become "yes" during formatting.
- Not done:
Unknown answers say so, rather than being left blank or filled in optimistically.
- Not done:
Any ongoing notification duty has an owner and a trigger, so that a change in insurance, ownership, or subprocessors actually reaches the buyer.
Whether an attestation creates a binding representation, and what happens if an answer later proves wrong, depends on the wording and the contract it connects to. Have counsel confirm before an officer signs.
A next step
Look at the last DDQ you received and note which sections the security team answered that someone else should own. Agree those owners now, before the next one arrives, and keep their answers alongside your security library. The glossary defines terms such as third-party risk management and data processing agreement, which helps when finance or legal pick up a section for the first time.