KENNIS BLOG
DORA: the digital backbone of the financial sector
13 march 2026
Background
Today the entire financial sector runs on ICT: payments, trading, lending, and investment services are fully dependent on stable digital systems. Because of the strong interconnectedness of more than 22,000 financial entities, local incidents can spread across borders at lightning speed, leading to large-scale disruptions and loss of confidence in the system. After the 2008 economic crisis, the focus was mainly on capital and solvency, while the digital infrastructure received relatively little attention.
That changed when the European Banking Authority (EBA), the European Insurance and Occupational Pensions Authority (EIOPA), and the European Securities and Markets Authority (ESMA) advised to create a single, sector-specific European framework for digital operational resilience. The previous patchwork of national rules caused fragmentation within the EU, higher compliance costs for all involved, and above all: inconsistent requirements for testing resilience and monitoring third-party ICT providers.
DORA aims to change that with a single common rulebook that places stability, market integrity, and consumer protection at its core. In this article, we guide you through the regulation’s main building blocks, its impact on different types of institutions, and the new reality for critical ICT service providers such as Amazon Web Services, Google Cloud, Microsoft, and Equinix.
What exactly is DORA?
DORA (the Digital Operational Resilience Act) is an EU regulation that has been in force since January 2025 and is directly applicable in all Member States. The rules apply to a broad range of financial entities, including banks, insurers, payment institutions, investment firms, and crypto service providers. Instead of having scattered rules on ICT risks, DORA consolidates all requirements into a single, integrated framework for digital operational resilience.
DORA was deliberately designed as a regulation rather than a directive to promote harmonization and limit national divergences. In the Netherlands, DORA also acts as a lex specialis in relation to the Network and Information Security 2 Directive (NIS2 Directive): for financial entities, the DORA rules on ICT risk take precedence over the general Cybersecurity Act and other laws, regulations, or decisions that overlap with it. This prevents institutions from facing conflicting requirements regarding cybersecurity and incident reporting.
The five pillars of DORA
DORA is built on five interrelated pillars that together are designed to ensure digital resilience. These pillars are further elaborated in the regulation through technical regulatory and implementing standards. So far, seven such technical standards have been issued, the list below reflects the current state of play. As things stand now, the framework looks as follows:
An integrated ICT risk management framework
Financial entities are required to have a solid, comprehensive, and well-documented framework for ICT risk management.
- RTS on Risk management: these technical standards specify how institutions must structure, monitor, and control their ICT risks, with a simplified regime for smaller entities.
- RTS on ICT services performed by ICT third-party providers: Specifies the detailed content of policy requirements for contractual arrangements regarding ICT services supporting critical or important functions provided by ICT third-party service providers.
Incident detection and reporting obligations
Financial entities must establish processes to detect, manage, and record ICT-related incidents. Major incidents must be mandatorily reported to the competent authorities within strict deadlines using harmonised templates.
- RTS on Classification of ICT incidents: these technical standards define when an ICT incident qualifies as “major” and must therefore be formally reported to the supervisor.
- RTS on Incident reporting: these technical standards set out which information institutions must provide at each stage of a major ICT incident and how voluntary threat notifications are handled.
Testing digital resilience
To identify vulnerabilities in security, entities must regularly test their systems and personnel. The testing level depends on the size and importance of the institution and the associated risk profile.
- RTS on TLPT testing: these technical standards establish rules for the design, execution, and follow‑up of threat‑led penetration testing at significant institutions.
Managing third‑party and outsourcing risks
Strict rules apply to managing risks arising from reliance on external ICT providers. Contractual agreements must include requirements such as audit rights and exit strategies. Additionally, a specific oversight framework is established for providers designated as "critical".
- RTS on Outsourcing: these technical standards prescribe the minimum policies and contractual terms required when outsourcing critical or important ICT services.
- RTS on Critical ICT service providers: these technical standards harmonize how European supervisory authorities jointly exercise oversight over ICT service providers designated as “critical.”
Information sharing
Financial entities are encouraged to voluntarily exchange information and intelligence on cyber threats within trust communities. By sharing tactics, techniques, and warnings, institutions can limit the spread of threats and strengthen their collective defense capabilities.
ICT risk management framework and inventory
Under DORA, the management body bears full responsibility for managing ICT risks. Board members must approve policies for ICT business continuity, response, and recovery plans, ensure they are periodically evaluated, and actively oversee their implementation. They must also demonstrate that sufficient budget and skilled personnel are available to meet all requirements.
In addition, board members have a legal obligation to maintain their knowledge of ICT risks through specific training programmes. This makes digital resilience an explicit board‑level responsibility rather than a purely IT matter. In practice, this means that, for example, a medium‑sized bank cannot rely solely on an annual report from the Chief Information Security Officer (CISO); board members should be able to ask and answer concrete questions about patch management, IT backup strategies, and dependencies on potential cloud providers. DORA does not specify what the minimum level of this knowledge should be, or how often “regular” means. Must a board member be able to discuss encryption in technical detail, or is a general understanding of cyber risks sufficient? These open standards will need to be defined in practice over time.
Every financial institution must have a sound, comprehensive, and documented ICT risk management framework. A person responsible for managing and overseeing the ICT risk policy must be designated, with sufficient independence to avoid conflicts of interest. This framework is subject to periodic internal audits, with the frequency and depth aligned to the institution’s risk profile.
An important step within this framework is the inventory of functions and assets. Institutions must map all ICT‑supported functions, processes, information, and ICT assets, including interdependencies. This explicitly includes identifying critical or important functions and the third parties on which they depend. A function is critical if a disruption would cause material prejudice to the institution’s financial performance or continuity. Institutions must determine for themselves the threshold at which a process becomes “critical,” or what constitutes “material prejudice.” For a payment service provider that processes transactions via a data centre, it can be said that a disruption in that data centre could cause material prejudice to a critical process of that financial institution. Whether this also applies to data analyses running on Google’s cloud services remains to be seen. Institutions will always need to assess what is critical and what is not. Both types of dependencies will ultimately be clearly documented and categorized.
Security, continuity, incidents, and testing
DORA requires a consistent information security policy that ensures the availability, integrity, and confidentiality of data. This includes preventive measures (logical and physical security, access controls, patch management policies), detection mechanisms for anomalies and incidents, and a detailed ICT continuity policy with concrete response and recovery plans. Financial institutions must establish processes to classify and log ICT incidents. Major ICT‑related incidents must be reported to the competent authorities according to a prescribed process. For certain entities (e.g., credit institutions, payment institutions), payment‑related operational or security incidents also fall under this reporting obligation, even if they are not directly ICT‑related.
In addition, DORA mandates periodic testing of digital operational resilience, at minimum for all critical and important ICT systems. For most institutions, regular tests such as vulnerability scans, scenario tests, and failover tests are sufficient. Institutions that are considered to be systemically important or highly ICT‑intensive must conduct advanced threat‑led penetration tests (Threat‑Led Penetration Testing, TLPT) at least every three years. This could mean, for example, that a major bank has its cloud environment at Microsoft or Amazon tested through a simulated attack, including the response capacity of internal teams.
Third parties, outsourcing, and CTPPs
Third parties and outsourcing in general
Institutions must have a clear strategy and policy for engaging external ICT providers, especially for critical or important functions. All such contracts must be recorded in an internal register, including whether the service supports a critical or important function.
An ICT service provider cannot simply subcontract to anyone. Contracts must include several minimum requirements enabling the ICT service provider to demonstrate that the subcontracted party has sufficient expertise and capability. For example, when outsourcing ICT functionalities that may be considered critical or important, the ICT service provider must contractually ensure unrestricted access for inspection by both the service provider itself, the financial entity, and the competent authority. This may even involve on‑site visits to verify the outsourced services. This naturally raises questions about the negotiating power of financial institutions vis‑à‑vis major players. It remains unclear how an institution can meet this strict legal requirement if the provider refuses to deviate from its standard contracts.
What is a CTPP?
A Critical Third‑Party Provider (CTPP) is an external ICT service provider designated as critical by the European supervisory authorities. This designation is based on criteria such as the potential systemic impact of a disruption, the degree of dependency of financial institutions on the provider, and the substitutability of the service provided. The more difficult it is to switch to an alternative, the more likely a provider is to be considered critical.
The first designations took place on 18 November 2025. This list of CTPPs includes, among others, Accenture, Amazon Web Services, Google Cloud, Microsoft Ireland Operations, SAP SE, Equinix B.V., and Kyndryl Inc. In practice, this means that a large part of the European financial sector relies on a limited number of players for cloud services, data analysis, core banking systems, and infrastructure. A disruption or security incident at, for example, Microsoft or Amazon could therefore immediately affect thousands of banks, insurers, and payment institutions simultaneously.
CTPPs feel the regulatory pressure
CTPPs face regulatory pressure under DORA for several reasons. First, they concentrate the risks of the entire sector: as cloud platforms or data centre providers for many systemically important institutions, they bear a disproportionate share of operational risk. An incident at a CTPP such as Google Cloud, Microsoft, or Equinix immediately affects hundreds or thousands of customers, increasing the likelihood of intervention by the Lead Overseer (a European supervisor) and national authorities.
Second, CTPPs are not only addressed through contractual requirements from their financial clients but also directly by European supervisors. They must provide intensive reporting, extensive documentation, cooperate with on‑site inspections, disclose sub‑outsourcing structures, and follow recommendations that may deeply impact their technical architecture and business model.
Third, these are often global players with uniform infrastructure; measures needed to comply with DORA can have domino effects on services in other regions and lead to significant costs. This creates ongoing tension for CTPPs between economies of scale, commercial interests, and compliance with European oversight that has designated them as systemically critical.
Oversight framework, obligations, and sanctions
CTPPs are subject to a specific European oversight framework. One of the three European supervisors (EBA, EIOPA, or ESMA) acts as the Lead Overseer and exercises direct supervision over the CTPP. The CTPP must provide all requested information and cooperate with inspections, including on‑site investigations at offices and data centres, even outside the EU if local authority’s consent.
A CTPP established outside the EU must establish an EU subsidiary within twelve months of designation to continue providing services to EU institutions. If the CTPP is part of a group, one legal entity must be designated as the central point of contact for the Lead Overseer. The CTPP must pay a fee to cover supervision costs and cooperate in good faith with all investigations and requests.
In cases of serious or persistent non‑compliance, the Lead Overseer may impose stringent measures. Options include periodic penalty payments of up to 1% of global average daily turnover, public disclosure of the breach and the provider’s identity, and as a last resort: requiring national supervisors to terminate or temporarily suspend contracts. Imagine structural shortcomings at a global cloud provider like Amazon or Microsoft are not resolved in time; in that scenario, a supervisor could compel financial institutions to rapidly reduce their dependency or even force them to terminate contracts, temporarily or otherwise.
The first round of reporting on critical third parties will take place in the first months of 2026. If this reveals that other ICT providers are responsible for a significant portion of critical systems for EU firms, those parties are also likely to be designated as Critical Third‑Party Providers in the future, with all the consequences that entails.
Information sharing
DORA encourages financial entities to voluntarily share cyber threat intelligence, such as IOCs (Indicators of Compromise), tactics, techniques, procedures, warnings, and configuration tools. This strengthens digital operational resilience by enabling faster threat detection, limiting their spread, and enhancing defence capabilities. The exchange takes place within trust communities of financial entities, with strict safeguards for confidentiality, data protection in accordance with the General Data Protection Regulation (GDPR), and compliance with competition rules.
Participating financial entities jointly establish voluntary arrangements, protocols, or agreements that set out the participation conditions, including any roles for government authorities or ICT service providers. Financial entities must promptly notify their competent supervisors, such as the AFM or DNB, once a trust community has approved their participation application following an internal assessment procedure. This notification obligation also applies upon termination of participation.
What does DORA mean for micro‑enterprises?
DORA provides an explicitly simplified framework for micro enterprises. These are financial entities with fewer than 10 employees and annual turnover or total assets of no more than €2 million. The principle remains that the management body is ultimately responsible for ICT risks.
Micro‑enterprises must have an ICT risk management framework but do not need to evaluate it annually, a periodic review is sufficient. They are exempt from comprehensive internal audits of the framework and do not need to designate a separate function to oversee third‑party contracts. Incident reporting obligations remain, but thresholds and information requirements must be proportionate. Micro‑enterprises are also fully exempt from TLPT-testing. They are required to conduct regular tests (such as scans or questionnaires) but may determine the frequency and type of test themselves based on their risk profile and available resources. They must therefore make a “reasonable judgment” between achieving high resilience and their available resources when testing. This is a highly subjective balance that will only be assessed by a supervisor retrospectively.
In practice, this could mean that a small FinTech start‑up using cloud services from Google or Microsoft, must be able to demonstrate a basic ICT risk management framework from day one during a licence application. At the same time, they are given breathing room through lighter audit and testing requirements, provided they properly understand and manage their dependency on major CTPPs.
Cybersecurity Act for non‑DORA companies
For organisations not covered by DORA, the Dutch Cybersecurity Act (Cbw), the implementation of the NIS2 Directive—provides the general framework for digital security. The Act applies to medium‑sized and large enterprises in vital sectors such as energy, transport, healthcare, drinking water, digital infrastructure (including data centres and cloud providers), wastewater, postal and courier services, chemicals, food supply chains, space, research, and various manufacturing industries. Generally, this concerns enterprises with more than 50 employees and annual turnover or total assets exceeding €10 million, although certain entities always fall under the Act regardless of size.
The Cybersecurity Act imposes three key obligations: a duty of care for appropriate security measures, a strict reporting obligation for significant incidents, and explicit management responsibility. Incidents must be reported to the supervisor and the Computer Security Incident Response Team (CSIRT), with deadlines of 24 hours for an early warning, 72 hours for a full notification, and a final report within one month. Board members must receive training on cyber risks and may be held personally liable in cases of serious negligence. Non‑compliance can result in fines of up to €10 million or 2% of global annual turnover for essential entities, and €7 million or 1.4% for important entities.
A data centre operator that is not a financial entity but provides critical infrastructure to banks and insurers may therefore fall under the Cybersecurity Act, while its clients fall under DORA.
Conclusion
DORA and the Cyber Security Act together form the new digital foundation of the European financial system: continuity, resilience to incidents, and managing dependencies on third parties have become integral parts of prudent business governance. For financial entities, this means that governance, ICT risk management, processes of incidents, testing of ICT resilience, and handling critical third-party ICT providers are no longer standalone technical topics, but closely interwoven pillars that must demonstrably be in order. DORA promotes voluntary information sharing on cyber threats within trust communities to strengthen sector-wide digital resilience, with strict safeguards for confidentiality, GDPR, and competition rules; participating entities establish participation conditions in joint agreements and must promptly report approval or termination to supervisors such as the AFM or DNB.
Micro-enterprises receive a simplified framework but remain bound by the same core principles: the board is ultimately responsible, they must be a basic ICT risk framework is, and incidents must be reported accordingly. Thus, DORA is not only intended for large systemically important banks but is a framework that affects the entire breadth of the financial sector, from fintech startups to established institutions.
Critical Third-Party Providers are in a unique position, as they simultaneously form the digital backbone of the sector, are directly subject to European supervision, and are often globally active. Measures needed to comply with DORA can have a domino effect on their services in other regions and lead to significant costs increases. They will also encounter DORA through various contractual relationships, as financial institutions are required to make their contracts DORA-compliant. These major players an enormous regulatory pressure.
Ultimately, DORA is best read as a principles-based framework rather than a rigidly detailed handbook. The regulation provides structure and minima but remains unclear on key points and uses many subjective concepts, such as "critical or important functions", "appropriate" measures, and "proportional" requirements. Even after the introduction of technical standards some ambiguity remains. Organisations will need to give meaning these open norms. Practical experience and dialogue with supervisors will determine what is considered sufficient. Entities engaging in serious governance and risk management in collaboration with ICT providers are unlikely to face issues from supervisors. Moreover, they build a robust foundation for the institution's operational resilience. In conclusion: operational resilience is not just another IT issue but forms the core of sound entrepreneurship and system protection within the EU.
Do you require legal assistance?
Click below to get in touch.
