What Is a Security Questionnaire?
A security questionnaire is a structured vendor-risk questionnaire that a buyer or partner sends to assess how a company protects systems and data. It typically covers SOC 2, access control, encryption, business continuity, and incident response, and it is usually driven by the sender's vendor risk program rather than a bank's own regulatory file.
For a fintech, these arrive from enterprise customers, procurement portals, and sometimes from the same institutions that also send a bank DDQ. They look similar on the page. They are not the same document.
Who sends a security questionnaire?
Usually the buyer's information-security or vendor-risk team, not the relationship owner on the commercial side.
Typical senders:
- Enterprise customers onboarding a fintech or payments vendor
- Procurement teams running a vendor risk process before contract signature
- Partner platforms that require a security pack before integration
- Existing customers on an annual or trigger-based re-review (incident, new product, new region)
The sender is building a vendor file for their own program. They may use a standard form such as SIG or CAIQ, a portal with hundreds of repeating questions, or a bespoke spreadsheet.
What does a security questionnaire usually cover?
Scope is mostly technical and organisational security, not the full business.
Common sections:
- Information security governance and policies
- Access control and identity
- Encryption in transit and at rest
- Vulnerability management and penetration testing
- Logging, monitoring, and incident response
- Business continuity and disaster recovery
- Data handling, subprocessors, and privacy
- Independent assurance: SOC 2, ISO 27001, PCI DSS where in scope
A bank DDQ often adds ownership, financial crime, operational resilience beyond IT, and regulatory permissions. That extra width is why DDQs and security questionnaires should stay separate topics even when some answers overlap.
How is it different from a bank DDQ?
| Security questionnaire | Bank DDQ | |
|---|---|---|
| Sender | Buyer security / vendor risk | Sponsor bank, partner bank, regulated institution |
| Driver | Vendor risk program | The sender's own regulatory obligation |
| Scope | Mostly security and data protection | Whole business, including AML, ownership, operations |
| Format | Often SIG, CAIQ, or a portal | Often bespoke to the institution |
| Volume | More frequent, often lighter each time | Fewer, heavier |
| Success | Cleared in the vendor register | Approved, on file, defensible to examiners |
The same SOC 2 fact can serve both. The surrounding answers cannot always be copied across. A DDQ answer that names evidence a bank examiner would recognise may still fail a SIG question that wants a yes/no plus a control ID.
See DDQ vs RFP for a related split on purpose, and security questionnaire automation for how reuse should work.
How should you answer one?
Same standard as a DDQ, narrower scope:
- Answer the question that was asked, not the adjacent marketing claim.
- Cite current evidence by document, version, and location.
- Flag gaps instead of filling them with plausible language.
- Have the control owner approve before it leaves.
If the same SIG arrives every quarter, the win is reuse of approved answers with freshness checks, not rewriting from a blank page.
Frequently asked questions
Is a security questionnaire the same as a DDQ? No. Overlap is real. Sender, driver, and scope are different. Treat them as related workloads that can share an evidence library.
Do we need a SOC 2 to complete one? Many senders expect independent assurance. Some will accept compensating evidence for a period. Do not invent a report you do not have.
Why do we keep getting asked the same questions? Because each buyer maintains their own vendor file. Your answers can be reused. Their process will not be.
Key takeaways
- A security questionnaire is a vendor-risk pack, not a bank risk file
- Standards and portals make reuse pay off if citations stay attached
- Share an evidence library with DDQ work; do not merge the two answer styles
General guidance on common practice. Requirements vary by institution and jurisdiction; this is background, not compliance or legal advice. Last updated 17 August 2026.