A bank rarely says no to a vendor because the product is weak. It says no because the vendor can’t answer the review. Knowing the questions in advance turns a six-month process into a six-week one.
Why the review exists
Regulators hold banks accountable for the risks their suppliers introduce. In Nigeria, the CBN’s risk-based cybersecurity framework and outsourcing guidelines make the bank responsible for the controls of every third party that touches customer data or critical systems. In the UK and EU, operational resilience rules do the same. Every new partner is a new route for data to leak, systems to fail or obligations to be missed, so the review is designed to find those routes before a contract is signed.
That framing matters. The people running the review are not trying to block you. They are trying to produce a file that will satisfy an examiner two years from now. The easier you make that file to write, the faster you move.
Who is in the room
- Procurement, who own the commercial process and the timeline.
- Information security, who assess technical controls and send the questionnaire.
- Risk and compliance, who map your service to regulatory obligations.
- Legal, who negotiate data-processing terms, liability and audit rights.
- The business sponsor, who wants the project to happen and will chase everyone else.
Each group asks different questions in different formats. A common mistake is to answer only the security questionnaire and assume the rest will follow. Find out early who signs off and what each of them needs to see.
What they will ask
- Where customer data lives, in which country and region, and who can access it.
- How access is granted, reviewed and revoked, and how it is logged.
- How you handle incidents: detection, escalation and notification times.
- Business continuity: what happens if your team, cloud region or a key person is unavailable.
- Secure development: code review, dependency scanning and how vulnerabilities are fixed.
- Subcontractors and their own controls, including cloud providers.
- Evidence: policies, penetration test reports and certifications, not promises.
Treat the review as a product requirement, not paperwork. The answers should already exist before the first meeting.
The evidence that carries weight
Questionnaires invite long narrative answers, but reviewers trust artefacts. A recent independent penetration test with remediation notes is worth more than three paragraphs about your security culture. An access review log signed off last quarter is worth more than a policy describing quarterly access reviews. Where you hold a certification such as ISO 27001 or a SOC 2 report, lead with it and map its controls to the bank’s questions.
If you are early and have no certification yet, be honest. Show the controls you operate today, the roadmap to certification and the compensating measures in the meantime. Reviewers respond far better to a clear plan than to vague claims they will later find to be untrue.
Common reasons reviews stall
- Data residency answers that change between meetings.
- No named owner for security on the vendor side.
- Penetration tests older than twelve months, or with open critical findings.
- Subcontractors that were not disclosed until late in the process.
- Contract terms on audit rights or breach notification that the vendor won’t discuss.
How to be ready
Keep a living security pack: architecture diagram, data-flow map, access policy, incident runbook, business continuity plan and the latest penetration test. Assign one owner who updates it whenever the system changes. When the questionnaire arrives, most answers become references to documents you already maintain, and the review becomes a conversation rather than a scramble.
It also helps to run a mock review internally. Ask someone outside the engineering team to work through a real bank questionnaire using only your pack. Every question they can’t answer is a gap a real reviewer will find.
Where we help
We build systems with these controls designed in, and prepare the evidence alongside the code. For clients going through their first bank review, we also sit in on the technical sessions, answer architecture questions directly and close findings quickly, so the review confirms what is true rather than prompting work that should have happened earlier.