Auditen
Home / Frameworks / DORA / Proportionality: how DORA scales with size and risk
DORA · Art. 4

Proportionality: how DORA scales with size and risk

Proportionality requires financial entities to scale the implementation of DORA’s ICT risk management and resilience requirements based on their size, internal governance, nature, scale, and complexity. It ensures that smaller or less complex firms are not burdened with the same administrative overhead as systemic institutions, provided they still manage their specific risks effectively.

What it means

In practice, proportionality means there is no "one-size-fits-all" checklist for DORA. The regulation recognizes that a small investment firm and a global systemic bank have different risk profiles; therefore, the depth, frequency, and formality of their controls should differ accordingly.

The intent is to avoid disproportionate costs and operational burdens on smaller entities while maintaining an overall level of resilience across the EU financial sector. However, proportionality does not exempt any entity from the core objectives of the regulation—it only allows for a scaled approach to how those objectives are achieved.

When implementing controls, firms must justify their choices based on objective criteria such as the volume of transactions, the criticality of the services provided, and the complexity of their ICT infrastructure.

How to meet it

Evidence an auditor asks for

  • A written Proportionality Framework or Policy detailing the criteria used to scale DORA requirements.
  • An asset register where each system is assigned a criticality level, linked to the corresponding level of control implementation.
  • Board meeting minutes showing that the management body has reviewed and approved the scaled approach to ICT risk management.
  • A gap analysis or compliance mapping document that explicitly justifies "simplified" implementations by referencing the proportionality assessment.

Common pitfalls

  • Using proportionality as a justification for omitting core security controls (e.g., claiming you are too small to need multi-factor authentication).
  • Applying a generic template from a larger firm without adjusting it, leading to inefficient and unsustainable operational overhead.
  • Failing to document the *why* behind the scaling, leaving the organization unable to defend its implementation choices during an audit.