DORA compliance: what financial firms must be able to show

Understand DORA scope, ICT supplier risk, incident reporting and testing, with practical implications for fund managers and compliance teams

Sep 22, 2026Geoffrey Safar1 min read
DORA compliance: what financial firms must be able to show

DORA compliance: what financial firms must be able to show

An investor review is due, but the document platform is unavailable. The compliance team cannot see the latest ownership evidence. Operations cannot establish whether an approval was completed before the outage. The supplier's support team is investigating, but nobody has agreed what information the fund manager needs or when.

This illustrative disruption brings DORA compliance into focus. A technology failure becomes a business problem through the records, decisions and services that depend on it. The Digital Operational Resilience Act has applied to in-scope EU financial entities since 17 January 2025. Its purpose is to strengthen their ability to manage disruption involving information and communication technology (ICT). CSSF's DORA overview

For investment firms, the useful starting point is to connect each important activity to its technology dependencies and the evidence needed to keep operating, recover and explain what happened.

Start with the regulated entity

“Financial firm” is too broad a category for deciding whether DORA applies. The Central Bank of Ireland directs firms to check their authorisation against the entity types and exclusions in Articles 2 and 3. A business description such as fund administrator does not produce a universal yes-or-no answer. Central Bank of Ireland scope guidance

For alternative investment fund managers, one distinction matters particularly. Sub-threshold AIFMs falling within Article 3(2) of AIFMD are excluded. However, ESMA confirms that a sub-threshold manager which opts into the full AIFMD regime is subject to DORA. Being below the asset thresholds is therefore insufficient by itself to establish an exemption. ESMA's AIFM scope clarification

Document that analysis for the relevant legal entity. A group may contain entities with different permissions and obligations. A single group-wide label can conceal those differences before any control assessment starts.

Under DORA, the management body holds ultimate accountability for the firm's ICT risk management framework. It must oversee the resilience strategy and ensure appropriate resources and clear responsibilities. CSSF's ICT risk management guidance

Proportionality also needs care. It affects how requirements are applied, with specific simplified arrangements and exemptions. It is not a general permission for a small firm to disregard technology risk. Central Bank of Ireland proportionality guidance

How the five areas fit together

The European Commission groups DORA around five areas:

  • ICT risk management: identifying, protecting and recovering the technology supporting financial services.

  • Incident reporting: managing and classifying incidents, then reporting major incidents to the competent authority.

  • Resilience testing: finding weaknesses in the firm's ability to withstand and recover from disruption.

  • ICT third-party risk: managing dependencies on technology suppliers and the contractual relationship.

  • Information sharing: voluntary arrangements to exchange cyber-threat intelligence.

The voluntary character of the final area matters. It should not be presented as an unconditional requirement to join an information-sharing scheme. European Commission explanation of DORA's pillars

In the opening example, these areas form one sequence. The firm identifies its reliance on investor records, sets protection and recovery arrangements, detects the outage, assesses its significance and uses rehearsed procedures. The supplier contract should support the information and assistance needed throughout.

Make the supplier register useful during an outage

DORA's register of information covers contractual arrangements for ICT services provided by third parties. It supports the firm's own risk management, supervisory work and identification of critical providers. The ESAs describe these purposes in their report on the register exercise. ESAs' register of information report

A useful operational companion to that register would let the incident team trace a business activity to its supplier, contract owner, escalation contact and recovery dependencies. This is a practical recommendation: completing the prescribed templates and making information usable in a crisis are related tasks.

Consider a KYC periodic review process. The visible application might be working while its identity service, document storage or access-management dependency has failed. Recording only the application name leaves the team searching for the real obstruction.

The register's scope extends beyond services supporting critical or important functions. The Central Bank of Ireland explicitly confirms that all relevant ICT contractual arrangements belong in it. Central Bank register guidance

Put the recovery plan into the contract

DORA contains contractual requirements for ICT arrangements. The Commission's explanation highlights service descriptions, data locations, supplier assistance and monitoring rights. Commission overview of third-party requirements

For services supporting critical or important functions, contract review should address the additional applicable requirements. The Central Bank points specifically to audit rights, participation in relevant testing and visibility of subcontracting changes. Central Bank guidance on third-party oversight

In practical terms, work through a failed-service scenario before accepting assurances. Establish who will provide incident updates, whether exported records are usable, and what assistance would be available during a transition. Ask the team expected to restore the process to review those answers.

A security document pack is useful evidence, but its existence does not answer every operational question. The discipline used when responding to a reverse KYC request, checking scope, currency and missing evidence, is also useful when reviewing supplier material.

Financial entities using ICT suppliers remain responsible for their obligations under DORA. Designation of a provider as critical should therefore remain part of the firm's supplier assessment, alongside its own contractual and risk-management work. Central Bank guidance on ICT third-party risk

Rehearse decisions as well as recovery

DORA combines resilience testing with incident-management and reporting obligations. Advanced threat-led penetration testing applies to selected entities, rather than every firm automatically. The CSSF distinguishes that regime from general resilience testing and explains the risk-based selection of tests. CSSF testing guidance

A practical exercise for the opening scenario would include the compliance reviewer, operations lead, technology team and person responsible for regulatory notifications. Give them an unavailable document platform and incomplete supplier information. Track their decisions and the evidence they use.

Can they identify which reviews are affected? Can they prevent an unsupported approval? Can they establish whether recovered records include the latest reviewer decisions? Record unresolved questions as specific actions with owners, then test the corrected process.

Major-incident reporting has prescribed content and time limits under delegated rules. The incident procedure should use the applicable reporting requirements and competent authority's submission arrangements, rather than rely on somebody recalling a deadline during the outage. CSSF incident-reporting guidance and technical standards

Bring AML operations into the resilience discussion

For compliance leaders, the practical contribution is to explain how disrupted technology affects the ability to make and evidence decisions. Which checks depend on live information? Which records must be recovered together? Which activity should pause until the evidence is reliable?

Steward's work in investor onboarding and AML/KYC sits within this operational context. Assess the technology supporting those workflows through the same service, evidence and recovery questions used across the firm.

Start with one important process and follow it through a realistic failure. A documented dependency, an agreed response and a tested recovery give management something concrete to assess when deciding where further work is needed.