What a bank's vendor security questionnaire actually checks — and how to answer it from evidence you already have

Every fintech that signs a bank partner eventually gets the spreadsheet. Two to four hundred rows, a due date three weeks out, and a procurement contact who cannot tell you which answers matter. Most teams treat it as a writing exercise. It isn't. It's a mapping exercise, and once you see the map the questionnaire stops being a fire drill.

This is the approach we use when OTH is the CISO-of-record answering on a client's behalf. It works because bank VSQs are not bespoke — they are assembled from the same handful of control catalogues, and you have almost certainly already produced the evidence for most of them.

Where the questions come from

Strip the branding off any Canadian or US bank's third-party risk questionnaire and you'll find it's built from some combination of:

• The SOC 2 Trust Services Criteria — security, availability, confidentiality, and sometimes processing integrity and privacy.
• NIST CSF functions — Identify, Protect, Detect, Respond, Recover, and (in 2.0) Govern. Banks like this one because their own regulators use it.
• OSFI B-10 / B-13 or the FFIEC handbook, depending on which side of the border the bank sits — these drive the sections about your subcontractors, your concentration risk, and your exit plan.

If you have a current SOC 2 report, a risk register mapped to NIST CSF, and a written vendor management procedure, you already hold the source material for roughly [NN]% of the rows. The remainder are usually about the bank's specific integration — data flows, encryption in transit to their endpoints, incident notification timelines written into the contract.

The four sections that get scored, not read

Not every row carries equal weight. In our experience the sections that move the risk rating, and therefore whether the deal clears procurement, are:

• Data handling and classification. What of theirs do you hold, where, for how long, and who can see it. Vague answers here are what trigger the follow-up call.
• Access control and MFA. They want to see enforced MFA on anything touching their data, joiner-mover-leaver evidence, and periodic access reviews with dates.
• Incident response. The question is not whether you have a plan. It's whether your notification window is shorter than the one in their contract, and whether you've tested it.
• Fourth parties. Your cloud provider, your payments processor, your support tooling. Name them, and have their SOC reports on file.

Answer from evidence, not from memory

The single biggest time-saver is refusing to write a fresh prose answer for anything that already has an artefact. Each row gets one of three treatments:

• Cite. "Yes — see SOC 2 Type 2 report, CC6.1, control [ID]." Attach the report under NDA.
• Extract. Pull the relevant paragraph from the policy verbatim, with the policy name and version. Don't paraphrase — paraphrasing creates drift between what you told the bank and what your policy says.
• Write. Only for questions specific to this bank's integration. These are the answers that should get a second pair of eyes.

Kept in a single answer library, this means the second bank's questionnaire takes days, not weeks. That library is one of the first things we build when we take on a fintech client, because it is worth more to the sales team than almost anything else the security program produces.

What to push back on

Some questions are written for a hosted-infrastructure vendor from 2012 and make no sense for a cloud-native company. "Describe your physical data centre access controls" is answered by citing your cloud provider's SOC 2 and your own logical access controls — not by pretending you have a badge reader. A good answer explains why the control is inherited, and where the evidence for it lives. Banks accept this; what they don't accept is a blank.

Takeaway: A VSQ is a test of whether your evidence is organized, not of whether your security is good. Organize it once and every subsequent questionnaire is a lookup.