For years, cybersecurity in the financial sector was mainly a matter of supervisory guidelines, internal policies and best practices. They were considered important, but scattered across different frameworks and supervisors, they simply weren’t working effectively.
That has changed since January 2025. Starting from then, the Digital Operational Resilience Act (DORA) is in full effect and applies to a range of financial entities across the European Union. Think banks, insurers, investment firms, payment institutions, crypto-asset service providers and many others. All those different institutions now share one common rulebook for managing digital risk.
At the same time, NIS2 is raising the bar for cybersecurity in a much broader range of sectors, from energy and healthcare to digital infrastructure and public administration.
Two European regulations, both focused on resilience. So what exactly is the difference? Which one applies to your organization? And what does it mean if you are an ICT provider serving the financial sector?
From cybersecurity to operational resilience
DORA starts from a simple observation: financial services have become digital services.
- Payments
- Trading
- Claims handling
- Customer onboarding
- …
Almost every critical process depends on ICT systems, networks, cloud platforms and external providers. A disruption in one of those links quickly affects clients and markets. And, in the worst case, financial stability as a whole.
That is why DORA does not only ask whether an organization is protected against cyberattacks. It asks a broader question:
“Can you continue to deliver your critical services when something goes wrong?”
The focus shifts from prevention alone to the ability to withstand and recover from disruptions. Whether they are caused by a cyberattack, a technical failure or a problem at a third-party provider.
The six pillars of DORA
DORA is built around six pillars.
- ICT risk management: a documented framework, approved by the management body, to identify, protect, detect, respond and recover.
- ICT-related incident management and reporting: classifying incidents and reporting major ones to the competent authority, using harmonised templates.
- Digital operational resilience testing: regular testing of systems and, for selected entities, advanced Threat-Led Penetration Testing (TLPT) at least every three years.
- ICT third-party risk management: a complete register of information on all ICT contractual arrangements, mandatory contract clauses and exit strategies.
- Information sharing: voluntary exchange of cyber threat intelligence between financial entities.
- Oversight of critical ICT third-party providers: direct European supervision of the technology providers the financial sector depends on most. More on that later.
DORA is a regulation, supported by a large set of regulatory and implementing technical standards (RTS and ITS). These specify in detail how incidents must be classified, what the register of information should contain and how Threat-Led Penetration Testing (TLPT) has to be performed.
DORA and NIS2: same ambition, different approach
Anyone who has worked on NIS2 will recognize many of these themes. Risk management, incident reporting, supply chain security and management accountability are focal points in both.
That is no coincidence. Both regulations were developed as part of the same European strategy to raise the level of digital resilience across the European Union.
But there are important differences:
- Legal form: NIS2 is a directive, so each Member State turns it into national law. In Belgium, that is the NIS2 law, supervised by the CCB. DORA is a regulation, so it applies directly and in the same way in every Member State. National financial supervisors enforce it, such as the NBB and FSMA in Belgium, coordinated at EU level by the European Supervisory Authorities (EBA, EIOPA and ESMA).
- Scope: NIS2 covers essential and important entities in a wide range of sectors. DORA focuses specifically on the financial sector and its ICT providers.
- Level of detail: NIS2 defines what needs to be achieved. DORA, through its technical standards, also defines in much more detail how.
- Testing: NIS2 requires organizations to assess the effectiveness of their measures. DORA goes further, with a formal testing programme and TLPT for the most significant entities.
- Third parties: NIS2 requires attention to supply chain security. DORA turns that into concrete obligations: a register of information, mandatory contractual provisions, concentration risk analysis and exit plans.
Which one applies: DORA or NIS2?
For financial entities, the answer is simple. DORA is the specific law for their sector, so it takes priority over NIS2. For banks, insurers and other entities under DORA, its rules replace NIS2 wherever the two overlap: ICT risk management, incident reporting, testing, information sharing and third-party risk.
In practice, that means a bank or insurer does not have to comply with two parallel sets of cybersecurity obligations.
But the story does not end there.
An organization can be part of a financial group that also has non-financial activities falling under NIS2. And many ICT providers serving the financial sector, such as cloud providers, data centres and managed security service providers, are themselves covered by NIS2 as essential or important entities.
For them, both worlds come together. They have to meet NIS2 requirements for their own organization, while their financial clients expect DORA-level contractual commitments, audit rights, reporting and exit support.
Incident reporting: the clock ticks faster
Incident reporting is one of the clearest differences between the two. Under NIS2, a significant incident needs an early warning within 24 hours, a notification within 72 hours and a final report within one month.
DORA is stricter at the start. For a major ICT-related incident, the initial notification is due within 4 hours of classifying it as major, and no later than 24 hours after becoming aware of it. An intermediate report follows within 72 hours and a final report within a month.
Classification has to happen fast. It’s based on criteria such as clients affected, data losses, duration and the criticality of the services involved. That speed calls for clear roles, reliable monitoring and a team ready to act around the clock.
A single EU cybersecurity incident reporting point for NIS2, DORA and GDPR has been proposed as part of the Digital Omnibus (a legislative package of the European Commission). Even so, the timelines and criteria stay the same.
Third-party risk: where DORA really makes a difference
If there is one area where DORA goes clearly beyond NIS2, it is the management of ICT third-party risk.
Financial entities remain fully responsible for their compliance, even when they outsource services. Handing a service over to a provider does not mean handing over the responsibility.
DORA translates that into a set of concrete questions:
- Which ICT providers support critical or important functions?
- Is every contractual arrangement recorded in the register of information?
- Do contracts contain the mandatory provisions on service levels, security, audit rights and termination?
- How dependent are we on one provider, or on a small group of providers?
- Which subcontractors are involved further down the chain?
- Is there a realistic exit strategy if a provider fails or has to be replaced?
That last question deserves particular attention. For ICT services supporting critical or important functions, DORA explicitly requires exit strategies that are documented and tested.
Anyone who has read our earlier articles on digital sovereignty will recognize this reasoning. Insight into dependencies, portability, open standards and a well-considered exit strategy are not only building blocks for sovereignty. Under DORA, they have become regulatory obligations for the financial sector.
Europe supervises the critical providers directly
DORA also introduces something that NIS2 does not: a European oversight framework for critical ICT third-party providers (CTPPs).
The reasoning behind it is clear. A large part of the financial sector depends on a limited number of technology providers. If one of them runs into trouble, the impact can spread across hundreds of financial institutions at the same time.
On 18 November 2025, the European Supervisory Authorities published the first list of 19 designated CTPPs. It includes major cloud providers, data center operators, IT service companies and financial data providers.
These providers are now subject to direct oversight, including inspections, information requests and recommendations.
For financial entities, this oversight is additional. It does not replace their own obligation to manage the risks of the providers they rely on.
Two regulations, one direction
For many financial entities, the first DORA deadlines are behind them. Frameworks have been approved, registers have been submitted and incident procedures have been drafted.
But DORA is not a project with an end date. It is a continuous obligation. Supervisors are now shifting from checking whether documents exist to checking whether they actually work in practice.
DORA and NIS2 differ in scope, legal form and level of detail. But they share the same message.
Digital resilience is no longer an IT topic. It is a governance responsibility. And it’s one that is never fully finished.
Organizations are expected to know their dependencies, manage their risks, test their defences and respond quickly when something goes wrong. Not once, but continuously.
Organizations that approach DORA and NIS2 as one integrated resilience programme, rather than two separate compliance exercises, will benefit the most. Less duplication, more insight and a clearer view of what really matters.
Resilience is not defined by the number of policies you have written. It is defined by how well your organization keeps functioning when it really counts.
Want to know where your organization stands on DORA or NIS2?
Our experts help you map your current situation, identify the gaps and define the steps that deliver the most value.
