Two EU regulations have teeth that reach beyond the EU’s borders. DORA and NIS2. If you’re an African fintech with European customers, European partners, or European third-party providers, they probably apply to you, and a lot of teams don’t realise it until a partner’s procurement team asks for evidence.
This is the plain-language version. What each one covers, how the extraterritorial reach works, and the practical things to put in place.
The Digital Operational Resilience Act governs how financial-services entities withstand, respond to, and recover from ICT disruptions. It applies to banks, payment institutions, e-money firms, investment firms, crypto-asset providers, and the ICT providers that serve them.
The core obligations are operational resilience, not paperwork for its own sake. You need an ICT risk management framework. You need to report major incidents to regulators on a defined timeline. You need to manage the risk your third-party ICT providers introduce. You need to test your resilience, including threat-led testing for the larger entities. And accountability sits with the management body, not buried in a technical team.
The NIS2 Directive raises the cybersecurity baseline for operators of essential and important services across the EU. The sectors are broad: energy, transport, banking, financial market infrastructure, health, digital infrastructure, ICT service management, public administration, and more. Many digital and managed service providers fall in scope.
The obligations centre on risk management measures and incident reporting. Covered entities must implement appropriate security measures, report significant incidents, manage supply-chain risk, and put cybersecurity governance at management level with accountability that can’t be delegated away.
This is the part teams miss. Neither regulation stops at the EU’s geographic edge.
If you provide ICT services to an EU financial entity, DORA reaches you through your customer. The EU entity is required to manage and contractually bind its third-party providers, which means the obligations flow down to you in the contract whether or not you’re EU-based. A Lagos fintech providing a payments service to a European bank is a third-party ICT provider in DORA’s eyes.
NIS2 works similarly through supply-chain risk requirements and through any establishment or service provision in the EU. If you serve EU customers in a covered sector, or you’re the provider an in-scope entity depends on, the directive’s expectations land on you through the relationship.
In practice you usually discover this not from a regulator but from a customer’s procurement or risk team handing you a questionnaire and a set of contractual clauses. Being unable to answer it costs you the deal.
A few concrete things appear across both regimes.
Incident reporting on a clock. Expect a tiered timeline: an initial notification within around 24 hours of detecting a major incident, an intermediate report within around 72 hours, and a full report later once the situation is understood. Your incident process has to be able to hit those windows, which means detection, triage, and a reporting path that’s rehearsed, not improvised.
Third-party risk management. You maintain a register of your own ICT suppliers, assess their risk, and hold contractual rights around security and continuity. The regulation that binds your customer expects them to see this in you.
Board-level accountability. A named person responsible for ICT risk, and a management body that’s informed and answerable. This is explicit. Cyber risk is a leadership responsibility, reported on a cadence, not a thing the CTO handles alone in the background.
ICT testing. Regular vulnerability assessments, and for larger or more critical entities, threat-led penetration testing that simulates real attacker behaviour against production-like systems.
You don’t need a compliance department on day one. You need a credible, evidenced baseline.
Document your controls. Write down how you manage access, encryption, logging, backups, and incident response, and map each control to evidence you can actually produce. “Show me” is the test these regimes apply.
Build a supplier register. List your ICT third parties, what data or access each has, and the risk each represents. This satisfies the third-party requirement and it’s genuinely useful for your own resilience.
Write and test an incident response plan. Define roles, escalation, and the regulatory reporting timeline. Run a tabletop exercise so the 24-hour clock isn’t the first time anyone tries to follow it.
Set a board reporting cadence. Name an ICT risk owner. Report posture to leadership on a regular schedule, and keep the minutes as evidence.
Run your testing. Vulnerability scans on a cadence, and penetration testing scaled to your size and criticality, with findings tracked to closure.
None of this is as frightening as the acronyms suggest. The obligations are, broadly, the security and resilience practices a serious fintech should have anyway. The regulations just make them explicit and demand evidence.
The strategic risk is in ignoring it. As more African fintechs sell into Europe, the ability to answer a DORA or NIS2 questionnaire becomes a precondition for the deal. The firms that can map controls to evidence win the European business. The ones that can’t get filtered out in procurement before anyone looks at the product.
We help clients do exactly that mapping: controls to evidence, gaps to a remediation plan, in a form a European partner’s risk team will accept. Our cybersecurity team runs this end to end. If you’ve been handed a questionnaire and aren’t sure how to answer it, request a quote and we’ll scope the work to get you to a credible, evidenced position.