DORA Proportionality Principle: 2026 Guide for Smaller Financial Entities
DORA proportionality principle in 2026: how smaller EU financial entities scale ICT risk, testing, third-party controls and produce supervisory-ready evidence.
In this article ↓
- Short answer
- What proportionality changes and what it does not
- Where DORA uses proportionality
- Proportionality decision record
- Examples of proportionate implementation
- What smaller firms can simplify
- What smaller firms should not simplify away
- Proportionality by DORA workstream
- ICT risk management
- Incident management
- Resilience testing
- ICT third-party risk
- Proportionality evidence matrix
- Management-body approval
- Board decision table
- Triggers to revisit proportionality
- Common mistakes
- Mistake 1: Treating proportionality as an exemption
- Mistake 2: No written rationale
- Mistake 3: Simplifying evidence away
- Mistake 4: Ignoring third-party concentration
- Mistake 5: Copying a bank framework
- Related reading
- Primary sources
- Bottom line
- FAQ
- Does DORA proportionality mean smaller firms are exempt?
- What should a proportionality decision include?
- Can a small fintech use spreadsheets for DORA evidence?
- Which DORA areas should not be simplified away?
- When should proportionality be reviewed?
- How should the board approve proportionality?
Last reviewed: 29 April 2026
Key takeaways
- DORA proportionality changes the depth of controls, not the need to manage ICT risk.
- Smaller entities still need defensible evidence for governance, incidents, suppliers, testing and continuity.
- Supervisors ask why the chosen control depth matches the entity risk, services and dependencies.
- Fastest path: document scope and criticality -> scale controls -> record rationale -> revisit after material change.
Short answer
DORA proportionality means a financial entity can calibrate how it implements digital operational resilience controls to its size, risk profile, nature, scale and complexity.
It does not mean that smaller firms can ignore DORA.
In 2026, the practical test is evidence:
- Can you explain why your ICT risk framework is proportionate?
- Can you show which requirements were simplified and why?
- Can you prove that the simplified controls still operate?
- Can the management body defend the decision?
For fintech SMBs, proportionality is useful only when it is documented. An undocumented “we are small” argument is weak.
What proportionality changes and what it does not
| Area | What proportionality can change | What it does not remove |
|---|---|---|
| ICT risk framework | Complexity, tooling, number of policies, reporting depth | Need for a documented ICT risk framework |
| Incident management | Workflow sophistication, automation level, staffing model | Need to classify, manage and report major ICT incidents |
| Resilience testing | Test scope, frequency detail, method proportional to risk | Need for regular testing and remediation |
| Third-party risk | Due-diligence depth by provider criticality | Need to manage ICT third-party risk |
| Register of Information | Operating process and tooling | Need to maintain required third-party information |
| Board reporting | Format and depth of board pack | Need for management-body oversight |
| TLPT | Only applies to entities identified by competent authorities | Need for proportionate testing where TLPT does not apply |
The key distinction: proportionality affects implementation depth, not accountability.
Where DORA uses proportionality
DORA recognises that financial entities differ. A small EMI, a local investment firm and a large cross-border bank do not have the same technology estate or systemic footprint.
Proportionality should consider:
- size of the entity;
- overall risk profile;
- nature, scale and complexity of services;
- criticality of functions;
- degree of ICT dependency;
- customer and market impact;
- third-party concentration;
- data sensitivity;
- cross-border activity;
- past incidents and control maturity.
The more complex or critical the operation, the harder it is to justify a very light implementation.
Proportionality decision record
Every material simplification should have a decision record. This is the evidence that turns proportionality from a slogan into a defensible control decision.
| Field | What to capture |
|---|---|
| Decision ID | Stable reference |
| Requirement area | ICT risk, incidents, testing, third-party risk, BCDR |
| Proposed approach | What the entity will do |
| Simplification | What is lighter than a large-entity approach |
| Rationale | Why it fits size, risk, complexity and criticality |
| Residual risk | What risk remains |
| Approval | Owner / management-body approval where needed |
| Review trigger | Annual review, incident, growth, new product, new provider |
| Evidence | Policy, register, test result, board pack, risk register entry |
This record is especially useful for smaller entities that rely on simpler tooling, part-time roles or less complex testing.
Examples of proportionate implementation
| Topic | Smaller entity approach | Larger / more complex entity approach |
|---|---|---|
| ICT risk register | 10-30 material risks with named owners and quarterly review | Enterprise risk taxonomy, system-level KRIs and monthly governance |
| Incident workflow | Single triage workflow with DORA decision points and manual approval trail | Integrated tooling, automated escalation, 24/7 SOC workflow |
| Testing | Annual BCDR test, incident tabletop, vulnerability assessment | Multi-scenario test programme, purple-team exercises, TLPT if identified |
| Third-party risk | Critical supplier review, Register of Information, contract gap tracker | Full TPRM platform, continuous monitoring, multi-layer concentration analysis |
| Board reporting | Quarterly concise ICT risk pack | Committee-level dashboards, KRIs, multi-entity reporting |
| Evidence storage | Structured folder or lightweight GRC board | Integrated GRC platform with automated evidence workflows |
Both columns can be valid. The wrong approach is a smaller entity doing almost nothing and calling it proportionate.
Trying to apply DORA proportionately without underbuilding?
A 15-minute call can test whether your scope, rationale and evidence depth are defensible - no pitch, just calibration.
Book a free 15-min call →What smaller firms can simplify
Smaller financial entities can often simplify:
- number of separate policies;
- tooling stack;
- committee structure;
- reporting format;
- test programme complexity;
- vendor due-diligence depth for low-criticality providers;
- evidence workflow;
- risk taxonomy.
But simplification should preserve core outcomes:
- risks are known and owned;
- incidents are classified and escalated;
- critical services can recover;
- ICT third-party dependencies are visible;
- management body receives risk information;
- remediation is tracked.
What smaller firms should not simplify away
Some controls are dangerous to remove entirely.
| Control | Why it should remain |
|---|---|
| ICT risk register | Without it, risk ownership is not visible |
| Incident classification log | Without timestamps and decisions, reporting is hard to defend |
| Register of Information | Required for ICT third-party arrangements |
| BCDR test evidence | Recovery claims need proof |
| Critical supplier assessment | Third-party dependency is central to DORA |
| Board / management reporting | DORA governance requires oversight |
| Remediation tracker | Findings without closure are weak evidence |
Proportionality is strongest when it preserves the control objective while reducing unnecessary complexity.
Proportionality by DORA workstream
ICT risk management
For a smaller entity, the ICT risk framework can be compact. It should still describe governance, roles, critical functions, risk assessment, controls, incidents, testing, third-party risk and review cadence.
Minimum useful evidence:
- approved ICT risk framework;
- ICT risk register;
- owner matrix;
- management-body review record;
- remediation tracker.
See also: DORA ICT Risk Register Template.
Incident management
The workflow can be simple, but it must preserve the decision trail.
Minimum useful evidence:
- incident intake process;
- DORA major-incident classification criteria;
- escalation matrix;
- incident log with detection and classification timestamps;
- post-incident remediation.
See also: DORA Incident Reporting 2026.
Resilience testing
Smaller firms may not need a complex testing programme. They still need a risk-based programme that proves critical services can recover.
Minimum useful evidence:
- annual test plan;
- BCDR or DR test report;
- incident tabletop record;
- vulnerability assessment or security test evidence;
- remediation tracker.
TLPT should not be treated as universal. It applies to financial entities identified by competent authorities under the relevant criteria.
For a dedicated scope and evidence guide, see DORA TLPT: 2026 Guide to Threat-Led Penetration Testing.
ICT third-party risk
Third-party risk is usually where smaller fintechs need the most discipline, because they often depend heavily on cloud, SaaS, payment processors, KYC vendors and fraud tools.
Minimum useful evidence:
- Register of Information;
- supplier criticality assessment;
- contract clause tracker;
- exit strategy for critical providers;
- concentration-risk note;
- owner and review cadence.
See also: DORA Register of Information.
Proportionality evidence matrix
| Evidence | What it proves |
|---|---|
| Scope note | Entity understands DORA applicability |
| Critical-function map | Controls are scaled to business impact |
| ICT risk register | Risks are known, scored and owned |
| Proportionality decision record | Simplifications are justified |
| Board pack | Management body oversees ICT risk |
| Testing plan | Resilience testing is risk-based |
| Register of Information | Third-party ICT dependency is visible |
| Contract gap tracker | Critical supplier obligations are managed |
| Remediation tracker | Weaknesses are followed to closure |
This matrix is a practical audit file for proportionality.
Management-body approval
The management body should be able to approve and challenge proportionality decisions. The board pack does not need to include every control detail, but it should include:
- what is being simplified;
- why the simplification is appropriate;
- what residual risk remains;
- what evidence supports the decision;
- when the decision will be reviewed.
Board decision table
| Decision | Example board question |
|---|---|
| Smaller testing programme | Which critical functions are covered and what is excluded? |
| Manual incident workflow | How do we preserve timestamps and approval evidence? |
| Lightweight GRC tooling | How do we prevent missing evidence or stale ownership? |
| Supplier due diligence by tier | Which providers receive enhanced review and why? |
| Risk acceptance | Is residual risk within appetite and who owns it? |
Board minutes should record challenge, not only approval.
Triggers to revisit proportionality
What is proportionate today may stop being proportionate after business change.
Review proportionality when:
- the entity receives a new licence;
- transaction volume or customer base grows materially;
- a new critical or important function is launched;
- a major ICT incident occurs;
- a critical supplier changes;
- the entity enters a new jurisdiction;
- outsourcing or cloud dependency increases;
- a competent authority raises a concern;
- a test exposes a material weakness.
Set these triggers in the ICT risk framework so proportionality is not treated as a one-time judgement.
Common mistakes
Mistake 1: Treating proportionality as an exemption
Proportionality allows calibration. It does not remove core DORA obligations.
Mistake 2: No written rationale
If the entity cannot explain why a lighter control is appropriate, the decision is hard to defend.
Mistake 3: Simplifying evidence away
Small firms still need evidence. A simple spreadsheet, minutes and test report can be enough, but they must exist.
Mistake 4: Ignoring third-party concentration
A small fintech can still be highly dependent on one cloud provider, processor or KYC vendor. Small size does not mean low third-party risk.
Mistake 5: Copying a bank framework
A large-bank control framework can overwhelm a smaller firm and become unmaintainable. Better to implement a smaller set of controls that actually operate.
Related reading
- DORA Compliance Checklist 2026: Practical Implementation Guide
- DORA Compliance Guide for European Fintech SMBs: 2026 Evidence Roadmap
- DORA ICT Risk Register Template: 2026 Guide for Financial Entities
- DORA Register of Information: 2026 Guide for ICT Third-Party Risk
- DORA Board Responsibilities 2026: Management Body Evidence Checklist
Primary sources
- Regulation (EU) 2022/2554 — DORA, EUR-Lex
- European Banking Authority — Digital Operational Resilience Act (DORA)
- EBA — Regulatory Technical Standards on the ICT risk management framework
Bottom line
DORA proportionality is useful when it is explicit, risk-based and evidenced.
For smaller financial entities, the best approach is not to copy a large bank and not to underbuild.
Document a control model that fits the entity's size and complexity. It should still prove the core outcomes:
- ICT risks are owned;
- incidents are handled;
- third parties are controlled;
- resilience is tested;
- the management body can challenge the evidence.
FAQ
Does DORA proportionality mean smaller firms are exempt?
No. Proportionality allows controls and evidence to be calibrated to the entity's size, complexity, risk profile and services. It does not remove the need for ICT risk management, incident handling, testing, third-party oversight or board accountability.
What should a proportionality decision include?
A defensible decision should explain what is being simplified, why the simplification is appropriate, which risks remain, who approved the decision, what evidence supports it and when the decision will be reviewed.
Can a small fintech use spreadsheets for DORA evidence?
Yes, if the spreadsheets are controlled, current, owned and reviewable. Lightweight evidence can be acceptable for a smaller entity, but it still needs version control, owners, review dates, decision records and links to supporting documents.
Which DORA areas should not be simplified away?
Core outcomes should remain visible: ICT risks are owned, incidents are classified, suppliers are mapped, resilience is tested, remediation is tracked and the management body receives usable information.
When should proportionality be reviewed?
Review proportionality after material business growth, new licences, new jurisdictions, major ICT incidents, critical supplier changes, new critical functions, failed tests or supervisory feedback.
How should the board approve proportionality?
The board or management body should receive a concise rationale, residual risk view, evidence summary and review date. Minutes should record challenge and decisions, not only approval.