DORA for Small and Non-Interconnected Investment Firms: What the Simplified Framework Requires
Under Article 16 of DORA, small and non-interconnected investment firms and a few other categories of smaller financial entities are exempt from Articles 5 to 15, the full ICT risk management chapter, and instead apply a simplified ICT risk management framework detailed in Title III of Commission Delegated Regulation (EU) 2024/1774. The relief is real but narrow: incident reporting still applies, the ICT third-party contract rules still apply, and the ESAs have confirmed that the register of information applies with no exception. Here is what the simplified framework actually requires.
Who qualifies for the simplified framework
Article 16(1) of Regulation (EU) 2022/2554 lists five categories:
- Small and non-interconnected investment firms, meaning investment firms that meet the conditions in Article 12(1) of Regulation (EU) 2019/2033 (DORA Article 3(34)). Those conditions are in the Investment Firms Regulation itself, which is not among the sources of this base, so check them there.
- Payment institutions exempted under Directive (EU) 2015/2366, i.e. under its Article 32(1).
- Institutions exempted under Directive 2013/36/EU, where the Member State has not used the option in DORA Article 2(4) to exclude them from DORA altogether.
- Electronic money institutions exempted under Directive 2009/110/EC, i.e. benefiting from the waiver in its Article 9(1).
- Small institutions for occupational retirement provision, defined in Article 3(53) as IORPs whose pension schemes together have fewer than 100 members. IORPs with no more than 15 members in total are outside DORA entirely (Article 2(3)(c)).
For US groups, the typical case is an EU-authorized investment firm subsidiary set up to serve EU clients. Whether it qualifies depends on the Regulation (EU) 2019/2033 test, not on the size of the US parent. If it does not qualify, the full Articles 5 to 15 regime applies.
What Article 16(1) still requires
The second subparagraph of Article 16(1) replaces Articles 5 to 15 with eight core obligations. Simplified-framework entities must:
- put in place and maintain a sound and documented ICT risk management framework, including protection of physical components and infrastructure;
- continuously monitor the security and functioning of all ICT systems;
- minimize the impact of ICT risk through sound, resilient and updated ICT systems, protocols and tools;
- allow sources of ICT risk and anomalies to be promptly identified and detected, and incidents to be swiftly handled;
- identify key dependencies on ICT third-party service providers;
- ensure continuity of critical or important functions through business continuity plans and response and recovery measures, including at least back-up and restoration;
- test regularly those plans and measures and the effectiveness of the controls;
- implement lessons from tests and post-incident analysis and develop, as needed, ICT security awareness and digital operational resilience training for staff and management.
Article 16(2) adds that the framework must be documented, reviewed periodically and after major ICT-related incidents, continuously improved, and that a report on its review must be submitted to the competent authority upon request.
How RTS 2024/1774 fleshes it out
Title III of RTS 2024/1774 (Articles 28 to 41) turns those principles into concrete controls. The headline requirements:
Simplified framework under RTS 2024/1774, Title III
| Area | Key requirements |
|---|---|
| Governance (Art. 28) | Management body bears overall responsibility, sets roles and security objectives, approves asset classification and continuity plans, and allocates and reviews the resilience budget at least once a year; independent control and internal audit; timely remediation of critical audit findings |
| Information security policy (Art. 29) | Documented policy protecting confidentiality, integrity, availability and authenticity, with measures under Articles 30 to 38 |
| Asset classification (Art. 30) | Identify and document all critical or important functions, the assets supporting them, and those supported by ICT third-party providers |
| ICT risk management (Art. 31) | Risk tolerance, risk assessment, mitigation, monitoring; alert thresholds that trigger incident response |
| Access control (Art. 33) | Need-to-know and least privilege; strong authentication for remote access, privileged access and publicly available assets supporting critical or important functions |
| Operations security (Art. 34) | Asset lifecycle, automated vulnerability scanning and patching, legacy asset risk, logging, anomaly monitoring, threat intelligence |
| Data and network security (Art. 35) | Protect data in use, in transit and at rest; secure deletion and disposal; teleworking and private devices |
| Testing (Art. 36) | An ICT security testing plan validating the security measures |
| Business continuity (Art. 39-40) | Plans approved by the management body, including a cyber-attack scenario; back-up and restore procedures tested at least once every year, or upon every major change of the plan |
| Review report (Art. 41) | Report on the review of the framework, in a searchable electronic format, with findings, self-assessment and remediation dates |
Article 28(3) of the RTS also allows these firms to outsource the verification of compliance with ICT risk management requirements to intra-group or third-party providers, while staying fully responsible for it. For a US group, that could mean a group technology company acting as an ICT intra-group service provider performs the verification, provided Union and national sectoral law allow it.
What is lighter, and what is not
Beyond Articles 5 to 15, DORA and its RTS grant simplified-framework entities a few further carve-outs:
- No ICT third-party risk strategy: Article 28(2) exempts Article 16(1) entities from adopting the formal strategy and policy on ICT third-party risk.
- No TLPT: Article 26(1) excludes them from threat-led penetration testing.
- No recurring-incident aggregation: Article 8(2) of RTS 2024/1772, which turns repeated incidents with the same root cause into one major incident, does not apply to them.
- No monitoring role: according to DORA Recital 43, as cited in Q&A 2025_7388, they need not establish a role to monitor arrangements with ICT providers.
What stays: the incident management, classification and reporting chapter (Articles 17 to 19) is not in the Article 16 exemption, so a major ICT-related incident must still be classified and reported. The key contractual provisions of Article 30 for ICT services are not carved out either. And the register of information is mandatory.
The register of information: no exception
In Q&A 2025_7388 (final answer published 8 August 2025), the ESAs answered that Article 28(3) "establishes the obligation to maintain and update a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers with no exception." All financial entities subject to DORA must keep one; proportionality is built into the register itself, since smaller firms typically use fewer ICT services.
A practical roadmap for a small EU firm in a US group
- Confirm eligibility under Article 16(1), and document the analysis.
- Classify critical or important functions and the ICT assets and providers supporting them (RTS Art. 30).
- Write the information security policy and get management-body approval of the classification and continuity plans.
- Implement the Article 33 to 35 controls, using group tooling where it fits, and record which group or third-party provider runs what.
- Build the register of information, including group companies providing ICT services as intra-group providers.
- Test back-up and restore at least yearly and document results for the management body (RTS Art. 40).
- Keep the review report ready to submit on request (DORA Art. 16(2); RTS Art. 41).
- Make sure the incident process can classify and report a major incident within DORA's deadlines.
If your compliance team needs to check one of these points quickly, the DORA knowledge base answers questions such as "Our bank qualifies as a small and non-interconnected investment firm under the simplified ICT risk management framework. Which full DORA articles are we exempt from?" with the exact citation.
Check your obligations against the texts
The DORA base indexes the regulation, RTS 2024/1774 (including the simplified framework), the incident and third-party RTS, and the ESAs' Q&A, so every answer comes with its source.
This article summarizes the rules and is not legal advice. Official texts: DORA on EUR-Lex and RTS 2024/1774 on EUR-Lex.
Frequently asked questions
Which DORA articles are small and non-interconnected investment firms exempt from?
Articles 5 to 15 of DORA, under Article 16(1). They must instead meet the lighter requirements in the second subparagraph of Article 16(1), detailed in Title III of RTS 2024/1774.
Do simplified-framework firms still need a register of information?
Yes. ESAs Q&A 2025_7388 confirms Article 28(3) applies with no exception to all financial entities subject to DORA.
Do Article 16 firms have to report major ICT incidents?
The Article 16 exemption covers only Articles 5 to 15, so the incident reporting chapter still applies. RTS 2024/1772 does exclude them from the recurring-incident rule in its Article 8(2).
Must simplified-framework firms carry out TLPT?
No. Article 26(1) of DORA excludes entities referred to in Article 16(1), first subparagraph, and microenterprises from threat-led penetration testing.
How often must a simplified-framework firm test its back-ups?
Article 40 of RTS 2024/1774 requires testing of the business continuity plans at least once every year for the back-up and restore procedures, or upon every major change of the plan.
Get the Kopik newsletter
New knowledge bases, RAG guides and product news. One email every week or two, unsubscribe in one click.
By subscribing you agree to receive our newsletter. We never share your address.