DORA Readiness for Fintech

Why this pillar exists

M ost regulated fintech operators in the EU treat DORA as a documentation exercise. They commission a gap analysis, write a policy bundle, and declare the project closed. Then the first ICT-related incident hits, and the gap between “we have a policy” and “we have an operating capability” becomes the only thing the regulator cares about.

This pillar is the operating capability, not the documentation.

The strategic question every fintech board should be asking

DORA introduces a single ICT risk framework across all EU financial services. The unfamiliar bit is the breadth: ICT risk management, incident reporting, operational resilience testing, and ICT third-party risk all live under one regulation.

The strategic question is simpler than the regulation:

Can we demonstrate, with evidence, that ICT failures don’t put customers at material risk — across our own systems and our third-party providers?

If the answer is yes, DORA is largely already done. If the answer is “we have a policy that says yes”, DORA is largely not yet started.

The 5 DORA Readiness Tiers

Five tiers, each a meaningful step. Most fintech we engage land at Tier 2 (policy in place, evidence patchy). Regulators expect Tier 4 (operating capability with full evidence) within the first surveillance cycle.

Tier 1 — Aware

Your firm knows DORA applies; a workstream exists; an owner is named; budget is allocated. Documentation is sparse. ICT register is missing or in a spreadsheet. No testing capability.

Tier 2 — Documented

Policies and procedures exist for all five DORA pillars. Roles and responsibilities mapped. Some evidence collected, much manual. ICT third-party register exists in spreadsheet form. Incident-reporting template ready but not stress-tested. Most operators sit here after a single project sprint.

Tier 3 — Operating

Policies translate to actual day-to-day controls. ICT register is in a queryable system, kept current via vendor-onboarding workflow. Incident detection capability runs, with documented MTTR. Resilience testing programme runs to a calendar. Some controls auto-validate.

Tier 4 — Demonstrable

Auditor-grade evidence available on demand for every control. ICT register includes fourth-party risk visibility for critical providers. Threat-led penetration testing programme delivers reports the board acts on. Incident-reporting clock proven sub-4-hour in tabletop exercises. Recovery-time objectives routinely met in tests.

Tier 5 — Anti-fragile

The ICT risk function is a strategic input to the firm. Resilience is designed into new products before launch. Cross-firm intelligence- sharing happens. Incidents become improvements within the same week.

Most operators target Tier 4 in year 1 of DORA, Tier 5 over 2-3 years.

The five DORA dimensions, mapped

DORA has five operational pillars. Each one is a measurable capability, not a document.

1. ICT risk management (Articles 5-15)

A working ICT risk register, refreshed quarterly. Each entry has owner, likelihood, impact, controls, and a residual risk score the board signs off on. Links from this register to the broader enterprise risk function.

2. ICT incident reporting (Articles 17-23)

A defined flow from detection → classification → reporting clock start → initial notification (within 4 hours of significant incident classification) → intermediate notification → final report. Tabletop exercises every 6 months until the timeline is reflexive, not aspirational.

3. Digital operational resilience testing (Articles 24-27)

A testing calendar with annual minimum coverage of vulnerability assessment, network security assessment, scenario-based testing, and business continuity testing. Threat-led penetration testing every 3 years for significant entities. Results feed Tier 4 evidence.

4. ICT third-party risk (Articles 28-44)

The biggest operational change for most operators. Article 28 requires:

• An ICT services register covering all third parties, classified by criticality
• Heightened due diligence and contractual controls for providers of critical or important functions
• Concentration-risk monitoring across the portfolio
• Exit strategies for critical providers
• Right-to-audit, right-to-information, right-to-substitute clauses in contracts

This is where most firms underestimate the work. The register isn’t a spreadsheet — it’s an operating capability that touches procurement, legal, security, and the business owner of every ICT-supported function.

5. Information sharing (Articles 45-49)

Voluntary, but worth doing. Participation in trusted information- sharing arrangements (e.g., FS-ISAC) elevates your operational maturity and gives you advance notice of supply-chain threats.

The ICT third-party register that actually works

A DORA-grade register has eight columns:

1. Provider (legal entity, group structure noted)
2. Service (described in business terms, not vendor terms)
3. Function supported (which of your functions; criticality rating)
4. Data categories handled (PII, payment data, etc.)
5. Sub-processors (fourth-party visibility for critical services)
6. Substitution effort (low / medium / high; documented exit plan)
7. Contractual controls (right to audit, right to information, incident reporting clock)
8. Last assurance (audit report, DPA refresh, certification renewal)

Maintained in a system that supports queries like “show me all third parties supporting Critical Function X” and “show me all providers with concentration in eu-west-1”. Not a spreadsheet that nobody queries.

The incident reporting clock

DORA’s reporting clock starts when an incident is classified as significant (not when it starts, and not when reporting feels convenient). The classification thresholds are spelled out in the RTS: duration, customers affected, geographic spread, data losses, economic impact, reputational impact.

Initial notification: within 4 hours of classification.

Most operators discover their first practice run that the classification step itself is the bottleneck. The detection capability spots the incident; the classification capability is missing or unrehearsed. Building the classification capability — and stress-testing it in tabletop — is week-1 work for any DORA programme.

DORA vs NIS2

For EU operators in scope of both DORA (financial services) and NIS2 (broader essential services), the right question is not “comply with both” but “build one operating capability and harvest evidence for both regimes”. Our cluster article on implementing ISO 27001 for regulated fintech walks through the control-mapping that lets you do this in practice.

What “in scope” actually means

DORA applies to most EU financial entities: credit institutions, payment institutions, e-money institutions, investment firms, insurance / reinsurance / intermediaries, central securities depositories, central counterparties, trade repositories, crypto-asset service providers, and more.

It also applies to ICT third-party service providers — including cloud providers — when they provide services to in-scope entities. If you’re a fintech that serves regulated financial customers, DORA reaches you indirectly through your customers’ contractual requirements even if you’re not directly in scope.

Several specific cases that catch firms by surprise:

• UK-based fintech serving EU customers — UK isn’t directly in scope, but EU customer contracts increasingly require DORA-aligned controls.
• Crypto-asset service providers — explicitly named in the regulation; most are still treating it as next year’s problem.
• Sub-£10M-revenue micro-entities — proportionality applies but doesn’t grant exemption; the operating bar is lower but non-zero.

Operating model for getting to Tier 4

Three phases, calendar-aligned, 12-20 weeks:

Phase 1 (weeks 1-4) — Programme set-up

• Sponsor named (typically COO or CISO with board mandate)
• Cross-functional team (security, legal, procurement, operations)
• Tier baseline assessed across all 5 dimensions
• 90-day plan with named owners per workstream

Phase 2 (weeks 5-12) — Capability build

• ICT register in queryable system (not spreadsheet)
• Incident classification + reporting flow stress-tested in tabletop
• Resilience testing calendar published, first quarter delivered
• Third-party contract uplift for critical providers (longest pole)

Phase 3 (weeks 13-20) — Evidence and proof

• Internal DORA audit (full evidence collection)
• Findings closed
• External assurance (auditor walk-through; some operators commission a third-party DORA readiness opinion)
• Board sign-off; programme transitions to BAU

How to know you’re getting it right

Five measurable signals:

• Tier ratings across all 5 dimensions — none below the firm’s target tier
• ICT register coverage — 100% of critical functions mapped to a named provider; fourth-party visibility on the most critical
• Time from incident detection to classification decision — trending towards minutes, not hours
• Resilience testing calendar adherence — 100% of planned tests delivered on time
• Internal-audit findings closure rate — trending down, not up

What to do tomorrow morning

If your firm is in scope of DORA and you don’t yet have a DORA programme, four hours of work this week:

• Hour 1: write your firm’s name into the regulation. (Yes, literally. Identify the article(s) you fall under.) Confirm with legal.
• Hour 2: sketch your current Tier rating on each of the 5 dimensions. Be honest. (Tier 2 is the most common honest answer.)
• Hour 3: list your 5 most critical ICT third parties. Note for each: contract status, last assurance date, exit feasibility.
• Hour 4: book a tabletop incident-classification exercise for next week with your security and operations leads. Use a real scenario from the past year if you have one. Time how long classification takes from detection.

By the end of next week you have a baseline you can defend at the next risk committee — and you know the size of your gap.