Proportionality applies to everyone
The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025. Article 4 sets proportionality as a general principle: financial entities implement the ICT risk management rules in Chapter II taking into account their size, their overall risk profile and the nature, scale and complexity of their services, activities and operations. Competent authorities apply the same principle when they review compliance.
Proportionality is not an exemption. It changes how deep an obligation goes, not whether it applies. A small investment firm and a large bank both need an ICT risk management framework under Articles 5 to 15; the bank's will be larger, more formal and more tested. Article 1 of Delegated Regulation (EU) 2024/1774 lists the elements of size and risk profile that entities and authorities take into account, from the number of clients and the services provided to the criticality of the functions supported by ICT and the use of outsourcing.
What proportionality looks like in practice
Proportionality shows up in the detail, not in the headings. Every entity under Articles 5 to 15 needs a documented framework, an information security policy, an asset inventory, a risk assessment, business continuity arrangements and testing. What varies is how formal each element is and how often it is reviewed.
A firm with a handful of systems might hold its asset inventory in a single register reviewed twice a year; a group with hundreds of applications will need automated discovery and continuous updates. A small entity might test its continuity plan with a tabletop exercise; a larger one will run technical failover tests. Both meet the same article. The difference has to be justified by the entity's profile and written down, because a supervisor will ask why the chosen depth is enough.
The simplified framework is something different. It replaces Articles 5 to 15 altogether for a closed list of entity types.
Who can use the simplified framework
Article 16(1) says Articles 5 to 15 do not apply to:
- Small and non interconnected investment firms.
- Payment institutions exempted under Directive (EU) 2015/2366 (PSD2).
- Institutions exempted under Directive 2013/36/EU where the Member State has not chosen to exclude them from DORA under Article 2(4).
- Electronic money institutions exempted under Directive 2009/110/EC.
- Small institutions for occupational retirement provision.
In each case, eligibility depends on a status defined in other legislation, not on headcount. A small payment institution qualifies because PSD2 exempts it, not because it is small. In a December 2025 answer published by ESMA, the European Commission confirmed that eligibility is assessed case by case: if an entity's main activity does not fall within one of the listed categories, it applies the full framework.
Where each status comes from
Each category points to a definition outside DORA, and that is where an entity should start when checking its position:
- Small and non interconnected investment firms are defined by the conditions in Article 12(1) of the Investment Firms Regulation, (EU) 2019/2033, which look at assets under management, client orders handled, client money held and balance sheet size, among others.
- Exempted payment institutions are those a Member State has exempted from full authorisation under Article 32 of PSD2, usually because their payment volume is low.
- Exempted electronic money institutions are those exempted under Article 9 of the second Electronic Money Directive, again based on limited activity.
- Exempted credit institutions are the specific institutions listed in Article 2(5) of the Capital Requirements Directive, where the Member State has kept them within DORA.
- Small institutions for occupational retirement provision are defined in DORA itself by the number of members in the pension schemes they operate.
Status can change. An exempted payment institution that grows past its national threshold and applies for full authorisation leaves Article 16 and moves to the full framework. Entities near a threshold should plan for that move rather than discover it at authorisation.
For Spanish entities, the competent authority depends on the sector: Banco de España for credit, payment and electronic money institutions, the CNMV for investment firms, and the Dirección General de Seguros y Fondos de Pensiones for occupational pension funds.
What the simplified framework still requires
Article 16(1) lists eight obligations that remain. The entities must:
- Put in place and maintain a sound, documented ICT risk management framework, including protection of physical components and infrastructure.
- Continuously monitor the security and functioning of all ICT systems.
- Use sound, resilient and updated systems, protocols and tools that protect the availability, authenticity, integrity and confidentiality of data.
- Identify and detect sources of ICT risk and anomalies promptly, and handle ICT incidents swiftly.
- 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 backup and restoration.
- Test those plans and the effectiveness of the controls regularly.
- Feed test results and lessons from incidents into the risk assessment, and develop security awareness and resilience training for staff and management.
Article 16(2) adds that the framework must be documented, reviewed periodically and after major ICT incidents, and improved continuously. A report on the review must be submitted to the competent authority on request.
The detail in Delegated Regulation 2024/1774
Title III of Delegated Regulation (EU) 2024/1774, Articles 28 to 41, turns these obligations into specific requirements:
- Governance (Article 28). The management body bears overall responsibility for the simplified framework, sets roles and responsibilities, and ensures staff receive ICT security training. The framework must be subject to internal audit in line with the entity's audit plan.
- Policy and assets (Articles 29 and 30). A documented information security policy, and the identification, classification and documentation of critical or important functions and the information and ICT assets that support them.
- Risk management and physical security (Articles 31 and 32). A process to identify, assess and treat ICT risk, and physical and environmental protection of ICT assets.
- Systems, protocols and tools (Articles 33 to 38). Further measures on how systems are secured and operated, through to ICT systems acquisition, development and maintenance (Article 37) and ICT project and change management (Article 38).
- Business continuity (Articles 39 and 40). The components of the business continuity plan and how it is tested.
- The review report (Article 41). Its format and content.
Simplified means fewer and less detailed requirements than the full framework in Title II. It does not mean informal. A small payment institution still needs written policies, an asset inventory, a risk assessment, access control, a tested continuity plan and an internal audit of the whole framework.
Where to start without an existing framework
For an entity starting from nothing, the order of work matters more than the volume. A workable sequence is:
- Confirm the route. Check the entity's status against the definitions above and record the conclusion, with the reasoning, so it can be shown to the supervisor.
- Identify critical or important functions. Most of the framework is scaled to them, so they come first: which services, if disrupted, would harm clients, the market or the entity's ability to continue.
- Inventory the assets and providers behind them. Systems, data, locations and the ICT third party providers each function depends on. The same inventory feeds the register of information.
- Assess and treat the risks. With a method written down, so the assessment can be repeated at each review.
- Write the policies the Delegated Regulation requires, and assign an owner to each control they describe.
- Put monitoring and incident handling in place before the continuity plan is tested, because the test should exercise the detection and response that a real disruption would rely on.
- Test, review, report. Run the first continuity test, carry out the internal audit, and produce the first review report even if nobody has asked for it yet.
The first cycle is the hardest. After that, the review report becomes the record of how the framework changes from one year to the next.
What goes in the review report
The review report is often the first document a supervisor asks for, because it summarises the state of the framework in one place. Article 41 of the Delegated Regulation requires it in a searchable electronic format and sets its content, including:
- Who was responsible for the review and the period it covers.
- A summary of findings, with a self assessment of the severity of the weaknesses, deficiencies and gaps identified.
- The measures to remedy them, with expected implementation dates, including follow up on gaps from earlier reports that remain open.
- A description of major changes to the framework since the previous report.
- Overall conclusions and planned developments.
An entity that cannot produce this report quickly usually has a deeper problem: the framework exists as a set of documents, but nobody tracks whether its controls are working.
What Article 16 does not remove
Article 16 disapplies Articles 5 to 15 and nothing else. The rest of DORA applies on its own terms, with the proportionality each chapter builds in.
- Incident management and reporting (Chapter III). Entities on the simplified framework still need a process to detect, classify and manage ICT incidents, and must report major ones to their competent authority within the DORA deadlines. The classification criteria are set in Delegated Regulation (EU) 2024/1772. The deadlines are covered in our guide to NIS2 and DORA incident reporting deadlines.
- Resilience testing (Chapter IV). Testing obligations are scaled, and advanced threat led penetration testing (TLPT) applies only to entities identified by their authorities, but testing does not disappear. Article 16(1) itself requires regular testing of continuity plans and controls.
- ICT third party risk (Chapter V). The contractual requirements for ICT services and the register of information required by Article 28(3) still apply. The practical work is covered in our guide to third party risk management under DORA and NIS2.
Why these obligations weigh more than the label suggests
The most common misreading of Article 16 is that "simplified" means "out of scope". For a small fintech or payment institution, the opposite can be true. These entities often run almost entirely on cloud providers and outsourced platforms: core systems, payment processing, identity, customer support. Every one of those arrangements needs to appear in the register of information, and contracts supporting critical or important functions need the provisions DORA sets out.
Incident reporting has the same effect. A small entity with no security operations has to be able to detect an incident, classify it against the criteria and report it within hours. That is an operational capability, not a document, and it is the same capability a large bank needs, at a smaller scale.
Microenterprises are a separate case
DORA defines a microenterprise, in Article 3(60), by reference to Commission Recommendation 2003/361/EC: fewer than 10 people and an annual turnover or balance sheet total of no more than EUR 2 million.
Being a microenterprise does not put an entity under Article 16. A microenterprise that is not one of the five listed types applies Articles 5 to 15, but DORA writes specific relief into those articles. For example, Article 6(4) requires a control function with an appropriate level of independence for managing ICT risk, but excludes microenterprises from that requirement. Recital 43 explains that microenterprises and entities on the simplified framework need not establish a dedicated role to monitor arrangements with ICT third party service providers.
The result is two different routes to a lighter regime: Article 16 for listed entity types, and microenterprise carve outs inside the full framework. An entity needs to know which route it is on before it designs anything, because the documents a supervisor will expect differ between them. A microenterprise on the full framework writes its documentation against Articles 5 to 15 and Title II of the Delegated Regulation; an Article 16 entity writes against Article 16 and Title III.
For the structure of DORA as a whole, see DORA: the five pillars, explained.
Building the framework on ISO 27001
An entity that already runs an ISO 27001 information security management system starts with much of the simplified framework in place. The overlap is close at the level of Article 16(1):
- Documented framework (point a): the ISMS itself, with its policy (clause 5.2), risk assessment (6.1.2) and the information security policies in Annex A control 5.1.
- Monitoring and detection (points b and d): logging (8.15) and monitoring activities (8.16), plus incident management (5.24 to 5.26).
- Secure systems and tools (point c): technical vulnerability management (8.8), network security (8.20) and cryptography (8.24), among others.
- Third party dependencies (point e): supplier relationship controls (5.19 to 5.22).
- Continuity and backup (point f): ICT readiness for business continuity (5.30), information security during disruption (5.29) and backup (8.13).
- Testing and learning (points g and h): continuity testing within 5.30, learning from incidents (5.27) and awareness, education and training (6.3).
The gaps are specific to DORA. ISO 27001 does not require classification and reporting of major ICT incidents to a financial supervisor, the register of information on ICT third party arrangements, a review report in the format Article 41 of the Delegated Regulation sets out, or business continuity tests built around scenarios where a critical or important function degrades to an unacceptable level. A certificate is evidence that a management system exists. It is not evidence of DORA compliance.
The practical approach is to treat DORA as an extension of the ISMS rather than a second programme: add the DORA requirements to the scope and the Statement of Applicability, map each Article 16 obligation to the controls that meet it, and build the missing pieces on top. The internal audit and management review that ISO 27001 already requires can then cover both, which also satisfies the internal audit requirement in Article 28 of the Delegated Regulation.
The other gap is operational. Article 16(1) asks for continuous monitoring of ICT systems and prompt detection of anomalies, which a policy cannot provide on its own. Qalea combines a compliance platform with guided support from a security team: the platform maps existing ISO 27001 controls to the DORA and Delegated Regulation requirements and tracks the gaps, and our team works with yours on the framework, the review report and the register. Qalea also operates EDR, SIEM and a 24/7 SOC, so the monitoring and detection obligations in Article 16(1) are met by controls that run continuously, with records an authority can review.
