DORA for fintech and insurtech: a practical guide and 90-day checklist
The Digital Operational Resilience Act (Digital Operational Resilience Act: reglamento UE 2022/2554 sobre resiliencia operativa digital. Exige a entidades financieras de la UE resistir, responder y recuperarse de incidentes TIC. En vigor desde 17 enero 2025. Leer más → DORA) has been in force since January 2025 and its impact on European entities remains, in many cases, poorly understood. It is not a cybersecurity rule in the classic sense. It is an operational risk management framework that demands documented technical evidence, not statements of intent.
For a growing fintech or insurtech, the challenge is not one of will but of resources: teams are small, the pace of development is high, and the accumulated technical debt tends to sit exactly where DORA points its focus. Insufficient logging, third-party dependencies without adequate service-level agreements, recovery processes never tested.
This guide breaks down DORA's five pillars, translates each one into concrete technical controls and proposes a realistic implementation path for entities that do not have a fifteen-person compliance team. The main conclusion: DORA is achievable with a well-designed architecture. The problem is not the volume of requirements; it is starting with the ones that have the highest impact and can be implemented without freezing the business.
Regulatory context: what DORA is and who it applies to
The regulation's real scope
DORA (Regulation (EU) 2022/2554) applies directly in every European Union member state since 17 January 2025. Unlike directives, it requires no national transposition: its text is the rule.
It applies to a wide list of financial and insurance entities: credit institutions, investment firms, payment institutions, electronic money institutions, crypto-asset service providers under MiCA, fund managers and crowdfunding platforms, among others. If an entity is regulated by the Bank of Spain, the DGSFP or the CNMV in any financial line, DORA very probably applies to it directly or will in the near future.
Proportionality modulates; it does not exempt
Obligations are modulated by the entity's size, risk profile and complexity, and certain small or exempted entities apply the simplified ICT risk management framework of Article 16. Proportionality adjusts the required depth of implementation; it does not discount pillars.
DORA's five pillars
The regulation is organised around five areas:
- ICT risk management (Articles 5 to 16): governance framework, asset identification and classification, access controls, incident management.
- Incident notification (Articles 17 to 23): incident taxonomy and strict deadlines: initial notification within 4 hours of classifying the incident as major (and at most 24 hours from detection), intermediate report within 72 hours, final report within one month.
- Resilience testing (Articles 24 to 27): basic annual testing for all entities; TLPT (threat-led penetration testing) for significant entities every three years.
- ICT third-party risk management (Articles 28 to 30): contracts with critical providers, audit clauses, exit strategy and the Register of Information of contractual arrangements. Articles 31 to 44 are the oversight framework for critical providers: they apply to the provider, not the entity.
- Information sharing (Article 45): voluntary participation in cyber threat intelligence sharing schemes.
From pillar to control: the technical translation
This guide's promise in one table: which technical control answers each pillar and what evidence that control generates when properly implemented. The sections below develop each row.
| Pillar | Technical control | Evidence it generates |
|---|---|---|
| ICT risk management (Arts. 5-16) | Asset inventory synchronised with the real infrastructure (infrastructure as code as source of truth); MFA and individual accounts with session logging for privileged access | Versioned inventory with history; a record of every authentication and authorisation event |
| Incident notification (Arts. 17-23) | Structured, centralised logging with event correlation; alerts with a response target under 30 minutes; documented escalation | Reconstructable incident timeline; log chain of custody that stands before an auditor |
| Resilience testing (Arts. 24-27) | Scheduled vulnerability scanning; annual tabletop exercise; game days over the continuity plans | Dated test reports, with improvement actions, owner and deadline |
| ICT third-party risk (Arts. 28-30) | Structured, versioned Register of Information; contractual checklist applied at every onboarding or renewal | Register presentable to the supervisor; contracts with SLAs, audit and exit plan |
| Information sharing (Art. 45) | Participation in sector threat intelligence schemes, with feeds integrated into detection | Detection rules derived from shared intelligence, with documented origin |
Where most growing fintech and insurtech fail
The risk pattern that appears systematically in mid-sized entities is this: it is not that they are unaware of DORA; it is that their technical architecture and operating processes were not designed for this level of demand from the start.
No real ICT asset inventory
DORA requires identifying, classifying and keeping updated an inventory of all ICT assets: hardware, software, data, cloud services and third-party dependencies. The usual reality in a fast-growing fintech or insurtech is a fragmented inventory: the architecture lives in Confluence or similar, or in the minds of the longest-tenured engineers, and changes faster than any document.
This gap is not minor. Without a precise inventory, a coherent risk assessment is impossible, and so is assigning control responsibilities per asset.
Logging and monitoring insufficient for incident notification
DORA's deadlines for notifying major incidents are strict: under 4 hours for the initial notification to the supervisor from classification, 72 hours for the intermediate report. Meeting them requires detecting the incident, classifying it as major and reconstructing its timeline in a very short window. The DORA incident case study walks that clock minute by minute.
Most fintech and insurtech have application-level logging, but not always the event correlation needed to detect a security or availability incident within minutes. Even less often a log chain of custody that stands as evidence before an auditor.
Third-party dependencies not properly contractualised
Fintech and insurtech build on stacks of cloud services, third-party APIs and infrastructure providers. DORA requires contracts with critical ICT providers to include specific clauses: service levels, audit rights, exit plans, incident notification by the provider.
The standard contracts of the large cloud providers do not include these clauses by default. And agreements with smaller providers (payment gateways, identity providers, KYC services) tend to be even weaker from a DORA perspective.
Continuity plans never tested
DORA does not only require having a business continuity plan and a disaster recovery plan: it requires having tested them. Tests must be periodic and documented, and their results must feed back into the plan. A PDF in a shared folder that no one has read in two years is not a continuity plan in DORA terms.
Privileged access without granular control
Article 9 of DORA requires strict access controls over critical systems, with particular attention to privileged access. In many entities, production access is managed relatively loosely: shared credentials, no recording of administration sessions, tokens with excessive permissions and no systematic rotation.
The approach: building DORA compliance without freezing
DORA compliance is not a one-quarter project or a one-off effort. It is a sustained operating state. The key for a growing fintech or insurtech is to prioritise the highest-impact controls and build on an architecture that generates compliance evidence natively, without additional manual processes.
Principle 1: architecture as an evidence generator
A control that needs a manual process to generate evidence is a fragile control. When engineers are in delivery mode, manual processes get skipped or postponed. The alternative is to design the architecture so that compliance evidence is a by-product of the system's normal operation.
That means: structured, immutable logging by default in every component, with retention configurable by data type; centralised identity and access management, with an automatic record of every authentication and authorisation event; an ICT asset inventory synchronised with the real infrastructure (infrastructure as code as source of truth), not a separate document.
Principle 2: Zero Trust as the foundation of access control
The Modelo arquitectónico bajo el axioma "nunca confíes, verifica siempre". Cada acceso se verifica individualmente con identidad criptográfica, en cada interacción — sin importar si la petición viene de dentro o fuera de la red. Leer más → Zero Trust architecture, described in detail in the article on Zero Trust in banking, is not just a security improvement: it is a natural way to meet DORA's access control requirements. When every service must authenticate before communicating with another, when privileged access requires justification and produces a session record, and when no implicit trust zone exists in the internal network, Article 9's controls are implemented as an architectural property, not an added layer.
Principle 3: third-party management as a continuous process
The Register of Information that DORA requires (Article 28) is not a static document. It is a management process that requires: identifying critical ICT providers, reviewing current contracts against the required clause list, negotiating the necessary additions and keeping the register updated when providers or conditions change.
A growing entity can structure this process with a provider inventory in an asset management system and a contractual checklist applied at every new engagement or renewal. The initial effort is significant; the ongoing maintenance, if the process is well designed, is manageable.
Principle 4: resilience testing as an engineering habit
The resilience testing DORA requires integrates naturally into engineering cultures that already practise chaos engineering, game days or incident response runbooks. If the entity does not have these practices, DORA is a structural reason to adopt them.
The required basic annual tests include: network security testing, vulnerability assessments, gap analysis against the defined controls, tests of the continuity plans. For non-significant entities, these tests can be internal with adequate documentation.
Principle 5: a core that generates traceability by design
The core processing system, whether in-house or third-party, is the most critical ICT asset from a DORA perspective. The core's resilience, transaction traceability and auditability are not optional: they are regulatory requirements.
Traditional third-party cores offer business-level traceability, but their integration architecture tends to complicate end-to-end technical audits. Modern cores with native traceability in every processing layer significantly simplify evidence generation for DORA.
Actionable checklist: the first 90 days towards DORA
The following checklist is designed for entities starting their DORA compliance process or needing to assess their current position. It is not exhaustive, but it covers the highest-impact controls and the highest non-compliance risk in mid-sized entities.
Weeks 1 to 2: inventory and classification
- [ ] Build an inventory of every system and service in production (own and third-party) with an assigned technical owner.
- [ ] Classify each asset by its criticality for business continuity (critical, important, auxiliary).
- [ ] Identify dependencies between assets and the third-party ICT service providers.
- [ ] Document what data each system processes and under which regulatory regime (customer data, transaction data, access data).
Weeks 3 to 4: privileged access management
- [ ] Audit all administrator-level access to production systems.
- [ ] Remove shared credentials and replace them with individual accounts with activity logging.
- [ ] Enforce MFA for all access to critical systems.
- [ ] Establish a secret rotation process (API keys, tokens, database passwords) with a defined frequency and owner.
- [ ] Evaluate privileged session recording for the most critical systems.
Weeks 5 to 6: logging and detection
- [ ] Verify that every production system generates structured logs with timestamp, user identifier, action and outcome.
- [ ] Centralise logs in a system with at least one year of retention and restricted, audited access.
- [ ] Define which event types constitute a major incident under DORA's taxonomy.
- [ ] Set automatic alerts for the highest-severity events with a response target under 30 minutes.
- [ ] Appoint an owner for supervisor notification and document the escalation process.
Weeks 7 to 8: third-party contracts
- [ ] Identify the providers DORA qualifies as critical (those whose interruption would prevent the provision of financial services).
- [ ] Review each critical contract against DORA's required clause list (SLAs, audit, incident notification, exit plan).
- [ ] Open negotiations with critical providers that do not meet the contractual requirements.
- [ ] Build the centralised Register of Information of all contractual arrangements with ICT third parties, with a periodic review date.
Weeks 9 to 12: resilience and testing
- [ ] Document or update the Business Continuity Plan (BCP) and the Disaster Recovery Plan (DRP) with concrete scenarios.
- [ ] Define recovery objectives (RTO and RPO) for each critical system.
- [ ] Plan and run a tabletop exercise (incident simulation) with the relevant technical and business teams.
- [ ] Document the test results and improvement actions with owner and date.
- [ ] Schedule the annual vulnerability testing DORA requires.
Conclusion: DORA as competitive advantage, not just obligation
Entities that treat DORA as one more regulatory obligation tend to implement the bare minimum to pass an audit. Those that treat it as an operational maturity opportunity tend to build more resilient systems, with less technical debt and more capacity to scale.
The difference is not philosophical; it is practical. An architecture that generates compliance evidence natively, with rigorous access management, complete logging and properly contractualised third parties, is also an architecture that is easier to operate, easier to debug when something fails and easier to scale when growth arrives.
For a fintech or insurtech aiming to grow in the regulated European market, the question is not whether to comply with DORA; it is how to do it in a way that reinforces the architecture instead of stacking complexity on a fragile base.
The 90-day checklist is a starting point. Full implementation requires a continuous cycle of assessment, improvement and testing. What changes with a well-designed architecture is the cost of that cycle: when controls are native, maintaining compliance is a normal part of engineering work, not a separate project competing for resources with product development.
If your fintech or insurtech is assessing its position against DORA or wants to reduce the friction between compliance and development speed, BlueUP combines BlueUP Core (a Rust financial engine with native traceability), a Zero Trust architecture built on OpenZiti and native compliance for DORA and Servicio Ejecutivo de la Comisión de Prevención del Blanqueo de Capitales e Infracciones Monetarias. Unidad de inteligencia financiera de España (FIU), receptor oficial de las comunicaciones de operativa sospechosa de las entidades obligadas.SEPBLAC. Start by assessing your maturity with the DORA Calculator or let's talk about your case.
Want to assess your position against DORA?
Initial assessment with no commitment: we show you the platform configured for your sector with representative data.
Related reading
- DORA 2026: a practical guide for financial institutions — The full framework, with a checklist by department.
- DORA Register of Information: why almost no one passes first time — The ICT third-party pillar in detail: Article 28's annual obligation.
- Anatomy of a DORA incident: from first signal to notification — The 4-hour clock, walked minute by minute.
- Zero Trust in banking: why VPNs are no longer enough — The architectural foundation of Article 9's access control.