DORA

DORA explained — digital operational resilience for finance

DORA explained — digital operational resilience for finance TL;DR — DORA is the EU's regulation making the financial sector resilient to ICT disruptions. It applies to financial entities (banks, insurers, investment firms, crypto-asset providers, and more) and to the ICT third-party providers that serve them. It mandates ICT risk management, incident reporting, resilience testing, and strict oversight of third-party ICT dependencies — including a designation regime for critical providers. What is DORA? The Digital Operational Resilience Act (Regulation (EU) 2022/2554) creates a harmonised framework so that financial entities can withstand, respond to, and recover from ICT-related disruptions and threats. Before DORA, ICT resilience rules were fragmented across the EU financial sector; DORA consolidates them. Who is in scope? DORA covers a wide range of financial entities, including credit institutions, payment and e-money institutions, investment firms, crypto-asset service providers, insurance and reinsurance undertakings, and more. Crucially, it also reaches ICT third-party service providers — the cloud platforms, software vendors, and managed-service firms that financial entities rely on. Providers designated as critical (CTPPs) come under direct EU oversight. If you sell technology into the financial sector, DORA affects you — through contractual requirements from your financial customers, and potentially through direct oversight if designated critical. The five pillars of DORA 1. ICT risk management — a comprehensive framework to identify, protect, detect, respond, and recover. 2. ICT incident management and reporting — classify incidents and report major ones to competent authorities on defined timelines. 3. Digital operational resilience testing — regular testing, including advanced threat-led penetration testing (TLPT) for significant entities. 4. ICT third-party risk management — govern the full lifecycle of ICT outsourcing, maintain a register of information on all ICT third-party arrangements, and ensure contracts include mandatory provisions. 5. Information sharing — voluntary exchange of cyber threat intelligence among financial entities. The third-party register One of DORA's most concrete demands is the register of information: financial entities must maintain a detailed inventory of every ICT third-party arrangement, at entity, sub-consolidated, and consolidated levels. This drives a wave of due-diligence and contractual scrutiny that flows to ICT providers. For a technology vendor, being ready with clear security and resilience evidence shortens these reviews considerably. How DORA overlaps with other frameworks DORA's ICT risk-management and incident-reporting requirements overlap conceptually with NIS2 and with the CRA's product-security duties. A vendor serving financial customers may need to satisfy DORA-driven contractual requirements, CRA product obligations, and NIS2 supply-chain expectations at once — with substantially shared evidence. Timeline DORA is in application for financial entities and their ICT third-party providers, with the oversight framework for critical providers ramping up. Confirm specific obligations and reporting expectations against current official and national sources. The five pillars at a glance ┌──────────────────────────────────────────────────────┐ │ DORA │ ├───────────┬───────────┬──────────┬─────────┬─────────┤ │ ICT risk │ Incident │ Resilience│ Third- │ Info │ │ management│ reporting │ testing │ party │ sharing │ │ │ │ (incl. │ risk + │ │ │ │ │ TLPT) │ register│ │ └───────────┴───────────┴──────────┴─────────┴─────────┘ │ │ │ │ │ Govern Report Test Oversee Collaborate Each pillar is a programme in itself; together they form a resilience framework that regulators can examine end to end. What it means for ICT providers specifically If you sell technology into finance, DORA reaches you through two channels: | ▸ Channel | ▸ What happens | |---|---| | Contractual | Financial customers must include mandatory provisions in your contracts and run due diligence | | Direct oversight | If designated a critical ICT third-party provider (CTPP), you come under direct EU oversight | Either way, being ready with clear security posture, resilience evidence, and contract-ready documentation turns a painful, repeated due-diligence exercise into a fast one. Frequently asked questions We're a SaaS vendor, not a bank — does DORA apply? Not directly as a financial entity, but very likely through your financial customers' third-party risk-management obligations — and directly if designated critical. What is the register of information? A detailed inventory every financial entity must maintain of all its ICT third-party arrangements. It drives the due diligence that flows to providers. How does DORA relate to NIS2? They share DNA (ICT risk management, incident reporting) but DORA is finance-specific and, for financial entities, takes precedence in its domain. A provider may face both. What is threat-led penetration testing (TLPT)? An advanced, intelligence-driven form of resilience testing that significant financial entities must perform periodically. It simulates realistic attacker behaviour against live systems, going well beyond routine vulnerability scanning, to prove that detection and response actually work under pressure. We already do ISO 27001 — is that enough for DORA? It helps considerably, but DORA has finance-specific requirements — the register of information, incident-reporting timelines, resilience testing, and mandatory contractual provisions — that a general security certification does not fully cover. Treat ISO 27001 as a strong foundation, not a substitute. What to do now If you are a financial entity: map your ICT risk-management framework to the five pillars, build your register of information, and plan your resilience testing. If you are an ICT provider to finance: prepare to answer DORA-driven due diligence — clear security posture, resilience evidence, and contract-ready documentation. Anticipate mandatory contractual provisions. A free scope review helps ICT providers understand what their financial customers will ask for under DORA. Key takeaways - ▸ DORA makes the financial sector resilient to ICT disruption — and reaches its ICT providers. - ▸ Five pillars: risk management, incident reporting, resilience testing, third-party risk, information sharing. - ▸ The register of information drives due diligence that flows to every ICT vendor. - ▸ Critical providers (CTPPs) come under direct EU oversight. - ▸ If you sell tech into finance, prepare for DORA-driven due diligence and mandatory contract provisions. → Related: How EU compliance works · The NIS2 Directive explained NexCyber provides a readiness analysis, not legal advice. DORA's application to your organisation may require legal review. Last reviewed 2026-07-10.

DORA — Five pillars and ICT third-party register, deep dive

In one paragraph DORA organises operational resilience for the financial sector around five pillars. NexCyber maps the entire framework, with particular focus on the ICT third-party register — the artefact that carries the most concrete and demanding data points. The five pillars 1. ICT risk management Governance and the full control loop: identify, protect, detect, respond and recover, learn. NexCyber tracks: governance documents, ICT risk policy, asset inventory with criticality, detection and response runbooks, post-incident learning records. 2. ICT-related incident management, classification, and reporting A documented incident management process with structured classification and reporting to competent authorities. NexCyber tracks: incident policy, classification taxonomy, reporting playbook, sample notifications, intermediate and final reporting templates. 3. Digital operational resilience testing A testing programme, including advanced threat-led penetration testing (TLPT) for significant entities. NexCyber tracks: testing strategy, scope per cycle, test reports (high-level findings), remediation plans, TLPT engagement records where applicable. 4. ICT third-party risk management Pre-contractual due diligence, contracts with mandated content, the register of contracts (the artefact below), exit strategies, continuous monitoring of critical providers. NexCyber tracks: every data point of the register, supplier evidence locker, contract clause inventory, exit plans per critical provider, monitoring metrics. 5. Information and intelligence sharing Optional but encouraged, with conditions on confidentiality and competition law. NexCyber tracks: sharing arrangements, contributions made and received, derogations and approvals where applicable. The ICT third-party register — what makes it different The register is the most data-rich artefact under DORA. ESAs publish technical standards (ITS / RTS) defining the exact data points. NexCyber tracks them all as structured fields in the supplier inventory. Data points per contract - Contract reference and date. - Name and identifier of the financial entity (LEI). - Name and identifier of the ICT provider (LEI when available). - Description of the ICT service. - Whether the service supports a critical or important function. - Substitutability assessment. - Sub-contracting chain, with each sub-provider documented. - Personal data processing involved. - Location of data and operation. - Whether the service is on-premises, in private cloud, in public cloud, or hybrid. - Service level objectives. - Termination notice and exit strategies. - Right-to-audit clauses. NexCyber surfaces each data point as a required field, gives you a per-field readiness indicator, and exports the register in a regulator-ready shape. Critical or important function flag This flag drives much of the regulatory treatment. NexCyber asks for a structured justification when you raise the flag, so the auditor sees not only the value but the rationale. Sub-contracting depth Sub-contractors of sub-contractors count. NexCyber stores the full chain as a tree, with each level carrying its own data points (where available). Critical ICT third-party providers (CTPP) Some providers will be designated CTPP by the ESAs. The designation triggers oversight at EU level and concentrates a set of obligations on the provider. If you are a financial entity, NexCyber lets you mark a provider as CTPP and track the corresponding oversight artefacts. If you are a CTPP yourself, the oversight pillar is its own workspace. Testing programme DORA expects a structured testing programme: - Routine tests (vulnerability assessment, scenario-based, penetration testing). - TLPT every three years for significant entities. NexCyber tracks the programme, the scope per cycle, and the remediation flow. TLPT engagements are typically scheduled with external red teams; NexCyber stores the engagement artefacts (not the offensive details). Incident reporting timelines DORA aligns on timelines for major ICT-related incidents. The exact timings come from the regulator; NexCyber surfaces the timer when an incident is opened, and the reporting playbook references the active timeline. Information sharing Information sharing is optional but encouraged. NexCyber lets you record sharing arrangements, contributions, and derogations. Privacy and competition-law guard-rails are surfaced as evidence prompts. Cross-regulation - NIS2 — overlaps on ICT risk management and supply chain security. NexCyber maps evidence once. - CRA — overlaps where the financial entity is also a manufacturer of digital products. - AI Act — overlaps where AI is used for safety, decision-making, or critical functions. Governance angle DORA puts ICT risk at the management body's level. The governance pillar requires explicit accountability, regular reporting to the board, and training. NexCyber tracks the governance artefacts and the cadence. What DORA via NexCyber does NOT do - It does not file your major-incident report. - It does not run TLPT. - It does not negotiate exit clauses with your providers. Common pitfalls - Treating the register as a spreadsheet. - Missing sub-contracting depth beyond first tier. - Critical-function flagging without rationale. - Exit strategies that exist only in slides. - Testing programmes without remediation tracking. Related articles - DORA basics — wider picture. - Supplier evidence basics — register data points overlap. - What evidence should I prepare? — cross-regulation evidence list. Next step Open the DORA assessment in your workspace and start by completing the register data points for your top ten ICT providers.