DORA Article 16 Simplified ICT Risk Framework: The 5 Entity Types That Qualify and the 14 RTS Articles They Must Meet

Article 16 of DORA swaps the full ICT risk management framework for a shorter one, but only for five named groups of financial entity, and it lifts less than its name suggests. For those groups, Articles 5 to 15 of Regulation (EU) 2022/2554 “shall not apply”. Eight duties in Article 16(1)(a) to (h) take their place, and Title III of Delegated Regulation (EU) 2024/1774 turns them into 14 articles of concrete requirements. Incident reporting, the register of information and the contract rules for ICT providers stay. Being small is not enough: a nine-person investment firm that fails one of the nine Investment Firms Regulation tests applies Articles 5 to 15 (with the microenterprise reliefs if it also meets the turnover or balance-sheet test), not Article 16.

This guide gives the qualifying test for each group, the provisions that still apply, Title III as a 14-row checklist, and the one question the texts leave open: whether Article 24 resilience testing reaches these entities. For DORA as a whole, start from our DORA compliance hub.

Who qualifies: the five Article 16(1) groups and their tests

Plain-language summary: Article 16 has no general size test. Four of the five groups are defined by a status under another EU act, so the test lives in that act; the small IORP is defined by a member count in DORA Article 3(53). Your evidence is the calculation, decision or count that gives you the status.

Article 16(1) group	DORA definition	Qualifying test	Watch for
Small and non-interconnected investment firms	Art. 3(34): meets the conditions of Article 12(1) of the Investment Firms Regulation	All nine conditions of Regulation (EU) 2019/2033, Article 12(1), including assets under management below EUR 1.2 billion, client money held of zero, an on- and off-balance-sheet total below EUR 100 million and gross revenue from investment services below EUR 30 million (two-year average)	Asset, order, balance-sheet and revenue tests are combined across the group (Art. 12(2))
Payment institutions exempted under PSD2	Art. 3(36): exempted under Article 32(1) of Directive (EU) 2015/2366	Monthly average of the preceding 12 months’ payment transactions within the national limit, which is “no more than EUR 3 million” (Directive (EU) 2015/2366, Art. 32(1)(a))	National limit may be lower; authorised payment institutions do not qualify
Institutions exempted under CRD	Art. 3(32): an entity referred to in Article 2(5), points (4) to (23), of Directive 2013/36/EU	Named national institutions. The list in Directive 2013/36/EU as adopted includes Irish credit unions, Germany’s Kreditanstalt für Wiederaufbau and Poland’s SKOK credit unions and Bank Gospodarstwa Krajowego	Only where the Member State has not used the Article 2(4) option to take them out of DORA altogether
Electronic money institutions exempted under EMD2	Art. 3(39): benefits from a waiver under Article 9(1) of Directive 2009/110/EC	Average outstanding electronic money within the national limit, at most EUR 5 000 000 (Directive 2009/110/EC, Art. 9(1)(a))	A Member State may set a lower limit
Small institutions for occupational retirement provision (IORPs)	Art. 3(53): pension schemes that “together have less than 100 members in total”	Member count across all schemes the IORP operates	An IORP whose schemes “together do not have more than 15 members in total” is outside DORA (Art. 2(3)(c))

Three boundaries that decide the hard cases

The IORP band runs from 16 to 99 members. Up to 15 members, Article 2(3)(c) takes the IORP out of DORA. From 16 members up to 99, it is a small IORP on the simplified framework. At 100 it is neither. Recital 42 describes small IORPs as schemes that “together do not have more than 100 members in total”, one member wider than the definition. Recitals do not bind, so the operative definition in Article 3(53) decides: at exactly 100 members, plan for the full framework.

CRD-exempt institutions depend on a national choice. Article 2(4) lets each Member State exclude the Article 2(5)(4) to (23) entities on its territory from DORA, and the Commission publishes who did. If yours did, you are outside DORA; if not, you are on the simplified framework. Check the information the Commission publishes under Article 2(4) and your national law, and keep the reference in your file. Our DORA exemption list covers the Article 2(3) exclusions and where NIS2 picks up.

A second licence can take the simplified framework away. Asked whether a small and non-interconnected investment firm that also holds a crowdfunding licence may use Article 16, the European Commission answered, in ESMA Q&A 2292 (DORA 121) of 17 December 2025, that the assessment is “case-by-case” and that “if the main activity of a financial entity does not fall within the scope of the entities benefiting from Article 16 DORA, the entity must apply a full ICT risk management framework”. Document which activity is your main one, and why. Our fintech DORA scope map works through eight business models.

Microenterprise is a different status. A microenterprise “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)) and keeps Articles 5 to 15 with the reliefs written into them. An entity that is both loses those reliefs with the articles, and Title III has no microenterprise exception.

Work through the decision in this order:

1. Financial entity under Article 2(1), and not excluded by Article 2(3) or a national Article 2(4) choice? If excluded, stop.
2. One of the five statuses today? File the evidence: the IFR calculation, the exemption or waiver decision, or the dated member count.
3. Another licence whose main activity falls outside the five groups? Then the full framework applies.
4. Otherwise Article 16 and Title III apply. Check microenterprise status for the reliefs in Chapters III to V.

What Article 16 switches off, and what it leaves in place

Plain-language summary: Article 16(1) itself disapplies Articles 5 to 15. Further reliefs exist where a later provision names Article 16(1) entities; in DORA and the incident-classification RTS there are three: DORA Article 26(1) (TLPT), DORA Article 28(2) (third-party strategy) and RTS 2024/1772 Article 8(2) (recurring incidents).

Obligation	Full framework	Article 16(1) entity	Basis
Governance, framework, strategy and the Articles 8 to 14 functions	Apply	Do not apply; Article 16(1)(a) to (h) and Title III instead	DORA Art. 16(1)
Incident management, classification and reporting	Apply	Apply	Arts 17 to 23 are not among the disapplied articles
Treating recurring incidents as one major incident	Applies	Does not apply	RTS (EU) 2024/1772, Art. 8(2)
Digital operational resilience testing programme	Applies (other than microenterprises)	Open point (see below)	DORA Art. 24(1)
Threat-led penetration testing (TLPT)	Only if identified	Does not apply	DORA Art. 26(1)
Strategy on ICT third-party risk	Applies (other than microenterprises)	Does not apply	DORA Art. 28(2)
Register of information	Applies	Applies	DORA Art. 28(3)
Pre-contract assessment, exit plans, contract terms	Apply	Apply; no Article 16 carve-out in the text	DORA Arts 28(4), 28(8), 30

Incident reporting has one relief. Delegated Regulation (EU) 2024/1772, Article 8(2), counts incidents that occurred at least twice within 6 months with the same apparent root cause as one major incident, and adds: “This paragraph does not apply to microenterprises and to financial entities listed in Article 16(1)”. Each incident is still classified on its own.

The register was in doubt because Article 28(1) places third-party risk “within their ICT risk management framework as referred to in Article 6(1)”, which these entities do not have. The Joint ESAs answer in EBA Q&A 2025_7388 of 8 August 2025 is that Article 28(3) applies “with no exception” and “All financial entities that are subject to DORA are required to maintain a register of information.”

The eight duties in Article 16(1) and where Title III fills them in

Plain-language summary: Article 16(1) states eight outcomes. Article 16(3) told the ESAs to specify points (a), (c), (f) and (g) and the review report in technical standards, and Title III’s four chapters follow that mandate: framework elements (Chapter I), systems, protocols and tools (Chapter II), business continuity plans and their testing (Chapter III) and the review report (Chapter IV).

Art. 16(1)	Duty	Where Title III sets the detail (our mapping)
(a)	A “sound and documented ICT risk management framework”, including protection of physical components and infrastructures	Arts 28 to 32
(b)	Continuously monitor the security and functioning of all ICT systems	Art. 34(a), (f) to (h)
(c)	Minimise the impact of ICT risk through sound, resilient and updated systems, protocols and tools	Arts 33 to 38
(d)	Detect sources of ICT risk and anomalies promptly and handle incidents swiftly	Art. 31(3) and (4); Art. 34(g) to (i)
(e)	Identify key dependencies on ICT third-party service providers	Art. 30(2); Art. 34(b); Art. 39(2)(d)
(f)	Business continuity plans and response and recovery measures, including “at least, back-up and restoration measures”	Art. 39
(g)	Test the (f) plans and the effectiveness of the (a) and (c) controls “on a regular basis”	Arts 36 and 40
(h)	Feed test results and post-incident analysis into risk assessment; awareness and training	Art. 28(2)(e) (budget, including training) and (h); Art. 31(1)(e); Art. 39(2)(j)

RTS Article 1 requires size, overall risk profile and complexity to be taken into account when the simplified framework is developed and implemented. That shapes how you meet each requirement; it removes none of them.

RTS 2024/1774 Title III as a checklist: Articles 28 to 41

Plain-language summary: Title III has 14 articles. The effort ratings are our estimate for a firm of under 50 staff that buys most of its IT as a service. The English-language corrigendum to the RTS of 15 May 2025 corrects Article 22(d) in Title II; it does not touch Title III.

Article	What it requires	Evidence to keep	Effort
28 Governance and organisation	Governance and control framework; management body duties (a) to (i), including a budget reviewed “at least once a year”; independent control and internal audit functions; internal audit by independent auditors with ICT risk expertise; remediation of critical findings	Management body approvals; budget review; audit plan and reports	High
29 Information security policy	One documented policy on confidentiality, integrity, availability and authenticity; ICT security measures covering Arts 30 to 38, including measures run by providers	Approved policy; list of measures	Medium
30 Classification	Identify, classify and document all critical or important functions, their supporting assets and interdependencies, and those supported by providers	Function and asset register	Medium
31 ICT risk management	Risk tolerance levels; assessment; mitigation at least for risks outside tolerance; reassessment after major change, tests and major incidents; threat monitoring; alert thresholds	Risk register; dated assessments	Medium
32 Physical and environmental security	Measures based on the threat landscape and the Art. 30 classification, protecting premises and any data centres	Site security record	Low
33 Access control	Need-to-know and least privilege, including remote and emergency access; user accountability; account management; periodic reviews; strong authentication for remote access, privileged access and publicly available assets supporting critical or important functions	Access reviews; authentication settings	Medium
34 ICT operations security	Asset lifecycle; provider support; capacity; automated vulnerability scanning and patching; legacy assets; logging; anomaly monitoring; threat information; leakage and malicious code	Scan reports; patch and log records	High
35 Data, system and network security	Data in use, in transit and at rest; endpoints and media; unauthorised connections; secure deletion and disposal; teleworking and private devices	Network and data protection record	Medium
36 ICT security testing	A testing plan validating the Arts 33 to 35, 37 and 38 measures; update measures without undue delay for systems supporting critical or important functions	Test plan, results, remediation log	Medium
37 Acquisition, development and maintenance	“Where appropriate”, a risk-based procedure: requirements approved before acquisition, testing before first use and before production changes	Requirement and test sign-offs	Low
38 Project and change management	A project procedure covering all stages; changes recorded, tested, assessed, approved, implemented and verified	Change log	Medium
39 Business continuity plans	Based on an analysis of severe disruptions, “including a cyber-attack scenario”; points (a) to (j), including backup scope and “minimum frequency of the backup, based on the criticality of the function”; mitigation of failures of critical third-party providers	Approved plans; backup register	High
40 Testing of continuity plans	Test “at least once every year for the back-up and restore procedures, or upon every major change of the business continuity plan”; show the business stays viable; report deficiencies to the management body	Test reports; deficiency log	Medium
41 Review report	Submitted “in a searchable electronic format”, with the content in points (a) to (h)	Report kept ready to submit	Low until requested

One policy, but not one document

Recital 26 of the RTS says these entities “should develop and document only one policy, that is an information security policy”. That is the Article 29 policy. The articles after it still ask for documented procedures: access control (Art. 33), project and change management (Art. 38) and, where appropriate, acquisition and development (Art. 37). One policy with short procedures under it meets the text. A separate policy for every Title II topic goes beyond it.

Internal audit has no size exemption, only proportionate frequency

RTS Article 28(5) requires the framework to be “subject to an internal audit by auditors, in line with the financial entities’ audit plan”, by auditors who “shall be independent”, and Article 28(4) requires “segregation and the independence of control functions and internal audit functions”. Neither has a size exception. DORA recital 43 lists, among things entities on the simplified framework “should not be required” to do, “to subject to internal audit on a regular basis the ICT risk management framework”. Recitals do not bind, and the RTS article is binding. On our reading, the room for small firms lies in Article 28(5)’s own words: the frequency and focus of ICT audits are “commensurate to the ICT risk”. An outsourced internal-audit engagement on a multi-year cycle may meet that, where the risk profile supports it.

Separately, Article 28(3) allows the “tasks of verifying compliance” to be outsourced to “ICT intra-group or ICT third-party service providers”, narrower words than DORA Article 6(10)’s “intra-group or external undertakings”. EIOPA, in Q&A 3450 (DORA 272), says “there is no practical difference”: these entities “can apply DORA Art. 6(10) to comply with Art. 28(3)”. Either way, the entity remains “fully responsible” for the verification.

The open point: does Article 24 testing apply to Article 16(1) entities?

Plain-language summary: the texts point both ways, and none of the ESA Q&As cited in this guide answers the question. Your management body should decide it and record the basis.

Reading 1: Article 24 applies. Article 16(1) disapplies Articles 5 to 15 only, and Article 24 sits in Chapter IV. Where the legislator wanted to exempt these entities from testing, it said so: Article 26(1) excludes “entities referred to in Article 16(1), first subparagraph” from TLPT. On this reading, entities other than microenterprises keep a programme, use independent testers (Art. 24(4)) and test “at least yearly” all ICT systems and applications supporting critical or important functions (Art. 24(6)).

Reading 2: it does not. Article 24(1) requires the programme “as an integral part of the ICT risk-management framework referred to in Article 6”, and Article 6 does not apply to these entities. Recital 43 points the same way: entities on the simplified framework “should not be required” to “establish a comprehensive digital operational resilience testing programme as an integral part of the ICT risk management framework provided for in this Regulation”. The recital does not bind, but its words match Article 24(1). On this reading, testing duties come from Article 16(1)(g) and RTS Articles 36 and 40 only.

What does not change. The Article 36 ICT security testing plan and the Article 40 continuity tests apply under both readings, so start there. If Article 24 applies and the entity is also a microenterprise, Articles 24(1) and (3) to (6) are addressed to entities “other than microenterprises”, and it tests under Article 25(3). Until the point is decided, applying the more demanding reading is a cautious interim choice. It does not mean that reading is the correct one.

The review report: Article 16(2) and RTS Article 41

Plain-language summary: you review the framework periodically and after major incidents, and you hand over a structured report when the competent authority asks for one.

Article 16(2) requires review “periodically and upon the occurrence of major ICT-related incidents in compliance with supervisory instructions” and a report “upon its request”. The full framework’s Article 6(5) says “at least once a year”; Article 16(2) sets no interval, so record yours and why. RTS Article 41 sets the content:

• an introduction: context, an executive summary of current and near-term ICT risk, the reported area and major changes since the last report;
• where applicable, the management body’s approval date;
• the reasons for the review, with evidence of supervisory instructions or, after incidents, “the list of all those ICT-related incidents with related incident root-cause analysis”;
• the review period and the person responsible;
• findings with a self-assessment of severity, remedying measures with expected dates (including open findings from earlier reports) and overall conclusions.

When we built the review-report template for our DORA pack, the Article 41(2) content list mapped almost point for point onto records a working framework already produces: the risk register, audit findings and test deficiencies. If those records carry dates and owners, a supervisory request becomes a compilation task rather than a project.

Who does what in a simplified framework

Role	Owns	First action
Management body	Overall responsibility (RTS Art. 28(2)(a)); approval of classification, main risks, business impact analysis and continuity plans (28(2)(d)); yearly budget review (28(2)(e)); receiving test deficiencies (40(3))	Minute the Article 16(1) status, and decide the Article 24 point
Compliance or legal	Evidence of Article 16(1) status and its triggers; audit plan; Article 41 report; register of information; incident reporting procedure	File the status evidence with a re-check date
CISO, IT lead or managed IT provider	Arts 33 to 38 measures; scanning, logging and the Article 36 testing plan; backups under Article 39(2)(g)	Run a restore test and record the result
Owner of a small firm (non-technical)	Making sure each item above has a named person, inside or outside the firm	Put the internal audit of the framework that Article 28(5) requires into the audit plan

When Article 16 status ends

Plain-language summary: Article 16 status follows your sectoral status. When that changes, Articles 5 to 15 apply, so plan the move from the day the change becomes foreseeable.

• Investment firms: under IFR Article 12(3), a firm stops being small and non-interconnected “with immediate effect”, or after three months if only the asset, order, balance-sheet or revenue thresholds are breached. It regains the status only six months after meeting all conditions again (Art. 12(4)). DORA’s definition refers to the Article 12(1) conditions and does not say whether this timing carries over, so plan from the day of the breach.
• Exempted payment institutions: where the conditions are no longer met, PSD2 Article 32(5) requires the institution to “seek authorisation within 30 calendar days”.
• IORPs: reaching 100 members ends small-IORP status.
• CRD-exempt institutions: a change in the Member State’s Article 2(4) choice moves you in or out of DORA.

The full framework adds the Article 5 governance duties, an Article 6(4) control function, the Article 6(8) strategy, Article 11 response and recovery plans, Article 12 backup rules, the Article 28(2) strategy, the RTS Title II policies and the recurring-incident test, among others. For a side-by-side view of where these overlap with NIS2, see DORA vs NIS2.

Frequently asked questions

Is every microenterprise on the DORA simplified framework?

No. Microenterprise status (Art. 3(60)) brings specific reliefs inside Articles 5 to 15. Only the five Article 16(1) groups move to the simplified framework.

Do Article 16(1) entities report major ICT-related incidents?

Yes. Articles 17 to 23 still apply. The only relief is that recurring incidents are not aggregated into one major incident under RTS (EU) 2024/1772 Article 8(2).

Do Article 16(1) entities need a register of information or TLPT?

A register, yes: the Joint ESAs answer that Article 28(3) applies “with no exception”. TLPT, no: Article 26(1) excludes them.

How often must the simplified framework be reviewed?

Periodically and upon major ICT-related incidents, in compliance with supervisory instructions (Art. 16(2)). Unlike Article 6(5), Article 16(2) sets no yearly minimum, though the back-up and restore procedures are tested at least once every year, or upon every major change of the business continuity plan (RTS Art. 40(1)).

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. European Parliament and Council. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA), Articles 2, 3, 6, 16, 24, 26 and 28 and recitals 42 and 43. Official Journal L 333, 27.12.2022. EUR-Lex (linked above).
2. European Commission. Delegated Regulation (EU) 2024/1774, RTS on ICT risk management tools, methods, processes and policies and the simplified ICT risk management framework, Article 1, Title III (Articles 28 to 41) and recital 26. EUR-Lex (linked above).
3. Corrigendum to Delegated Regulation (EU) 2024/1774, OJ L 2025/90420, 15.5.2025. EUR-Lex (linked above).
4. European Commission. Delegated Regulation (EU) 2024/1772, RTS on the classification of ICT-related incidents and cyber threats, Article 8(2). EUR-Lex (linked above).
5. Regulation (EU) 2019/2033 on the prudential requirements of investment firms (IFR), Article 12. EUR-Lex (linked above).
6. Directive (EU) 2015/2366 on payment services in the internal market (PSD2), Article 32. EUR-Lex (linked above).
7. Directive 2013/36/EU (CRD), Article 2(5). EUR-Lex (linked above).
8. Directive 2009/110/EC on electronic money institutions (EMD2), Article 9. EUR-Lex (linked above).
9. Directive (EU) 2016/2341 on institutions for occupational retirement provision (IORP II), Article 5. EUR-Lex (linked above).
10. ESMA. Q&A 2292 (DORA 121), answer provided by the European Commission, 17 December 2025 (linked above).
11. EIOPA. Q&A 3450 (DORA 272), ICT risk management, final (linked above).
12. EBA Single Rulebook Q&A 2025_7388, Joint ESAs answer, 8 August 2025 (linked above).