The Digital Operational Resilience Act (DORA — Regulation EU 2022/2554) has been fully enforceable since January 17, 2025. For French fintechs, payment institutions, investment firms, and crypto-asset service providers, this is no longer a future deadline to prepare for — it is a present compliance obligation that supervisors are actively reviewing.
Yet many mid-sized fintechs still treat DORA as a large-bank problem. It is not. The ACPR and AMF have both signalled that 2025 is a transition year focused on framework review — but enforcement will tighten in 2026. Now is the time to close the gaps.
This guide is written for compliance officers, CTOs, and risk managers at French fintechs who need a clear, actionable understanding of what DORA actually requires — without the regulatory jargon.
Table of Contents
- What Is DORA and Who Does It Apply To?
- The Five Pillars of DORA Compliance
- ICT Risk Management Framework
- ICT Incident Reporting: Timelines and Obligations
- Digital Operational Resilience Testing (TLPT)
- Third-Party ICT Risk: Managing Your Vendors
- Information Sharing
- DORA and MiCA: The Overlap for Crypto Fintechs
- Common Gaps Found in French Fintechs
- A Practical DORA Implementation Roadmap
- How Seqlense Supports Your DORA Programme
1. What Is DORA and Who Does It Apply To? {#what-is-dora}
DORA establishes a unified EU framework for digital operational resilience in the financial sector. Its core objective is to ensure that financial entities can withstand, respond to, and recover from ICT-related disruptions — whether caused by cyberattacks, system failures, or third-party outages.
Who Is In Scope?
DORA applies to a wide range of financial entities, including:
| Entity Type | Examples |
|---|---|
| Credit institutions | Banks, online banks |
| Payment institutions | PSPs, e-money institutions |
| Investment firms | Portfolio managers, advisors |
| Crypto-asset service providers | CASPs licensed under MiCA |
| Insurance and reinsurance companies | Including InsurTechs |
| Crowdfunding service providers | Regulated platforms |
| ICT third-party service providers (critical) | Cloud providers, data centres |
The Proportionality Principle
DORA explicitly recognises that a startup fintech and a systemic bank cannot be held to identical standards. Article 16 introduces a simplified ICT risk management framework for smaller entities — specifically:
- Payment institutions and e-money institutions that are not considered significant
- Small and non-interconnected investment firms
- Certain insurance undertakings below thresholds
However, proportionality does not mean exemption. Even entities on the simplified track must have documented ICT risk policies, incident response procedures, and basic continuity plans.
2. The Five Pillars of DORA Compliance {#five-pillars}
DORA organises its requirements around five interconnected pillars:
| Pillar | DORA Articles | Core Obligation |
|---|---|---|
| 1. ICT Risk Management | Art. 5–16 | Govern, identify, protect, detect, respond, recover |
| 2. ICT Incident Reporting | Art. 17–23 | Classify, report major incidents to ACPR/AMF within strict timelines |
| 3. Digital Resilience Testing | Art. 24–27 | Annual basic testing; TLPT every 3 years for significant entities |
| 4. Third-Party ICT Risk | Art. 28–44 | Due diligence, contractual requirements, register of arrangements |
| 5. Information Sharing | Art. 45 | Voluntary sharing of cyber threat intelligence |
Each pillar has both strategic and operational dimensions. The common failure mode for fintechs is treating each pillar as an isolated project rather than building an integrated resilience programme.
3. ICT Risk Management Framework {#ict-risk-management}
This is the backbone of DORA. Article 6 requires financial entities to have a comprehensive, documented, and Board-approved ICT risk management framework.
What the Framework Must Cover
Governance:
- Clear allocation of ICT risk responsibility at Board and senior management level
- An ICT risk function or designated owner (does not need to be a separate team in smaller fintechs)
- Annual review of the framework
Risk Identification:
- Mapping of all ICT assets supporting critical or important functions
- Classification of assets by criticality and sensitivity
- Documentation of information flows and dependencies
Protection Measures:
- Access control policies (least privilege, MFA)
- Patch management and vulnerability management procedures
- Network segmentation and endpoint protection
Detection:
- Monitoring systems capable of detecting anomalies and incidents in real time
- Log retention policies aligned with regulatory requirements
Response and Recovery:
- Documented incident response playbooks
- Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) for critical functions
- Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP) tested at least annually
Learning and Evolving:
- Post-incident reviews
- Integration of threat intelligence into risk assessments
The ICT Asset Register
One of the most tangible deliverables DORA requires is a register of all ICT assets — hardware, software, data, and external services — mapped to the business functions they support. For many fintechs, building this register from scratch is the most time-consuming part of DORA implementation.
Practical tip: Start with your critical business functions (payment processing, customer onboarding, trading execution) and work backwards to the ICT assets that support them. Do not try to catalogue everything at once.
4. ICT Incident Reporting: Timelines and Obligations {#incident-reporting}
DORA introduces harmonised, mandatory reporting timelines for major ICT incidents. This replaces the patchwork of national reporting obligations that previously applied.
Classification: What Is a "Major ICT Incident"?
Not every outage or security event requires regulatory reporting. DORA's delegated regulations define materiality thresholds based on:
- Number of clients affected
- Duration of the incident
- Geographical spread (multi-country impact)
- Data losses (availability, authenticity, confidentiality, integrity)
- Financial impact (direct losses or costs)
- Reputational impact
- Criticality of affected services
Reporting Timeline to ACPR / AMF
Once an incident is classified as major, the reporting sequence is:
| Report | Deadline | Content |
|---|---|---|
| Initial notification | Within 4 hours of classification (max 24h after detection) | Basic facts: nature, impact, containment status |
| Intermediate report | Within 72 hours of initial notification | Updated impact assessment, root cause hypothesis, measures taken |
| Final report | Within 1 month of resolution | Full root cause analysis, lessons learned, permanent fixes |
Key Operational Requirements
- Designate a single point of contact responsible for regulatory incident reporting
- Build a classification decision tree that your on-call team can follow at 3am without needing to escalate for guidance
- Maintain a secure incident log with timestamps from detection through resolution
- Ensure your SIEM or monitoring platform can generate the data fields required by the ESMA/EBA reporting templates
5. Digital Operational Resilience Testing (TLPT) {#tlpt}
DORA requires financial entities to conduct regular testing of their ICT resilience. The requirements differ significantly based on entity size and systemic importance.
Basic Testing (All Entities)
At minimum, all in-scope entities must conduct annual testing covering:
- Vulnerability assessments and scans
- Open source analyses
- Network security assessments
- Gap analyses
- Physical security reviews
- Questionnaire-based assessments of ICT third-party providers
These tests must be performed by independent parties — either internal teams without operational responsibility for the tested systems, or external providers.
Threat-Led Penetration Testing (TLPT)
Significant financial entities must conduct TLPT every three years. TLPT is a structured, intelligence-driven penetration test that simulates a realistic advanced persistent threat (APT) against production systems.
Key characteristics of TLPT under DORA:
- Based on the TIBER-EU framework (or national equivalents like TIBER-FR)
- Must target live production systems, not test environments
- Requires a Threat Intelligence provider to develop a targeted threat scenario
- Conducted by a certified Red Team provider
- Supervised by the financial entity's competent authority (ACPR or AMF depending on entity type)
- Requires written authorisation from the Board before commencement
Who Needs TLPT?
The competent authority identifies which entities are subject to TLPT based on systemic relevance. For French fintechs, the ACPR or AMF will notify entities directly. However, even if not mandated, conducting a TLPT-aligned exercise is considered best practice and demonstrates proactive engagement with resilience testing.
Note for CISOs: TLPT is a significant undertaking — typical engagements run 3–6 months and require substantial internal coordination. Build this into your annual planning cycle.
6. Third-Party ICT Risk: Managing Your Vendors {#third-party-risk}
Third-party ICT risk is one of the areas where fintechs are most exposed. Cloud providers, payment processors, KYC vendors, and data providers are all ICT third-party service providers (ICT-TPPs) under DORA — and your contracts with them must meet specific requirements.
The Register of ICT Third-Party Arrangements
Article 28 requires financial entities to maintain a comprehensive register of all contractual arrangements with ICT third-party providers, including:
- Name and location of the provider
- Description of services provided
- Classification of the arrangement (supporting critical/important function or not)
- Contract start and end dates
- Most recent audit or assessment results
This register must be submitted to competent authorities upon request and is a key supervisory document.
Contractual Requirements
For ICT third-party arrangements supporting critical or important functions, contracts must include provisions covering:
- Accessibility and availability of services and data
- Audit rights for the financial entity and its competent authority
- Business continuity obligations of the provider
- Data location and portability — ability to migrate data upon contract termination
- Subcontracting restrictions and notification requirements
- Incident response cooperation obligations
- Termination rights in case of regulatory or resilience concerns
Exit Strategy
One of the most operationally complex DORA requirements is the obligation to maintain an exit strategy for each critical ICT third-party arrangement. This means documenting how you would migrate away from a key provider (e.g., your cloud infrastructure, your core banking system, your AML platform) within a defined timeframe, without disrupting service to clients.
Practical tip: Map your critical providers now and identify which ones would be genuinely difficult to replace. Prioritise those for contract renegotiation and exit strategy documentation.
Critical ICT Third-Party Providers (CTPPs)
DORA also creates a new EU-level oversight regime for providers designated as Critical ICT Third-Party Providers (CTPPs) — large cloud providers, major data centres, and similar systemic vendors. As of 2025, the joint ESA oversight framework for CTPPs is being established under a dedicated Director. French fintechs using services from designated CTPPs will benefit from enhanced regulatory oversight of those providers.
7. Information Sharing {#information-sharing}
Article 45 of DORA enables — but does not mandate — financial entities to participate in cyber threat intelligence sharing arrangements. These are voluntary schemes where entities share anonymised information about threats, vulnerabilities, and incidents to strengthen collective resilience.
The ACPR and AMF are supportive of French participation in EU-level intelligence sharing frameworks. For fintechs, the most practical entry points are:
- CERT-AGORA (French financial sector CERT)
- FS-ISAC European chapter (Financial Services Information Sharing and Analysis Centre)
- ENISA-coordinated EU cyber exercises
Participation in these schemes is increasingly viewed favourably by supervisors as evidence of proactive resilience culture.
8. DORA and MiCA: The Overlap for Crypto Fintechs {#dora-mica-overlap}
If your fintech is a CASP under MiCA, you are subject to both DORA and MiCA simultaneously. Understanding where they overlap — and where they diverge — is essential to avoiding duplicated effort or compliance gaps.
Where They Overlap
| Area | DORA Requirement | MiCA Requirement |
|---|---|---|
| ICT incident reporting | Major ICT incidents → ACPR/AMF | Operational incidents affecting clients → NCA |
| Business continuity | BCP/DRP for critical functions | Continuity of service obligations for CASPs |
| Systems security | Security protocols documentation | Systems and security access protocol guidelines (ESMA) |
| Third-party risk | ICT-TPP register and contracts | Outsourcing policy for critical functions |
Where They Diverge
- DORA focuses on operational resilience — can your systems stay up and recover?
- MiCA focuses on market conduct — are your systems detecting and preventing market abuse?
The key principle: a cyber incident at a CASP will typically trigger both DORA incident reporting (to ACPR/AMF as the ICT supervisor) and potentially MiCA incident notifications (if the incident affected service delivery or market integrity). Your incident response workflows must be designed to handle both reporting tracks simultaneously.
9. Common Gaps Found in French Fintechs {#common-gaps}
Based on supervisory signals from the ACPR and AMF, and on typical assessment findings, the following gaps are most frequently identified in French fintechs approaching DORA compliance:
1. Incomplete ICT Asset Register Many fintechs have never formally documented all ICT assets and their criticality. Shadow IT and untracked SaaS dependencies are common.
2. Untested BCP/DRP Having a Business Continuity Plan on paper is not sufficient. DORA requires evidence of testing — but many fintechs have never run a realistic continuity exercise.
3. Contracts with ICT Vendors That Do Not Meet DORA Standards Legacy contracts with cloud providers or payment processors were written before DORA. They often lack audit rights, data portability clauses, and exit strategy provisions.
4. No Formal Incident Classification Process Teams know how to respond to a technical outage, but lack a documented decision tree for determining whether an incident meets DORA's "major incident" classification thresholds.
5. TLPT Not on the Roadmap Entities that may be subject to TLPT have not initiated early-stage preparation — including provider selection, scope definition, and Board engagement.
6. Governance Gaps at Board Level DORA requires the Board to approve and regularly review the ICT risk framework. Many fintechs have not yet formalised ICT risk reporting to Board level.
10. A Practical DORA Implementation Roadmap {#roadmap}
If you are starting from scratch or need to close gaps before your next supervisory review, here is a prioritised implementation sequence:
Phase 1 — Foundation (Months 1–2)
- [ ] Confirm your entity's DORA scope and applicable tier (full vs. simplified framework)
- [ ] Appoint an ICT risk owner at senior management level
- [ ] Conduct a gap assessment against the five DORA pillars
- [ ] Build your ICT asset register (focus on critical functions first)
- [ ] Draft or update your ICT risk policy and get Board approval
Phase 2 — Core Compliance (Months 3–5)
- [ ] Implement or formalise your incident classification and reporting procedure
- [ ] Review and update ICT vendor contracts for DORA compliance
- [ ] Build your register of third-party ICT arrangements
- [ ] Document RTOs and RPOs for all critical functions
- [ ] Conduct your first annual resilience test (vulnerability assessment)
Phase 3 — Maturity (Months 6–12)
- [ ] Run a full BCP/DRP exercise and document results
- [ ] Develop and document exit strategies for critical ICT providers
- [ ] Establish a threat intelligence monitoring process
- [ ] Assess TLPT applicability and initiate preparation if required
- [ ] Integrate DORA compliance into your annual audit programme
Ongoing
- [ ] Annual ICT risk framework review and Board sign-off
- [ ] Annual resilience testing cycle
- [ ] Quarterly review of ICT vendor register
- [ ] Continuous monitoring of ESMA/EBA/ACPR/AMF DORA-related publications
11. How Seqlense Supports Your DORA Programme {#seqlense}
Seqlense DOC provides automated monitoring of DORA-related publications across all relevant sources: ESMA, EBA, ACPR, AMF, and national competent authorities across the EU. Every new RTS, ITS, guideline, Q&A, or enforcement decision is captured, summarised, and mapped to the relevant DORA article — so your team spends time on implementation, not on manually checking regulator websites.
For French fintechs navigating the combined obligations of DORA and MiCA, Seqlense offers a single platform covering both regulatory watch and on-chain market abuse detection — purpose-built for the European regulatory landscape.
Key Takeaways
- DORA has been enforceable since January 17, 2025 — supervisory reviews are underway
- Proportionality applies, but even smaller fintechs must have documented ICT risk frameworks and incident procedures
- The ICT asset register and vendor contract review are the most urgent practical deliverables for most fintechs
- Incident reporting timelines are strict: 4 hours for initial notification after classification, 72 hours for an intermediate report
- TLPT is mandatory for significant entities every three years — start planning early
- For CASPs, DORA and MiCA obligations overlap: build workflows that handle both simultaneously
Last updated: March 4, 2026. This article reflects DORA implementing measures and supervisory guidance available as of that date. Use Seqlense DOC to track updates.
Tags: DORA, operational resilience, fintech compliance, ICT risk management, TLPT, ACPR, AMF, third-party risk, MiCA, French fintech, digital resilience