DORA Compliance for Financial Services: What It Means and What You Need to Do

The Digital Operational Resilience Act — DORA, or Regulation (EU) 2022/2554 — came into full effect on 17 January 2025. For compliance officers at Irish and EU financial services firms, it represents one of the most significant regulatory developments in years. For the first time, the EU has established a harmonised and directly applicable legal framework for digital operational resilience across much of the financial sector.

If your organisation is still working through what DORA actually requires — or whether it applies to you — this guide is for you.

What is DORA?

DORA is an EU regulation that establishes a comprehensive framework for digital operational resilience across the financial sector. Its core objective is straightforward: ensure that financial entities can withstand, respond to, and recover from ICT-related disruptions and threats.

The regulation is directly applicable across all EU member states, including Ireland, which means there is no transposition into national law required. If you are in scope, you are already subject to it.

DORA also introduces an EU oversight framework for ICT third-party service providers designated as critical, while imposing extensive vendor management obligations on financial entities in relation to all ICT third-party providers. This is one of the regulation's most significant expansions compared to previous guidance frameworks.

It is also worth noting that DORA applies proportionality principles throughout. The requirements are calibrated to the size, risk profile, and business model of each entity — meaning that smaller or less complex firms may benefit from simplified requirements in certain areas.

Who does DORA apply to?

DORA applies to a broad range of financial entities, including:

• Credit institutions and banks
• Payment institutions and e-money institutions
• Investment firms
• Insurance and reinsurance undertakings
• Crypto-asset service providers
• Central securities depositories
• Trading venues and trade repositories

It also applies, in a more limited capacity, to ICT third-party service providers designated as critical by the European Supervisory Authorities.

For most Irish financial services firms, the Central Bank of Ireland is the competent supervisory authority for DORA. However, for significant institutions supervised under the Single Supervisory Mechanism, the ECB plays a central supervisory role alongside the relevant national competent authority. If you are uncertain which authority has jurisdiction over your organisation, this is worth clarifying with your legal or regulatory affairs team.

Who is responsible under DORA?

This is a point that often gets underweighted in DORA conversations. DORA places ultimate responsibility for ICT risk management on the management body — the Board of Directors and senior leadership — and makes clear that this responsibility cannot be delegated away.

This means boards must approve the ICT risk management framework, receive regular reporting on ICT risks, and demonstrate active oversight. Regular management body reporting will generally be necessary to demonstrate effective oversight. For compliance officers, this creates a direct line of accountability to the boardroom — and board-level engagement with DORA obligations is an expectation, not a discretionary activity.

The five pillars of DORA

DORA organises its requirements across five core areas. Understanding these is the starting point for any compliance programme.

1. ICT Risk Management

Financial entities must implement a comprehensive ICT risk management framework. This means having documented policies for identifying, classifying, and managing ICT risks across the organisation. The framework must be reviewed at least annually and whenever a significant incident occurs.

This is not a one-time exercise. DORA requires ongoing risk identification, monitoring, and response — not a risk register that gets dusted off before an audit.

2. ICT-Related Incident Management, Classification, and Reporting

DORA introduces a strict, three-stage mandatory incident reporting regime, formalised through the DORA incident reporting RTS and ITS measures. Firms must be able to detect, manage, and report major ICT-related incidents to their competent authority within tight windows.

Whether an incident is "major" must be assessed against the criteria and thresholds established in the DORA incident classification RTS — this is a regulatory determination, not a matter of internal judgement alone.

The three reporting stages, measured from the moment of classification as a major incident, are:

Initial Notification: Within 4 hours of classifying the incident as major. Financial entities are expected to assess and classify incidents without undue delay — delaying classification will not generally be viewed favourably by supervisors.

Intermediate Report: Within 72 hours of the initial notification, or immediately upon recovery of regular activities if that occurs sooner.

Final Report: Within 1 month of the intermediate report, including full root-cause analysis and actual financial and operational impact figures.

With an intermediate report required within 72 hours of initial notification, there is very little room for delay once the process begins. Incident classification frameworks need to be built, tested, and understood across the organisation before an incident occurs — not assembled under pressure when one does.

3. Digital Operational Resilience Testing

Financial entities must maintain a proportionate digital operational resilience testing programme, with testing performed regularly and at a frequency appropriate to the firm's risk profile. This includes vulnerability assessments, network security tests, and gap analyses as part of the baseline testing programme.

Certain financial entities identified by supervisors must also conduct Threat-Led Penetration Testing, generally at least every three years. The key shift across all testing requirements is that testing must be evidence-based and documented — not just completed, but demonstrably completed and acted upon.

4. ICT Third-Party Risk Management

This is the pillar that catches many organisations off guard. DORA requires firms to maintain a granular, audit-ready Register of Information detailing ICT third-party service providers and the contractual arrangements that fall within the scope of the Register of Information requirements. Heightened contractual obligations apply to providers supporting critical or important functions.

Contracts must explicitly cover audit rights, data security, business continuity, and exit strategies. Firms cannot simply rely on a vendor's own compliance certifications — they must conduct and document their own due diligence.

There is also a significant reporting obligation attached to this pillar. Financial entities must maintain the Register of Information and submit it in accordance with the reporting arrangements established by their competent authority and the applicable ITS. In practice, the submission cycle has operated on an annual basis — the 30 April date has been used under supervisory implementation arrangements, though firms should confirm the current requirements with their competent authority. The submission must be made in a strict xBRL-CSV format specified by the European Supervisory Authorities.

Many firms find spreadsheet-based approaches increasingly difficult to maintain at scale given the volume of data, evidence, and reporting required under this pillar. The xBRL submission requirement in particular makes the limitations of manual tracking concrete.

5. Information and Intelligence Sharing

Article 45 of DORA creates a framework for voluntary cyber threat information sharing between financial entities, subject to safeguards relating to confidentiality, data protection, and competition law. Participation is entirely voluntary. Firms should be aware of relevant sharing schemes and consider how participation might fit within their broader risk management approach.

What does DORA compliance actually look like in practice?

Understanding the five pillars is the starting point. Operationalising them is where most organisations are still finding their footing.

The risk register is not enough on its own. DORA requires risk to be continuously monitored and acted upon. A static document that is reviewed annually does not meet the standard. Risk management under DORA needs to be a live process connected to the systems and events that generate risk.

Vendor management needs to be systematic. The third-party risk requirements under DORA are detailed and ongoing. Many firms find that managing the volume of provider relationships, contractual obligations, due diligence records, and regulatory reporting required under DORA is increasingly difficult to sustain through manual processes alone.

Incident classification needs to be defined before an incident happens. The reporting timelines under DORA are tight. With an initial notification required promptly upon classification and an intermediate report due within 72 hours of that, firms without a pre-agreed classification framework will find themselves making consequential decisions under significant pressure.

Evidence matters as much as action. DORA is an audit-ready regulation. What you do matters, but what you can demonstrate you did matters equally. Every risk assessment, every vendor review, every incident response action needs to be documented and retrievable.

The challenge for compliance teams

DORA has arrived at a time when compliance teams in Irish financial services are already managing significant regulatory pressure — GDPR, the Consumer Protection Code, AML obligations, and sector-specific requirements from the Central Bank. Adding a comprehensive operational resilience framework on top of existing workloads is a real challenge.

The firms navigating this most effectively are those that have moved away from compliance as a collection of disconnected workstreams and towards compliance as an integrated operational function. Risk management, vendor oversight, incident tracking, and audit evidence need to work together — not exist in separate tools, folders, and spreadsheets.