DORA: What Irish financial firms need in place

What DORA is, and who it catches

The Digital Operational Resilience Act is an EU regulation, which means it applies directly rather than through Irish transposing legislation. It sets a single framework for how financial entities manage information and communications technology risk.

The scope is wider than firms expect. It reaches across banking, insurance and investment, and takes in intermediaries, payment and e-money institutions, fund managers, crypto-asset service providers and others. A great many Irish firms that do not think of themselves as technology businesses are inside it.

Proportionality applies, so a small intermediary is not held to the same operational standard as a systemic bank. Proportionality is not exemption, and the register of information obligation catches firms that assumed otherwise.

The board owns it

DORA places ultimate responsibility for ICT risk on the management body, not on the IT function. The board approves the risk management framework, sets the risk tolerance, approves the policy on third-party providers, and has to keep its own knowledge current, including by following specific training on a regular basis. A supervisor can ask for the date and content of the board’s last ICT risk training, and increasingly does.

Proportionality and the simplified framework

The smallest entities, such as small and non-interconnected investment firms and payment or e-money institutions exempted under their own directives, apply a simplified framework with fewer elements. Everyone in scope still reports major incidents and still keeps the register. Which regime applies is a question for the compliance officer to answer in writing early, because it decides the size of everything that follows.

The five pillars

1. ICT risk management. A documented framework, owned at board level, covering identification, protection, detection, response and recovery.
2. ICT incident management and reporting. Classifying incidents consistently and reporting major ones to the competent authority within defined windows.
3. Digital operational resilience testing. A regular testing programme, scaled to the firm, with advanced threat-led testing for the largest entities.
4. ICT third-party risk. Managing dependency on providers, with specific contractual requirements and a register of arrangements.
5. Information sharing. Voluntary arrangements for exchanging cyber threat intelligence between entities.

The fourth pillar is where most of the work has landed in practice, because it obliges firms to know things about their supply chain that many had never written down.

What the framework has to contain

The first pillar is where a supervisor starts, and the framework is expected to be a set of working documents rather than one policy:

• An inventory of ICT assets and the business functions each supports, with the critical or important functions identified
• Protection and prevention controls: access management, patching, encryption, network security, change management
• Detection: monitoring that would notice an anomaly, with someone responsible for looking at it
• Response and recovery: ICT business continuity plans, backup and restoration policies, and recovery objectives for each important function
• A crisis communication plan covering clients, counterparties and the public
• Post-incident reviews after major incidents, with the lessons fed back into the framework
• Training for all staff and for the board, and a review of the whole framework at least once a year

The register of information

Every in-scope entity must maintain a register of its contractual arrangements for ICT services. It is a deceptively large exercise, because it forces a complete and accurate inventory of who you depend on, for what, and how critical each dependency is.

The recurring difficulties are the same across firms:

• Nobody owned a complete list of ICT suppliers before this, and procurement records do not equal a dependency map
• Subcontracting chains are opaque, and the obligation looks through to them
• Deciding which functions are critical or important requires a judgement the business has to make, not IT
• Existing contracts often lack the clauses DORA expects, so renegotiation runs on the supplier’s timetable rather than yours

Firms that started from the business services their customers rely on, and worked back to the technology under each one, produced better registers than firms that started from an asset list.

What goes in it, and when it is submitted

The register follows templates set by the European supervisory authorities and is submitted to the Central Bank once a year through the Central Bank Portal, as a structured data file rather than a spreadsheet, with the data as at 31 December; the Central Bank passes it on for the European authorities’ analysis of concentration across the sector. In 2026 the window ran through March, with the European Banking Authority’s data quality checks following in April and resubmissions where they found problems. It covers every contractual arrangement for ICT services, not only the ones supporting critical or important functions, and for each one it records the provider and its legal entity identifier, the service, the function it supports, the data and locations involved, the subcontractors behind it, and the exit arrangements. In the dry run most errors were missing mandatory fields, in particular the type of service, whether it could be brought back in house and whether an alternative provider exists, followed by invalid or inconsistent identifiers. The harder question the templates force is which functions are critical or important, and that decision belongs to the business, not to IT.

The contract clauses DORA expects

Every ICT contract has to describe the service and its locations, the handling and return of data, service levels, the provider’s duty to assist with incidents, cooperation with the firm’s supervisor, termination rights and notice periods. Contracts supporting critical or important functions add full service levels with performance targets, business contingency and recovery commitments, participation in the firm’s testing, unrestricted access and audit rights, and an exit plan with a transition period long enough to use. A clause review of the critical contracts, with a dated gap list, is the document a supervisor asks for second, after the register.

Incident reporting in practice

The obligation to report major ICT incidents runs on tight timescales, which means the classification decision has to be made under pressure by whoever is on duty. That is an operational problem more than a legal one.

What separates firms that cope is unglamorous: a written classification test that a duty manager can apply at three in the morning, a named decision-maker with a named deputy, a pre-drafted notification template, and at least one rehearsal. Firms that have never rehearsed discover the gaps during the incident.

The clock

Three reports to the Central Bank, on fixed timescales set by the technical standards: an initial notification within four hours of classifying the incident as major and in any case within 24 hours of becoming aware of it; an intermediate report within 72 hours of the initial notification, updated when things change and once services are restored; and a final report within a month of the intermediate report or its latest update. Where an incident runs on, the supervisors expect an updated intermediate report at least monthly until the final one arrives. The initial notification can be thin. It cannot be late.

Clients have to be told where a major incident affects their financial interests, and the firm may also report significant cyber threats voluntarily. Both decisions belong to the same named person as the classification decision.

Classifying a major incident

The classification test weighs a fixed set of factors, and the plan should list them in the order a duty manager would check them:

• How many clients and financial counterparts are affected, how many transactions, and whether there has been reputational damage
• How long the incident lasted, including any service downtime
• The geographical spread, and in particular whether more than two member states are affected
• Whether data was lost, or its availability, authenticity, integrity or confidentiality compromised
• The criticality of the services affected, including the firm’s own transactions and operations
• The economic impact, direct and indirect, in absolute and relative terms

Thresholds attach to several of these, so the decision is a calculation rather than a feeling. Record it either way: an incident assessed and found not to be major, with the reasoning, is evidence that the process works.

Concentration risk

DORA is explicit that dependency on a small number of providers is itself a risk, and the largest providers are subject to direct EU-level oversight. For an individual firm the practical question is narrower: what happens if this provider is unavailable for a week, and is the answer written down anywhere?

Exit planning is the part that gets deferred, because it is expensive to think about and nobody expects to use it. It is also the part that a supervisor can test cheaply, by asking what the plan is and watching the room.

An exit plan that would actually work

• What data comes back, in what format, and how long the provider has to hand it over
• Where the service goes: a named alternative provider, or in-house, with the lead time written down
• The transition support the contract obliges the provider to give, and for how long
• What the firm does for its clients during the gap, if there is one
• The last date the plan was walked through on paper, and by whom

Testing, and what a supervisor will ask

Every in-scope firm runs a digital operational resilience testing programme sized to its risk. Unless the firm is a microenterprise, the systems supporting critical or important functions are tested at least once a year, through a mix of vulnerability scanning, gap analysis, scenario-based tests and penetration testing, and the findings are tracked to remediation with dates. Entities the Central Bank identifies for it, in practice the largest and most interconnected, also run threat-led penetration testing at least every three years. For most Irish firms the gap is not the testing; it is the untracked remediation afterwards.

What the Central Bank asks for

1. The register of information, and whether it reconciles to the contracts
2. The date and content of the board’s last ICT risk training, and the minutes showing the framework was approved
3. The incident log, including incidents assessed as not major and the reasoning
4. The last test of the critical systems, the findings, and the remediation status
5. The exit plan for the provider the firm could least afford to lose
6. Evidence that staff outside IT would recognise an incident and know who to call

Six documents. A compliance officer who can produce them the same afternoon has, in practice, already passed.

If you are behind

Sequence matters more than speed. A workable order:

1. Identify your important business services from the customer’s point of view
2. Map the ICT dependencies under each one, including subcontractors
3. Build the register from that map rather than from a procurement spreadsheet
4. Fix the contractual gaps, starting with the dependencies you could least afford to lose
5. Write the incident classification test and rehearse it once
6. Train the people who will have to act, which is a wider group than the technology team

The last step is routinely skipped. Resilience frameworks fail at the point where somebody has to recognise an incident and escalate it, and that person is usually not in IT.