Answering a bank's vendor due diligence questionnaire
When a United States bank or credit union, or a European Union bank under the Digital Operational Resilience Act, sends a vendor due diligence questionnaire, the fintech vendor maps each question to existing evidence, closes gaps with penetration, access control, and failover tests, retests fixes, lists subcontractors and data locations, and returns a dated test evidence pack.
A bank sends its vendor due diligence questionnaire
The trigger is a shortlist: a bank or credit union wants to buy a fintech company's software, such as a loan origination platform, an identity check, or a payments API, and its third-party risk team sends a due diligence questionnaire with a deadline. The founder owns the deal, and the CTO and the security lead own the answers. The questions cover the security programme, the latest SOC 2 report, penetration test results, business continuity testing, incident handling, subcontractors, and data locations. A fintech programme launching on a partner bank is the partner bank integration scenario, and a review of a live programme is the sponsor bank compliance audit scenario.
In the United States, the bank's due diligence rests on the Interagency Guidance on Third-Party Relationships (88 FR 37920, final as of 6 June 2023) for banks supervised by the Federal Reserve, the FDIC, and the OCC. Among due diligence factors, a bank may consider reviewing SOC reports and whether their scope and results are relevant to the activity (section C.2.f). Results of vulnerability and penetration tests can provide valuable information (C.2.g). A bank may review the results of operational resilience and business continuity testing (C.2.i), and it evaluates the volume and types of subcontracted activities (C.2.l). Credit unions follow the NCUA letter 07-CU-13, Evaluating Third Party Relationships (December 2007, listed as active). The agencies, now joined by the NCUA, published proposed replacement guidance (91 FR 58536) on 15 September 2026 that would also cover insured credit unions. Status verified on 2026-09-22: comments close on 16 November 2026, and the 2023 guidance still applies.
In the European Union, a bank that buys ICT services falls under DORA (Regulation (EU) 2022/2554, applicable from 17 January 2025). Before it signs, the bank shall undertake all due diligence on the prospective ICT third-party service provider (Article 28(4)(d)).
What an unprepared vendor risks in the review
- The deal stalls or shrinks. When a bank cannot get the information it requests, the 2023 guidance says it may obtain other information, add controls on or monitoring of the third party, or consider a different third party. The 2026 proposal adds that where a third party is unable or unwilling to provide information reasonably necessary for due diligence, alternative sources may not be sufficient for the bank to engage within its risk appetite.
- The SOC 2 report does not cover the product. A report whose system description predates a new API or excludes the hosting region leaves the questions on that product without independent evidence. Under C.2.f, a mismatch in scope can suggest that additional scrutiny of the third party may be appropriate. See SOC 2 testing requirements for what the report covers.
- Open penetration test findings become contract terms. Due diligence can evaluate the third party's implementation of corrective actions for deficiencies discovered during testing (C.2.g). A report with open high-severity findings and no retest invites remediation deadlines in the contract.
- Undisclosed subcontractors put the contract at risk. A contract may require notice before a new subcontractor is used, prohibit specific subcontractors, and reserve the bank's right to terminate without penalty if subcontracting arrangements do not comply with contractual obligations (section C.3.n).
- EU contract clauses the vendor cannot meet. A financial entity may only enter into contracts with ICT third-party service providers that comply with appropriate information security standards (Article 28(5)). For ICT services supporting critical or important functions, the contract must oblige the provider to implement and test business contingency plans (Article 30(3)(c)) and to participate and fully cooperate in the bank's threat-led penetration testing (Article 30(3)(d)). The bank must be able to terminate for evidenced weaknesses in the provider's ICT risk management (Article 28(7)(c)).
The vendor due diligence checklist, in order
- Register the questions. Record each question with the bank's jurisdiction, the product in scope, an owner, and whether the service is a critical or important function. Output: a question register with one owner per item.
- Map each question to evidence. Link each question to a SOC 2 or ISO 27001 control, a policy, or a test record, and note the SOC 2 report period against the questionnaire date. Output: Requirement-to-test traceability matrix.
- List the gaps. Flag questions with no evidence, evidence older than the bank's window, or a product outside the SOC 2 system description. Output: Gap report before the assessment.
- Test the product the bank will buy. Run penetration tests on the web application, APIs, and mobile app in scope. Output: Web, API, and mobile penetration test report, and Findings with severity, reproduction steps, and retest results.
- Test access to the bank's data. Check roles, tenant separation, multifactor authentication, and API scopes against the questionnaire's access questions. Output: Access control and authorisation test matrix.
- Test continuity and failover. Run failover and restore tests, and simulate the outage of a cloud or data provider the product depends on. Output: Failover and recovery time results, and Third-party provider outage simulations.
- Map data flows and locations. Trace where the bank's customer and account data is stored and processed, including subcontractors, and confirm test environments use synthetic data. Output: Personal and cardholder data flow map, and Data residency checks for US, EU, and Canada.
- List subcontractors. Name each subcontractor, its service, its location, and the data it touches. Output: a subcontractor register the bank can check against the contract.
- Retest every fix. Rerun each failed test on a build that contains the fix. Output: Retest evidence after remediation.
- Assemble the answers. File each dated record under its question, state open items with owners and fix dates, and map EU answers to DORA Articles 28 and 30. Output: Test evidence pack per audit scope, and Test evidence mapped to DORA requirements for an EU bank.
Timeline and scope of the due diligence preparation
Durations are typical engineering estimates for one product and one bank; the bank's own review time comes on top.
| Phase | Duration (estimate) | Roles | Output |
|---|---|---|---|
| Question register and evidence mapping | 3 to 5 working days | Security lead, QA lead | Question register, traceability matrix |
| Gap check | 2 to 4 working days | QA lead, security lead | Gap report before the assessment |
| Penetration and access control tests | 2 to 3 weeks | Security testers | Penetration test report, access control matrix |
| Continuity, failover, and data flow tests | 1 to 3 weeks, in parallel | Platform engineer, QA engineer | Failover results, outage simulations, data flow map |
| Fix and retest | 1 to 3 weeks | Product engineers, security testers | Retest evidence after remediation |
| Answer assembly | 3 to 5 working days | Security lead, founder | Test evidence pack per audit scope |
Scope grows with each product, API, and mobile app the bank will use. A bank in both the United States and the European Union needs two answer sets, and a critical or important function under DORA adds contingency plan tests and threat-led penetration testing cooperation terms. A product outside the current SOC 2 system description needs its own test evidence until the next report covers it.
How we help with a bank's due diligence
- Audit and certification test evidence covers steps 2, 3, 9, and 10 with the Requirement-to-test traceability matrix, the Gap report before the assessment, Retest evidence after remediation, and the Test evidence pack per audit scope.
- Security testing covers steps 4 and 5 with the Web, API, and mobile penetration test report and the Access control and authorisation test matrix.
- Operational resilience testing covers step 6 and adds Test evidence mapped to DORA requirements for EU banks.
- Data privacy and test data management covers step 7 with the Personal and cardholder data flow map and Data residency checks for US, EU, and Canada.
- QA audit and test strategy adds a Due diligence summary for investors or partners when the bank asks how the product is tested before each release.
A testing vendor with access to your staging environment is itself a subcontractor on your list. Our attestations for that entry:
ISO/IEC 27001
Verified via SGS Spain, valid until 2030
SOC 2
Verified via Deloitte Spain, valid until 2030
PCI DSS, service provider level 2
Verified via A2SECURE, valid until 2030
The bank's third-party risk team decides on the relationship; our test records are input to its due diligence.
Questions
What is third party risk management?
What is an ICT third party service provider?
Scope the testing evidence for a bank's questionnaire
Send the questionnaire, the bank's jurisdiction, and the product in scope, and we return a gap list and a test plan with the evidence each answer needs.