What Does a Bank DDQ Template Include?

Use this template two ways: to pre-build answers before a questionnaire arrives, and to audit whether your evidence library has gaps that will surface at the worst moment.

How do you use this DDQ template?

1. Work section by section, not question by question. Questions repeat across institutions in different wording. Answering at the domain level makes reuse possible.
2. Attach evidence as you go. An answer without a source document is usually treated as unanswered — see what a DDQ is for why.
3. Record the date of every artifact. Reviewers check dates before content. Stale evidence causes more rework than missing evidence.
4. Name an approver per section. Someone accountable should sign off before anything is exported.

Section 1 — Corporate & ownership

What the reviewer is establishing: who they are actually contracting with, and whether the entity is licensed for what it does.

Example questions:

• What is the full legal entity name, jurisdiction of incorporation, and registration number?
• List all beneficial owners holding 10% or more.
• Which licences or registrations does the entity hold, and in which jurisdictions?
• Describe the group structure and any parent or subsidiary relationships.
• Has the entity been subject to regulatory enforcement action?

Evidence to attach: certificate of incorporation, ownership register, licence documentation, org chart.

Section 2 — Information security

What the reviewer is establishing: whether controls exist, are documented, and have been independently tested.

Example questions:

• Do you hold a current SOC 2 report or ISO/IEC 27001 certification? Attach it.
• Describe encryption in transit and at rest, including algorithms and key management.
• How is access to production systems granted, reviewed, and revoked?
• Describe your secure development lifecycle and code review practice.
• When was your most recent penetration test, who performed it, and have findings been remediated?

Evidence to attach: SOC 2 Type II report, information security policy, access control policy, penetration test report and remediation summary.

Section 3 — Compliance program

What the reviewer is establishing: whether financial-crime controls are real and supervised.

Example questions:

• Describe your AML/KYC program and who owns it.
• What customer identification and verification procedures do you apply?
• How do you perform sanctions and PEP screening, and at what frequency?
• Describe transaction monitoring, including how alerts are investigated and escalated.
• Who is your designated compliance officer, and what is their reporting line?

Evidence to attach: AML policy, KYC procedures, screening vendor documentation, compliance officer appointment and CV, most recent independent AML review.

Section 4 — Third-party risk

What the reviewer is establishing: whether risk has been passed to parties they cannot see.

Example questions:

• List all subprocessors with access to customer or cardholder data.
• Describe your vendor due diligence process before onboarding a third party.
• How do you monitor third parties on an ongoing basis?
• Do you have concentration risk on any single provider?

Evidence to attach: subprocessor list, TPRM policy, sample vendor assessment, key vendor contracts or DPAs.

Section 5 — Business continuity & resilience

What the reviewer is establishing: whether you can keep operating, and whether the plan has been tested rather than merely written.

Example questions:

• Attach your business continuity and disaster recovery plans.
• What are your documented RTO and RPO?
• When was the plan last tested, and what were the results?
• Describe your infrastructure redundancy and failover arrangements.

Evidence to attach: BCP and DR plans, most recent test report, architecture diagram, uptime history.

Section 6 — Incident response

What the reviewer is establishing: whether you would detect an incident, and whether they would hear about it in time to meet their own obligations.

Example questions:

• Describe your incident response process, including severity classification.
• What are your notification timelines to customers and partners?
• Who is on the escalation path, and how is it staffed out of hours?
• Have you experienced a security incident or breach in the last 24 months? Describe it.
• How do you meet regulatory notification obligations such as GDPR Article 33?

Evidence to attach: incident response policy, escalation matrix, tabletop exercise records, any prior breach notifications.

Section 7 — Financial condition

What the reviewer is establishing: whether you will still exist for the term of the relationship.

Example questions:

• Provide audited financial statements for the last two years.
• Describe your current funding position and runway.
• What insurance coverage do you carry, including cyber and professional indemnity?

Evidence to attach: audited financials, cap table summary, insurance certificates.

Section 8 — Data privacy

What the reviewer is establishing: what happens to personal data, and where.

Example questions:

• What categories of personal data do you process, and on what lawful basis?
• Where is data stored and processed, and what governs international transfers?
• What are your retention and deletion practices?
• Attach your standard Data Processing Agreement.
• How do you handle data subject access requests?

Evidence to attach: privacy policy, DPA, records of processing, data flow diagram, transfer mechanism documentation.

What a strong answer looks like

The difference between a strong and a weak answer is rarely the underlying control. It is specificity, evidence, and dates.

Question: Describe your incident response process, including notification timelines and testing cadence.

Weak answer:

We take security seriously and have a comprehensive incident response process in place. Our team responds rapidly to any incident and notifies affected parties promptly.

Nothing here can be verified. There is no document, no timeline, no owner, no date. A reviewer has to come back and ask again.

Strong answer:

Incidents are classified P1–P4 under our Incident Response Policy (v3.2, approved 12 March 2026, attached, §4). P1 incidents page the on-call security engineer within 15 minutes and escalate to the CISO within 1 hour. Where a personal data breach is confirmed, we notify the relevant supervisory authority within 72 hours in line with GDPR Article 33, and affected partners within 24 hours per §6.1. The process was tested in a tabletop exercise on 4 June 2026; the report is attached. Two findings were raised and both were closed by 30 June 2026.

Same control, entirely different reviewability: named policy, version, date, section reference, concrete timelines, evidence of testing, and remediation status.

Pre-flight checklist

Before submitting, confirm:

• Every answer cites a specific source document, with section or page where relevant
• No cited artifact is older than the reviewing institution accepts
• Policy versions referenced match the versions actually attached
• Gaps are stated plainly with a remediation date, not papered over
• A named human has approved each section
• No marketing language survived from RFP source material

That last item is the most common contaminant — see DDQ vs RFP for why copy should flow from DDQ to RFP and not the reverse.

Key takeaways

• Most bank DDQs reduce to eight recurring domains — build answers per domain, not per question
• Every answer needs a narrative plus an inspectable artifact
• Dates matter as much as content; reviewers check currency first
• Strong answers name the policy, the version, the section, and the date
• Stating a gap with a remediation date beats an unsupported claim

Related

• What is a DDQ? — the definition and context
• DDQ automation: the complete guide
• Compliance glossary — every term used above