DORA entered into force on 17 January 2025. Unlike NIS2 (which had national transposition delays), DORA is directly applicable EU regulation — no national legislation was required, no transition grace period. From 17 January 2025, compliance is mandatory.

This article covers what financial entities using cloud ERP need to know and do. For broader security compliance context, see Security and Compliance in Cloud ERP 2026.

Who Is in Scope

DORA Article 2 lists the categories of financial entities covered:

  • Credit institutions (banks)
  • Payment institutions
  • E-money institutions
  • Investment firms
  • Crypto-asset service providers (under MiCA)
  • Central securities depositories
  • Central counterparties
  • Trading venues
  • Trade repositories
  • Alternative investment fund managers
  • Management companies
  • Insurance and reinsurance undertakings
  • Insurance intermediaries
  • Institutions for occupational retirement provision
  • Credit rating agencies
  • Statutory auditors and audit firms
  • Administrators of critical benchmarks
  • Crowdfunding service providers
  • Securitisation repositories
  • ICT third-party service providers (as a separate category with lighter obligations)

Proportionality: microenterprises (fewer than 10 employees, annual turnover under 2M €) benefit from simplified requirements for some pillars (particularly testing — they are exempt from TLPT obligations).

Five Pillars of DORA

Pillar 1: ICT Risk Management

Every financial entity must have a comprehensive ICT risk management framework including:

  • ICT risk policy, approved by the management body
  • ICT asset inventory (hardware, software, data, processes)
  • Risk identification and classification
  • Protection, prevention, and detection measures
  • Response and recovery procedures
  • Business continuity plan for ICT disruptions
  • Post-incident review process
  • Communication policy

The management body (board of directors, supervisory board) bears personal accountability for the ICT risk management framework. This mirrors the DORA principle that operational resilience is a governance matter, not just IT.

Definition of major ICT incident (EBA RTS defines specific thresholds):

  • Significant impact on critical services
  • Data breaches affecting many clients
  • Availability below SLA thresholds for a defined period
  • Significant financial losses

Reporting timeline for major incidents:

  • Initial notification to national competent authority (NCA): within 4 hours of classification as major incident
  • Intermediate report: within 3 business days
  • Final report: within 1 month of resolution

Cyber threats: significant cyber threats (not yet incidents) must be reported on a voluntary basis and in some cases mandatorily.

Pillar 3: Digital Operational Resilience Testing

Basic testing (all entities):

  • Regular ICT system testing (vulnerability scanning, network penetration testing, etc.)
  • At least annually

TLPT — Threat-Led Penetration Testing (significant entities only):

  • Red team testing based on real threat intelligence
  • Covers production systems and critical third-party providers
  • Minimum every 3 years
  • Conducted by certified external testers
  • Results reviewed by the competent authority

Microenterprises are exempt from TLPT.

Pillar 4: ICT Third-Party Risk Management

This is the pillar most relevant for companies using cloud ERP. DORA requires:

Strategy and policy for ICT third-party risk, approved by the management body.

Pre-contract due diligence for every new ICT provider supporting critical or important functions:

  • Security assessment
  • Business continuity and recovery capability
  • Sub-outsourcing chain mapping
  • Concentration risk assessment (are too many functions with one provider?)

Contractual requirements (DORA Article 30) for critical/important function contracts — see FAQ above.

Register of Information — maintained and updated, reportable to supervisory authorities.

Exit strategies — documented plan for terminating a provider relationship, including data portability and transition support requirements.

Pillar 5: Information Sharing

DORA encourages financial entities to share cyber threat intelligence with each other and with supervisory authorities. Information sharing arrangements must be:

  • Voluntary participation
  • Trusted and confidential
  • Guided by Union law

ICT Third-Party Risk: Practical Implications for ERP

The most direct operational impact of DORA for many companies is managing the relationship with their cloud ERP vendor.

Is Your ERP Vendor a Critical ICT Third-Party Provider?

Under DORA, an ICT third-party service provider is critical or important if:

  • It supports a critical function or important function of the financial entity
  • Disruption would significantly impact core financial services
  • The provider is hard to replace in the short term

For most financial entities, their ERP is critical — it processes financial transactions, holds accounting records, and supports regulatory reporting. If the ERP goes down, core business stops.

What You Must Do with Your ERP Vendor

  1. Include them in your Register of Information with full details
  2. Ensure the contract includes all DORA Article 30 clauses — audit rights, incident notification, exit support, data location, SLA with specific metrics
  3. Conduct annual due diligence — request updated security certification (ISO 27001, SOC 2), business continuity test results, sub-outsourcing disclosures
  4. Assess concentration risk — if the ERP vendor uses a single hyperscaler for all EU clients, document this concentration risk
  5. Maintain an exit strategy — how would you migrate to a different system if needed?

Modulario DORA Compliance Package

For financial sector clients, Modulario provides:

  • DORA Article 30 contractual annex — all required clauses pre-drafted
  • Register of Information data sheet — pre-filled template with all required data points
  • ISO 27001 certificate and annual surveillance audit report
  • Business continuity and disaster recovery documentation
  • Sub-outsourcing disclosure — all infrastructure sub-processors documented
  • Audit rights — contractual right to audit Modulario (or via third-party auditor)
  • SLA with specific metrics — availability, RTO, RPO
  • Incident notification procedure — formal process for notifying clients of significant incidents

DORA vs. NIS2 vs. GDPR: How They Interact

All three regulations apply in parallel to financial entities that also process personal data:

RegulationFocusIncident ReportingAudit
DORAICT operational resilience4h/3d/1m to NCAICT third-party audit rights
NIS2Network and information security24h/72h to CSIRTNot specified
GDPRPersonal data protection72h to DPA (if personal data)DPA investigation

A single incident may trigger reporting obligations under all three — ensure your incident response runbook covers all three simultaneously.

Practical Checklist for Financial Entities

Immediate (if not done):

  • Map all ICT providers supporting critical or important functions
  • Create Register of Information
  • Review all ICT contracts for DORA Article 30 compliance gaps
  • Assign DORA accountability at management body level

Within 3 months:

  • Implement ICT risk management policy
  • Establish incident classification criteria and reporting workflow
  • Conduct basic ICT resilience testing (vulnerability scan, penetration test)
  • Complete pre-contract due diligence for all critical ICT providers

Within 6 months:

  • Business continuity and disaster recovery testing for ICT systems
  • Exit strategy documentation for critical ICT providers
  • TLPT scoping assessment (significant entities)

Ongoing:

  • Annual review of Register of Information
  • Annual renewal of due diligence for critical ICT providers
  • Post-incident reviews documented
  • Management body reporting on ICT risk

Frequently Asked Questions

Does DORA apply to our company? We are a small insurer / credit union / payment processor. DORA applies to all financial entities regulated under EU financial services law — banks, insurers, investment firms, payment institutions, e-money institutions, crypto-asset service providers (MiCA), central counterparties, trading venues, credit rating agencies, crowdfunding platforms, and many more. There is a proportionality principle — smaller entities (microenterprises under 10 employees and 2M € turnover) benefit from simplified requirements. But zero entities in scope are exempt. If you process financial transactions, manage assets, or provide financial services under EU licence, you are in scope.

What is the Register of Information under DORA and how does it work? The Register of Information (RoI) is DORA’s central tool for mapping ICT third-party dependencies. Every financial entity in scope must maintain a register of all ICT service providers that support critical or important functions — including cloud providers, ERP vendors, network operators, data analytics providers, outsourced IT. For each provider, the register must document: service description, criticality classification, data processed, contractual arrangements, exit strategy, sub-outsourcing chain. The European Supervisory Authorities (EBA, EIOPA, ESMA) will use aggregated RoI data to identify systemic ICT concentration risks.

What must a SaaS ERP vendor provide to a financial sector client under DORA? Under DORA Article 30, ICT third-party contracts with financial entities for critical or important functions must include: full description of services including SLAs and performance metrics, data locations (which EU/EEA countries), audit rights (financial entity or its regulator can audit the provider), incident reporting obligations (provider notifies client of significant ICT incidents), termination rights and exit support, sub-outsourcing disclosure, business continuity and disaster recovery provisions, security standards (ISO 27001 or equivalent). As a SaaS ERP vendor serving financial clients, Modulario provides a DORA-compliant contractual annex.