In March 2026, a major bank operating in Rwanda disclosed a fraud incident involving roughly $3.4 million in irregular transactions. Investigators identified a vendor-managed digital banking platform, used under licence, as a suspected entry point, alongside weaknesses in mobile money float purchases, as reported by ITWeb Africa and Techweez. The bank responded quickly (most fraudulent transactions were reversed within 24 hours), but the suspected initial access came through software the bank did not develop and only partially controlled. The pattern is not isolated: across Africa, attackers are reaching regulated institutions through the technology vendors those institutions depend on.
If you have not read our analysis of that incident, start there: A major bank in Rwanda was hit by fraud. Here is what every institution should do next.
This guide covers how to build a practical vendor security assessment programme: why it matters, what BNR requires, how to evaluate vendors, what to put in contracts, and how to maintain oversight once the contract is signed.
Why vendor risk matters in African banking
An African bank typically depends on external technology vendors across every critical function:
- Core banking software: the platform that runs your entire banking operation (Temenos, Finacle, Flexcube and regional providers)
- Internet banking and mobile banking platforms: customer-facing applications, often supplied by third-party vendors
- Payment switches and gateways: the connections to national payment systems, card networks and mobile money
- Cloud infrastructure: AWS, Azure or local hosting providers running production workloads
- Cybersecurity tools: security information and event management (SIEM), endpoint protection and email security, all from external vendors
- IT managed services: outsourced network management, helpdesk and infrastructure support
Every vendor with access to your network, data or systems extends your attack surface, and a vulnerability in any one of them can be exploited to compromise your institution. Yet many banks apply rigorous security testing to their own applications while treating vendor-supplied platforms as trusted by default.
The trust assumption is the risk. When a bank deploys a vendor's core banking platform, it implicitly assumes the vendor has secured it properly. That assumption is frequently wrong. Penetration tests of vendor-supplied banking platforms regularly turn up critical vulnerabilities: SQL injection, broken authentication, insecure direct object references and hardcoded credentials. A vendor's reputation does not guarantee the security of its code.
What BNR requires
BNR's cybersecurity requirements for supervised institutions include third-party risk management. Article 14 of Regulation N° 50/2022 requires written policies and procedures for service providers, and Regulation N° 49/2022 on outsourcing sets out due diligence, contract and audit requirements. Between them, they call for:
- Due diligence before contracting: assess the vendor's security posture before signing an agreement
- Contractual security requirements: include security obligations in vendor contracts
- Periodic assessment: reassess each vendor according to the risk it presents, using audits, test results or other evaluations
- Breach notification: the outsourcing agreement must address the vendor's obligation to inform you of a security breach
- Testing of external interdependencies: specific testing of connectivity to payment systems, messaging services, delivery channels and other critical service providers, plus response and recovery testing with suppliers
When examination time comes, that means producing documented assessments, contractual clauses, and test evidence that covers your vendor connections. The most direct way to produce that evidence is to bring vendor-supplied systems into your own penetration testing scope.
Vendor risk assessment methodology
Step 1: Inventory and classify vendors
Start by building a complete inventory of third-party vendors and classifying them by risk.
Critical vendors (highest risk):
- Access to production banking systems or customer data
- Process or store cardholder data
- Provide core banking, payment processing or internet banking platforms
- Have persistent network connectivity to your environment
High-risk vendors:
- Access to non-production environments that mirror production
- Provide cybersecurity or IT infrastructure services
- Handle employee data or confidential business information
Medium-risk vendors:
- Provide SaaS tools that handle some institutional data
- Supply hardware or software used in the banking environment
- Have occasional access for support or maintenance
Low-risk vendors:
- No access to systems or data
- Provide commoditised services (office supplies, facilities)
Focus your assessment resources on critical and high-risk vendors. Low-risk vendors may need only a basic questionnaire.
Step 2: Pre-engagement due diligence
Before contracting with a new critical or high-risk vendor, assess the following.
Security certifications and audits:
- Does the vendor hold ISO 27001 certification? Is it current, and does its scope cover the services you are using?
- Does the vendor have a SOC 2 Type II report? Review it for relevant control areas and any exceptions.
- Has the vendor undergone independent penetration testing? Request the executive summary or attestation letter.
Security programme maturity:
- Does the vendor have a dedicated security team or CISO?
- What is its patch management process and cadence?
- How does it manage privileged access to systems that serve your institution?
- What is its incident response capability?
- Does it have cyber insurance?
Data handling:
- Where is your data stored (geographic location)?
- How is data encrypted in transit and at rest?
- Who at the vendor has access to your data?
- What happens to your data when the contract ends?
- Does the vendor use sub-processors, and if so, what oversight exists?
Step 3: Security questionnaire
A structured questionnaire keeps assessments consistent across vendors. The domains to cover:
- Governance: security policies, organisational structure, board oversight
- Access control: authentication mechanisms, privilege management, access reviews
- Data protection: encryption, data classification, backup, retention
- Network security: segmentation, monitoring, intrusion detection
- Application security: secure development lifecycle (SDLC) practices, code review, security testing
- Incident response: plan, testing, notification procedures
- Business continuity: disaster recovery, recovery time and recovery point objectives (RTO/RPO), testing
- Human resources: background checks, security training, termination procedures
- Physical security: data centre controls, access restrictions
- Compliance: regulatory certifications, audit history, legal obligations
Use a standardised framework. The Shared Assessments Standardized Information Gathering (SIG) questionnaire, or the Consensus Assessments Initiative Questionnaire (CAIQ) for cloud vendors, is a good starting point. Adapt it to the African banking context.
Step 4: Technical assessment
Questionnaires tell you what the vendor claims; a technical assessment verifies it. For critical vendors:
Penetration testing of vendor platforms: Include every vendor-supplied application and system in your penetration testing programme. That means testing the internet banking platform, the mobile banking app, the APIs and any other vendor software that touches your banking environment, with the same rigour you apply to internally developed systems.
Configuration review: For vendor-managed infrastructure (hosted servers, cloud environments), review security configurations against the Center for Internet Security (CIS) benchmarks or equivalent standards.
Architecture review: Understand how the vendor's platform connects to your environment, what data flows between systems, and what network-level controls exist. Identify single points of failure and shared infrastructure risk.
Vendors may resist penetration testing. Some vendors will push back on security testing of their platforms, and that is a red flag. Your contract should include the right to test, and a vendor that will not allow independent security testing of systems that process your banking data is a vendor you should reconsider. At minimum, require the vendor to provide evidence of its own annual penetration testing by a qualified firm.
Step 5: Risk scoring and decision
Score each vendor on:
- Inherent risk: how critical the vendor is to your operations, and what data it handles
- Security maturity: how strong its security programme is, based on the questionnaire and technical assessment
- Residual risk: the risk that remains once mitigating controls are taken into account
Use the scores to decide whether to accept the risk, require the vendor to remediate specific gaps, add compensating controls on your side, or choose a different vendor.
Contractual security requirements
Your vendor contracts must include enforceable security obligations. The key clauses:
Security standards
The vendor must maintain security controls consistent with industry standards (ISO 27001, the NIST Cybersecurity Framework or equivalent) and comply with all relevant regulations, including BNR requirements.
Right to audit
You, or a third party you designate, must have the right to audit the vendor's security controls, conduct penetration testing of vendor-supplied platforms, and review security documentation. This right should be exercisable at least annually and after any security incident.
Incident notification
The vendor must notify you within a defined timeframe of any security incident that could affect your data or systems (24 hours is a common requirement for critical vendors). The notification must cover the nature of the incident, the data or systems affected, containment actions and the remediation timeline.
Data protection
The contract should set specific requirements for data encryption, access controls, data residency, data retention, and secure data destruction when the contract ends.
Sub-processor management
The vendor must disclose every sub-processor that handles your data and ensure each one meets equivalent security standards. Changes to sub-processors should require advance notice.
Business continuity
The vendor must maintain business continuity and disaster recovery plans that support your RPO and RTO requirements, and test them regularly.
Liability and indemnification
The contract should allocate liability clearly for security incidents caused by the vendor's negligence or its failure to meet contractual security obligations.
Ongoing monitoring
Vendor assessment does not end when the contract is signed. Security postures change, new vulnerabilities emerge, and vendors may cut corners after the initial engagement.
Annual reassessment
- Refresh the security questionnaire for all critical and high-risk vendors
- Review updated SOC 2 reports and ISO 27001 certificates
- Include vendor platforms in your annual penetration testing scope
- Review any vendor security incidents that occurred during the year
Continuous monitoring
- Subscribe to threat intelligence feeds that cover your vendors' infrastructure
- Monitor the news for vendor data breaches and security incidents
- Track how quickly vendors patch known vulnerabilities
- Review vendor access logs to your environment quarterly
Triggered reassessment
Reassess vendor security after:
- A security incident involving the vendor
- Significant changes to the vendor's services or infrastructure
- Changes in the vendor's ownership or leadership
- Changes in the data or systems the vendor accesses
- Negative findings in a penetration test of the vendor's platform
Common vendor security gaps in African banking
These gaps come up repeatedly in our lead tester's earlier work on vendor-supplied platforms across the region:
- Hardcoded credentials: database passwords, API keys and service account credentials embedded in application code
- Missing authentication on internal APIs: vendor platforms with well-secured front ends but completely unprotected backend APIs
- SQL injection: still present in vendor-supplied banking applications that have been deployed for years without security testing
- Insecure data storage: customer data stored in plaintext in vendor-managed databases
- Excessive vendor access: vendor support accounts with persistent administrative access to production banking systems
- No segmentation: vendor management interfaces reachable from the same network as production banking systems
- Outdated dependencies: vendor applications running on frameworks and libraries with known critical vulnerabilities
None of these findings is exotic, and a competent penetration test would identify every one of them. The problem is that many banks have never tested their vendor platforms independently.
How we can help
IMIZI Cyber is a Kigali-based firm providing manual penetration testing for banks, fintechs, telecoms, government and healthcare institutions across Africa. Our testing is led by an OSCP- and PNPT-credentialled practitioner and follows recognised methodology, with evidence-led reporting that a board and a regulator can both act on. We test vendor-supplied banking platforms with the same rigour we apply to in-house systems, so that institutions can verify the security of the third-party software they depend on. We scope that testing around the vendor platforms common in the region and the places where their vulnerabilities tend to hide.
For full details of our testing methodology, see our penetration testing service page. For broader vendor risk and security assessment needs, see our security assessments service page. Contact us to include your vendor platforms in your next security assessment.