Third-party vendor security assessment: a guide for East African banks

In March 2026, a fraud incident at a major Rwandan bank was traced back to a vulnerability in a third-party vendor’s internet banking platform. The bank’s own security controls worked well during the response, but the initial access came through software it did not develop and only partially controlled. This is not an isolated case. Across East Africa, banks are increasingly being compromised not through their own systems but through the technology vendors they 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 include in contracts, and how to maintain ongoing oversight.

Why vendor risk matters in East African banking

The average East African bank depends on a dozen or more technology vendors for critical functions:

• 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: connecting to national payment systems, card networks, and mobile money
• Cloud infrastructure: AWS, Azure, or local hosting providers running production workloads
• Cybersecurity tools: SIEM, endpoint protection, email security, all from external vendors
• IT managed services: outsourced network management, helpdesk, and infrastructure support

Each vendor with access to your network, data, or systems is an extension of your attack surface. A vulnerability in any one of them can be exploited to compromise your institution. Yet most banks apply rigorous security testing to their own applications while treating vendor-supplied platforms as trusted by default.

What BNR requires

BNR cybersecurity regulation requires supervised institutions to manage third-party security risk. Specifically:

• Due diligence before contracting: assess the vendor’s security posture before signing an agreement
• Contractual security requirements: include security obligations in vendor contracts
• Ongoing monitoring: continuously monitor vendor security and compliance
• Incident notification: vendors must report security incidents that could affect your institution
• Inclusion in testing: vendor-supplied systems must be covered by your security testing programme

BNR examiners will ask about your vendor risk management programme. They will want to see documented assessments, contractual clauses, and evidence that vendor systems are included in penetration testing scope.

Vendor risk assessment methodology

Step 1: Inventory and classify vendors

Start by building a complete inventory of all 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 require only a basic questionnaire.

Step 2: Pre-engagement due diligence

Before contracting with a new critical or high-risk vendor, assess:

Security certifications and audits:

• Does the vendor hold ISO 27001 certification? Is it current and does the 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 their patch management process and cadence?
• How do they manage privileged access to systems that serve your institution?
• What is their incident response capability?
• Do they 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 ensures consistent assessment across vendors. Key domains to cover:

1. Governance: security policies, organisational structure, board oversight
2. Access control: authentication mechanisms, privilege management, access reviews
3. Data protection: encryption, data classification, backup, retention
4. Network security: segmentation, monitoring, intrusion detection
5. Application security: SDLC practices, code review, security testing
6. Incident response: plan, testing, notification procedures
7. Business continuity: disaster recovery, RTO/RPO, testing
8. Human resources: background checks, security training, termination procedures
9. Physical security: data centre controls, access restrictions
10. Compliance: regulatory certifications, audit history, legal obligations

Use a standardised framework. The Shared Assessments SIG questionnaire or the CAIQ (Consensus Assessments Initiative Questionnaire) for cloud vendors are good starting points. Adapt them to the East African banking context.

Step 4: Technical assessment

Questionnaires tell you what the vendor claims. Technical assessment verifies it. For critical vendors:

Penetration testing of vendor platforms: Include all vendor-supplied applications and systems in your penetration testing programme. This means testing the internet banking platform, mobile banking app, APIs, and any other vendor software that touches your banking environment. Test it with the same rigour you apply to internally developed systems.

Configuration review: For vendor-managed infrastructure (hosted servers, cloud environments), review security configurations against 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.

Step 5: Risk scoring and decision

Score each vendor based on:

• Inherent risk: how critical is the vendor to your operations and what data do they handle?
• Security maturity: how strong is their security programme based on questionnaire and technical assessment?
• Residual risk: after considering mitigating controls, what risk remains?

Use this scoring to make informed decisions: accept the risk, require the vendor to remediate specific gaps, implement additional compensating controls on your side, or choose a different vendor.

Contractual security requirements

Your vendor contracts must include security obligations that are enforceable. Key clauses:

Security standards

The vendor must maintain security controls consistent with industry standards (ISO 27001, NIST CSF, or equivalent) and comply with all relevant regulations including BNR requirements.

Right to audit

You (or your designated third party) 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 of any security incident that could affect your data or systems within a defined timeframe (24 hours is standard for critical vendors). The notification must include the nature of the incident, data or systems affected, containment actions, and remediation timeline.

Data protection

Specific requirements for data encryption, access controls, data residency, data retention, and secure data destruction at contract termination.

Sub-processor management

The vendor must disclose all sub-processors who handle your data and ensure they meet 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

Clear allocation of liability for security incidents caused by the vendor’s negligence or failure to meet contractual security obligations.

Ongoing monitoring

Vendor assessment is not a one-time activity. 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 for vendor data breaches and security incidents in the news
• Track vendor patching cadence for 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 East African banking

From our experience testing 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 accessible from the same network as production banking systems
• Outdated dependencies: vendor applications running on frameworks and libraries with known critical vulnerabilities

These are not exotic findings. They are basic security failures that a competent penetration test would identify. The problem is that most banks have never tested their vendor platforms independently.

How we can help

We are an OSCP-certified penetration testing firm based in Kigali. We conduct penetration tests of vendor-supplied banking platforms, helping institutions in Rwanda and East Africa verify the security of the third-party systems they depend on. We understand the common vendor platforms used in the region and know where to look for the vulnerabilities that matter.

For full details on 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.