DORA Compliance Guide for EU Fintech SMBs: 2026 Evidence Roadmap
Practical 2026 DORA compliance guide for European fintech SMBs: scope, evidence, incidents, ICT third-party risk, board oversight and remediation roadmap step.
In this article ↓
- The short answer
- Who this guide is for
- DORA scope for fintech SMBs
- What supervisors and partners expect in 2026
- DORA operating model at a glance
- Pillar 1: ICT risk management
- Evidence checklist
- Pillar 2: Incident management and reporting
- Pillar 3: Digital operational resilience testing
- Testing evidence that matters
- Pillar 4: ICT third-party risk
- Supplier evidence map
- Pillar 5: Information sharing
- Management-body and board responsibilities
- Board pack structure
- 90-day roadmap for fintech SMBs
- Days 1-15: Scope and evidence baseline
- Days 16-30: Gap analysis and operating design
- Days 31-60: Evidence build
- Days 61-90: Remediation and review
- Evidence index for a DORA review
- Common mistakes
- Mistake 1: Treating proportionality as an exemption
- Mistake 2: Keeping supplier data outside the risk process
- Mistake 3: Reporting incidents from memory
- Mistake 4: Running tests without remediation
- Mistake 5: Leaving the board out until review time
- Related reading
- Primary sources
- Bottom line
- FAQ
- What does DORA compliance mean for fintech SMBs in 2026?
- Which fintechs are usually in DORA scope?
- What evidence do supervisors and partner banks usually ask for?
- Can a smaller fintech rely on proportionality?
- What should a 90-day DORA programme deliver?
- Is DORA compliance handled only by compliance teams?
- Last reviewed: 29 April 2026
- ~18 min read
- All 5 DORA pillars covered
The short answer
DORA compliance in 2026 is no longer a deadline project. The Digital Operational Resilience Act — Regulation (EU) 2022/2554 — has applied since 17 January 2025.
For a European fintech SMB, the practical question is now:
Can you show that your ICT risk, incident, third-party, resilience testing and board-reporting controls actually operate?
That means keeping evidence, not only policies:
- management-body approval and review records;
- ICT risk register and control owners;
- incident classification and escalation logs;
- Register of Information for ICT third-party arrangements;
- supplier criticality and contract-clause tracking;
- business continuity and disaster recovery test results;
- remediation tracker with owners and dates;
- board or management-body reporting packs.
DORA applies directly across the EU, but day-to-day reporting and supervisory dialogue still happen through the relevant national competent authority (NCA). The operating model should therefore be EU-law aligned and jurisdiction-aware.
Who this guide is for
This guide is written for EU fintech SMBs that do not have a large internal regulatory engineering team:
- payment institutions and electronic money institutions;
- MiCA-authorised crypto-asset service providers;
- investment firms and brokers with material ICT dependency;
- fintechs operating under an EU licence with cloud, SaaS, banking-as-a-service or payment-processor dependencies;
- founder-led or scale-up financial entities preparing for supervisory review, partner-bank due diligence or investor diligence.
The article is not legal advice. It is an operating roadmap for building a DORA evidence pack that can be reviewed by compliance, technology, management and external stakeholders.
DORA scope for fintech SMBs
DORA applies to financial entities listed in Article 2 of the Regulation. For fintechs, the most common in-scope categories are payment institutions, electronic money institutions, investment firms, crypto-asset service providers authorised under MiCA, and credit institutions where the fintech has a banking licence.
Some service providers are not themselves financial entities, but still matter under DORA because the regulated fintech depends on them. Cloud platforms, core banking providers, payment processors, KYC vendors, fraud tools, customer-support systems, data platforms and software vendors can all become part of the DORA evidence set if they support a critical or important function.
The useful first exercise is not a legal memo. It is a scope table.
| Question | Evidence to keep | Owner |
|---|---|---|
| Which licensed entity is in DORA scope? | Licence register extract, internal entity map | Compliance / CEO |
| Which services are critical or important? | Critical-function register and business impact analysis | Risk / Operations |
| Which ICT assets support those services? | Asset inventory, system map, data-flow notes | CTO / Security |
| Which third parties support those assets? | Supplier register and Register of Information | Procurement / Risk |
| Which authority supervises the entity? | NCA mapping by licence type and jurisdiction | Compliance |
This table becomes the base layer for the rest of the programme.
What supervisors and partners expect in 2026
In 2026, a weak DORA programme usually fails because it cannot prove operation. A policy document may exist, but the evidence trail is missing.
The evidence questions are usually simple:
- Who owns ICT risk?
- When did the board or management body review the framework?
- Which incidents were assessed against DORA criteria?
- Which suppliers support critical or important functions?
- Which contracts have Article 30 clauses?
- Which business continuity tests were run?
- What changed after testing or incidents?
- Which remediation actions are late?
For fintech SMBs, this should not become a 300-control enterprise GRC programme. The better model is a smaller evidence-led operating system with named owners and review cadences.
Running a DORA readiness check for your board?
Book a free 15-min scoping call to identify which evidence gaps affect your specific NCA and licence type — no slide deck, no sales pitch.
Book a free 15-min call →DORA operating model at a glance
| DORA area | What to operate | Minimum useful evidence |
|---|---|---|
| Governance and ICT risk | ICT risk framework, roles, risk appetite, annual review | Approved framework, risk register, board pack |
| Incident management | Detection, classification, escalation and reporting | Incident log, classification rationale, timeline record |
| Resilience testing | Risk-based testing and remediation | Test plan, results, after-action report, tracker |
| ICT third-party risk | Due diligence, monitoring, contracts, exit | Register of Information, supplier assessments, clause tracker |
| Business continuity | Recovery objectives and tested playbooks | BCP/DR plans, RTO/RPO evidence, test records |
| Information sharing | Threat intelligence handling where relevant | Membership / source list, intake notes, actions taken |
This is the main DORA implementation principle for an SMB: keep the control set small enough to operate, but complete enough to defend.
The DORA SMB principle: A smaller evidence-led operating system with named owners and review cadences beats a 300-control enterprise GRC programme every time. Supervisors check that controls operate — not that they exist in a policy library.
Pillar 1: ICT risk management
DORA requires a documented ICT risk management framework. For a fintech SMB, the framework should explain how the company identifies, protects, detects, responds and recovers across ICT-supported financial services.
The framework should cover:
- management-body responsibility and reporting;
- ICT asset and dependency inventory;
- critical or important functions;
- risk assessment method;
- security controls and access management;
- logging, monitoring and vulnerability management;
- business continuity and disaster recovery;
- incident management;
- third-party ICT risk;
- review cadence and change control.
The common mistake is writing a generic ICT policy and calling it a framework. A DORA-ready framework links risks, controls, owners and evidence.
Evidence checklist
| Artefact | Why it matters | Review cadence |
|---|---|---|
| ICT risk management framework | Shows the operating model and accountability | At least annually and after material change |
| ICT risk register | Shows material risks, controls and owners | Quarterly or on material change |
| Asset and dependency inventory | Shows what supports critical services | Monthly/quarterly depending on change rate |
| Board / management reporting pack | Shows oversight and challenge | Quarterly or per board cycle |
| Remediation tracker | Shows control weaknesses are managed | Weekly/monthly until closed |
Pillar 2: Incident management and reporting
DORA requires financial entities to manage, classify and report major ICT-related incidents. Article 19 establishes the reporting obligation. The detailed classification and reporting process is developed through the related EU technical standards.
Operationally, a fintech needs one incident workflow with DORA decision points:
- Detect and record the incident.
- Assign owner and severity.
- Assess whether it is ICT-related.
- Classify against DORA major-incident criteria.
- Decide whether NCA reporting is triggered.
- Preserve the timeline and approval trail.
- Submit required reports through the local channel.
- Run root-cause analysis and remediation.
The widely used DORA reporting cadence for major ICT-related incidents is:
| Report | Timing logic | Evidence to preserve |
|---|---|---|
| Initial notification | Within 4 hours after classification as major, and no later than 24 hours after detection/awareness | Detection time, classification time, approver, submitted form |
| Intermediate report | Within 72 hours of the initial notification | Updated impact, containment status, affected services |
| Final report | Within one month of the latest intermediate report | Root cause, remediation, lessons learned |
Local submission channels, templates and portal instructions should be verified on the competent authority website before filing. For jurisdiction-specific links, use the DORA National Competent Authorities selected-jurisdiction hub.
Pillar 3: Digital operational resilience testing
DORA expects financial entities to test digital operational resilience. For fintech SMBs, this should be risk-based and connected to critical services, not a collection of disconnected scans.
The testing programme can include:
- vulnerability assessments;
- scenario-based incident exercises;
- backup restore tests;
- disaster recovery tests;
- business continuity tabletop exercises;
- supplier-failure simulations;
- access-control reviews;
- penetration testing where appropriate.
Threat-led penetration testing under Article 26 is not universal. It applies to financial entities identified by competent authorities according to the relevant criteria. Smaller fintechs should not claim TLPT readiness unless the scope is clear; they should maintain a proportionate testing programme and evidence of remediation.
Testing evidence that matters
| Test type | What it proves | Output |
|---|---|---|
| Backup restore test | Data can be recovered within expected time | Restore log, RTO/RPO result |
| Payment/service outage tabletop | Teams understand escalation and customer impact | Scenario notes, action list |
| Supplier failure exercise | Critical provider dependency is understood | Impact map, fallback decision |
| Vulnerability assessment | Technical weaknesses are found and tracked | Findings, risk rating, remediation status |
| BCDR test | Recovery plan works beyond paper | Test report, exceptions, owner sign-off |
Pillar 4: ICT third-party risk
This is usually the hardest DORA area for fintech SMBs because modern fintech stacks are supplier-heavy.
DORA Article 28 requires financial entities to manage ICT third-party risk and maintain a Register of Information for ICT third-party arrangements. Article 30 sets contractual requirements for ICT services, with additional expectations for services supporting critical or important functions.
For an SMB, the operating model should answer:
- Which suppliers provide ICT services?
- Which suppliers support critical or important functions?
- Which contracts lack DORA-required clauses?
- Which subcontractors are material?
- What happens if the supplier fails?
- How would the company exit or migrate?
- Who monitors the supplier after onboarding?
Supplier evidence map
| Supplier question | Evidence |
|---|---|
| Is this an ICT third-party service provider? | Supplier classification decision |
| Does it support a critical or important function? | Criticality assessment |
| Is the contract DORA-aligned? | Article 30 clause tracker |
| Is there concentration risk? | Provider dependency map |
| Can the service be exited? | Exit strategy and portability notes |
| Is performance monitored? | SLA/security review records |
The Register of Information should not be treated as a spreadsheet created once for filing. It is the live control that connects contracts, services, functions, entities and providers.
Pillar 5: Information sharing
DORA allows financial entities to participate in cyber threat information-sharing arrangements, subject to conditions. For many fintech SMBs, this does not require a large formal programme. It does require a clear way to receive, assess and act on relevant threat intelligence.
Useful evidence includes:
- threat-intelligence sources or communities used;
- internal process for reviewing relevant alerts;
- decision records where intelligence triggers action;
- security changes made because of threat information;
- management reporting where material threats affect risk posture.
The key point is not membership in every possible forum. It is proving that relevant threat information is considered and translated into action.
Management-body and board responsibilities
DORA makes digital operational resilience a management-body responsibility. For a fintech SMB, that does not mean the board must run technical operations. It means the management body must approve, understand and oversee the ICT risk framework.
The board or management body should see:
- top ICT risks and changes since last review;
- major incidents and near misses;
- supplier concentration and critical dependencies;
- resilience testing results;
- overdue remediation;
- material policy changes;
- NCA or partner-bank requests;
- exceptions accepted by management.
Board pack structure
| Section | What to include |
|---|---|
| Risk posture | Top ICT risks, risk appetite exceptions |
| Incidents | Significant incidents, classification decisions, lessons learned |
| Third parties | Critical providers, contract gaps, concentration risks |
| Testing | Recent tests, failed assumptions, remediation |
| Compliance | Register of Information status, NCA interactions |
| Decisions needed | Risk acceptances, budget, ownership changes |
This pack is one of the strongest "show me the evidence" artefacts because it proves DORA is governed, not only documented.
Board-level accountability is not optional under DORA. Article 5 makes the management body directly responsible for approving the ICT risk management framework and overseeing its implementation. A board that receives only annual updates does not satisfy the supervisory expectation of ongoing oversight.
90-day roadmap for fintech SMBs
Most fintech SMBs do not need a year-long transformation to become materially better prepared. They need a focused operating programme.
Days 1-15: Scope and evidence baseline
- Confirm the licensed entity and DORA scope.
- Identify critical or important functions.
- Build the initial ICT asset and supplier map.
- Collect existing policies, incident records, BCP/DR artefacts and supplier contracts.
- Map the relevant NCA by jurisdiction and licence type.
Days 16-30: Gap analysis and operating design
- Compare current controls to DORA pillars.
- Rate gaps by supervisory risk and operational impact.
- Define control owners and review cadences.
- Design the incident classification workflow.
- Start the Register of Information structure.
Days 31-60: Evidence build
- Update the ICT risk framework.
- Populate the ICT risk register.
- Build the supplier criticality assessment.
- Review critical supplier contracts against Article 30.
- Run at least one incident tabletop or BCDR test.
- Create the first management-body reporting pack.
Days 61-90: Remediation and review
- Close high-priority control gaps.
- Document unresolved gaps and accepted risks.
- Finalise incident-reporting playbook and escalation matrix.
- Validate Register of Information completeness.
- Run management review and capture decisions.
- Prepare an evidence index for partner-bank or supervisory review.
Want this 90-day roadmap delivered for your entity?
We run this programme for EU-licensed EMIs, PIs and CASPs. Your team commits 2–4 hours a week; we build the evidence pack.
Book a free 15-min call →Evidence index for a DORA review
When a supervisor, partner bank or investor asks for DORA readiness, avoid sending a zip file of disconnected policies. Use an evidence index.
| Evidence area | Documents / records |
|---|---|
| Governance | ICT risk framework, board minutes, reporting pack |
| Scope | Entity map, licence type, NCA mapping |
| ICT risk | ICT risk register, asset inventory, control mapping |
| Incidents | Incident policy, classification log, timeline records |
| BCDR | BCP/DR plan, test reports, RTO/RPO evidence |
| Third parties | Register of Information, supplier assessments, contracts tracker |
| Testing | Annual test plan, results, remediation |
| Remediation | Tracker, owners, due dates, closure evidence |
This makes the review faster and reduces the risk that the reviewer concludes the programme is only policy-level.
Practical tip: When a supervisor, partner bank or investor requests DORA evidence, respond with the evidence index first — not a zip file. A structured index signals a mature programme and cuts review time significantly. Include document owners and review dates so the reviewer can judge currency at a glance.
Common mistakes
Mistake 1: Treating proportionality as an exemption
Proportionality helps calibrate controls. It does not remove the obligation to manage ICT risk, incidents, testing and third-party dependencies.
Mistake 2: Keeping supplier data outside the risk process
Procurement, legal and compliance often hold different supplier lists. DORA requires one operating view of ICT third-party arrangements, criticality and contract status.
Mistake 3: Reporting incidents from memory
Incident reporting depends on timestamps and decisions. If detection time, classification time and approval trail are not recorded, the final report becomes difficult to defend.
Mistake 4: Running tests without remediation
A test without a remediation owner and due date is weak evidence. Supervisors look for the closed loop: test, finding, owner, deadline, closure.
Mistake 5: Leaving the board out until review time
Management-body oversight cannot be reconstructed at the end of the year. It needs regular reporting and recorded decisions.
Related reading
- DORA Incident Reporting 2026: Initial Notification, Intermediate Report and Final Report Timeline
- DORA Register of Information: A Complete Guide for Financial Institutions
- DORA Business Continuity and Disaster Recovery: Articles 11-12 Roadmap for 2026
- DORA Requirements in 2026: 10 Controls Financial Entities Must Keep Current
- DORA National Competent Authorities — selected jurisdiction guides
DORA by competent authority
DORA applies as EU law, but day-to-day reporting, evidence and supervisory dialogue runs through your National Competent Authority (NCA). Pick the jurisdiction-specific guide that matches your authorisation:
| Jurisdiction | DORA competent authority | Guide |
|---|---|---|
| Cyprus | CBC | Cyprus guide → |
| Denmark | Finanstilsynet | Denmark guide → |
| Estonia | Finantsinspektsioon | Estonia guide → |
| France | ACPR | France guide → |
| Germany | BaFin | Germany guide → |
| Ireland | Central Bank of Ireland | Ireland guide → |
| Italy | Banca d'Italia | Italy guide → |
| Latvia | Latvijas Banka | Latvia guide → |
| Lithuania | Lietuvos bankas | Lithuania guide → |
| Luxembourg | CSSF | Luxembourg guide → |
| Malta | MFSA | Malta guide → |
| Netherlands | DNB | Netherlands guide → |
| Sweden | Finansinspektionen | Sweden guide → |
See the DORA National Competent Authorities selected-jurisdictions hub for the full directory and the difference between NCAs and the EU ESAs (EBA, ESMA, EIOPA).
Primary sources
- Regulation (EU) 2022/2554 — DORA, EUR-Lex
- European Banking Authority — Digital Operational Resilience Act (DORA)
- EBA — Joint Technical Standards on major incident reporting
- ESMA — Digital Operational Resilience Act (DORA)
- EIOPA — Digital Operational Resilience Act (DORA)
Bottom line
For a European fintech SMB, DORA compliance in 2026 is an evidence discipline.
The winning operating model is simple:
- know which entity and services are in scope;
- assign ICT risk ownership;
- classify and record incidents consistently;
- keep the Register of Information current;
- test resilience and close findings;
- report ICT risk to the management body;
- maintain an evidence index that can survive external review.
That is the difference between having DORA documents and operating DORA controls.
FAQ
What does DORA compliance mean for fintech SMBs in 2026?
DORA compliance means operating and evidencing ICT risk management, incident classification and reporting, resilience testing, ICT third-party oversight, management-body reporting and remediation. It is not only a set of policies.
Which fintechs are usually in DORA scope?
Common in-scope fintech categories include payment institutions, electronic money institutions, investment firms, crypto-asset service providers authorised under MiCA and other financial entities listed in DORA Article 2.
What evidence do supervisors and partner banks usually ask for?
Typical evidence includes the ICT risk framework, ICT risk register, incident classification log, Register of Information, supplier assessments, contract gap tracker, resilience test reports, board packs and remediation tracker.
Can a smaller fintech rely on proportionality?
Yes, but proportionality changes the depth of controls, not the existence of the obligation. A smaller fintech can use simpler artefacts, but it still needs owners, current evidence, risk-based decisions and management-body oversight.
What should a 90-day DORA programme deliver?
A 90-day programme should deliver scope and NCA mapping, an evidence baseline, gap analysis, ICT risk register, incident workflow, Register of Information structure, supplier criticality review, resilience test evidence, board pack and remediation tracker.
Is DORA compliance handled only by compliance teams?
No. Compliance coordinates part of the programme, but DORA evidence requires technology, security, operations, legal, procurement, risk, business owners and the management body to operate together.