The Digital Operational Resilience Act turned ICT risk in EU finance from supervisory guidance into directly applicable law, and most of the work sits in a stack of technical standards that many teams have only partly read. Regulation (EU) 2022/2554 (DORA) has applied since 17 January 2025 to banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers and more than a dozen other types of financial entity, and it reaches their ICT providers through contracts and, for the largest, direct EU oversight. This guide covers the five pillars, the Level 2 standards that set the actual thresholds and deadlines, the identity requirements in the ICT risk management standard, and how to phase the work. It is for CISOs, ICT risk, compliance, third-party risk and identity teams in financial entities and their technology providers.
Key takeaways
- DORA is a regulation, not a directive. It applies directly in every Member State from 17 January 2025, and its Level 2 standards carry the detailed requirements.
- The management body owns ICT risk. Article 5(2) makes it responsible for the ICT risk management framework, and penalties can reach board members where national law allows.
- Incident reporting runs on hours, not days. A major incident needs an initial notification within four hours of classification and no later than 24 hours after awareness, then a 72 hour intermediate report and a final report within a month.
- Identity controls are written into law. RTS 2024/1774 Articles 20 and 21 require unique identities for people and systems, need-to-use privileged access, strong authentication for remote and privileged access, and access reviews at least every six months for systems supporting critical or important functions.
- Third-party risk is now evidenced through data. The register of information under Article 28(3) feeds supervisors directly, and the ESAs used it to designate critical ICT third-party providers on 18 November 2025.
Who DORA applies to, and how it sits beside NIS2
Article 2(1) lists the entities in scope in points (a) to (u), from credit institutions, payment institutions and investment firms to insurers, pension schemes, crypto-asset service providers, trading venues, credit rating agencies and crowdfunding platforms. Point (u) adds ICT third-party service providers for the oversight chapter.
- Proportionality: Article 4(1) requires financial entities to implement Chapter II "in accordance with the principle of proportionality".
- Simplified framework: Article 16(1) disapplies Articles 5 to 15 for small and non-interconnected investment firms, exempted payment, credit and e-money institutions and small occupational pension schemes. They follow Article 16 and Title III of RTS 2024/1774 (Articles 28 to 41), which still has an access control article (Article 33).
- Microenterprises: excluded from some obligations, such as the Article 5(3) third-party monitoring role and TLPT.
- NIS2: Article 4 of Directive (EU) 2022/2555 disapplies the corresponding NIS2 provisions, including supervision, where a sector-specific Union act imposes requirements "at least equivalent in effect". DORA is that act for financial entities, which is why it is described as lex specialis. A group IT company that is not itself a financial entity may still fall under national NIS2 law, so map legal entities, not brands.
The five pillars and their Level 2 standards
DORA sets principles; Commission regulations drafted by the European Supervisory Authorities (EBA, EIOPA and ESMA) set the detail. Numbers below were checked against EUR-Lex and the Liechtenstein FMA's list of Level 2 acts as of 16 October 2026.
| Pillar | DORA articles | Core obligations | Key Level 2 acts |
|---|---|---|---|
| ICT risk management | Art. 5-16 (Chapter II) | Management body accountability, documented framework, protection, detection, response, recovery and backup | Delegated Regulation (EU) 2024/1774 (ICT risk management tools and simplified framework) |
| ICT-related incident management and reporting | Art. 17-23 (Chapter III) | Classification, reporting of major incidents, voluntary notification of significant cyber threats | Delegated Regulation (EU) 2024/1772 (classification and materiality thresholds); Delegated Regulation (EU) 2025/301 (content and time limits of reports) |
| Digital operational resilience testing | Art. 24-27 (Chapter IV) | Risk-based testing programme, yearly tests of systems supporting critical or important functions, threat-led penetration testing (TLPT) for selected entities | Delegated Regulation (EU) 2025/1190 (TLPT criteria, testing requirements, internal testers, mutual recognition) |
| ICT third-party risk | Art. 28-44 (Chapter V) | Register of information, due diligence, mandatory contract terms, exit strategies, CTPP oversight | Implementing Regulation (EU) 2024/2956 (register templates); Delegated Regulations (EU) 2024/1773 (contractual policy), 2025/532 (subcontracting), 2024/1502 (CTPP criteria), 2024/1505 (oversight fees), 2025/295 (oversight conditions) |
| Information sharing | Art. 45 (Chapter VI) | Voluntary threat intelligence sharing within trusted communities | None; national and sector arrangements apply |
ICT risk management: what RTS 2024/1774 actually asks for
Articles 5 to 14 follow a management system outline: governance, the framework, tools, identification, protection, detection, response and recovery, backup, learning and communication. RTS 2024/1774 turns this into specific controls in Articles 1 to 27. The ones teams most often under-scope are:
- Asset management (Art. 4-5): an inventory that records ICT assets with their owners, location, classification and interdependencies. Without it, "critical or important function" mapping and the register of information cannot be reconciled.
- Cryptographic key management (Art. 6-7): a policy covering the full key lifecycle. See the Cryptographic Key Management Guide.
- Logging (Art. 12): defined events and retention, explicitly including access control and identity management events.
- Anomaly detection (Art. 23): criteria for detecting anomalous activities and triggering incident response.
Where identity fits: Articles 20 and 21 of RTS 2024/1774
DORA's identity requirements are unusually prescriptive and cover systems as well as people. Article 20 requires identity policies that ensure "unique identification and authentication of natural persons and systems accessing the financial entities' information", which brings service accounts, workloads and integrations into scope alongside staff.
| RTS 2024/1774 requirement | What it means in practice | Related guidance |
|---|---|---|
| Art. 20: a unique identity and user account for each staff member and relevant ICT third-party staff | No shared vendor logins; outsourcer accounts issued individually | Third-Party Access Guide |
| Art. 20: recorded assignments and a lifecycle from creation to termination, automated where feasible | Joiner, mover and leaver processes driven from an authoritative source | Joiner-Mover-Leaver Guide |
| Art. 20: identification and authentication of systems | An inventory of service accounts, API keys and workload identities, each with an owner | Service Account Security Guide |
| Art. 21(a): need-to-know, need-to-use and least privilege, including remote and emergency access | Scoped entitlements; break-glass accounts controlled and monitored | Break-Glass Account Guide |
| Art. 21(c): limit the use of generic and shared user accounts to the extent possible | Remaining shared accounts vaulted and checked out to named users | Privileged Access Management Guide |
| Art. 21(e)(ii): privileged, emergency and administrator access on a need-to-use or ad-hoc basis | Just-in-time elevation instead of standing admin rights | JIT Access Guide |
| Art. 21(e)(iii)-(iv): withdrawal without undue delay on termination; review at least yearly, and every six months for systems supporting critical or important functions | Two review cadences keyed off the function mapping | Access Reviews Guide |
| Art. 21(f)(ii): strong authentication for remote access, privileged access, critical or important function assets and publicly accessible assets | Phishing-resistant MFA for administrators and remote staff | MFA Guide |
For machine identities, strong authentication usually means workload identity federation, short-lived tokens or certificates rather than static secrets. See the Financial Services Identity Security Guide.
Classifying and reporting major ICT-related incidents
Articles 17 to 19 require an incident management process, classification and reporting of major ICT-related incidents to the competent authority. Under RTS 2024/1772 Article 8(1), an incident is major if it affects critical services and either involves "any successful, malicious and unauthorised access" to network and information systems (the Article 9(5)(b) threshold), or meets two or more of the other materiality thresholds.
| Criterion (RTS 2024/1772) | Example materiality threshold |
|---|---|
| Clients, financial counterparts and transactions (Art. 1, 9(1)) | More than 10% of all clients using the affected service, or more than 100,000 affected clients |
| Duration and service downtime (Art. 3, 9(3)) | Incident lasts longer than 24 hours, or downtime exceeds 2 hours for ICT services supporting critical or important functions |
| Data losses (Art. 5, 9(5)) | Impact on availability, authenticity, integrity or confidentiality, or malicious unauthorised access |
| Criticality of services affected (Art. 6) | Gateway condition: critical services must be affected |
| Reputational impact, geographical spread, economic impact (Art. 2, 4, 7) | Thresholds in Article 9 |
Recurring incidents with the same apparent root cause, occurring at least twice within six months, count as one major incident, checked monthly (Art. 8(2)).
- Initial notification: within four hours of classifying the incident as major, and no later than 24 hours after becoming aware of it (RTS 2025/301 Art. 5(1)(a)).
- Intermediate report: within 72 hours of the initial notification, even if nothing has changed.
- Final report: within one month of the latest intermediate report, once root cause analysis is complete (DORA Art. 19(4)(c)).
- Weekends: other entities may file by noon on the next working day, but credit institutions, central counterparties, trading venue operators and NIS2 essential or important entities cannot use this for initial and intermediate reports.
- Outsourced reporting: permitted under Article 19(5), but the entity "remains fully responsible".
An identity compromise is the most direct route to the unauthorised access threshold. The CitrixBleed 2023 case, where stolen session tokens bypassed MFA at organisations including ICBC, shows why token telemetry must feed classification. See the ITDR Guide.
Digital operational resilience testing and TLPT
Article 24 requires a risk-based testing programme, with appropriate tests at least yearly on all ICT systems and applications supporting critical or important functions (Art. 24(6)). Article 25 lists the test types, from vulnerability scans, open source analyses and source code reviews to scenario-based, performance, end-to-end and penetration testing.
Threat-led penetration testing applies to entities identified by competent authorities under Article 26 and RTS 2025/1190:
- Frequency: "at least every 3 years", adjustable by the authority (Art. 26(1)).
- Scope: critical or important functions, "performed on live production systems", including outsourced ones, whose providers must participate (Art. 26(2)-(3)).
- Pooled tests: an ICT provider can commission a pooled TLPT covering several financial entities, which counts for each participant (Art. 26(4)).
- Testers: internal testers are permitted under conditions, but entities using them "shall contract external testers every three tests" (Art. 26(8)).
- Method: aligned with TIBER-EU: preparation, threat intelligence and red team testing, then closure with remediation plans (Art. 26(6)).
Include identity attack paths (help desk resets, privileged access, machine credentials) in the threat intelligence scenarios rather than leaving them to chance.
ICT third-party risk, the register and CTPP oversight
Article 28(1) states that financial entities "remain fully responsible" for compliance when they use ICT third-party services.
- Register of information (Art. 28(3)): maintained at entity, sub-consolidated and consolidated level for all ICT contractual arrangements, using the templates in Implementing Regulation (EU) 2024/2956. Entities report at least yearly, provide the full register on request, and give advance notice of planned arrangements for critical or important functions.
- Pre-contract assessment (Art. 28(4)): function criticality, concentration risk, due diligence and conflicts of interest.
- Contract terms (Art. 30): every ICT contract needs service description, subcontracting conditions, data locations, data return, incident assistance "at no additional cost, or at a cost that is determined ex-ante" and termination rights. For critical or important functions, add performance targets, tested contingency plans, TLPT participation, "unrestricted rights of access, inspection and audit", and an exit with "a mandatory adequate transition period".
- Subcontracting: Delegated Regulation (EU) 2025/532 sets what to assess when ICT services supporting critical or important functions are subcontracted.
- Exit strategies (Art. 28(8)): documented, tested and reviewed, so the entity can exit "without disruption to their business activities".
Critical ICT third-party providers: the ESAs designate CTPPs under Article 31 using the Delegated Regulation (EU) 2024/1502 criteria, each with a Lead Overseer from the EBA, EIOPA or ESMA. On 18 November 2025 the ESAs published the first list of designated CTPPs, built from data in the registers of information, and described it as "a crucial step in the implementation of the DORA oversight framework". As of 16 October 2026 oversight examinations are under way; check the ESAs' sites for the current list. Lead Overseers can inspect, issue recommendations and impose periodic penalty payments of up to "1 % of the average daily worldwide turnover" per day for up to six months (Art. 35(6)-(8)).
Third-party access is where contract terms meet identity. The Snowflake breach, where infostealer credentials without MFA unlocked customer data warehouses, shows that the customer side still needs its own access controls.
Information sharing, supervision and penalties
- Information sharing (Art. 45): financial entities may exchange cyber threat intelligence, including indicators of compromise, within trusted communities, and must notify competent authorities when they join.
- Penalties (Art. 50): DORA sets no fixed EU fine level for financial entities. Member States lay down administrative penalties and remedial measures that must be "effective, proportionate and dissuasive", including cessation orders, pecuniary measures and public notices naming the entity. Under Article 50(5) these can extend to management body members where national law allows.
How to implement DORA: a phased approach
- Establish governance and scope: confirm each legal entity's DORA, Article 16 and NIS2 status, brief the management body and assign the Article 5(3) third-party monitoring role.
- Map critical or important functions: map the ICT assets, identities and providers behind each. This mapping drives TLPT scope, review cadences, contract tiers and incident criticality.
- Gap-assess against the RTS, not the regulation: walk RTS 2024/1774 article by article; identity gaps such as shared accounts and standing admin are common.
- Build the register of information: extract contracts, enrich with function mapping and subcontractors, validate against the ITS 2024/2956 templates and reconcile with the asset inventory.
- Stand up classification and reporting: encode the RTS 2024/1772 thresholds in the incident tool, pre-fill RTS 2025/301 fields, and run tabletops that test both the four hour and 24 hour clocks.
- Remediate contracts: repaper critical or important function contracts first with Article 30(3) clauses, then the rest at renewal.
- Test and pilot: test exit plans for the most concentrated providers first, and pilot new access review cadences on one business line before extending them.
- Roll back safely: run old escalation and review processes in parallel until the new ones complete one full cycle, so a tooling failure leaves no reporting gap.
Decision guidance
- Standard or simplified framework: Article 16 eligibility is set by entity type and exemption status, not by choice. If you qualify, use Title III of RTS 2024/1774, but keep Article 33 access control and backup testing at a level that would survive an incident review.
- Small versus large entities: a small payment institution can run DORA from a GRC tool and a well-kept register; a banking group needs consolidated registers, a TLPT programme and automated identity lifecycle. Groups with NIS2 entities too should run one control set mapped to both.
- Outsourced or in-house reporting: outsourcing incident reporting to a provider or group entity speeds filing but not accountability. Keep classification authority in-house.
- TLPT testers and pooling: internal teams build knowledge, external testers bring independence (required every third test); pooled tests cut provider cost but check they cover your functions.
Detection and measurement
Monitor the signals that drive classification: authentication anomalies on privileged and remote access, new service principals and API keys, provider outage feeds and downtime of critical or important functions. See the Identity Security Metrics Guide.
- Classification time: median time from detection to major or non-major decision, against the 24 hour ceiling.
- Reporting timeliness: percentage of initial, intermediate and final reports filed within RTS 2025/301 deadlines.
- Register quality: validation errors per submission and percentage of contracts with function mapping and subcontractor data complete.
- Exit readiness: percentage of critical or important function providers with an exit plan tested in the last 12 months.
- Access review cadence: percentage of systems supporting critical or important functions reviewed within six months, and leaver revocation time.
- Privileged access posture: percentage of administrator access granted just in time, and number of remaining shared or generic accounts.
Framework mapping
| DORA area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 |
|---|---|---|---|---|
| Governance and framework (Art. 5-6) | GV.RR, GV.RM | PM-9, RA-3 | 5.1, 5.2 | n/a |
| Identity and access (RTS Art. 20-21) | PR.AA | AC-2, AC-6, IA-2 | 5.15-5.18, 8.2, 8.5 | 5, 6 |
| Logging and detection (Art. 10, RTS Art. 12, 23) | DE.CM, DE.AE | AU-2, AU-6, SI-4 | 8.15, 8.16 | 8, 13 |
| Incident management and reporting (Art. 17-19) | RS.MA, RS.CO | IR-4, IR-6 | 5.24-5.28 | 17 |
| Continuity and backup (Art. 11-12) | RC.RP | CP-2, CP-4, CP-9 | 5.29, 5.30, 8.13 | 11 |
| Resilience testing and TLPT (Art. 24-27) | ID.IM | CA-8, RA-5 | 8.8 | 18 |
| ICT third-party risk (Art. 28-30) | GV.SC | SA-9, SR-6 | 5.19-5.23 | 15 |
Common failure patterns
- Treating the register as a procurement spreadsheet: without function mapping or subcontractor data it fails validation and cannot support concentration analysis.
- Starting the reporting clock in the wrong place: teams plan for "four hours" and miss that the 24 hour limit runs from awareness. Slow classification is the real risk.
- Ignoring system identities: Article 20 covers systems, yet many programmes inventory only human accounts. Leaked integration tokens are a recurring third-party path, as the Salesloft Drift breach showed across hundreds of Salesforce tenants. See the Secrets Management Guide.
- Shared vendor accounts: outsourcer staff using one support login breaks Article 20 and Article 21(c), and makes attribution impossible after an incident. The Marks and Spencer cyberattack involved attackers impersonating a third-party user.
- Untested exit plans: an exit strategy never rehearsed rarely meets Article 28(8), especially for cloud providers with proprietary services.
- Assuming CTPP designation covers you: Lead Overseer scrutiny does not replace your own due diligence, contracts or testing.
Practitioner checklist
- Confirm each legal entity's DORA, Article 16 and NIS2 status, and map critical or important functions to assets, identities and providers.
- Gap-assess against RTS 2024/1774 article by article, including Articles 12, 20 and 21.
- Inventory service accounts and API keys, remove standing admin access and set six-monthly reviews for critical or important function systems.
- Encode RTS 2024/1772 thresholds and RTS 2025/301 deadlines in the incident process, and exercise them.
- Validate the register of information against ITS 2024/2956 before each submission.
- Repaper critical or important function contracts with Article 30(3) terms and test exit plans.
- Report DORA status, open findings and TLPT remediation to the management body at least quarterly.
Standards and references
- EUR-Lex: Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA)
- EUR-Lex: Commission Delegated Regulation (EU) 2024/1774 on ICT risk management tools, methods, processes and policies
- EUR-Lex: Commission Delegated Regulation (EU) 2024/1772 on classification of ICT-related incidents and cyber threats
- EUR-Lex: Commission Delegated Regulation (EU) 2025/301 on the content and time limits of major incident reports
- ESMA: European Supervisory Authorities designate critical ICT third-party providers
- Liechtenstein FMA: DORA-related delegated regulations and directives
- DORA text: Article 28, general principles of ICT third-party risk management
- NIS2 text: Article 4, sector-specific Union legal acts
Related NHI Mgmt Group resources: Financial Services Identity Security Guide · Third-Party Access Guide · Privileged Access Management Guide · Identity Security Regulatory Map. This guide summarises Regulation (EU) 2022/2554 and its Level 2 standards as of 16 October 2026 and is not legal advice.