Due Diligence Questionnaire (DDQ): What Buyers Are Really Looking for Before They Sign

A due diligence questionnaire is one of the most consequential documents in a vendor relationship, and one of the least understood. It arrives late in a procurement process, when the commercial decision has been made but the contract has not yet been signed. The DDQ asks the vendor to demonstrate, as part of a broader GDPR vendor management process, not just that it is secure, but that it is financially stable, legally sound, operationally reliable, and increasingly, that it governs its data and AI responsibly.

The DDQ is the document that consolidates these demands. Understanding what it is, where it comes from, and how it differs from an RFP or a security questionnaire is essential for any organisation that wants to move through vendor onboarding without unnecessary delay. Most vendors treat a DDQ as a nuisance. The sophisticated ones treat it as a closing instrument.

This guide covers the full picture.

What Is a DDQ?

A DDQ, or Due Diligence Questionnaire, is a structured document used by buyers to reduce the risk of engaging vendors who could introduce legal, operational, or financial liabilities. It is designed to confirm a vendor's readiness to enter into a contractual relationship by collecting consistent and comparable evidence across the factors that matter most to the buying organisation.

Where a vendor security questionnaire focuses primarily on information security and compliance controls, a DDQ is broader. It is designed to give a complete organisational picture: financial health, legal exposure, operational structure, security posture, data governance, and increasingly, AI governance. The DDQ is the document that asks: can we trust this organisation with not just our data, but our business?

That question gets sharper every year.

In vendor procurement, a DDQ evaluates a supplier before onboarding. It is the document that converts a commercial conversation into a documented risk assessment: what does this vendor actually do, who controls it, what can go wrong, and what evidence exists that the risk is managed? The underlying logic is straightforward, even blunt: structured, documented verification before commitment. No exceptions, no shortcuts, no reliance on a sales deck where a SOC 2 report should be.

The DDQ is not a checkbox exercise. For the buyer, it is the formal mechanism that transforms commercial enthusiasm into auditable diligence. For the vendor, it is the last gate between a handshake and a signed contract. Treating it with anything less than operational seriousness is a strategic mistake that costs pipeline velocity, and sometimes the deal itself.

Who Sends a DDQ and When

DDQs are sent by organisations that need to make a high-stakes, multi-dimensional assessment of a counterparty. The sender profile varies by context, but the underlying motivation is consistent: documented proof that the vendor relationship will not create an unacceptable exposure.

Enterprise vendor procurement: Procurement, GRC, or legal teams evaluating a new supplier before contract award. Typically sent after initial commercial discussions and before contract signature. The DDQ here serves as the organisation's internal record that it conducted adequate pre-contract diligence, a record that procurement leadership, the board, and external auditors may each review at different times.

Regulated industries (financial services, healthcare, public sector): Compliance and risk teams fulfilling regulatory obligations to document third-party vendor oversight. Often mandatory under frameworks such as DORA for ICT service providers. In these sectors, the DDQ is not optional: it is a regulatory artefact, and its absence can trigger supervisory action.

Technology and SaaS procurement: Security and GRC teams assessing cloud, AI, or data-processing vendors where the service involves access to sensitive data or critical systems. The scope of these DDQs has expanded materially since 2024 as AI governance sections have become standard. Buyers now routinely ask about AI inventories, model transparency, and high-risk AI system classifications.

Outsourcing and managed services: Legal and operations teams evaluating a provider taking on significant operational functions, where failure or liability risk is high. The DDQ in this context often includes detailed business continuity and disaster recovery sections that are less prominent in standard software procurement.

The timing matters. A DDQ does not arrive at the start of a sales cycle. It lands after the buyer has already decided, commercially, that the vendor is the right fit. The DDQ is the instrument that confirms whether the organisation behind the product is equally fit. Confusing a DDQ with an RFP, or treating it as an afterthought, is how deals stall at the finish line.

DDQ vs RFP vs Security Questionnaire: How They Compare

Organisations frequently confuse these three documents because they often arrive in sequence and sometimes overlap in content. Understanding the distinction matters both for the receiving organisation, which needs to route and resource the response appropriately, and for the sending organisation, which needs to choose the right instrument for its purpose. For detailed coverage of the RFP distinction, see our guide on security questionnaire automation and RFP automation, which covers the RFP side in depth.

DDQ: Its primary purpose is a comprehensive vendor assessment before contract award, verifying the vendor is operationally ready, legally sound, and safe to work with. The scope covers financial, legal, operational, security, data governance, ESG, and AI governance. Sent by procurement, GRC, or legal teams after commercial alignment, before contract signature. The output is a risk-assessed vendor profile used for procurement sign-off. Regulatory function: primary due diligence record for regulatory purposes (DORA, GDPR processor obligations).

RFP: The primary purpose is vendor selection, evaluating capability, fit, and commercial proposition. Scope covers capability, pricing, implementation, support, with a security section often appended. Sent by procurement or business teams early in the sales cycle, before vendor selection. Output is a vendor selection decision with commercial and technical scoring. No regulatory function: it is purely a commercial instrument. For automation guidance, see our guide on RFP automation.

Security questionnaire: The primary purpose is security and GRC posture verification before granting system or data access. Scope covers security controls, privacy compliance, certifications, incident response. Sent by security, risk, or compliance teams before system access or data sharing, and also at renewal. Output is a risk-assessed security posture that feeds into contract negotiation. Regulatory function: GDPR processor verification, SOC 2, ISO 27001 compliance evidence. For the most common formats, see our guides on the CAIQ, SIG questionnaire, and HECVAT.

The simplest way to think about it: the RFP asks "can you do this?", the security questionnaire asks "can you do it safely?", and the DDQ asks "should we trust you enough to sign?"

What a DDQ Covers: Domain-by-Domain Breakdown with Example Questions

A well-structured DDQ is organised into numbered tabs, each covering a distinct category of organisational risk. The structure below reflects how a real enterprise DDQ is typically built, based on the question types Whisperly sees most frequently through the vendor assessment and security questionnaire automation workflows.

Step 1: Data Security

Information security controls, certifications, incident response procedures, access management, encryption standards, and penetration testing cadence. Example question: Provide your most recent SOC 2 Type II report or equivalent certification and describe any material exceptions noted by the auditor, together with the remediation steps taken.

Step 2: Data Processing Controls

Controls governing data validation, consistency, quality measurement, audit trails, and testing of automated and manual data processing procedures. Example question: Does your organisation have a system for measuring and monitoring data quality? If yes, describe the methodology on which data quality measurement is based.

Step 3: Data Management

Data lineage, metadata management, master data governance, data cataloguing, data quality escalation procedures, and data integration controls across third-party services. Example question: Does your organisation have the capability to manage data lineage and document all data integration processes, whether automated or manual, including those handled by third parties?

Step 4: Personal Data Protection

GDPR compliance, data processing agreements, subprocessor management, data transfer mechanisms, data subject rights procedures, and records of processing. Example question: Provide your Data Processing Agreement template and a current, versioned list of subprocessors, including the legal transfer mechanism applied to any transfers outside the EEA. This section has grown in scope since 2024 as regulators increasingly expect documented processor chains with clear accountability at every link. For organisations subject to CCPA, equivalent disclosures on service provider arrangements may also be required.

Step 5: General Organisational Overview

Organisational overview, corporate structure, key contacts, and scope of services. Example question: Provide a current organisational chart, describe the legal entity structure, and identify the primary point of contact for this due diligence process.

Step 6: Finance

Revenue sustainability, audit history, debt structure, financial controls, and material financial changes. Example question: Provide audited financial statements for the past three fiscal years and describe any material changes in financial position, including any outstanding loans, guarantees, or contingent liabilities.

Step 7: Ethics and Regulatory Compliance

Anti-bribery and corruption policies, regulatory licences, sanctions screening, whistleblower procedures, and adherence to applicable sector-specific regulations. Example question: Describe your anti-bribery and corruption framework, including training cadence, escalation procedures, and any enforcement actions or internal investigations in the past five years.

Step 8: Conflicts of Interest

Beneficial ownership, board-level conflicts, related-party transactions, and disclosure and management procedures for actual or potential conflicts. Example question: Identify all beneficial owners holding more than five percent of the organisation and disclose any actual or potential conflicts of interest among board members or senior management, together with how each is managed.

Step 9: Business Continuity Management

Business continuity plans, disaster recovery arrangements, recovery time and point objectives, testing frequency, and critical service resilience. Example question: Describe your business continuity and disaster recovery arrangements for critical services, including your recovery time objective, the date of your most recent full test, and the outcome of that test.

Step 10: ESG

Environmental impact and reporting, labour practices, supply chain ethics, governance structure, and commitments to recognised sustainability frameworks. Example question: Describe your current carbon emissions measurement and reporting practices, including any commitments to science-based targets and the framework under which you report.

Step 11: AI Governance

For vendors deploying or providing AI-powered services, this section covers your AI inventory, AI risk classification under the EU AI Act, AI literacy programmes, and responsible AI practices. Example question: Provide your AI system register and describe how you classify AI systems by risk level, including any high-risk AI systems deployed or provided as part of the services under consideration. This domain did not exist in most DDQs before 2024. It is now standard in enterprise procurement for any vendor whose service includes an AI component, whether customer-facing or internal.

Every one of these domains carries its own review cadence, its own internal owner, and its own documentation requirements. That is what makes the DDQ uniquely difficult to coordinate, and why organisations that treat it as a single-owner task invariably miss the deadline.

The Multi-Stakeholder Problem: Why DDQs Stall and How to Prevent It

A DDQ does not have one reviewer. It has many. The buying organisation's procurement team, security team, legal counsel, finance function, and increasingly a privacy or AI governance officer will each evaluate the responses that fall within their domain. Each reviewer applies different criteria, has different priorities, and reports to a different internal stakeholder.

That last point is the one most vendors underestimate.

The implication for vendors completing a DDQ is direct: your responses are not evaluated by a single decision-maker. They are read by a committee in which each member is looking for something different, and each gap or ambiguity becomes a point of internal friction. A financial reviewer who cannot find audited accounts, a security reviewer who receives a generic answer about encryption, and a legal reviewer who finds no DPA template will each independently raise a concern. Those concerns compound. The deal stalls not because any single response was inadequate, but because the committee cannot reach consensus on whether the combined picture is acceptable.

According to Gartner research, 74% of B2B buyer teams demonstrate unhealthy conflict during the buying decision process, defined as conflicting objectives, disagreement on the best course of action, or being overruled by external decision-makers. The same research found that buying groups that reach consensus are 2.5 times more likely to report that their deal was high-quality. Buying groups now range from five to sixteen people across as many as four functions. Each reviewer of a DDQ response is a potential point of conflict, or, if handled correctly, a potential advocate.

The most effective DDQ responses are therefore not the most comprehensive. They are the most precisely calibrated to each reviewer's concern, presented with enough evidence to close the question rather than invite a follow-up. A response that says "we hold ISO 27001 certification" and attaches nothing gives a security reviewer nothing to verify. The same response with the certificate attached, the scope noted, and the last audit date confirmed closes the question entirely. Precision wins. Volume does not.

This is also why proactive evidence publication matters. A vendor whose Trust Center already contains current certifications, a DPA template, and an AI governance statement gives each reviewer access to the evidence they need independently, without requiring the security reviewer to wait for the legal reviewer's questions to be resolved first. The committee can review in parallel rather than sequentially, which is often the difference between a deal that closes in four weeks and one that stalls for three months.

How to Complete a DDQ Efficiently

The difficulty of a DDQ is not in any individual question. Almost every question in a well-structured DDQ is answerable if the underlying documentation exists and is current. The difficulty is coordination: the information required lives in different teams, different systems, and different document formats, and the people who hold it have other priorities.

Here is the sequence that compresses completion time without sacrificing accuracy.

Step 1: Triage by domain before routing

The first step when a DDQ arrives is to map each section to the team that owns the evidence, not the team that received the questionnaire. Financial sections go to finance and to the external auditor's contact. Legal sections go to legal counsel. Security and GRC sections go to the security team. Privacy sections go to the DPO or privacy function. AI governance sections go to whoever owns your ISO 42001 programme or EU AI Act compliance. ESG sections go to sustainability or corporate governance.

Routing without triage is how sections get lost.

Step 2: Answer with evidence, not assertions

Every answer in a DDQ should be supported by attached documentation where possible. A current SOC 2 Type II report answers an entire security domain. An ISO 27001 certificate with statement of applicability addresses governance and organisational controls. A GDPR-compliant DPA template closes the data protection contractual section. Evidence converts a DDQ from a self-declaration into a verifiable record. Reviewers who cannot verify an assertion will ask follow-up questions; reviewers who have attached documentation will not.

The rule is simple: if a reviewer has to take your word for it, you have not answered the question.

Step 3: Maintain a response library mapped to DDQ domains

The organisations that complete DDQs fastest are not those with the best writers. They are those with the best knowledge infrastructure. A centralised response library that maps approved answers to each DDQ domain, linked to the underlying documentation, allows each section to be pre-populated before a human reviewer engages. For the GRC, security, and privacy domains, this is the same infrastructure used in security questionnaire automation. For financial and legal domains, it requires equivalent preparation: current audited accounts, a standard legal disclosure statement, and a reviewed litigation register.

The payoff compounds. The first DDQ takes weeks; the tenth takes hours.

Step 4: Standardise your GRC posture documentation

The GRC sections of a DDQ (security, privacy, and AI governance) are the sections where most organisations lose the most time, because the evidence is distributed across multiple systems and has never been assembled in one place. Publishing this evidence through a Trust Center addresses the problem at source: buyers who review the Trust Center before formalising the DDQ arrive with the GRC and privacy sections already answered. The 30-40% of DDQ content that concerns data protection and security can be deflected entirely by proactive publication. Start with a free Trust Center and add deflection value from day one.

How Whisperly Helps with DDQ Completion and Management

Whisperly's platform addresses the GRC, security, privacy, and AI governance dimensions of a DDQ: the sections that most frequently cause delays and require coordination across multiple teams. The two capabilities that make the most direct difference are the Trust Center and security questionnaire automation, which together handle both proactive disclosure and reactive completion.

Pre-built evidence for the GRC and privacy sections

When a DDQ arrives, the GRC and privacy sections can be pre-populated from Whisperly's response library: your SOC 2 report, ISO 27001 certificate, GDPR documentation including your DPA template and Records of Processing Activities, and your AI governance posture are all connected to Whisperly's AI-driven matching engine. Questions are matched against your live documentation, confidence-rated answers are generated, and exceptions are routed to the right reviewer. What would otherwise require days of cross-team coordination becomes a same-day review task.

The Trust Center as a DDQ pre-response

For organisations that regularly receive DDQs, a Whisperly Trust Center functions as a standing pre-response to the GRC sections. When the buyer's security reviewer, DPO, or AI governance officer can access your current certifications, DPA template, subprocessor list, and AI governance statement before they formalise the DDQ, those sections often do not appear in the questionnaire at all. The 30 to 40 percent of DDQ content that concerns data protection and security can be deflected entirely by proactive publication. Start with a free Trust Center and add deflection value from day one.

Vendor assessment: the sending side

For organisations that send DDQs as part of their own vendor assessment or supplier due diligence programme, Whisperly's platform standardises the questionnaire design, automates response analysis, and maps answers to regulatory requirements including GDPR processor obligations and EU AI Act deployer due diligence. Instead of receiving unstructured responses across different formats and assessing them manually, you receive a risk-scored, comparable picture of each vendor's posture.

From Manual DDQ Responses to Structured GRC Automation: A Client Story

Street 17 had the same challenge that most scaling B2B technology companies face: their commercial team was closing deals across regulated industries, and the volume of incoming DDQs was growing faster than the capacity to answer them. The GRC and legal teams were fielding parallel requests, security documentation was scattered across shared drives, and the data protection section of every DDQ required the DPO to start from scratch each time. The questionnaire that should have taken a day was taking a week. The delay was showing up in the pipeline.

The underlying problem was not the questionnaires themselves. Street 17 had the certifications, the policies, and the compliance documentation. The problem was that none of it was assembled in one place, current, and immediately accessible. Each DDQ triggered a retrieval exercise rather than a review exercise. The distinction sounds minor. It is not.

After implementing Whisperly, Street 17 connected their SOC 2 report, GDPR documentation, and security policies to Whisperly's AI-driven response engine. The GRC and data protection sections of incoming DDQs now pre-populate automatically. Their Trust Center publishes the same documentation proactively, which means buyers who review it before sending a DDQ arrive with those sections already satisfied.

The security and privacy domain questions that previously consumed the most time are now the fastest to close.

The broader lesson from Street 17's experience is one that applies to any organisation receiving regular DDQs in regulated sectors: the questionnaire is not the problem. The absence of structured, always-current GRC documentation is the problem. Once that infrastructure exists, every DDQ that arrives becomes a review task rather than a research project. And every buyer who finds the Trust Center first never sends the DDQ at all.

Frequently Asked Questions

What does DDQ stand for?

DDQ stands for Due Diligence Questionnaire. It is a standard document buyers send to a new vendor to verify operational, legal, and GRC readiness before committing to a contract. Nothing more, nothing less, though the depth of what each section demands can be considerable.

What is the difference between a DDQ and a security questionnaire?

A security questionnaire focuses specifically on information security controls, certifications, and compliance posture. A DDQ goes wider: it covers financial health, legal and regulatory compliance, operational structure, security and GRC, data protection, AI governance, and ESG. A security questionnaire is typically one section within a DDQ, or a separate document sent alongside it. Think of the security questionnaire as the chapter and the DDQ as the book. For the most common security questionnaire formats, see our guides on CAIQ, SIG, and HECVAT.

What is the difference between a DDQ and an RFP?

An RFP (Request for Proposal) is a commercial instrument used to evaluate and select a vendor based on capability, pricing, and fit. It answers: can this vendor do the job? A DDQ answers a different question entirely: should we trust this organisation with our business? DDQs typically arrive after commercial alignment and focus on risk assessment rather than capability evaluation. The two are often sent in sequence: the RFP selects the vendor, the DDQ validates them. For the automation layer, see our guide on RFP and security questionnaire automation.

What industries use DDQs most frequently?

Financial services and insurance, healthcare, the public sector, and enterprise technology procurement: any sector where regulatory obligations or internal risk frameworks require documented vendor assessment before onboarding. The EU's DORA regulation, for example, requires financial entities to conduct and document due diligence on their critical ICT service providers using a framework that closely mirrors a formal DDQ. But DDQs are not limited to regulated industries. Any organisation with a mature procurement function and a meaningful risk appetite uses some form of structured pre-contract assessment, and the trend is accelerating as AI vendor risk becomes a board-level concern.

How long does it take to complete a DDQ?

That depends almost entirely on how well the responding organisation is structured. An organisation with current certifications, a maintained response library, and GRC documentation already assembled can typically complete the GRC and privacy sections within hours. Financial and legal sections require input from finance and legal counsel and tend to take longer: practitioners commonly report that a complete DDQ takes between one and three weeks of elapsed time when all functions are involved. This is distinct from effort time, since the coordination overhead is often larger than the actual writing time. See our guide on supplier due diligence for detailed guidance on building the documentation infrastructure that compresses this timeline.

What makes a strong DDQ response?

Strong DDQ responses share three characteristics: they are precise rather than generic, consistent with prior disclosures and internal documentation, and evidenced with attached documents rather than unsupported assertions. A security reviewer who receives a SOC 2 Type II report attached to the security section has nothing further to ask. A legal reviewer who receives only a statement that the organisation "complies with applicable law" will generate a follow-up list. The DDQ is not won by comprehensive writing. It is won by attached evidence that closes each question definitively.

Do I need a separate DDQ for every buyer?

Not entirely. The majority of DDQ content is reusable: financial statements, certifications, DPA templates, security policies, and AI governance documentation do not change between buyers. The proportion that is buyer-specific, covering questions about the particular service scope, contractual terms, or the buyer's specific regulatory context, is typically a minority of the total. Organisations that maintain a centralised GRC response library can pre-populate the repeatable sections automatically and focus human review effort on the buyer-specific remainder. That is the core value proposition of any response automation platform, including Whisperly.

Complete DDQ GRC sections faster with Whisperly. The GRC, security, privacy, and AI governance sections of a DDQ are the ones that most frequently stall completion. Whisperly connects your SOC 2 report, ISO 27001 certificate, GDPR documentation, and AI governance records to an AI-driven response engine that pre-populates those sections automatically. Your team reviews and approves rather than drafts from scratch. Proactively publish your GRC posture in a Trust Center and deflect the same sections entirely for buyers who review it first.

Book a demo · Start a free Trust Center

If your team also handles RFPs alongside DDQs, our guide on RFP response best practices covers the most common mistakes.