Article 16 of the Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, lets a closed list of small financial entities replace the full ICT risk management requirements of Articles 5 to 15 with a lighter framework. The list covers small and non-interconnected investment firms, exempted payment and electronic money institutions, certain exempted credit institutions and small institutions for occupational retirement provision (IORPs). Those entities must still keep a sound, documented framework that covers monitoring, protection, detection, ICT third-party dependencies, business continuity with backup and restoration, testing, and staff awareness. The detailed content is set out in Title III of Commission Delegated Regulation (EU) 2024/1774, and the obligations have applied since 17 January 2025 (Article 64 of DORA).

What is the DORA simplified ICT risk management framework?

It is the reduced set of ICT risk requirements in Article 16 of DORA. For the entities it lists, Articles 5 to 15 of Chapter II do not apply. Those entities meet instead the eight obligations of Article 16(1), points (a) to (h), and the documentation and review duty of Article 16(2).

Article 16(3) mandated the European Supervisory Authorities (ESAs) to develop regulatory technical standards (RTS) specifying the content of the simplified framework. The Joint Committee of the ESAs published its final report on these draft RTS in January 2024 (JC 2023 86), and the Commission adopted them as Delegated Regulation (EU) 2024/1774. Title II of that regulation deals with the full framework, and Title III (Articles 28 to 41) with the simplified one.

The simplified framework is not the proportionality principle. Article 4 applies to every financial entity: it requires the rules of Chapter II, among others, to be implemented in a way that takes account of the entity's size, overall risk profile and the nature, scale and complexity of its services, activities and operations. Article 16 is a separate regime that only the entities it names can use. A small financial entity outside that list applies Articles 5 to 15, proportionately.

Which financial entities can use the simplified framework?

Article 16(1) gives a closed list. Articles 5 to 15 do not apply to:

  1. small and non-interconnected investment firms (in practice, the firms that meet the conditions of Article 12(1) of the Investment Firms Regulation, Regulation (EU) 2019/2033);
  2. payment institutions exempted pursuant to Directive (EU) 2015/2366 (PSD2, whose Article 32 sets the exemption conditions);
  3. institutions exempted pursuant to Directive 2013/36/EU in respect of which the Member State has decided not to apply the option referred to in Article 2(4) of DORA;
  4. electronic money institutions exempted pursuant to Directive 2009/110/EC (whose Article 9 sets the optional exemptions);
  5. small institutions for occupational retirement provision.

Being a microenterprise or a small or medium-sized enterprise is not enough. A small credit institution, insurer, asset manager or crypto-asset service provider outside this list applies the full Articles 5 to 15, scaled under Article 4. Microenterprise status relieves an entity of some specific requirements inside the full framework (for example, Article 6(5) allows a microenterprise to review its framework periodically rather than at least once a year), but it does not open the Article 16 regime.

The legal category decides. Check your authorisation, and where it is unclear whether an exemption under PSD2, the Electronic Money Directive or the Capital Requirements Directive covers you, ask your competent authority to confirm your status before you build on the simplified regime. Our scope determination tool starts from the same question, and the sector pages for investment firms, payment institutions and pension funds show how each category sits.

What must the simplified framework contain?

Article 16(1), second subparagraph, requires the listed entities to:

  1. (a) put in place and maintain a sound and documented ICT risk management framework that details the mechanisms and measures aimed at a quick, efficient and comprehensive management of ICT risk, including for the protection of relevant physical components and infrastructures;
  2. (b) continuously monitor the security and functioning of all ICT systems;
  3. (c) minimise the impact of ICT risk through the use of sound, resilient and updated ICT systems, protocols and tools which are appropriate to support the performance of their activities and the provision of services and adequately protect availability, authenticity, integrity and confidentiality of data in the network and information systems;
  4. (d) allow sources of ICT risk and anomalies in the network and information systems to be promptly identified and detected, and ICT-related incidents to be swiftly handled;
  5. (e) identify key dependencies on ICT third-party service providers;
  6. (f) ensure the continuity of critical or important functions, through business continuity plans and response and recovery measures, which include, at least, back-up and restoration measures;
  7. (g) test, on a regular basis, the plans and measures referred to in point (f), as well as the effectiveness of the controls implemented in accordance with points (a) and (c);
  8. (h) implement, as appropriate, relevant operational conclusions resulting from the tests referred to in point (g) and from post-incident analysis into the ICT risk assessment process, and develop, according to needs and ICT risk profile, ICT security awareness programmes and digital operational resilience training for staff and management.

Full framework vs simplified framework

The table compares the two regimes on the points where small entities most often hesitate. References are to DORA unless marked RTS (Delegated Regulation (EU) 2024/1774).

TopicFull framework (Art. 5 to 15, Title II RTS)Simplified framework (Art. 16, Title III RTS)
WhoEvery financial entity in scope that is not listed in Art. 16(1), applied proportionately (Art. 4)Only the five categories listed in Art. 16(1)
GovernanceManagement body defines, approves, oversees and is responsible for the framework (Art. 5)Governance and organisation specified in Art. 28 RTS
Control functionIndependent ICT risk control function, under a three lines of defence or equivalent model (Art. 6(4))Not named in Art. 16; check Art. 28 RTS for the governance and audit arrangements
StrategyDigital operational resilience strategy (Art. 6(8))Not named in Art. 16
Identification, protection, detectionArt. 8 to 10Art. 16(1)(a) to (d); Art. 29 to 38 RTS
Continuity, backup, restorationArt. 11 and 12Business continuity plans with at least backup and restoration (Art. 16(1)(f)), tested regularly (Art. 16(1)(g)); Art. 39 and 40 RTS
Learning and awarenessArt. 13 and 14Lessons from tests and post-incident analysis, awareness and training according to risk profile (Art. 16(1)(h))
Framework reviewAt least once a year, periodically for microenterprises, and after major ICT-related incidents (Art. 6(5))Periodically and after major ICT-related incidents, in line with supervisory instructions (Art. 16(2))
Review report formatArt. 27 RTSArt. 41 RTS
Incidents, testing, ICT third-party riskApply to both regimes (Chapters III, IV and Chapter V, Section I), with no threat-led penetration testing for Art. 16(1) entities (Art. 26(1))

Implement the simplified framework step by step

Title III of Delegated Regulation (EU) 2024/1774 turns the eight duties into concrete requirements. Its articles follow a logical order that you can use as a work plan:

  1. Confirm eligibility. Record the Article 16(1) category you fall under, the authorisation or exemption decision that proves it, and the date you checked. If your competent authority confirmed it, keep that correspondence.
  2. Set governance and write the framework down. Article 28 RTS covers governance and organisation, with the management body holding overall responsibility. Assign named owners for each ICT task and document the framework as Article 16(1)(a) requires.
  3. Write the information security policy and classify your assets. Article 29 RTS covers the information security policy and measures, Article 30 RTS the classification of information assets and ICT assets. Map which assets support critical or important functions: point (f) of Article 16(1) and most of the RTS key off that list.
  4. Run ICT risk management. Article 31 RTS sets out how to identify, assess and treat ICT risk under the simplified regime. Our guide to running the ICT risk assessment describes the method for the full framework; under Article 16 the steps are lighter but the logic is the same.
  5. Implement protection controls. Physical and environmental security (Article 32 RTS), access control (Article 33), ICT operations security (Article 34), data, system and network security (Article 35), ICT security testing (Article 36), ICT systems acquisition, development and maintenance (Article 37), and ICT project and change management (Article 38).
  6. Organise detection and incident handling. Article 16(1)(b) and (d) require continuous monitoring and prompt detection, and swift handling of ICT-related incidents. Define who watches what, the criteria that start a response, and how an incident is escalated into the classification and reporting process of Article 18 and 19.
  7. Map your ICT third-party dependencies. Article 16(1)(e) asks for the key dependencies. The register of information under Article 28(3), which still applies to you, gives the structured list to start from.
  8. Write the ICT business continuity plan. Article 39 RTS sets out its components. Point (f) of Article 16(1) requires, at a minimum, backup and restoration measures. Resiplan, a SaaS for DORA, business continuity and GRC, can help you build and test your ICT business continuity plan, and our business impact analysis page covers the analysis that feeds it.
  9. Test, learn and train. Article 40 RTS governs the testing of the business continuity plans. Article 16(1)(g) requires the plans, the backup and restoration measures and the effectiveness of your controls to be tested regularly, and point (h) requires the conclusions to go back into the risk assessment, alongside awareness and training for staff and management.

Before you rely on a specific paragraph of the RTS, read it in the official EUR-Lex text: this sequence names the articles, not every obligation inside them. Our RTS and ITS overview places Delegated Regulation (EU) 2024/1774 among the other Level 2 texts.

How often must the framework be reviewed and documented?

Article 16(2) requires the framework to be documented and reviewed periodically and upon the occurrence of major ICT-related incidents, in compliance with supervisory instructions. It must be continuously improved on the basis of lessons derived from implementation and monitoring, and a report on the review must be submitted to the competent authority upon its request.

Article 16(2) does not set a fixed interval. The full framework, by contrast, must be reviewed at least once a year under Article 6(5). The periodicity under Article 16 therefore follows your competent authority's instructions: find out whether it has issued any, and record the interval you chose and why. Article 41 RTS sets the format and content of the review report, so build the report to that article from the first review rather than reformatting it when the authority asks.

Which DORA obligations still apply in full?

Article 16 replaces Articles 5 to 15 only. The rest of the regulation applies to the listed entities, with proportionality under Article 4:

  • ICT-related incident management, classification and reporting (Articles 17 to 23). Major incidents are reported to the competent authority; see our DORA incident reporting guide.
  • Digital operational resilience testing (Articles 24 and 25). Threat-led penetration testing does not apply: Article 26(1) excludes the entities referred to in Article 16(1). See the TLPT page for who is in scope.
  • ICT third-party risk management (Articles 28 to 30), including the register of information of Article 28(3) and the key contractual provisions of Article 30.

The simplified regime lightens the ICT risk management framework, not the other pillars. Our DORA compliance checklist lists the evidence expected for each of them.

Common mistakes small entities make

  1. Assuming eligibility from size alone. Article 16(1) lists legal categories, not size thresholds. A small insurer or credit institution that is not exempted under the directives named in Article 16(1) does not qualify.
  2. Writing a policy with no test evidence. Article 16(1)(g) requires regular tests of the continuity plans and of the effectiveness of the controls. A framework document without test records does not show either.
  3. Backing up without restoring. Point (f) requires backup and restoration measures, and point (g) requires them to be tested. A backup that has never been restored is an untested measure.
  4. Ignoring ICT third-party dependencies. Point (e) requires the key dependencies on ICT third-party service providers to be identified, and Articles 28 to 30 still apply in full.
  5. Not tracing the review after a major incident. Article 16(2) requires a review upon the occurrence of a major ICT-related incident, and point (h) requires post-incident lessons to reach the risk assessment. Keep the review record and the change it produced.

For the policy set behind these steps, see the policies DORA names, and for templates covering Pillar 1, the ICT Risk Management Playbook.

Sources

Frequently asked questions

Is every SME in the financial sector eligible for the DORA simplified framework?

No. Article 16 applies only to the entities it lists: small and non-interconnected investment firms, exempted payment institutions, certain exempted credit institutions, exempted electronic money institutions and small institutions for occupational retirement provision. Other small entities apply Articles 5 to 15 proportionately under Article 4.

Does the simplified framework exempt me from DORA incident reporting?

No. Article 16 replaces only Articles 5 to 15. Incident management and reporting (Articles 17 to 23), resilience testing (Articles 24 and 25) and ICT third-party risk requirements, including the register of information (Articles 28 to 30), still apply. Only threat-led penetration testing is excluded, by Article 26(1).

Where are the detailed requirements of the simplified framework defined?

In Title III (Articles 28 to 41) of Commission Delegated Regulation (EU) 2024/1774, the regulatory technical standards adopted under Article 16(3) of DORA.

When must the simplified ICT risk management framework be reviewed?

Periodically and upon the occurrence of major ICT-related incidents, in compliance with supervisory instructions (Article 16(2)). DORA sets no fixed interval for the simplified framework, unlike the at least yearly review of Article 6(5) for the full framework. A report on the review must be submitted to the competent authority upon its request.

Do I need a business continuity plan under the simplified framework?

Yes. Article 16(1)(f) requires business continuity plans and response and recovery measures for critical or important functions, including at least backup and restoration measures, and point (g) requires them to be tested regularly.