DORA Proportionality: What It Actually Means and How to Document It

If you work in compliance at a smaller financial entity — a payment institution, an investment firm, a pension fund — you have probably heard that DORA applies "proportionally." That sounds reassuring. But what does it actually mean for the work you need to do?

The short answer: proportionality does not let you skip DORA. All five pillars still apply to every entity in scope. What proportionality does is let you scale the depth and complexity of your implementation to match the size, risk profile, and operational complexity of your organisation. A regional payment institution does not need the same ICT risk management apparatus as a systemically important bank. But it still needs one.

The catch is that proportionality only works if you can demonstrate it. If a supervisor asks why your resilience testing programme is lighter than what the RTS describes, you need a documented answer — not just a feeling that your organisation is small enough to do less.

This guide walks through what proportionality means in practice, who qualifies for the simplified framework, what changes for each pillar, and how to build a proportionality assessment that actually holds up.

What Article 4 Actually Says

Article 4 of DORA establishes the proportionality principle in three paragraphs. The core message is in paragraph 1:

Financial entities shall implement the ICT risk management rules in accordance with the principle of proportionality, taking into account their size and overall risk profile, and the nature, scale and complexity of their services, activities and operations.

Paragraph 2 extends this to incident management (Chapter III), resilience testing (Chapter IV), and third-party risk management (Chapter V, Section I). So proportionality is not limited to the risk management framework — it applies across the regulation.

Paragraph 3 gives competent authorities the job of checking whether you have applied proportionality correctly. They will do this based on reports you submit under Article 6(5) and Article 16(2).

In practice, three criteria drive the proportionality assessment:

• Size and overall risk profile — How many employees, what is your balance sheet, how much systemic risk do you carry?
• Nature of services — Are you providing critical infrastructure to the financial system, or a narrower set of services to a limited client base?
• Scale and complexity of operations — How many ICT systems do you run, how many third-party providers do you rely on, how interconnected are your operations?

These are not binary. There is no checkbox that says "small entity, reduced requirements." It is a sliding scale, and your position on it needs to be justified.

Who Qualifies for the Simplified Framework

DORA defines two distinct groups that get formal relief: Article 16 entities and microenterprises. They are treated differently.

Article 16 Entities — Simplified ICT Risk Management Framework

Certain categories of financial entities are entirely exempt from the full ICT risk management framework in Articles 5 to 15. Instead, they follow the simplified framework set out in Article 16. These include:

• Small and non-interconnected investment firms (under MiFID II)
• Payment institutions exempted under PSD2 (Directive 2015/2366)
• Credit institutions exempted under CRD (Directive 2013/36/EU), where the member state has opted not to apply DORA's Article 2(4)
• Electronic money institutions exempted under the E-Money Directive (2009/110/EC)
• Small institutions for occupational retirement provision

If your entity falls into one of these categories, Article 16 is your starting point. You still need a sound and documented ICT risk management framework, but the specific requirements are lighter. The emphasis is on having the basics covered: risk identification, protection measures, detection capabilities, and a business continuity plan.

Microenterprises — Specific Exemptions

A microenterprise under DORA is a financial entity with fewer than 10 employees and annual turnover or balance sheet total below EUR 2 million. Trading venues, central counterparties, trade repositories, and central securities depositories cannot qualify regardless of size.

Microenterprises stay within the full ICT risk management framework (Articles 5 to 15 apply), but they get specific exemptions from certain requirements across all pillars. These are not optional reductions — they are carved out in the regulation itself.

Everyone Else — Proportionality Without a Label

Most financial entities do not fall into either category above. If you are a mid-sized insurer, a regional bank, or a larger payment institution, you are subject to the full requirements. But Article 4 still applies. You can and should calibrate the depth and formality of your implementation to your actual risk profile.

The difference is that you do not get automatic exemptions. You have to make the proportionality argument yourself and document it.

What Proportionality Means Across the Five Pillars

Here is how proportionality plays out in practice for each pillar, comparing what a larger entity would typically do versus what a smaller or less complex entity might justifiably do.

Pillar 1: ICT Risk Management (Art. 5–16)

Applies to everyone: A documented ICT risk management framework, approved by the management body, with clear ownership and accountability. Where proportionality matters:

• Asset inventory depth. A large bank maps thousands of ICT assets with automated discovery tools. A smaller entity can maintain a spreadsheet-based inventory, as long as it covers all assets supporting Critical or Important Functions.
• Risk assessment frequency. Annual is the baseline. Larger or more dynamic environments may need quarterly or continuous assessments.
• Business continuity testing. Everyone needs BCP tests. A smaller entity can run tabletop exercises rather than full failover simulations, provided the scenarios are realistic.
• Dedicated ICT risk function. Larger entities need a separate control function. Microenterprises are explicitly exempt from this, and smaller entities can assign the responsibility to an existing role — but it must be clearly documented.

Pillar 2: Incident Management (Art. 17–23)

Applies to everyone: An incident classification process, the ability to detect and report major incidents within the required timelines (4-hour initial notification, 72-hour interim report, 1-month final report). Where proportionality matters:

• Classification tooling. Large entities may use automated classification engines. Smaller entities can work with manual classification against the eight criteria in Article 18, as long as the process is documented and someone is trained to run it.
• Threat intelligence. The regulation expects entities to monitor cyber threats. For a smaller entity, this does not require a dedicated threat intelligence team — subscribing to relevant sector alerts and CERT feeds can be sufficient.
• Post-incident cost estimation. Microenterprises are explicitly exempt from estimating aggregated annual costs and losses from major ICT incidents.

Pillar 3: Resilience Testing (Art. 24–27)

Applies to everyone: A risk-based testing programme covering ICT systems that support Critical or Important Functions. Where proportionality matters:

• Testing scope and frequency. All entities must test, but the type and frequency should reflect available resources and actual risk exposure. Smaller entities are not expected to run the same testing programme as a G-SIB.
• Threat-led penetration testing (TLPT). Only significant entities identified by competent authorities under Article 26 are required to perform TLPT every three years. Microenterprises are explicitly exempt.
• Internal vs external testers. Smaller entities can use internal resources for vulnerability assessments. TLPT, where required, must involve external testers certified under the TIBER-EU framework.

Pillar 4: Third-Party Risk Management (Art. 28–30)

Applies to everyone: A Register of Information covering all contractual arrangements with ICT third-party service providers, submitted annually to the competent authority. Where proportionality matters:

• Third-party risk strategy. Most entities need a documented strategy for managing ICT third-party risk. Microenterprises are explicitly exempt from this requirement (Article 28(2)).
• Contract clauses. Article 30 sets out mandatory clauses for ICT contracts. These apply to everyone, but for contracts supporting non-critical functions, the depth of negotiation and monitoring can be lighter.
• Audit rights. Microenterprises that cannot negotiate direct audit and inspection rights into their contracts can delegate this to an independent third party — a practical recognition that a 5-person firm has limited leverage with a major cloud provider.
• Subcontracting chains. All entities must assess the impact of subcontracting, but the depth of that analysis should reflect the criticality of the function and the complexity of the chain.

Pillar 5: Information Sharing (Art. 45)

This pillar is voluntary. There is no mandatory requirement to participate in cyber threat information sharing arrangements. Proportionality here means that smaller entities are not expected to set up or join threat intelligence sharing platforms, though they are encouraged to do so.

Specific Microenterprise Exemptions — The Full List

For clarity, here is a consolidated list of what microenterprises (fewer than 10 employees, under EUR 2 million turnover/balance sheet) are exempt from:

ICT Risk Management:

• Assigning a dedicated role to monitor ICT third-party service provider arrangements
• Designating a separate control function for ICT risk management
• Maintaining a crisis management function for BCP activation
• Conducting internal audits of the ICT risk management framework
• Conducting internal audits of ICT response and recovery plans
• Performing risk assessments upon major changes to network and information system infrastructure
• Performing risk assessments on legacy ICT systems
• Notifying competent authorities about changes made following post-incident reviews
• Estimating aggregated annual costs and losses caused by major ICT incidents

Incident Reporting:

• Reporting recurring incidents to competent authorities (major incident reporting still applies)

Resilience Testing:

• Threat-led penetration testing (TLPT)

Third-Party Risk:

• Developing a formal ICT third-party risk strategy
• Direct audit and inspection rights (may delegate to an independent third party)

What still applies in full: incident classification, major incident reporting timelines, the Register of Information, annual submission to the competent authority, Article 30 contract clause requirements, and the core ICT risk management framework.

How to Document Your Proportionality Assessment

This is where many entities fall short. They apply proportionality in practice — running a lighter testing programme, maintaining a simpler asset register — but they never write down why. When a supervisor asks, the answer is "we are small," which is not an assessment. It is an opinion.

A documented proportionality assessment gives you an audit trail. It shows that you considered the criteria in Article 4, mapped them to your specific situation, and made deliberate choices about your implementation approach. It does not need to be a 50-page report. For most entities, a structured document of 5 to 10 pages is enough.

What the Document Should Contain

1. Entity Profile

Start with the facts. Document your entity type, authorisation status, number of employees, balance sheet total, annual turnover, and the member state where you are supervised. State whether you qualify as a microenterprise or an Article 16 entity.

2. Services and Activities

Describe what your entity does. List the financial services you provide, the client segments you serve, and the jurisdictions you operate in. Identify which of your functions are Critical or Important Functions under DORA.

3. ICT Landscape Overview

Summarise your ICT environment: how many systems you operate, how many third-party ICT providers you rely on, whether you use cloud infrastructure, and how complex your technology stack is. You do not need a full asset inventory here — just enough to show the scale and complexity of your operations.

4. Risk Profile Summary

Describe your overall risk exposure. Consider factors like: how much of your service delivery depends on ICT, whether a disruption at your entity would have systemic impact, your history of ICT incidents, and the sensitivity of the data you process.

5. Proportionality Assessment Per Pillar

This is the core of the document. For each of DORA's five pillars, explain:

• What the full requirement is
• How you have implemented it
• Where you have scaled back the depth or formality of your implementation
• Why that level of implementation is appropriate given your size, risk profile, and complexity

Be specific. "We are a small entity so we do less" is not a proportionality assessment. "We have 15 employees, three ICT systems supporting one Critical or Important Function, and two third-party providers. Our annual resilience testing programme consists of vulnerability scanning and a tabletop BCP exercise, which we consider proportionate because..." — that is.

6. Board Approval

The management body should review and approve the proportionality assessment. This connects to Article 5, which places ICT risk governance at board level. A proportionality assessment that was never seen by the board is a weaker document.

How Often to Review

Review your proportionality assessment at least annually, or whenever there is a material change in your entity's size, risk profile, or operational complexity. If you acquire a new business line, onboard a major new ICT provider, or experience a significant incident, your proportionality position may have shifted.

A Simple Template Outline

If you are starting from scratch, here is a workable structure:

• Document control — Version, date, author, approver
• Entity classification — Type, size, authorisation, microenterprise/Article 16 status
• Business overview — Services, clients, jurisdictions, CIFs
• ICT environment — Systems, providers, cloud usage, complexity
• Risk profile — Systemic relevance, incident history, data sensitivity
• Pillar-by-pillar assessment — For each pillar: requirement, implementation, justification
• Conclusion and board sign-off — Summary position, date of next review, board resolution reference

Common Mistakes

Treating proportionality as exemption. Proportionality lets you scale your implementation. It does not remove obligations. Every entity in scope must have an ICT risk management framework, report major incidents, test resilience, maintain a Register of Information, and manage third-party risk. The question is how, not whether. Not documenting the reasoning. If you cannot explain why your implementation level is appropriate, a supervisor will assume it is not. The proportionality assessment is your evidence. Without it, you are relying on the supervisor's interpretation of your situation rather than your own. Applying proportionality inconsistently. Some entities reduce their testing programme but then also reduce their incident reporting capability, without considering that the two are linked. If you do less testing, your incident detection may need to be stronger, not weaker. Proportionality should be assessed as a coherent whole, not pillar by pillar in isolation. Forgetting to update. A proportionality assessment from 2025 may not reflect your situation in 2026. If your entity has grown, taken on new services, or started relying on more ICT providers, the basis for your original assessment has changed. Confusing microenterprise exemptions with general proportionality. The specific exemptions for microenterprises are carved out in the regulation. If you do not meet the microenterprise definition (fewer than 10 employees, under EUR 2 million), you cannot claim those exemptions. You can still apply proportionality, but you need to justify it under Article 4 rather than pointing to a specific carve-out.

Where to Start

If you have not done a proportionality assessment yet, start with three questions:

• What category are you? Determine whether you qualify as a microenterprise, an Article 16 entity, or neither. This sets the baseline.
• What are your Critical or Important Functions? Everything in DORA revolves around CIFs. If you have not identified yours, proportionality is impossible to assess because you do not know what matters most.
• Where are you doing less than the full requirement? Be honest about where your implementation is lighter. Then document why that level is appropriate for your specific situation.

Proportionality is one of the more practical features of DORA. It recognises that a regulation covering 22,000 entities cannot apply identically to all of them. But it only works if you do the work to justify your position. The assessment itself does not need to be complex — it needs to be honest, specific, and signed off by the people accountable for ICT risk at your organisation.