The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025. It sets EU rules for the digital operational resilience of specified financial entities and an oversight framework for critical ICT third-party service providers. For a financial entity, compliance is an ongoing ability to identify ICT risk, withstand and recover from disruption, report qualifying incidents, test controls and govern ICT suppliers. It is not a certificate obtained by purchasing one tool. The European Supervisory Authorities’ DORA implementation page identifies the related standards and reporting instruments that give the Regulation operational detail.
This guide is a route through the main obligations and decisions. Start by identifying the legal entity and financial category in Article 2, then choose the applicable ICT risk-management framework and map each duty to an owner and evidence. The original version of this page used generic deadlines, fines and supplier overlap figures. Those shortcuts can send a firm to the wrong authority or give its board a false sense of completion. Use the Regulation, its current technical standards and the competent authority’s instructions for the actual entity.
Verify scope before applying a checklist
Article 2 lists categories of financial entities, including credit institutions, payment and electronic-money institutions, investment firms, insurers and reinsurers, certain pension institutions, trading venues and crypto-asset service providers, among others. It also separately lists ICT third-party service providers. The latter are not automatically subject to every duty imposed on a financial entity merely because they supply software to a bank. Critical providers designated under the DORA oversight framework have distinct direct oversight obligations. Review the legal status of the entity, any Article 2 exclusions and the activity being performed. Group membership or a broad label such as “fintech” does not by itself answer scope.
A small financial entity may benefit from proportionality, but size is not a universal DORA exemption. Article 16 provides a simplified ICT risk-management framework for specified categories, such as certain small and non-interconnected investment firms, exempt payment or electronic-money institutions, certain exempt credit institutions and small institutions for occupational retirement provision. A microenterprise does not automatically qualify for Article 16 solely because it has fewer than ten staff. Verify the exact category and national supervisory position. Other DORA duties, such as incident handling and third-party risk, still need to be assessed under their own provisions.
Build a scope note with the entity’s authorisation, Article 2 category, applicable exclusions, supervisory authority, group relationships and whether Article 16 applies. If different group companies hold different licences, repeat the analysis for each. A procurement team should ask suppliers for information that helps the financial entity comply; it should not label every supplier as a designated critical ICT provider. The DORA software selection guide can structure tool questions once the actual regulatory scope is settled.
Put the management body in charge of ICT risk
Articles 5 and 6 place ICT risk-management governance at the centre of DORA. The management body defines, approves, oversees and is responsible for implementation of the ICT risk-management framework, subject to the Regulation’s allocation of tasks. The framework should be documented and integrated into the financial entity’s overall risk management. Ownership must extend beyond a security team: business-function leaders need to identify services that would fail if an ICT asset, data feed or supplier became unavailable.
Begin with the functions the entity delivers, then map the information assets, systems, dependencies and suppliers that support them. Identify critical or important functions and the consequences of disruption. A register of servers alone is insufficient if it cannot show which payment or customer service depends on them. Conversely, the management body does not need to configure every firewall; it needs an intelligible view of risk, decisions, incidents, tests and unresolved exceptions. Record approvals and changes in the framework so the board can see what it is actually overseeing.
The risk framework covers identification, protection and prevention, detection, response and recovery, learning and communication across DORA’s relevant chapter. A useful control map names the risk, system, measure, owner, evidence and trigger for review. Test whether recovery procedures work when an identity provider, cloud region or key supplier is unavailable. A plan that assumes those same services remain available during the incident may fail at the first real test. The ICT risk-management guide offers a more detailed view of operational control choices where the destination applies to the entity.
Classify and report incidents under the current standard
DORA’s Article 17 requires an ICT-related incident-management process. The entity must record, classify, manage and follow up incidents. Article 18 and related technical standards govern classification, including when an incident is major. Only after classification and the applicable reporting decision should the team use the major incident reporting standard, Commission Delegated Regulation (EU) 2025/301. A service outage, suspected intrusion and confirmed major incident are not interchangeable labels.
Article 5 of that delegated regulation requires an initial notification as early as possible and, generally, within four hours after major classification and no later than 24 hours after the financial entity became aware of the ICT incident. If classification as major occurs later than 24 hours after awareness, Article 5(2) provides a four-hour period from classification. The intermediate report is due at the latest 72 hours after the initial notification, even where status has not changed, with updates on recovery as required. The final report is due no later than one month after the intermediate report or latest updated intermediate report. The same Article contains late-report reasons and weekend/bank-holiday qualifications with exclusions; a team must read the full rule and its competent authority’s filing instructions before relying on a calendar shortcut.
A practical incident record should show first awareness, classification evidence and time, affected critical services, reporting decision, submissions, remedial steps and communications. Reclassify when new facts cross a major-incident threshold. Do not backdate a classification or delay it merely to shift a deadline. Prepare contacts and a filing route before an event, and confirm which legal entity reports. The incident playbook can help coordinate operations, but DORA’s classification and reporting clocks are separate from GDPR’s personal-data breach tests.
Run resilience testing proportionate to the entity
DORA requires a digital operational resilience testing programme. The programme should match the entity’s size, business and risk and test whether relevant ICT systems and processes withstand plausible disruption. Tests can include vulnerability assessments, scenario work, network-security assessments and recovery exercises, as appropriate under the Regulation. Results need owners and remediation, not only a certificate from a test provider. A test that reveals an unprotected dependency but is never fixed offers limited assurance.
Threat-led penetration testing under Article 26 is an advanced requirement for financial entities selected by competent authorities under the statutory criteria. It is not mandatory for every “significant” business or every supplier. Article 26 sets a testing frequency framework for selected entities, generally at least every three years, with the authority’s role and circumstances specified in the text. Do not assert that TIBER-EU is universally required for all DORA tests. Verify whether the entity is selected, the scope of critical or important functions, how testers are engaged and the authority’s instructions. The DORA testing guide can help distinguish routine programme tests from TLPT if that article is relevant to the reader’s entity.
An exercise should include actual operational dependencies. If a payment firm tests a database restore but not the service account needed to decrypt backups, the exercise misses a critical route to recovery. If a firm tests only office networks while a cloud supplier hosts the critical function, scope is incomplete. Document what was tested, limitations, observed recovery time, unresolved findings and who accepted or rejected remediation. Feed the result back into the ICT risk framework and supplier reviews.
Manage ICT third parties and the register
Article 28 requires financial entities to manage ICT third-party risk as part of their ICT risk framework. Article 28(3) requires an up-to-date register of information about contractual arrangements for ICT services with ICT third-party providers, at entity and, where relevant, sub-consolidated and consolidated levels. DORA Article 28(3) itself sets the register’s scope across those contractual arrangements. The register is not simply a GDPR record of processing renamed: it concerns ICT services, contracts and their relationship to financial functions, even where a service does not process personal data.
Map each arrangement to the service, legal entity, provider, supported function, location and any concentration or exit concern, following the applicable implementing standards. Article 30 specifies contractual content, with additional provisions where an ICT service supports a critical or important function. Review service descriptions, data location, availability, access, incident assistance, audit and termination arrangements against the actual contract. A standard GDPR data processing agreement may be needed for personal data but does not automatically supply DORA’s operational-resilience clauses.
Supplier due diligence should examine what happens if a provider changes subcontractor, region, security practice or pricing in a way that affects continuity. Ask how the entity would retrieve data and transition a critical function. Do not assume that every supplier can accept the same audit clause or that a paper right alone makes an exit feasible. Test the highest-impact dependencies. The GDPR ROPA guide can contribute information about personal-data flows, but it cannot replace the DORA ICT register. The DORA supplier-risk guide can support the contractual review when its detail matches the entity’s use case.
Keep DORA and GDPR incident duties distinct
An ICT incident may also be a personal data breach, but neither label automatically triggers the other’s reporting duty. GDPR Article 33 asks whether a personal data breach is unlikely to result in risk to individuals, with notification to a competent data-protection authority without undue delay and, where feasible, within 72 hours after awareness. DORA asks whether the ICT incident is classified as major under its criteria and requires a different report to the financial supervisor under its delegated standard. One event may require both, one or neither report. The GDPR breach-notification guide explains that separate assessment.
Use one incident chronology and evidence store where practical, with distinct decision fields and recipients. A GDPR personal-data breach may involve confidentiality, integrity or availability of personal data; DORA’s ICT event may disrupt a critical financial service without compromising personal data. A report to a financial supervisor does not substitute for a required data-protection authority notification. The data protection impact assessment guide, GDPR requirements overview and GDPR compliance checklist can supply relevant context for a processing operation, but neither document is automatically an ICT risk assessment.
DORA’s relationship with NIS2 also needs precise analysis. Union law includes provisions coordinating overlapping cyber obligations for financial entities, but “DORA supersedes NIS2 for everyone in finance” is too broad. A financial entity should identify its category and the particular obligation being compared, along with national implementation and supervisory arrangements. The DORA and NIS2 comparison helps frame that question without treating the frameworks as identical.
Understand enforcement without inventing a universal fine
Article 50 requires Member States to provide appropriate administrative penalties and remedial measures for financial-entity infringements, within its stated framework. It does not impose one EU-wide 2% turnover fine on every financial entity. National rules and the entity’s competent authority determine available measures and process. The Regulation separately empowers Lead Overseers in the critical ICT third-party provider oversight framework, including periodic penalty payments under specified conditions. Do not transfer the provider regime to an ordinary regulated firm. The DORA enforcement guide and the fintech cost guide offer related questions, but actual exposure must be checked against law and a real decision.
Management-body responsibility is important, yet Article 50 is not a blanket automatic ban on individual board members for any DORA issue. Look to the Regulation, relevant sector law and national measures before describing personal sanctions. During an inspection, the most useful material is the contemporaneous framework, incident chronology, test results, supplier register and documented decisions. A firm that records gaps honestly and fixes them can show how its programme functions; unsupported assurance statements can make a gap harder to resolve.
A workable first review
Choose one critical or important function and trace it from business owner through applications, data, internal teams and external ICT services. Confirm the entity’s Article 2 scope and Article 16 status. Examine the management body’s approved ICT framework, the incident classification route, a recent recovery test, the relevant ICT contracts and register entries. Ask the owner to describe a severe service outage: who detects it, when it may become major, who files which report, how operations continue and how the service returns. Record missing evidence as actions with accountable owners and dates.
Then repeat with a different function and a shared supplier. That reveals whether the framework works beyond the first showcase example. Use the actual text of Regulation (EU) 2022/2554 and the current incident-reporting delegated standard for legal decisions. DORA compliance is maintained through functioning governance, tested recovery and accurate reporting, not by assuming that a GDPR record or a software purchase covers the five areas by itself.