Due diligence questionnaire

A due diligence questionnaire, or DDQ, is a structured set of questions used to gather information for a due-diligence review. In vendor risk management, its job is not just to collect answers, a useful DDQ links each answer to evidence, red flags, follow-up actions, and a defensible risk decision.

For ICT suppliers, NIST describes due diligence as gathering pertinent information about a supplier or product to inform decisions on new acquisitions and existing systems. That framing matters: the questionnaire informs the decision, but it is not the decision itself. A completed DDQ should help a reviewer decide whether to approve the vendor, approve with conditions, escalate concerns, request remediation, or reject the relationship.

What is a due diligence questionnaire?

In this guide, a DDQ means a structured question set used to assess risk before starting, renewing, expanding, or continuing a business relationship.

For a vendor or third-party review, the questionnaire typically collects information about areas such as:

The company, ownership, and services provided.
Security governance and policies.
Data protection and privacy practices.
Access controls and identity management.
Infrastructure, cloud, and operational security.
Incident response.
Business continuity and disaster recovery.
Compliance, certifications, and assurance reports.
Subcontractors or fourth parties.
Legal, contractual, financial, or operational risk.

The DDQ should not be treated as a self-attestation form that automatically clears a vendor. An evidence-gathering tool. The stronger version asks: “What do you do, what evidence supports that answer, and what should we do if the evidence is missing or weak?”

When is a DDQ used?

DDQs are used when an organisation needs structured information before making or revisiting a risk decision. In vendor and third-party risk management, that can include:

Onboarding a new supplier.
Reviewing an IT, cloud, outsourcing, or service provider.
Assessing a vendor that will access systems, networks, confidential information, or personal data.
Reassessing an existing supplier after a material change in service, access, ownership, or risk profile.
Periodically reviewing suppliers where the relationship and risk justify it.

The UK ICO’s guidance on IT supplier relationships says organisations should carry out risk assessment and due diligence before giving IT suppliers access to organisational networks or assets, and group suppliers by service risk while considering factors such as personal information sensitivity, likely threats, and operational impact.

DDQ-style formats also show up in transaction, investment, legal, financial, ESG, DEI, and responsible-business contexts. Those areas need domain-specific questions and reviewers. This article focuses on vendor and third-party risk DDQs.

DDQ vs. vendor assessment vs. broader due diligence

For this article, the terms are used this way:

Due diligence questionnaire: the structured question set used to collect information from the vendor.

Vendor assessment: the broader evaluation process that may include the DDQ, evidence review, risk scoring, contract review, security review, stakeholder approval, remediation tracking, and ongoing monitoring.

Broader due diligence: a wider investigation that may include legal, financial, operational, commercial, regulatory, strategic, and technical review.

The practical distinction is simple: the DDQ is one input. The vendor assessment is the process that turns that input into a decision.

What should a due diligence questionnaire include?

A vendor-risk DDQ should be scoped to the vendor’s service role. A payroll processor, penetration testing firm, office supplies vendor, and cloud hosting provider should not all receive the same questionnaire.

Useful scoping factors include:

What service the vendor provides.
Whether the vendor handles confidential information, personal data, regulated data, or production systems.
The level of system, network, or administrative access.
The operational impact if the vendor service fails.
Whether the vendor uses subcontractors for material parts of the service.
Applicable contractual, privacy, security, or sector obligations.

NIST’s cybersecurity supply-chain guidance supports tailoring supplier-risk assessment rigor to the organisation’s risk posture, system criticality, risk appetite, and risk tolerance. In practice, that means high-criticality vendors should receive deeper service questions and stronger evidence requests, while lower-risk vendors may only need a shorter baseline review.

A practical DDQ usually covers these decision areas:

Who is the vendor? Company profile, ownership, locations, service description, and key contacts.
What will they do for you? Services provided, systems involved, data processed, access needed, and dependencies.
How do they manage security? Policies, governance, risk management, training, and internal accountability.
How do they protect data? Data handling, privacy controls, retention, encryption, and segregation.
How is access controlled? User provisioning, privileged access, multi-factor authentication, reviews, and offboarding.
How do they operate technology? Cloud architecture, vulnerability management, logging, backups, and change control.
How do they respond to incidents? Incident response process, escalation contacts, testing, and notification commitments.
Can they continue service? Business continuity, disaster recovery, backup restoration, and service resilience planning.
What assurance exists? Certifications, independent reports, security assessments, policies, or customer-facing summaries.
Who else is involved? Subcontractors, hosting providers, support providers, and other fourth parties.
What commercial or contractual risks matter? Insurance, liability, data-processing terms, service levels, and termination support.
Are responsible-business factors relevant? ESG, ethics, labour, anti-bribery, or responsible sourcing where relevant to the service relationship.

The DDQ should define what evidence is acceptable for each area. Otherwise, reviewers receive vague “yes” answers that are difficult to validate.

Sample DDQ questions, evidence, red flags, and follow-up actions

The table below is illustrative editorial guidance, not a universal standard. Adapt it to your risk appetite, vendor tiering model, legal obligations, and approval process. Evidence should support review judgment; it should not—or should not by itself—be treated as automatic proof of compliance.

Risk area	Sample question	Expected evidence	Red flag	Follow-up action	Risk rating cue
Security governance	Do you maintain documented information security policies with named ownership and periodic review?	Policy index, security policy summary, review date, governance owner.	No documented policy set, unclear owner, or policies not reviewed.	Request policy summary, ownership details, and review cadence.	Medium for most technology vendors; higher if the vendor has privileged access or handles sensitive data.
Data protection and privacy	What personal or confidential data will you process, where is it stored, and how is it protected?	Data flow summary, privacy/security control summary, retention approach, encryption description.	Vendor cannot identify data handled, storage locations, or protection measures.	Clarify data scope, limit data shared, request privacy/security assurance, and confirm contract requirements where applicable.	Higher where sensitive personal data, regulated data, or cross-border processing is involved.
Access control	How do you manage user access, privileged access, and access removal?	Access control policy, MFA description, privileged access process, sample access review evidence.	Shared accounts, no privileged access process, or no offboarding controls.	Request compensating controls, access review evidence, and restrictions on privileged access.	Medium or high depending on access level and system criticality.
Infrastructure and cloud security	How do you manage vulnerabilities, configuration, logging, and change control for the service?	Vulnerability management summary, patching process, cloud control summary, logging and monitoring overview.	No vulnerability process, no logging, or inability to describe cloud responsibility boundaries.	Request recent assessment summary, remediation process, and architecture/security overview.	Higher for hosted platforms, integrations, or internet-facing services.
Incident response	Do you maintain and test a documented incident response process?	Incident response policy summary, tabletop or test record, escalation contacts, recent review date.	No documented process, no owner, or unclear customer notification route.	Request plan summary, escalation path, and contractual incident notification commitments where applicable.	Medium or high depending on data sensitivity and service criticality.
Business continuity	How would you continue or recover the service after a major disruption?	Business continuity plan summary, disaster recovery approach, backup and restoration evidence, test summary.	No recovery process, untested backups, or no defined responsibilities.	Request recovery assumptions, recent test evidence, and service-impact scenarios.	Higher where the service is operationally critical.
Compliance and assurance	What independent assurance, certifications, or assessments are available for the service in scope?	Relevant audit report, certification, penetration test summary, customer assurance package, or security assessment.	Assurance is expired, unrelated to the service, or unavailable for high-risk services.	Confirm scope, date, exceptions, remediation status, and whether alternative evidence is available.	Lower if current, relevant evidence supports key claims; higher if critical claims remain unsupported.
Subcontractors and fourth parties	Do you rely on subcontractors or cloud providers to deliver the service?	List of material subcontractors, hosting locations, oversight process, notification process for changes.	Vendor cannot identify material subcontractors or has no oversight process.	Request subcontractor list, change notification terms, and evidence of supplier oversight.	Higher where subcontractors handle sensitive data or critical operations.
Financial or operational stability	Are there known operational, staffing, ownership, or financial issues that could affect service delivery?	Company profile, service continuity statement, insurance summary, ownership information where appropriate.	Material instability, unclear ownership, or inability to support contracted service levels.	Escalate to procurement, legal, finance, or business owner for commercial review.	Depends on substitutability and operational dependency.
Legal and contractual risk	Are you able to meet required security, privacy, confidentiality, audit, and incident terms for this engagement?	Contract mark-up, data-processing terms where applicable, insurance certificate, service-level commitments.	Refusal of material protections needed for the risk profile.	Escalate to legal and risk owners; consider conditions, compensating controls, or alternative vendors.	Higher where contractual gaps leave material risk unaddressed.
Responsible business practices	Are there responsible-business requirements relevant to this service or supply chain?	Policy summary, code of conduct, supplier standards, relevant attestations.	No response where responsible-business requirements are material to the engagement.	Clarify applicability and route to procurement, legal, or sustainability reviewer if needed.	Usually conditional on industry, geography, customer commitments, and service type.

Where a supplier processes personal data, the ICO notes that organisations should assess whether the supplier provides sufficient security guarantees; relevant assurance may include reviewing security assessments, and required protections should be placed in the written processor contract where applicable. That does not mean one report, or one answer, proves compliance. It means evidence and contract follow-through should be part of the review where the relationship and applicable law make them relevant.

How to review and risk-rate DDQ responses

A DDQ review should test whether the response is complete, supported, relevant, and acceptable for the vendor’s role.

Use this sequence:

Check completeness. Identify unanswered questions, skipped sections, expired documents, and missing attachments.
Validate evidence. Confirm that evidence supports the specific answer and applies to the service in scope.
Compare against the vendor tier. A light answer may be acceptable for a low-risk vendor but not for a critical provider with sensitive data access.
Look for contradictions. Compare answers across the DDQ, contracts, architecture notes, policies, and assurance reports.
Identify material gaps. Separate minor documentation gaps from issues that affect confidentiality, availability, legal commitments, or operational resilience.
Assign a risk rating. Use consistent criteria and record the reasoning.
Trigger the right response. Approve, approve with conditions, request remediation, escalate, monitor, or reject.

NIST’s supply-chain guidance supports using collected assessment information to identify risk, select an appropriate response, document the decision, and monitor for changes. A DDQ that stops at collection misses the point.

A simple illustrative model:

Rating	Typical criteria	Possible decision response
Low	Complete answers; relevant and current evidence; no material gaps; limited data access, system access, or operational dependency.	Approve, document rationale, and set reassessment through the normal risk process.
Medium	Some missing or partial evidence; gaps have plausible compensating controls; moderate data, access, or operational exposure; issues can be remediated or accepted by the right owner.	Approve with conditions, request remediation, track open items, or escalate specific issues.
High	Unsupported critical claims; contradictory answers; material control gaps; refusal to provide necessary evidence; sensitive data exposure; privileged access; critical service dependency; or unresolved legal/contractual concerns.	Escalate to accountable stakeholders, require remediation or compensating controls, defer approval, or consider an alternative vendor.

This model should be adapted to the organisation’s risk appetite, criticality criteria, and approval process. The important point is not the labels themselves; it is that similar risks are assessed consistently and the final decision is documented.

How to run a practical DDQ workflow

A practical DDQ workflow connects scoping, evidence, review, and decision-making.

Define the vendor risk tier. Use service criticality, access level, data sensitivity, operational impact, and applicable obligations.
Select the DDQ scope. Send only the sections needed for the vendor’s role.
State evidence expectations upfront. Tell the vendor which documents, summaries, reports, or attestations should support key answers.
Track missing items. Separate late responses from material gaps.
Review answers against evidence. Do not treat unsupported “yes” answers as equivalent to validated responses for high-risk vendors.
Assign a preliminary risk rating. Base it on evidence quality, severity of gaps, and vendor criticality.
Escalate red flags. Route privacy, security, legal, commercial, or operational concerns to the right accountable owner.
Request remediation or compensating controls. Make the requested action specific and tied to the risk.
Document the decision. Record assumptions, accepted risks, conditions, and owners.
Set reassessment triggers. Review suppliers periodically where appropriate to the relationship and risk, especially after material changes.

Standard templates help with consistency and comparability. They become weak when reused blindly. A short, risk-tiered DDQ with clear evidence requirements will usually produce a better decision than a long generic questionnaire with no review rules.

Common DDQ mistakes to avoid

The most common DDQ failures are process failures, not wording failures.

Avoid these patterns:

Using one universal questionnaire for every vendor. It creates unnecessary work for low-risk suppliers and shallow review for high-risk ones.
Asking questions without defining acceptable evidence. Reviewers then have no basis for distinguishing a good answer from a vague one.
Treating self-attestation as sufficient for critical vendors. Higher-risk relationships usually need stronger support than unchecked “yes” responses.
Ignoring incomplete or contradictory answers. Gaps should either be resolved, accepted by an accountable owner, or reflected in the risk rating.
Scoring every category equally. A weak business continuity answer matters more for a critical operational provider than for a replaceable low-impact service.
Collecting DDQs without documenting the decision. The organisation should be able to explain why it approved, conditioned, escalated, or declined the vendor.
Assuming a template is enough. The value comes from tailoring, evidence review, and follow-through.

Making DDQs operational, not just documentary

A DDQ is valuable only when it supports a clear risk decision. Templates provide structure, but evidence standards, risk tiering, reviewer judgment, and follow-up rules make the result defensible.

For teams that repeatedly issue, review, or answer questionnaires, the operational goal is to connect DDQ responses to living evidence, reusable controls, risk records, and follow-up workflows. Ciphrix’s perspective is that compliance and risk work should run from operational evidence rather than recurring document projects. If DDQs are becoming repetitive or hard to trust, the next step is to examine how questionnaire workflows, evidence ownership, and risk decisions are managed end to end, as a starting point.