DORA Compliance: What the Regulation and Its Eight Technical Standards Require — and What You Need on File
DORA compliance means showing, document by document, that you meet Regulation (EU) 2022/2554 and the eight technical standards that fill in its detail. This page maps each obligation to its article, its standard and the record a supervisor will ask for, and shows which obligations switch off for microenterprises and Article 16(1) entities.
General information based on the texts published on EUR-Lex, not legal advice. Check your competent authority’s guidance before acting.
DORA compliance at a glance
DORA is a directly applicable regulation: no national transposition is needed, though national law sets the penalties. The word “pillar” does not appear anywhere in the Regulation: the familiar “five pillars” are a shorthand for its chapters, and the obligations behind them are spread across nine legal acts.
What DORA requires: five areas, mapped to the chapters and technical standards
Article 1(1)(a) names the five areas: ICT risk management, major-incident reporting, resilience testing, information sharing and ICT third-party risk. The table shows where each lives and the record that proves it.
| Area | Where in DORA | Technical standard(s) | What you need on file |
|---|---|---|---|
| 1. ICT risk management | Chapter II, Arts 5–16 | RTS (EU) 2024/1774 (Title II full framework, Title III simplified framework) | Management body approval record, ICT risk-management framework, digital operational resilience strategy, policies and procedures, asset and risk registers, business continuity and backup plans, annual review report |
| 2. Incident management, classification and reporting | Chapter III, Arts 17–23 | RTS (EU) 2024/1772 (classification), RTS (EU) 2025/301 (content and time limits), ITS (EU) 2025/302 (forms) | Incident management process, incident and cyber-threat log, classification record, initial / intermediate / final reports |
| 3. Digital operational resilience testing | Chapter IV, Arts 24–27 | RTS (EU) 2025/1190 (threat-led penetration testing) | Testing programme, test plans and reports, findings and remediation register; TLPT documentation if identified |
| 4. ICT third-party risk | Chapter V, Section I, Arts 28–30 | ITS (EU) 2024/2956 (register), RTS (EU) 2024/1773 (policy), RTS (EU) 2025/532 (subcontracting) | Third-party strategy and policy, register of information, pre-contract assessments, Art. 30 contract terms, exit strategies and plans |
| 5. Information sharing | Chapter VI, Art. 45 | None | Notification to the competent authority when you join or leave an information-sharing arrangement |
The takeaway: the classification thresholds, reporting time limits, report forms and register templates all sit in the technical standards, so a file built from the Regulation alone has gaps.
1. ICT risk management (Chapter II)
The management body carries this area. Article 5(2) requires it to “define, approve, oversee and be responsible for the implementation of all arrangements related to the ICT risk management framework”, including approving the digital operational resilience strategy, the ICT business continuity policy and the policy on the use of ICT third-party services.
Article 6 requires a “sound, comprehensive and well-documented” ICT risk-management framework. It must be reviewed “at least once a year, or periodically in the case of microenterprises”, after major ICT-related incidents and after supervisory instructions or test and audit conclusions (Art. 6(5)), and it must include the digital operational resilience strategy described in Article 6(8). Articles 8 to 14 set the functions it must cover, from identification and protection to backup, learning and communication.
RTS (EU) 2024/1774 Title II turns these articles into policy content; its Title III (Articles 28 to 41) is the shorter framework for Article 16(1) entities. For where NIS2 controls already overlap, see DORA vs NIS2.
2. ICT-related incidents: classify, then report (Chapter III)
Every ICT-related incident and significant cyber threat is recorded (Art. 17(2)); only major incidents are reported (Art. 19(1)). Under RTS (EU) 2024/1772, Article 8(1), an incident is major where it has affected critical services and either the data-loss threshold for successful, malicious and unauthorised access (Art. 9(5)(b)) is met, or two or more of the other materiality thresholds are met. Worked examples, the recurring-incident rule and the open readings: how to classify a major incident under RTS 2024/1772.
| Criterion (RTS 2024/1772) | Materiality threshold (Art. 9) |
|---|---|
| Clients, financial counterparts and transactions | Any of: over 10% or over 100 000 of the clients using the service; over 30% of counterparts; over 10% of daily average transaction number or value; relevant clients affected (Art. 9(1)) |
| Reputational impact | Media coverage, repetitive complaints, regulatory breach or material client loss (Art. 9(2), Art. 2) |
| Duration and service downtime | Incident lasts longer than 24 hours, or downtime longer than 2 hours for ICT services supporting critical or important functions (Art. 9(3)) |
| Geographical spread | Impact in two or more Member States (Art. 9(4)) |
| Data losses | Adverse impact on business objectives or compliance, or malicious unauthorised access (Art. 9(5)) |
| Economic impact | Costs and losses exceed or are likely to exceed EUR 100 000 (Art. 9(6)) |
| Criticality of services affected | The gate: required for every major incident (Art. 8(1), Art. 6) |
Recurring incidents that are each below the bar count as one major incident when they occurred at least twice within 6 months, share the same apparent root cause and together meet the criteria; entities must check for this monthly (Art. 8(2)). That aggregation rule does not apply to microenterprises or to Article 16(1) entities. Some points are open, such as whether your home Member State counts towards “two or more Member States”: record your reading.
Once classified, the reporting clock runs on the time limits of RTS (EU) 2025/301, Article 5, and the reports use the standard forms of ITS (EU) 2025/302:
| Report | Time limit (RTS 2025/301 Art. 5(1)) |
|---|---|
| Initial notification | “as early as possible, but in any case, within four hours from the classification” of the incident as major “and no later than 24 hours from the moment the financial entity has become aware” of it |
| Intermediate report | At the latest within 72 hours from the submission of the initial notification, even where status or handling have not changed; an updated intermediate report without undue delay and in any case when regular activities have been recovered |
| Final report | No later than one month after the intermediate report or, where applicable, the latest updated intermediate report |
If an incident is classified as major only after the first 24 hours, the initial notification is due within four hours of that classification (Art. 5(2)). Weekend and bank-holiday deadlines move to noon of the next working day (Art. 5(4)), except for the initial and intermediate reports of credit institutions, central counterparties, trading-venue operators and NIS2 essential or important entities (Art. 5(5)). Where a major incident affects clients’ financial interests, clients must be informed without undue delay (DORA Art. 19(3)). The delay notice, updated intermediate reports, the client notice and the open points in the weekend rule are worked through in our DORA incident reporting timeline guide. How these clocks compare with NIS2’s 24-hour early warning is covered in our DORA vs NIS2 comparison.
3. Digital operational resilience testing (Chapter IV)
Entities other than microenterprises run a testing programme (Art. 24(1)) with independent testers (Art. 24(4)) and ensure that appropriate tests are conducted “at least yearly” on all ICT systems and applications supporting critical or important functions (Art. 24(6)). Microenterprises test on a risk-based plan (Art. 25(3)).
Threat-led penetration testing (TLPT) is not universal. Only entities that the competent authority identifies under Article 26(8) must carry it out, “at least every 3 years” (Art. 26(1)); microenterprises and Article 16(1) entities are excluded. RTS (EU) 2025/1190 sets the identification criteria (Art. 2) and the method; with internal testers, external testers are needed every three tests (Art. 26(8)). How this compares with the testing duties of NIS2 is set out in NIS2 penetration testing requirements.
4. ICT third-party risk (Chapter V)
ICT third-party risk is part of the ICT risk-management framework, and the financial entity “at all times” remains fully responsible for compliance (Art. 28(1)(a)). The core duties are:
- a third-party risk strategy and policy (Art. 28(2), content in RTS (EU) 2024/1773; not for microenterprises or Article 16(1) entities), set out clause by clause in our DORA ICT third-party risk policy guide;
- a register of information, reported on “at least yearly” (Art. 28(3));
- pre-contract assessment and due diligence (Art. 28(4)) and a concentration-risk check (Art. 29);
- termination rights (Art. 28(7)) and tested exit plans for critical or important functions (Art. 28(8));
- contracts with the nine elements of Art. 30(2), plus six more under Art. 30(3) for critical or important functions, and RTS (EU) 2025/532 for subcontracting.
Providers that the ESAs designate as critical under Article 31 also fall under an EU Oversight Framework (Chapter V, Section II). Who has been designated, and why NIS2 is still involved, is covered in What Is DORA?. Where DORA’s third-party rules stop and NIS2’s supply-chain duty takes over is the subject of our finance supply-chain guide.
5. Information sharing (Chapter VI)
Article 45 lets financial entities share cyber threat intelligence within trusted communities. Participation is voluntary; the one obligation is to notify the competent authority when membership is validated or ends (Art. 45(3)).
Who is in scope: 20 financial-entity types, three compliance regimes
DORA applies to the 20 types of financial entity in Article 2(1), points (a) to (t), and lists ICT third-party service providers in point (u), which are not “financial entities” (Art. 2(2)). There is no general size threshold: a small payment institution is in scope just as a bank is. Size changes how much you must do, not whether you are covered.
They run from credit institutions, payment and e-money institutions (including exempted ones), investment firms and crypto-asset service providers to insurers, IORPs, market infrastructures and securitisation repositories. Article 2(3) takes six groups out entirely:
| Excluded group | Provision |
|---|---|
| Alternative investment fund managers referred to in Art. 3(2) of Directive 2011/61/EU | Art. 2(3)(a) |
| Insurance and reinsurance undertakings referred to in Art. 4 of Directive 2009/138/EC | Art. 2(3)(b) |
| IORPs operating pension schemes with no more than 15 members in total | Art. 2(3)(c) |
| Natural or legal persons exempted under Arts 2 and 3 of Directive 2014/65/EU (MiFID II) | Art. 2(3)(d) |
| Insurance, reinsurance and ancillary insurance intermediaries that are micro, small or medium-sized enterprises | Art. 2(3)(e) |
| Post office giro institutions referred to in Art. 2(5), point (3), of Directive 2013/36/EU | Art. 2(3)(f) |
| Entities in Art. 2(5), points (4) to (23), of Directive 2013/36/EU, where a Member State uses the option | Art. 2(4) |
Full framework, microenterprise or Article 16(1) entity
Inside the scope, DORA runs three regimes. A microenterprise is a financial entity, other than a trading venue, central counterparty, trade repository or central securities depository, that “employs fewer than 10 persons and has an annual turnover and/or annual balance sheet total that does not exceed EUR 2 million” (Art. 3(60)). An Article 16(1) entity (small and non-interconnected investment firms, exempted payment and e-money institutions, certain exempted credit institutions, small IORPs) is outside Articles 5 to 15 and follows the simplified framework of Article 16 and RTS (EU) 2024/1774, Title III. Everyone else applies the full framework.
Our count finds 21 places between Articles 5 and 30 where an obligation is lifted or softened for microenterprises. The ones that matter most:
| Obligation | Full framework | Microenterprise | Article 16(1) entity |
|---|---|---|---|
| ICT third-party monitoring role (Art. 5(3)) | Required | Not required | Art. 5 does not apply |
| Independent ICT risk control function (Art. 6(4)) | Required | Not required | Art. 6 does not apply; independence of control and audit functions under RTS 2024/1774 Art. 28(4) |
| Framework review (Art. 6(5) / Art. 16(2)) | At least once a year | Periodically | Periodically, and after major incidents |
| Internal audit of the framework (Art. 6(6)) | Required | Not required | Required under RTS 2024/1774 Art. 28(5) |
| Testing programme and yearly tests of critical systems (Art. 24) | Required | Not required; Art. 25(3) risk-based testing | Not lifted by Art. 16(1); read with Art. 24(1), an open point |
| TLPT (Art. 26(1)) | If identified | Excluded | Excluded |
| Third-party strategy and policy (Art. 28(2)) | Required | Not required | Not required |
| Register of information (Art. 28(3)) | Required | Required | Required |
| Major incident reporting (Art. 19) | Required | Required | Required |
| Recurring-incident aggregation (RTS 2024/1772 Art. 8(2)) | Monthly check | Does not apply | Does not apply |
| Provider audit rights in contracts (Art. 30(3)(e)) | Full rights | May be delegated to an independent third party | Full rights |
The takeaway: being small reduces the governance and testing load, but it never removes the register of information or major-incident reporting. Fintechs unsure which regime they fall in can use our scope map for 8 fintech business models.
Deadlines and recurring time limits
DORA has applied since 17 January 2025, so the open deadlines are recurring ones. Besides the incident-reporting limits above, these cadences are fixed in the texts:
| Obligation | Time limit | Source |
|---|---|---|
| Check for recurring incidents | Monthly | RTS 2024/1772 Art. 8(2) |
| Review of the ICT risk-management framework | At least once a year (microenterprises: periodically) | DORA Art. 6(5) |
| Test ICT business continuity and response and recovery plans | At least yearly, and on substantive changes | DORA Art. 11(6)(a) |
| Risk assessment of legacy ICT systems | At least yearly (not microenterprises) | DORA Art. 8(7) |
| Tests on systems supporting critical or important functions | At least yearly (not microenterprises) | DORA Art. 24(6) |
| Report on ICT third-party arrangements | At least yearly | DORA Art. 28(3) |
| TLPT | At least every 3 years, if identified | DORA Art. 26(1) |
| Back-up and restore test (Art. 16(1) entities) | At least once every year, or upon every major change of the plan | RTS 2024/1774 Art. 40(1) |
The dates on which you send the register of information to your authority are not in the texts; your competent authority sets them. All dated milestones across DORA, NIS2, the CRA and the AI Act are tracked on our EU cyber compliance deadline tracker.
The register of information
The register of information is the list, required by DORA Article 28(3), of every contractual arrangement under which the entity uses ICT services from a third party, distinguishing those that support critical or important functions. It must be kept in the 15 templates of ITS (EU) 2024/2956 (Art. 3(1)), at entity level and, in groups, at sub-consolidated and consolidated level.
| Templates | What they record (ITS 2024/2956 Art. 5(1)) |
|---|---|
| B_01.01–B_01.03 | The entity maintaining the register, the entities in the consolidation, and branches outside the home country |
| B_02.01–B_02.03 | General and specific information on each contractual arrangement, and links between intra-group and external arrangements |
| B_03.01–B_03.03 | Who signs each arrangement, on the receiving and the providing side |
| B_04.01 | The entities that use the ICT services |
| B_05.01–B_05.02 | Direct ICT third-party service providers and subcontractors, and the ICT service supply chain |
| B_06.01 | Identification of functions |
| B_07.01 | Assessment of ICT services supporting critical or important functions |
| B_99.01 | Terminology and closed lists used to fill in the templates |
Providers that are legal persons are identified by a valid, active LEI or EUID, both where available (Art. 3(5)); the direct provider is always rank 1 in the supply chain (Art. 2); and the data must meet six quality principles, from accuracy to validity (Art. 3(4)). The ITS define the templates and columns; the file format and channel for sending the register are set by your competent authority. For the fill order across all 15 templates, how to rank a supply chain and the column codes the September 2025 corrigendum changed, see our guide to filling in the DORA register of information.
Where to start: an order that follows the deadlines
Start with what has an external clock:
- Applicability: Article 2(1) category, exclusions, microenterprise and Article 16(1) status.
- Incidents: classify against RTS (EU) 2024/1772 and notify within the RTS (EU) 2025/301 limits.
- Register: move ICT contracts into the ITS templates; fix LEI and EUID gaps early.
- Framework: management body approval of framework, strategy and policies; schedule the review.
- Testing: a calendar that covers critical systems and continuity plans yearly.
- Contracts: Article 30 terms at renewal, critical functions first, with exit plans.
If your group also holds NIS2 obligations, DORA Article 1(2) makes DORA the sector-specific Union act for financial entities identified as essential or important under national NIS2 law. Some duties stay with NIS2 authorities, and national rules differ: see whether DORA exempts your institution from NIS2, where NIS2 still applies in banking and, for entities outside DORA, the NIS2 checklist for financial entities DORA excludes.
What the DORA Compliance Pack contains
The documentation this page describes, built from the published texts of DORA and its eight technical standards: 42 editable files (35 Word, 7 Excel; 36 templates and 6 guides). A master map ties 1,173 requirements from the nine acts to the document and section that addresses them, and 16 points the texts leave open are flagged with a default for your management body to decide.
Three routes are set before you write a word: full framework, microenterprise or Article 16(1) simplified framework. The classification tool (D22) exports its result in one paste into the report-drafting workbook (D24). The pack is not legal advice and does not guarantee compliance: you adapt the documents, decide the open points, and your management body approves the result.
One-time payment · single legal entity licence · instant download · 30-day update-or-add pledge: if a template does not fit your environment, email us within 30 days and we will update it or add a document.
Our DORA guides
Go deeper on specific questions: What Is DORA? (the Regulation article by article and the designated critical ICT providers), DORA vs NIS2 (Article 1(2) and the 4-hour vs 24-hour split), the fintech scope map, the Article 2(3) exemption list, the Article 16 simplified ICT risk framework (who qualifies and the RTS 2024/1774 Title III checklist), DORA and NIS2 in banking, the checklist for entities DORA excludes and the finance supply-chain gap.
Country guides on where DORA ends and national NIS2 rules begin: Germany, France, the Netherlands, Poland, Italy, Belgium and Ireland.
Frequently asked questions
Does DORA apply to small financial entities?
Yes, unless an Article 2(3) exclusion applies. DORA has no general size threshold. Microenterprises (Art. 3(60)) get specific reliefs and Article 16(1) entities a simplified framework. Insurance intermediaries that are micro, small or medium-sized enterprises are excluded entirely (Art. 2(3)(e)).
How fast must a major ICT-related incident be reported under DORA?
The initial notification is due within four hours of classifying the incident as major and no later than 24 hours after becoming aware of it; the intermediate report within 72 hours of the initial notification; and the final report no later than one month after the latest intermediate report (RTS (EU) 2025/301, Art. 5(1)). If classification happens after 24 hours, the four hours run from the classification.
What is the DORA register of information?
It is the record, required by Article 28(3), of all contractual arrangements for ICT services provided by third parties, kept in the 15 templates of ITS (EU) 2024/2956 at entity level and, for groups, at sub-consolidated and consolidated level.
Is threat-led penetration testing mandatory for every financial entity?
No. TLPT is required only of entities that their competent authority identifies under Article 26(8) using the criteria in RTS (EU) 2025/1190, and then at least every three years. Microenterprises and Article 16(1) entities are excluded.
What are the penalties for DORA non-compliance?
For financial entities, DORA does not set fine amounts. Article 50(3) requires Member States to lay down administrative penalties and remedial measures that are “effective, proportionate and dissuasive”; amounts depend on national law.
Does DORA replace NIS2 for financial entities?
For financial entities identified as essential or important under national NIS2 rules, DORA Article 1(2) makes DORA the sector-specific Union legal act for the purposes of NIS2 Article 4. Some NIS2 elements can still apply under national law.
Do ICT providers have to comply with DORA?
DORA’s Chapters II to V are addressed to financial entities. An ICT provider meets DORA mainly through its customers: the Article 30 contract elements, their register of information and their exit plans. A provider designated as critical under Article 31 is also subject to the EU Oversight Framework in Chapter V, Section II.
Sources
- European Parliament and Council. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal L 333, 27.12.2022. EUR-Lex
- European Commission. Delegated Regulation (EU) 2024/1774, RTS on ICT risk management tools, methods, processes and policies and the simplified ICT risk management framework. EUR-Lex
- European Commission. Delegated Regulation (EU) 2024/1772, RTS on the classification of ICT-related incidents and cyber threats and materiality thresholds. EUR-Lex
- European Commission. Delegated Regulation (EU) 2025/301, RTS on the content and time limits of major ICT-related incident reports. EUR-Lex
- European Commission. Implementing Regulation (EU) 2025/302, ITS on standard forms and templates for reporting major ICT-related incidents and notifying significant cyber threats. EUR-Lex
- European Commission. Implementing Regulation (EU) 2024/2956, ITS on standard templates for the register of information. EUR-Lex
- European Commission. Delegated Regulation (EU) 2024/1773, RTS on the policy for ICT services supporting critical or important functions. EUR-Lex
- European Commission. Delegated Regulation (EU) 2025/532, RTS on subcontracting ICT services supporting critical or important functions. EUR-Lex
- European Commission. Delegated Regulation (EU) 2025/1190, RTS on threat-led penetration testing. EUR-Lex
- European Parliament and Council. Directive (EU) 2022/2555 (NIS2 Directive). Official Journal L 333, 27.12.2022. EUR-Lex
Legal texts checked against the versions published on EUR-Lex, including the English corrigenda to ITS (EU) 2024/2956 and RTS (EU) 2024/1774. Check EUR-Lex for amendments after this page’s date. This page is general information, not legal advice, and is not affiliated with any EU institution or supervisory authority.