In November 2024, the Bank of Uganda was hacked, and the bad actors stole $16.8 million. This incident sent ripples through the banking ecosystem in Africa. It was mind-numbing that hackers could target a country's central bank and succeed. It reinforces the argument that a security breach is existential for every fintech, bank, or financial institution. So, you can’t lower your guard at any point, or you’ll pay for it. 

‍

But here’s the dilemma: Financial institutions rely on third parties, and bad actors can exploit this. Third parties include cloud storage providers, financial processors and partners, SaaS vendors and collaboration tools. 

‍

Yes, a robust cybersecurity process insulates you to a large extent, but one of the most proactive ways to prevent an attack is to have a solid third-party risk management framework. 

‍

Why is a third-party risk management framework important for fintechs? 

Attackers know that it's better to attack third-party providers and get access to dozens of companies instead of focusing on penetrating one company. 

‍

Painting a scenario, let's imagine I'm trying to launch an attack on businesses for financial rewards. Sometimes it really doesn't pay much to go after a business—it's more lucrative when I go after a third party. Why? Because I know that a third party is most likely connected to multiple businesses. Going after a third party, if I'm able to successfully execute an attack, it can cascade to multiple businesses. So, it's basically like a jackpot. 

Olaoluwa Eweje, CISO at Kora

‍

Picture your own third-party stack: payment processors for transactions, cloud providers for hosting, SaaS tools for operations, and dozens of other partners between you and your customers. Each represents a potential entry point that exists outside your direct control but can devastate your business just as effectively as any internal security failure.

‍

Many attacks in the African fintech ecosystem that cost companies millions actually result from third-party breaches by trusted partners, not direct attacks. You can't avoid these relationships because you need partners to scale and provide seamless customer experiences—you have to manage the risk intelligently.

Some fintechs make the mistake of totally trusting their partners to bear the risk alone, thinking that investing in their own environment provides enough protection. That's not the case, even if one's partner has impressive certifications. 

‍

It is not enough for you to make significant investments in security in your own environment. It is also important to implement a third-party risk management process.

Olaoluwa Eweje, CISO at Kora

‍

There's a systematic approach to managing third-party security risk that doesn't require you to become a security expert or slow down operations. This guide covers everything from initial partner selection to ongoing monitoring and, when necessary, termination.

You'll learn how to spot red flags before they become breaches, structure contracts that protect you, and build processes that scale your business.

‍

Whether you're a CISO formalising your third-party risk program or a fintech founder understanding what "good enough" security looks like, this guide will help you build relationships that enable growth without compromising security.

‍

Your customers trust you with their financial lives, and when you extend that trust to third parties, you need to be sure they're worthy of it. No financial institution is safe from third-party risk in a world where bad actors can breach central banks. 

‍

Categories of third-party risk

Not all third parties pose the same level of risk to your business. When you understand these categories, you can allocate your security resources and apply the right level of scrutiny to each relationship. 

‍

Payment processors and financial partners

These carry the highest risk because they have direct access to your customers' money and data. Financial partners process transactions, store payment credentials, and often maintain dashboards where you monitor your business finances. A breach here doesn't just expose data but can expose actual money.
‍

For third parties that process card transactions, for example, there's a security standard called PCI DSS that ensures that entities that process card data implement a couple of security standards within their environment. 

But certification alone isn't enough. You need to verify that your partners implement and maintain these standards. Consider what's at stake: customer payment methods, transaction histories, settlement data, and integration credentials that attackers could use to initiate transactions on your behalf. If an attacker compromises your payment processor, they could redirect funds, access customer payment data, or use your credentials to commit fraud in your name.

Many payment companies also provide customer dashboards for transaction monitoring and financial management. 

‍

Cloud service providers

Fintechs can’t do without cloud infrastructure providers. Unless you somehow manage to build your own server locally, which would significantly cost you and probably derail you from your primary goal as a business. 

‍

So, cloud infrastructure providers—AWS, Azure, Google Cloud, or a local provider—represent a critical infrastructure dependency. These relationships are high-risk because they have foundational access to your entire operation.

Cloud providers have access to your databases, API Keys, networking configurations, and often your backup and disaster recovery systems. A compromise at this level would be catastrophic. 

‍

SaaS vendors and collaboration tools

Think again if you think using Slack or emails don’t pose a risk. Disney’s Slack breach says otherwise. These tools often fly under the security radar but represent a significant risk because of their broad access to business operations and data.

‍

Think about the SaaS tools your organisation uses daily: Slack for communication, Google Workspace for productivity, Intercom for customer management, HubSpot for marketing, and dozens of other specialised tools. Each one requires permissions to access, store, and process business data.

‍

When bad actors compromise a major SaaS platform, the impact spreads across thousands of client organisations simultaneously.

‍

The risk with SaaS vendors isn't always obvious. Your marketing automation tool might have access to customer lists and communication preferences. Your project management tool contains sensitive product roadmaps and strategic discussions. Your HR platform stores employee personal information and compensation data.

‍

These tools also create lateral movement opportunities for attackers. If a social engineering attack succeeds against an employee, attackers could stay dormant for months and make a move at the right time. One email or Slack message from a “trusted” teammate could compromise the system. 

‍

Physical suppliers and contractors

While these represent lower digital risk, they can create unexpected vulnerabilities.

‍

Physical suppliers include companies that provide laptops, mobile devices, office equipment, and other hardware. The risk here is typically related to supply chain integrity—compromised hardware with pre-installed malware or backdoors.

‍

Another category includes contractors and service providers with physical access to your offices. Cleaning services, security guards, maintenance workers, and even food vendors can access sensitive areas or equipment without proper controls.

‍

The five-phase third-party security risk management framework

Phase 1: Selection and "know your partner"

You’ve heard of Know Your Customer (KYC), but there’s also Know Your Partner (KY3P). 

Think of this like the talking stage of a relationship. Here, you're trying to quickly identify whether a prospective partner deserves more of your time and attention. The goal here isn't to conduct a comprehensive security audit. That comes later. Instead, you're doing high-level due diligence to answer one fundamental question: Is this partner worth the risk of a deeper relationship?

‍

The first stage of that procedure is the selection phase, and this is the part where you basically try to know the partners that you're getting involved with. "You're trying to understand the services that they'll be offering. Olaoluwa Eweje, CISO at Kora

Assess the service criticality 

Before diving into security questionnaires and certifications, you need to understand what you're buying and how important it is to your operations.

‍

A cloud infrastructure provider like AWS that hosts your core payment systems represents existential risk—if they go down, your business stops. Compare that to a vendor that supplies laptops to your office. Both are third parties, but they're not even in the same risk bracket.

‍

This criticality assessment shapes everything that follows. High-criticality services receive intensive scrutiny and ongoing monitoring, while lower-criticality services receive basic due diligence and periodic check-ins.

‍

For fintechs and financial institutions, consider these criticality levels:

Critical: Payment processors, core banking systems, primary cloud infrastructure, fraud detection services

High: Customer support platforms, compliance tools, backup systems, key API providers

Medium: Productivity tools, marketing platforms, secondary hosting providers

Low: Office supplies, facilities management, non-technical services

‍

Send them a security questionnaire 

Once you determine that a service is a good fit, send the third party a security questionnaire to gather basic information. The goal is to understand the partner's security posture without overwhelming them. 

‍

The questionnaire basically cuts across multiple things. It's basically a form, and it's basically used for information gathering. You want to understand the size of their organisation in terms of staff strength and the size of their information security team. Olaoluwa Eweje, CISO at Kora

‍

Key areas your questionnaire should cover:

Organisational structure: How many people work on security? Do they have a dedicated security leader? What's their security team's reporting structure?

Investment and resources: How much do they invest in security annually? Do they have adequate resources to implement necessary security measures?

Certifications and compliance: What security standards do they follow? When were they last audited?

Incident history: Have they experienced security incidents? How did they handle them?

Technical basics: What encryption do they use? How do they handle access control? What's their patch management process like?

The questionnaire serves a dual purpose: it gathers information you need for assessment and signals to the prospective partner that you take security seriously. It also gives you a clearer picture of their security practices. 

‍

Security certification verification

Certifications like PCI DSS and ISO 27001 provide valuable baseline assurance but are not magic bullets. They tell you a company has implemented certain controls and passed an audit at a specific time, not that they're currently secure.

‍

For any organisation that will be processing card transactions on our behalf, one of the requirements will be that we need to ensure that they're PCI certified, which means that they've implemented a couple of security controls. Olaoluwa Eweje, CISO at Kora

However, verification goes beyond just checking that certificates exist:
‍

Currency: When was the certification issued? When does it expire? Annual renewals are important because security posture can degrade quickly.

Scope: What systems and processes does the certification cover? 

Auditor credibility: Who conducted the audit? Well-known auditing firms generally provide more rigorous assessments than unknown ones.

Report details: Request the actual audit reports rather than just certificates. The details matter as a clean report differs from one with multiple exceptions. Verify everything and don’t leave things to chance. 

‍

Basic dashboard security review for payment processors

Payment processors and financial partners often provide customer dashboards for monitoring transactions and managing your account. These dashboards deserve special attention during the selection phase because they could be the weakest link in an otherwise secure system.

‍

In the past, we've seen some third parties provide us with dashboards that do not have MFA implemented or audit logs implemented. So that means we're not able to tell who did what. Olaoluwa Eweje, CISO at Kora

Your basic dashboard review should check for:

‍

Multi-factor authentication: Is MFA required for all users? Can it be bypassed? What happens if users lose their second factor? 

Access controls: Can you restrict user permissions? Do they support role-based access? Can you limit access by IP address?

Audit logging: Do they track who logs in, when, and what actions they perform? Can you access these logs?

Session management: Do sessions timeout appropriately? Are concurrent sessions allowed? What happens with idle sessions?

Data handling: What data is displayed in the dashboard? Is sensitive information masked or encrypted?

This review doesn't require deep technical testing; you're looking for obvious gaps that indicate poor security practices.

‍

Preliminary risk scoring using standardised formulas

All this information feeds into a preliminary risk score that helps you decide whether to proceed with a partnership.

‍

At Kora, we conduct some sort of evaluation to risk-rate the particular third party, to give them some sort of risk rating, based on what we expect them to have for the kind of services that they're providing.
Olaoluwa Eweje, CISO at Kora

‍

Organisations typically use scoring systems with scales like 1-10, where 10 represents the highest risk. The formula considers multiple factors:

Service criticality weight: Critical services start with a higher base risk score

Security team maturity: Organisations with dedicated security teams receive better scores

Certification status: Current, relevant certifications reduce risk scores

Investment levels: Companies that invest significantly in security score better

Dashboard security: Basic security controls reduce risk for applicable services.

‍

We look at the level of information that you're going to be having access to, because when you're having access to sensitive information, it is very important for us that you've made a significant level of investment to protect that data. Olaoluwa Eweje, CISO at Kora

The preliminary score helps you make go/no-go decisions. Partners who score above your risk threshold either don't proceed or move to a conditional evaluation where they commit to security improvements before you fully onboard them.

Making the selection decision

At the end of this phase, you should have enough information to answer three questions:

1. Does this partner meet our minimum security standards for their service?
2. Are they willing to invest in security improvements if needed?
3. Do the benefits of the partnership justify the security risks?
   ‍

Any organisation that does not see the need to improve on its security practices is a serious red flag for us, and we don't deal. But once we see your responses, we see that okay, you're taking the risk assessment seriously, you appreciate it, and you're looking for ways to improve. Those are the kind of people that we can work with Olaoluwa Eweje, CISO at Kora.

‍

The selection phase isn't about finding perfect partners; it's about finding partners who take security seriously and are committed to continuous improvement. Even if they don't meet all your requirements today, their willingness to invest in security improvements can make them viable long-term partners. 

‍

Phase 2: Contractual agreements and legal protections

You've identified a partner worth working with, but trust alone won't protect you when things go wrong. Now, it’s time for the lawyers to come in and do their thing and turn handshake agreements into enforceable protections that shield your business from third-party risks.

‍

Once we have the risk rating, if we think that you are of low risk to us based on the things that you currently have in your environment, we pass it to the next stage, which basically is contractual agreements. Olaoluwa Eweje, CISO at Kora
‍

The contractual phase isn't just about liability protection; it's about establishing clear expectations, responsibilities, and consequences that align both parties' incentives toward good security practices.

‍

Security and privacy clauses

These clauses form the backbone of your security protection and should go far beyond generic "we take security seriously" language.

‍

Data protection practices need specific definitions: What data will the partner access? How will it be encrypted in transit and at rest? 

‍

Access controls should be clearly specified: Will they implement role-based access? Do they support multi-factor authentication? 

‍

Confidentiality requirements extend beyond just keeping data secret. They should cover how the partner can use your data, whether they can aggregate it with other customers' data, and what happens to derived insights or analytics.

‍

Incident reporting obligations

When a security incident occurs, time is everything. Your contracts need to establish clear notification timelines and procedures that give you the information you need to protect your business.

‍

What happens when there is an incident? Would you notify me when there's a security incident or a breach? How soon would I be notified? Olaoluwa Eweje, CISO at Kora

‍

Service level agreements 

SLAs without enforcement mechanisms are just suggestions. Your contracts need to include uptime guarantees with financial penalties that make downtime expensive for your partners.

‍

Effective SLAs define specific metrics: 99.9% uptime sounds good, but what does it mean? How is uptime measured? What counts as an outage? Are planned maintenance windows excluded?

‍

The penalty structure should reflect the business impact on your organisation. If your payment processor goes down during peak transaction hours, the financial impact is significant, and your penalties should reflect that reality.

‍

Penalty amounts should be proportional to both the service criticality and the impact of the failure.

‍

Audit rights that actually work

Audit rights give you ongoing visibility into your partner's security practices, but they need to be structured to provide meaningful access without being burdensome.

‍

Would they be giving us access to their audit reports and certifications based on requests? The answer should be yes, with clear timelines and scope.

‍

Your audit rights should include things like: regular reporting, on-demand assessments, third-party audits and remediation tracking.

Supply chain responsibilities

Your partner's security is only as strong as its weakest vendor. Contracts need to address how they manage their own third-party risks.

‍

We need our partners to also take responsibility for carrying out third-party security risks for their own suppliers as well, for their own third parties as well. Olaoluwa Eweje, CISO at Kora

‍

This is particularly important in fintech, where attacks often cascade through multiple layers of vendors. Your payment processor might use a fraud detection service that relies on a cloud provider—each link in that chain represents potential risk.

‍

Liability and indemnification

Clear liability assignment prevents disputes and ensures rapid response when security incidents occur. These clauses need to balance protection for your organisation with realistic expectations for your partners.

Common incidents liability clauses address:

• Data breaches caused by partner negligence
• Service outages that impact your business operations
• Compliance violations that result in regulatory penalties
• Third-party claims arising from partner security failures

‍

Compliance requirements

Different industries and regions have varying compliance requirements, and your contracts need to ensure partners meet all applicable standards.

What is their responsibility concerning compliance with relevant standards, such as ISO 27001 and PCI DSS for security and GDPR for data privacy?

‍

For African fintech companies, this might include:

• Local data protection laws (NDPR in Nigeria, POPIA in South Africa)
• Financial sector regulations (Central Bank requirements)
• International standards (GDPR for European customers)
• Industry-specific requirements (PCI DSS for payment processing)

‍

At this stage, your legal team must work closely with your security and compliance teams to ensure contracts support your risk management objectives.

‍

You often see a lot of back and forth, a lot of pushback, probably not on the level of uptime that has been guaranteed, but in terms of the fines. This negotiation process is normal and necessary; partners need to understand you're serious about security requirements. Olaoluwa Eweje, CISO at Kora

‍

The contractual phase sets the foundation for everything that follows. Get it right, and you have strong legal protection and clear expectations. Get it wrong, and you'll discover during a crisis that your contracts don't actually protect you when you need them most.

‍

Phase 3: Onboarding and detailed risk assessment

This is where the real work starts. You've identified a viable partner and signed contracts that protect your interests. But before you start routing real customer data and transactions through their systems, you need to understand what you're dealing with from a security perspective.

‍

Moving from theory to practice

Unlike the broad questionnaire from the selection phase, this assessment drills down into specific technical details. 

‍

This is where you bring in your technical teams. 

‍

We have the application security team also carrying out security testing on the integration, trying to understand the authentication measures that have been implemented, trying to understand if their integration conforms with best practice. Olaoluwa Eweje, CISO at Kora

The testing often reveals gaps between documentation and reality. For payment processors, dashboard security receives particular attention. Cross-check the dashboard security controls again, including MFA implementation, audit logging capabilities, and access controls that actually work.

‍

Risk-based exposure management

Not every partner will meet your full security standards immediately. 

There are some of them that have something significant in place, but there's also a need for serious improvement. There are other ways that we handle partners like that, especially if in markets where it's difficult to find reliable partners providing that particular service that the business needs. Olaoluwa Eweje, CISO at Kora

‍

The solution is conditional onboarding with reduced exposure.

Let's say we're looking for a partner that's going to be processing 10,000 transactions for us. What we need to do within the time frame is to say, okay, let's reduce this volume of transactions to 3,000. Olaoluwa Eweje, CISO at Kora

‍

Technical integration security

This phase includes hands-on testing of authentication mechanisms, API endpoint security, webhook implementations and encryption. The goal is to validate that security controls work in practice, not just on paper. API security testing, data flow mapping, and integration conformance with security best practices happen during this phase.

‍

Generating informed risk ratings

All of this detailed assessment feeds into a much more informed risk rating. 

‍

The risk rating that is being developed at this stage is more informed. The one that is being done at the selection phase is just for us to know whether we can deal with you or not. But the risk rating at this stage has a lot of information that we are tapping into. Olaoluwa Eweje, CISO at Kora

‍

This rating considers not just what security controls exist, but how well they're implemented and whether they actually provide the protection they're supposed to deliver. 

By the end of this phase, you know exactly what you're working with and can make informed decisions about exposure levels and ongoing monitoring requirements.

‍

Phase 4: Termination and offboarding

Think of this phase as the one where you delete your exes’ pictures from your phone and remove them from your Netflix and Spotify accounts. 

Partnerships do come to an end. It could be because of security or because you’re simply switching providers. Whatever the reason, you need to have a proper offboarding framework to protect yourself. 

‍

It is not in all cases that we terminate or offboard our partners. It is rare. Sometimes this comes as a decision from the business, and we don't want to deal with this partner anymore. Or it could mean that there's been some sort of security breach from your end, and then we need to take some actions to terminate the business relationship. Olaoluwa Eweje, CISO at Kora

Offboarding procedures that actually work

When business relationships end, especially under adverse circumstances, you need clear procedures that ensure your data doesn't remain vulnerable in systems you no longer control.

‍

Access revocation across all systems and platforms

This goes beyond simply deactivating user accounts. 

What happens in this stage is to revoke all the access they used to have. Revoke API keys, disable webhook endpoints, and invalidate any integration credentials. 

The challenge is that many integrations involve multiple access points. Identify and revoke them all.

‍

Data inventory and custody verification‍

Before demanding data deletion, you need to understand exactly what data the partner has.

‍
It’s so important to confirm the kind of data that the partner has been processing or that they have in their custody. It could be your data or your customers' data. Olaoluwa Eweje, CISO at Kora

‍

This inventory should cover not just obvious data points like customer records and transaction histories but also derived data, analytics, logs, and backups. Many partners retain more data than you might expect, and some of it might be in unexpected forms.

‍

Mandatory data deletion with evidence requirements

Simply asking partners to delete your data isn't sufficient.

We carry out an offboarding review basically to ensure that whatever data is in your custody has been deleted the right way, and we request evidence of that. Before demanding data deletion, you need to understand exactly what data the partner has. Olaoluwa Eweje, CISO at Kora

The evidence requirements should be specific: certificates of destruction for physical media, detailed logs showing data purging from databases, and confirmation of backup deletion. In addition, the evidence needs to be verifiable and auditable. A simple email saying "we've deleted your data" doesn't provide adequate assurance that they did. 

‍

Final security assessment and relationship review

This review should document what went right and wrong in the relationship, identify any security issues that emerged, and capture lessons that can improve future partner selection and management.

‍

Triggers for termination

Understanding when to end partnerships is as important as knowing how to end them properly. These are some situations in which you should consider terminating a partnership. 

‍

Security breaches or incidents demonstrating negligence

Not every security incident requires termination, but incidents that demonstrate fundamental negligence or lack of commitment to security might leave you no choice. The key is having clear criteria in your contracts for what constitutes grounds for immediate termination.

‍

Failure to meet contractual security obligations

This includes missing security improvement deadlines, failing to maintain required certifications, or persistently ignoring security requirements despite repeated warnings.

‍

Business decision to change service providers

Sometimes termination isn't about security failure but about changing business needs, cost considerations, or strategic direction. Even planned terminations require careful offboarding to protect your data.

‍

Persistent non-compliance with security requirements

You might need to terminate your relationship with partners who consistently fail to meet security standards, miss improvement deadlines, or resist implementing necessary controls despite providing unsatisfactory service.

‍

Making termination work in practice

The termination process needs to balance speed with thoroughness. Security-related terminations might require immediate action to protect your business, while planned transitions can follow more deliberate timelines.

‍

Document your termination procedures to prevent confusion and ensure nothing falls through the cracks during a stressful time. Your legal, security, and business teams all need to understand their roles and responsibilities when relationships end. 

‍

The goal of proper offboarding isn't punishment; it's protection. Even when partnerships end on good terms, you need assurance that your former partner handles your data properly and you’re not vulnerable to future incidents from them.

‍

Conclusion

Third-party risk management isn't optional for fintech companies. You need it whether you're a unicorn or an early-stage startup. Trust is difficult to gain and easy to lose, and a third-party breach can destroy your reputation and business overnight.

‍

If you don't have a third-party risk management framework, you'll find yourself unprepared when attackers strike. And they will, because hackers constantly look for loopholes in systems, especially through vulnerable third-party connections.

‍

That's why the framework in this guide matters. The five phases (selection, contracting, onboarding, monitoring, and termination) provide a systematic approach that scales with your business and addresses each stage where vulnerabilities can emerge.

‍

The question isn't whether you'll face third-party security challenges, but whether you'll be prepared for them. Don't wait for hackers to exploit your third-party relationships. Use this guide to build a framework that protects your business and keeps your customers' trust intact.

‍

‍

‍