DORA Compliance Guide for Fintechs (2026)

The Digital Operational Resilience Act, known as DORA, has applied since 17 January 2025. It creates a single EU framework for how covered financial entities manage ICT risk, report major incidents, test resilience, and control technology-provider risk.

A fintech is not automatically in scope simply because it uses technology in finance. The legal entity, authorisation, activity, location, and any exemptions must be checked. Technology suppliers may also face strong contractual duties, while designated critical ICT providers can be overseen directly.

Confirm whether DORA applies

DORA covers a wide range of EU financial entities, including banks, payment institutions, electronic-money institutions, investment firms, insurers, crypto-asset service providers, crowdfunding service providers, and certain other regulated entities.

Some microenterprises receive proportionate treatment or exemptions from specified provisions. That is not a reason to assume the whole regulation disappears.

UK and US fintechs should check EU subsidiaries, authorisations, branches, customer relationships, and ICT services supplied to covered EU entities. Direct regulatory scope and customer contract requirements should be recorded separately.

Build an ICT risk-management framework

DORA expects ICT risk to sit inside business governance. The management body approves and oversees the framework, sets risk tolerance, allocates responsibilities, and keeps its knowledge current.

The framework should cover:

• ICT systems, assets, information, dependencies, and owners
• Threats, vulnerabilities, and risk assessments
• Protection and prevention controls
• Detection of unusual activity
• Response, recovery, backup, and restoration
• Communication during incidents
• Lessons learned and continuous improvement

An asset list with no connection to critical services is not enough. Map systems and providers to the business functions they support.

Prepare major incident reporting

Covered entities must classify ICT-related incidents and report major incidents through the applicable competent channel. The detailed timing, templates, and thresholds come from DORA and its supporting technical standards.

Create one operating procedure covering:

1. Detection and internal escalation
2. Classification against current thresholds
3. Management and legal involvement
4. Initial, intermediate, and final reporting
5. Customer and stakeholder communication
6. Evidence preservation and lessons learned

Test the procedure. A document that nobody can use during an outage is not operational resilience.

Test digital operational resilience

DORA requires a risk-based testing programme. This can include vulnerability assessments, scans, scenario testing, compatibility testing, performance testing, and end-to-end exercises.

Certain entities must conduct threat-led penetration testing at least every three years, subject to the regulation's scope and competent-authority requirements. Do not market an ordinary penetration test as TLPT unless it meets the applicable framework.

Track findings to closure and keep evidence of retesting.

Control ICT third-party risk

Using a cloud or software provider does not transfer accountability away from the financial entity. Maintain a register of information covering contractual arrangements for ICT services and classify which arrangements support critical or important functions.

Contracts need specified provisions covering matters such as service descriptions, locations, data, availability, assistance, incident support, security, audit and access rights, cooperation with authorities, termination, and exit.

Concentration risk matters too. Identify where several critical services depend on one provider, region, or subcontractor.

Connect DORA with NIS2 and GDPR

DORA is the sector-specific ICT-risk framework for many financial entities that might otherwise encounter overlapping NIS2 requirements. The legal interaction is specific, so do not simply add both checklists together.

GDPR still applies where incidents, logs, testing, or supplier arrangements involve personal data. A major ICT incident may also be a personal-data breach, with a separate assessment and reporting route.

This is where cross-compliance helps. One supplier inventory, incident process, or recovery test can support several obligations, provided each legal test is documented.

Your 2026 evidence checklist

Keep current copies of:

• Governance approvals and management training
• ICT risk framework and risk assessments
• Asset, service, dependency, and provider records
• Incident classifications, reports, and exercises
• Testing plans, results, remediation, and retests
• The ICT third-party register
• Contract reviews and exit plans
• Internal audit findings and improvement actions

Assign an owner and review date to every item. Link evidence to the requirement it supports rather than storing documents in an unstructured folder.

Run the free audit to map DORA alongside NIS2, data protection, and AI obligations affecting your fintech.

This article provides general information, not legal advice. Regulated entities should confirm DORA technical standards and supervisory requirements with qualified advisers.