Practical Guide to a Third-Party Due Diligence Questionnaire

This guide explains a practical DDQ architecture, the control domains to cover, a six-stage workflow for collecting audit-grade evidence, and specific considerations for research projects and AI-powered services.

Editorial approach and scope

We don’t present a checklist of isolated questions. Instead, we map the DDQ to control objectives and evidence types, drawing on industry questionnaires such as SIG, CAIQ and sector-specific templates. The goal: every question should require a verifiable artifact (dated document, config extract, or report) and a clear risk decision.

A useful DDQ forces three outputs from each response:

• A precise assertion (what the supplier claims);
• A control that makes that assertion credible (policy, procedure, technical control);
• A dated, attributable piece of evidence that demonstrates the control is implemented and effective.

If a supplier provides only a policy without a supporting log, test result or certificate, the answer remains a narrative, not proof. That distinction—claim versus evidence—is the difference between a compliance checkbox and an operationally defensible risk posture.

Why the DDQ is a core third‑party risk control

In a mature GRC (governance, risk and compliance) program the DDQ is a verification system, not an administrative form. It creates an auditable record of supplier posture and drives remediation, monitoring and contractual commitments. For regulated entities, demonstrable oversight of third parties is often a legal requirement under frameworks such as DORA and GDPR.

Good DDQ practice establishes a defensible position for auditors and incident response. Asking for concrete evidence—pen test reports, configuration snapshots, BCDR test results—creates a traceable chain of responsibility and reduces reliance on implicit trust.

For suppliers, a DDQ can be competitive advantage: well-documented, easily retrievable evidence signals operational maturity and reduces friction in procurement. For buyers, it’s the primary mechanism to translate supplier claims into an actionable risk rating. Read more about how this fits into a broader risk program in our article on risk management and compliance: https://audit-ready.eu/en/blog/risk-management-compliance

The anatomy of a modern DDQ

A contemporary DDQ is layered and purpose-driven. It groups questions by control domain, sequences them from general to technical, and scales depth according to supplier criticality.

Key domains to include:

• Information security & cybersecurity: identity & access, encryption, vulnerability management, penetration testing, system hardening and monitoring. Focus on how controls are implemented and validated, not only on their existence.
• Business continuity & disaster recovery (BCDR): documented plans, test schedules, recent test results, and metrics such as RTO (Recovery Time Objective) and RPO (Recovery Point Objective).
• Data governance & privacy: data classification, lawful basis for processing, data retention and deletion, and GDPR-related obligations where applicable.
• Corporate and organisational governance: financial stability, insurance, employee background checks, security training and separation of duties.
• Supply chain security (fourth‑party risk): how the supplier manages its own subcontractors and what controls are required of them.
• AI systems governance: data provenance, model explainability, bias testing, human oversight and alignment with the EU AI Act where relevant.

Sequencing and depth

Start with the perimeter (who they are, what services they deliver, and whether they process your data). Next, address governance and compliance. Only then ask for technical configuration, logs and test evidence. This prevents asking for technical details before the relevant system boundaries are defined.

Depth should match risk. Low-risk commodity providers may only need attestation and recent policy documents; critical providers—those with system access or sensitive data—require implementation evidence and recent test outputs. For each critical question implement three tiers: claim → control → proof.

Example (data access for research):

1. Which experimental datasets do you receive and who is authorized to access them? (claim)
2. What controls separate identifiable data from research datasets and how are changes recorded? (control)
3. Provide an excerpt from the access log or review report for the most recent research period. (evidence)

Maintain the link between claim, control owner and evidence expiry so responsibility is always clear.

DDQ considerations for research collaborations

Research projects often span universities, startups, internal labs and industrial partners. A DDQ for research should therefore start with organisational and economic boundaries, not only technical details. For each project record: objective, scientific owner, budget, datasets, legal basis for processing, third parties, execution environment and acceptance criteria for outputs.

Reproducibility is a core risk in research. Ask for versioned protocols, parameter management, change tracking, compute environment details, materials and peer‑review criteria. The Nature reproducibility survey highlighted frequent replication challenges; a DDQ should therefore require versioned protocols and an approvals register to distinguish documented processes from ad‑hoc practice.

A governance question that yields useful evidence: “Who approves the protocol, what peer review was conducted, and provide the approval log including dates and approvers.” The answer should map responsibilities, review cadence and exceptions, plus evidence of data retention, access control, backups and deletion policy.

AuditReady ties each evidence request to an owner, state and expiry so validation remains an active process rather than a file dump.

Six‑stage DDQ workflow (for buyers)

A repeatable workflow prevents ad‑hoc, email‑driven chaos. Treat a DDQ response as a small project and map roles clearly.

1. Intake & triage — establish scope, deadlines and a single coordinator (CISO or compliance lead).
2. Deconstruction — split the questionnaire and assign questions to SMEs via an ownership matrix.
3. Evidence mapping — link each question to internal controls, policies and the specific evidence that will prove them.
4. Evidence collection — centralise evidence (screenshots, logs, reports) in an evidence library.
5. Review & approval — coordinator and executive reviewer ensure consistency and sufficiency.
6. Secure submission — deliver through an encrypted portal or secure data room.

A central evidence library with version control dramatically reduces response time. Instead of searching for the latest penetration test or policy, SMEs pull an approved artifact from the repository with clear provenance.

Common operational challenges and how to address them

Typical failure modes:

• Overreliance on self‑attestation without verification.
• Inefficient evidence collection that uses email and ad‑hoc storage.
• Failure to track remediation items so findings remain open and unmonitored.

To address these issues: centralise evidence in a secure, versioned repository; map controls to evidence; and automate assignments and reminders using workflow tools. Doing so turns the DDQ from a procurement bottleneck into a repeatable verification process.

Surveys of regulated industries show a major execution gap: organisations may invest in compliance yet lack operational systems to collect and maintain evidence over time. The outcome is a paper‑based process that fails the audit test. Treat the DDQ as an engineering discipline—design the process, instrument evidence collection, and measure outcomes.

AI governance in the DDQ

As AI becomes embedded in supplier offerings, DDQs must assess model lifecycle governance. Regulators and customers now expect clarity about data sources, model limits, and human oversight. Treat AI components as software systems with specific governance requirements.

Key AI topics to include:

• Data provenance and quality—where training data came from, cleansing steps and bias mitigation.
• Model transparency and explainability—documentation of architecture, assumptions and operational limits.
• Human oversight—how human‑in‑the‑loop controls work, and evidence of intervention procedures.

Industry DDQs for AI (for example, templates released by sector groups) are standardising expectations and aligning questions with the EU AI Act. Suppliers should be prepared to show impact assessments, model constraints and records of human oversight—not just a brochure describing capabilities.

Evidence management: the single source of truth

Claims without evidence remain claims. In 2026 regulators expect not only proof at the time of response but mechanisms to demonstrate that evidence remains valid (assignments, review dates, renewal procedures). Evidence must be maintained as an auditable asset.

Principles for an evidence library:

• Immutability & versioning: maintain an audit trail of changes so you can show historical posture.
• Strong encryption for data at rest and in transit (e.g., AES‑256 recommended as baseline).
• Role‑based access control (RBAC) to restrict who can view or change evidence.

Submission should be via secure portals rather than email attachments. Provide an audit‑ready export pack for reviewers: a completed questionnaire, an index mapping each question to specific evidence files, the evidence set organised and named, and an export log showing who produced the package and when. This reduces auditor friction and demonstrates operational discipline. See also our guidance on virtual data rooms and evidence handling: https://audit-ready.eu/en/blog/vdr-due-diligence and https://audit-ready.eu/en/blog/audit-evidence

Practical FAQs

How often should we re‑assess a supplier?

• Base frequency on risk. Critical suppliers: annually at minimum. Lower‑risk suppliers: every two to three years may suffice. Crucially, use event‑driven reassessments for incidents, major service changes or corporate transactions.

Is a SOC 2 the same as a DDQ?

• No. A SOC 2 is an independent, attested audit against AICPA Trust Services Criteria. A DDQ is a targeted inquiry that lets you probe your specific risks and requires evidence relevant to your use case. Treat SOC 2 as an important evidence item within a broader DDQ.

Can one DDQ cover all suppliers?

• Use a standard baseline (e.g., CAIQ, SIG) but adapt depth and modules by supplier risk class. One-size-fits-all is inefficient and can either under‑test critical providers or overburden low‑risk vendors.

What must a research‑focused DDQ include?

• Start with scope, actors and legal basis. Then require versioned protocols, data lineage, compute environment details and traceable approvals. Each question must map to a responsible owner and dated evidence.

Which research questions are indispensable?

• Ask about the project perimeter, datasets, third parties, technical controls, human oversight and independent review. For example: “Which critical decisions are automated, and what evidence shows human intervention is possible and recorded?” The useful answer always includes proof, not just a description.

Closing practical checklist

• Design the DDQ around claims → controls → evidence.
• Sequence questions from perimeter to technical detail.
• Scale depth to supplier criticality.
• Centralise and version your evidence library; protect it with encryption and RBAC.
• Use automated workflows to assign owners, collect evidence and produce audit‑ready exports.

A well‑engineered DDQ turns supplier assessments into a measurable, auditable control. It’s the operational mechanism that lets organisations comply with modern third‑party risk obligations and maintain resilient supply chains. AuditReady helps teams implement workflows and evidence management that make DDQs repeatable and defensible—so supplier oversight becomes a source of assurance, not friction.