EU Regulation 2022/2554, known as DORA (Digital Operational Resilience Act), has been applicable since 17 January 2025. No grace period, no national transposition: unlike NIS2, which is a directive, DORA is a regulation that applies directly and uniformly across all 27 EU Member States from its entry into force.
For a CIO at a financial institution, this distinction is fundamental. Your ERP, if it supports critical functions, falls within the supervisory scope. And your contract with your vendor must contain clauses that the majority of agreements signed before 2024 simply do not include.
This guide takes stock of the compliance obligations in 2026, eighteen months after the regulation came into force.
DORA at a Glance: Who Is Affected and Since When?
Regulatory Scope: 21 Categories of Financial Entities
DORA covers 21 categories of entities defined in Article 2 of the regulation. The scope is broad: credit institutions, investment firms, insurance and reinsurance undertakings, asset management companies, payment service providers, electronic money institutions, licensed crypto-asset service providers, market infrastructures (central counterparties, central securities depositories), and regulated fintechs (source: EUR-Lex).
Smaller entities benefit from a simplified framework under Article 16, but the core requirements — ICT risk mapping, vendor register, contractual clauses — remain mandatory for all.
Application Date: 17 January 2025, With No Tolerance Period
The European Supervisory Authorities (EBA, ESMA, EIOPA) confirmed entry into force on 17 January 2025 without a formal grace period. The year 2025 served as a phase of auditing and documentary requirements. In 2026, supervisory authorities across the EU moved to in-depth controls.
If your institution has not yet finalised its ICT Register of Information or updated its contracts with critical ICT providers, you have technically been non-compliant for more than a year.
What DORA Is Not: A Generic Directive Like NIS2
NIS2 is a directive: each Member State has transposed it (or not, within the deadlines) into its national law. DORA is a regulation: it applies directly, uniformly, throughout the European Union. No national variation, no transposition deadline, no “wait for implementing measures.”
Moreover, DORA is sector-specific and prescriptive. It does not merely set resilience objectives; it defines concrete mechanisms: notification deadlines down to the quarter-hour, minimum test frequencies, a mandatory list of contractual clauses.
Is Your ERP a “Critical ICT Third-Party Provider” Under DORA?
When an ERP Becomes a Critical ICT Service
DORA draws a distinction between two levels in ICT contracts:
- Standard contracts: any ICT provider, regardless of the importance of the service supplied.
- Critical or important functions: ICT services where, in the event of disruption, the financial entity’s regulatory obligations or essential activities are directly compromised.
A financial ERP managing general ledger accounting, regulatory reporting (COREP, FINREP for banks), or settlement processing generally meets the “critical or important function” criterion. In that case, the reinforced contractual requirements of Article 30 of the regulation apply in full.
Major Vendors Facing DORA Concentration Criteria
DORA introduces a concept new at the European scale: the direct supervision of “Critical Third-Party Providers” (CTPPs) designated at European level by the ESAs (EBA, ESMA, EIOPA). These providers are subject to oversight by a “lead overseer.”
In practice, the first hyperscalers (AWS, Microsoft Azure, Google Cloud) were designated in this category in 2025–2026. SAP S/4HANA Cloud, Oracle NetSuite, Microsoft Dynamics 365 Finance, and other SaaS ERPs rely heavily on these infrastructures. Your “ERP vendor” is therefore not simply your direct counterpart: the subcontracting chain runs all the way to the hyperscalers.
The Cascading Subcontracting Challenge
Article 28(2) of DORA requires financial entities to identify and document the full subcontracting chain of their critical ICT providers. If your SaaS ERP runs on AWS and AWS subcontracts part of its infrastructure to an N+2 tier provider, this information must appear in your ICT register.
Ask your ERP vendor for the list of its critical subcontractors. If this list does not exist or is not kept up to date, that is a DORA non-compliance on your side — not solely the vendor’s responsibility.
The 5 DORA Pillars That Directly Affect Your ERP
DORA is structured around five pillars. Here is how each one translates into concrete action for ERP management.
1. ICT Risk Management (Articles 5 to 16)
The management body of the financial entity bears personal responsibility for approving and overseeing the ICT risk management framework (Article 5). This is not a topic that can be delegated solely to the CISO. For the ERP, this means:
- Identifying critical business processes that depend on the ERP (period-end close, regulatory reporting, payment processing).
- Mapping the ICT assets associated with those processes.
- Defining formally documented RTO (Recovery Time Objective) and RPO (Recovery Point Objective) targets.
- Testing continuity at a minimum annually.
2. ICT Incident Management (Articles 17 to 23)
DORA imposes a harmonised notification regime for major ICT incidents. Deadlines are strict: initial notification to the competent authority within 4 hours of incident classification (and no later than 24 hours after detection), an intermediate report at 72 hours, and a final report within one month.
An incident affecting your accounting ERP or payment module can trigger this obligation. Do you have an ICT incident classification process that distinguishes minor events from major incidents under DORA? Most institutions realise in 2026 that they have no formalised criteria.
Classification thresholds include a service interruption exceeding 2 hours, an impact on more than 10% of clients, or an economic loss exceeding €100,000.
3. Digital Operational Resilience Testing (Articles 24 to 27)
All entities must conduct resilience testing at a minimum once per year. For significant entities (systemically important institutions identified by the EBA or ESMA), Threat-Led Penetration Testing (TLPT) is mandatory every three years.
A TLPT is a red-team exercise simulating a realistic attack on production systems. If your ERP falls within the systemic scope, it may be included in this test. Anticipate this with your vendor: has it already participated in a TLPT for a financial client? Does it maintain security documentation accessible to a mandated testing provider?
4. ICT Third-Party Risk Management (Articles 28 to 44)
This is the most operational pillar for a CIO. It requires:
- An ICT Register of Information documenting all ICT provider contracts, with granularity on subcontractors. This register is transmitted annually to supervisory authorities.
- Mandatory contractual clauses (Article 30) for all ICT providers, reinforced for critical functions.
5. Information Sharing on Cyber Threats (Article 45)
Sharing is voluntary, but DORA encourages financial entities to join sector-specific threat intelligence groups (ISACs). The European financial sector has dedicated structures. This is an increasingly scrutinised signal of maturity during supervisory audits.
What You Must Demand from Your ERP Vendor in the Contract (Article 30 Clauses)
Article 30 of DORA lists the mandatory clauses for any contract with an ICT provider supporting critical or important functions. If your current contract does not include them, you must negotiate an addendum.
Full audit rights. Your institution must have a direct audit right over your ERP vendor’s premises, systems and processes — or via an independent third party mandated by you. A simple SOC 2 report provided by the vendor is insufficient: the right to active audit is required.
Availability SLAs with contractual RTO/RPO. Service level agreements must include formally defined recovery objectives. A contract that promises “99.9% availability” without defining RTO or RPO in the event of a major incident is non-compliant.
Incident notification within 4 hours. If your ERP vendor suffers an incident that affects your service, it must notify you within a timeframe compatible with your own obligation to notify the regulator (4 hours). This clause must appear explicitly in the contract, with designated notification channels.
Documented exit plan. In the event of termination or vendor failure, you must be able to migrate your data within a reasonable timeframe. The contract must specify the period during which data remains accessible, the export format, and the guaranteed migration window.
Subcontracting transparency. Your vendor must communicate the list of its critical subcontractors and notify you of any material change. A change of hosting provider (moving from AWS to Azure, for example) must be flagged to you before going live in production.
Cloud ERP and DORA: Specific Risks to Monitor
Concentration on 3 Hyperscalers: A Recognised Systemic Risk
Virtually all SaaS ERPs on the market (SAP, Oracle, Microsoft, Sage, Workday) rely on AWS, Azure or GCP. DORA explicitly recognises this systemic concentration risk. Regulators are concerned about a scenario where a major hyperscaler outage would simultaneously affect dozens of financial institutions.
For your institution, this means documenting this dependency in your ICT register and thinking through mitigation plans (multi-cloud redundancy, tested business continuity plans).
Multi-Tenancy: Your Availability Depends on Other Clients
A multi-tenant SaaS ERP means you share resources with other clients of the vendor. An incident on another client’s tenant (a massive DDoS attack, an application bug, a misconfiguration) can impact your availability. Ask your vendor how tenants are isolated and what its incident isolation policy is.
Data Localisation: The Sovereignty Question
Article 30(2)(j) of DORA requires contracts to specify the countries in which data will be processed and stored. For a financial institution subject to EU prudential supervision, prudential reporting data hosted outside the EU raises sovereignty and regulatory access questions.
Verify in your ERP contract that data localisation is explicitly defined and that processing outside the EU (for support or maintenance operations) is governed by appropriate contractual safeguards.
6-Step Action Plan for DORA Compliance of Your ERP
Step 1: Map critical ICT services. Identify whether your ERP supports critical or important functions under DORA. Document the dependent business processes, associated ICT assets, and target service levels (RTO/RPO).
Step 2: Assess your ICT register and existing contracts. Build or update your Register of Information. Audit your ERP contracts to identify clauses missing from the Article 30 requirements.
Step 3: Negotiate contractual addenda with your vendor. Present your vendor with the list of missing clauses. Major vendors (SAP, Oracle, Microsoft, Sage) updated their standard contracts in 2024–2025, but earlier versions often require specific addenda.
Step 4: Implement resilience testing on the ERP scope. Schedule annual continuity tests that include the ERP. If you are a significant entity, assess whether the ERP should be included in your TLPT programme.
Step 5: Document ICT incident management processes. Formalise your ICT incident classification criteria, your notification chains (internal and to your competent supervisory authority), and your reporting procedures.
Step 6: Prepare your DORA report for the supervisory authority. EU supervisory authorities are requesting evidence of DORA compliance progress. Prepare a dossier documenting your ICT register, test results, and your contractual remediation plan.
DORA ERP Dashboard: Key Indicators to Track in 2026
Key metrics to instrument in your CIO dashboard:
- ICT register coverage rate: percentage of active ICT contracts documented in the Register of Information, with subcontractor granularity.
- Article 30 contractual coverage: percentage of critical ICT contracts updated with the mandatory clauses.
- RTO/RPO defined and tested: for each critical function supported by the ERP.
- Average internal notification time: time from ICT incident detection to classification, to verify you can meet the 4-hour notification deadline to the regulator.
- Date of last ERP resilience test and results.
DORA is not another compliance checkbox. It is a clear signal from European regulators: the digital operational resilience of the financial sector can no longer rest on verbal commitments from vendors. It must be contractualised, tested and documented.
To go further on the regulatory dimensions of your financial IT systems, read also our guide on NIS2 and ERP compliance requirements, our article on ERP business continuity and disaster recovery planning, and our analysis on ERP data archiving and retention obligations.
