A Due Diligence Questionnaire is a structured set of questions used to assess a third party’s security, compliance, and operational risk before engagement. In identity security, it validates controls over IAM, NHI governance, secrets handling, access management, logging, incident response, and regulatory obligations across cloud and application environments.
What a DDQ is designed to do
A due diligence questionnaire is not just a form, it is the first structured test of whether a third party can safely receive trust, access, or data. For security teams, its value is in making a vendor’s claims comparable, evidence-based, and reviewable before any relationship is approved.
Because DDQs are used before onboarding, they often shape the rest of the risk decision, including whether a vendor needs deeper review, contractual security clauses, or compensating controls. In practice, they are a governance tool as much as a security artifact.
What a DDQ should cover
A strong DDQ covers the control areas that most often create third-party exposure: access management, logging, incident response, vulnerability handling, data protection, subcontractor use, and the handling of credentials or secrets. In environments that rely on cloud services or software integrations, it should also test how the vendor protects administrator access, service accounts, and other non-human access paths.
The best questionnaires are scoped to the relationship rather than copied from a generic template. A payment processor, a SaaS provider, and a consulting firm may all be vendors, but the risks they introduce are different, so the questions should differ too.
When organisations need a structured starting point, NHIMG’s Vendor Security Assessment Template is built around tiering, evidence requests, scoring, and approval decisions.
How DDQs support third-party governance
DDQs are most effective when they are part of a broader third-party risk management process rather than a one-time procurement checkbox. They help establish baseline trust, but they should be paired with contract terms, evidence review, security testing where appropriate, and ongoing reassessment for higher-risk vendors.
They also help different teams work from the same record. Security, procurement, legal, privacy, and business owners may each care about different dimensions of the same vendor relationship, and a well-designed DDQ gives them a common evidence set instead of separate, inconsistent requests.
For a broader operating model, NHIMG’s Third-Party Risk Management Guide explains how due diligence fits into vendor tiering, contract security clauses, continuous monitoring, and offboarding.
Why DDQs matter for identity and access risk
In identity-heavy environments, the most important DDQ answers are often about who can access what, how access is approved, and how credentials are issued, rotated, revoked, and monitored. A vendor with weak controls around IAM, shared admin accounts, long-lived secrets, or poorly governed service identities can create an outsized blast radius even if its product looks low-risk on paper.
DDQs also help surface inherited access risk in M&A, outsourcing, and platform migration scenarios, where a third party may already hold trust relationships that are not obvious from the contract alone. The question set should make those hidden dependencies visible before they become operational debt.
When the vendor relationship involves integration or post-deal inheritance, NHIMG’s Identity Integration in M&A Guide is a useful companion for understanding how due diligence connects to day-one access and inherited identities.
Risk and Threat Considerations
DDQs fail when they are treated as self-attestation without evidence. The main risk is false confidence: a vendor may answer “yes” to the right control questions while still lacking effective segregation of duties, logging, revocation discipline, or incident response capability. That gap becomes most dangerous when the vendor has privileged access, processes sensitive data, or operates in the software supply chain.
Failure mechanism: Incomplete or overly generic questionnaires miss the access paths, secrets, subcontractors, and operational dependencies that attackers later exploit, so the buyer approves a relationship without understanding the true exposure.
Impact: A weak DDQ can leave organisations exposed to data leakage, unauthorized access, delayed breach detection, contract drift, and inherited compromise from a third party that was never properly assessed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SA-9 — External System Services | DDQs assess security expectations for third-party services and trust relationships. |
| RA-3 — Risk Assessment | DDQs are a primary input for evaluating vendor security and operational risk before engagement. | |
| SR-3 — Supply Chain Controls and Processes | DDQs check supplier controls over subcontractors, dependencies, and supply-chain exposure. | |
| Recommendation — Define security requirements for external services and verify them before integration. Use risk assessment results to drive vendor due diligence depth and approval decisions. Assess supplier controls and require evidence for supply-chain risk management. | ||
| CIS Controls v8 | CIS-15 — Service Provider Management | DDQs operationalize vendor review, evidence collection, and ongoing oversight. |
| Recommendation — Use service-provider management to vet suppliers and monitor their control posture. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | DDQs gather supplier security assurances needed for relationship governance. |
| Recommendation — Set supplier security requirements and review them before engagement. | ||
Practitioner Guidance
Governance implication: Treat the DDQ as an evidence-gathering control, not a procurement formality. The most useful questionnaires are tied to risk tier, refreshed when the service changes, and reviewed by the teams that own security, privacy, and vendor risk decisions.
What to watch for: Repeatedly vague answers, refusal to provide evidence, and generic policy claims without operational detail usually indicate that the questionnaire is not measuring actual control maturity. In those cases, the issue is often not the form itself but the buyer’s willingness to challenge the response.
Practitioner takeaway: A DDQ should make hidden trust explicit enough that you can justify the onboarding decision, defend it later, and know what must be monitored after contract signature.
Related resources from NHI Mgmt Group
- What do organisations get wrong when they treat vendor due diligence as a one-time questionnaire?
- Who is accountable when wallet-based customer due diligence fails?
- What is the difference between customer due diligence and strong customer authentication here?
- How should security teams assess a vendor’s ownership claims during due diligence?