Mastering DORA: Digital Operational Resilience Act Expert Track

Digital Operational Resilience Act (DORA)

Regulation (EU) 2022/2554 on digital operational resilience for the financial sector, part of the EU Digital Finance Package, establishing harmonized rules on ICT risk management, incident handling, testing, third‑party risk, and information sharing for financial entities and certain ICT providers.

Digital Operational Resilience

The ability of a financial entity to build, assure and review its operational integrity and reliability by ensuring that it can withstand, respond to and recover from all types of ICT‑related disruptions and threats.

ICT Risk Management (under DORA)

A comprehensive framework of governance, processes, and controls through which a financial entity identifies, protects against, detects, responds to, and recovers from ICT risks, integrating them into overall risk management and decision‑making.

Critical ICT Third‑Party Provider (CTPP)

An ICT service provider designated as critical under DORA due to its systemic importance to the EU financial sector, subject to direct oversight by a Lead Overseer (one of the ESAs).

Threat‑Led Penetration Testing (TLPT)

An advanced form of penetration testing required for significant entities under DORA, simulating realistic threat actor techniques to test the resilience of critical live production systems and controls.

Incident Classification and Reporting (under DORA)

The obligation for financial entities to detect ICT‑related incidents, classify them according to standardized criteria (e.g. major incidents), and report significant ones to competent authorities within prescribed timelines and formats.

Financial entity (under DORA)

A legal person authorised or registered under specified EU financial services legislation (e.g., CRR/CRD banks, MiFID II investment firms, PSD2 payment institutions, Solvency II insurers, UCITS/AIFM managers, certain CASPs under MiCA, market infrastructures, etc.), as listed in Article 2(1) and Annex I of DORA.

ICT third‑party service provider (ICT TPP)

Any undertaking providing ICT services (e.g., cloud, data centre, software, security operations) to one or more financial entities. It is indirectly regulated via contractual obligations imposed on financial entities and, if designated as critical, may be directly overseen.

Critical ICT third‑party provider (CTTP)

A subset of ICT TPPs formally designated as critical by the ESAs based on systemic impact, concentration, and substitutability. CTTPs are subject to direct EU‑level oversight, information requests, inspections, and remedial measures.

Critical or important function (CIF)

A function whose disruption would materially impair the financial entity’s soundness, continuity of services, or compliance with regulatory obligations. ICT services supporting CIFs receive enhanced scrutiny under DORA.

Proportionality principle (in DORA)

The requirement that DORA obligations are applied in a manner commensurate with an entity’s size, internal organisation, nature, scale, and complexity of services and risk profile, especially regarding ICT dependencies and systemic relevance.

Territorial scope of DORA

Covers all in‑scope financial entities authorised in the EU, regardless of ICT location, and indirectly covers non‑EU ICT providers via contractual obligations; designated non‑EU CTTPs are also subject to direct EU oversight.

Digital Operational Resilience Act (DORA)

EU Regulation (EU) 2022/2554 establishing a harmonised framework for digital operational resilience of financial entities and oversight of critical ICT third‑party providers, fully applicable since January 2025.

Lex specialis (DORA vs. NIS2)

Legal principle under which DORA, as a sector‑specific act for financial services, takes precedence over the more general NIS2 cyber rules for entities within its scope.

Major ICT‑related incident (DORA)

A significant ICT event that materially affects the availability, authenticity, integrity, or confidentiality of data or services, triggering mandatory reporting to financial supervisors under DORA.

Critical ICT Third‑Party Provider (CTPP)

An ICT provider designated under DORA as critical to the stability of the EU financial system, subject to direct EU‑level oversight by the ESAs via a Joint Oversight Forum.

Regulatory Technical Standards (RTS)

Binding technical rules developed by the ESAs and adopted by the European Commission, specifying detailed requirements to implement DORA (e.g. on risk management, testing, incident reporting).

GDPR Article 32 vs. DORA ICT risk management

Art. 32 requires appropriate security of personal data; DORA requires a comprehensive ICT risk management framework for all relevant systems and data. Implementing DORA controls often helps meet Art. 32 for financial data processing.

Management body (under DORA)

The board of directors or equivalent, including senior management where applicable, which has ultimate responsibility for setting, approving, and overseeing the ICT risk management framework and ICT risk appetite.

ICT Risk Management Framework (ICT RMF)

The set of policies, procedures, governance structures, processes, and tools that an entity uses to identify, assess, manage, monitor, and report ICT and cyber risks, integrated into overall enterprise risk management.

ICT risk appetite / tolerance

The level and types of ICT and cyber risk an organization is willing to accept in pursuit of its objectives, expressed in qualitative and quantitative terms (e.g., maximum downtime, incident thresholds).

Critical / important functions

Business services or operations whose disruption would materially impair the firm’s financial performance, customer protection, market integrity, or the stability of the financial system; they require enhanced ICT resilience measures under DORA.

Documentation and auditability (in DORA)

The requirement that policies, decisions, incidents, changes, and risk assessments be recorded in a way that allows internal and external parties (including supervisors and auditors) to trace what was done, when, by whom, and based on which rationale.

Lifecycle management of ICT assets

The governance and processes covering the entire lifespan of ICT assets—from acquisition and development through operation and change to decommissioning—ensuring security, compliance, and resilience at each stage.

ICT-related incident (under DORA)

Any event or series of events compromising the availability, authenticity, integrity or confidentiality of data or ICT services and adversely affecting the services provided by the financial entity.

Major ICT-related incident

An ICT-related incident with a high adverse impact on the network and information systems supporting financial services, determined using DORA’s criteria and RTS thresholds, and subject to mandatory reporting.

Significant cyber threat

A cyber threat that, if materialised, could result in a major ICT-related incident. It may be subject to reporting and should be monitored and managed proactively.

Incident lifecycle (DORA-aligned)

A structured sequence: detection & reporting → triage & classification → containment → eradication → recovery → post-incident review → documentation and reporting.

DORA incident reporting

The obligation of financial entities to notify competent authorities of major ICT-related incidents via initial, intermediate, and final reports using harmonised templates and timelines.

Regulatory Technical Standards (RTS)

Detailed technical rules adopted by the ESAs under DORA that specify, among other things, classification criteria and thresholds for major ICT-related incidents.

Digital Operational Resilience Testing (DORT) Programme

The structured, risk‑based set of testing activities required by DORA to assess the robustness and effectiveness of a financial entity’s ICT systems and controls, covering vulnerability assessments, scenario‑based tests, BCP/DR exercises, and where applicable TLPT.

Threat‑Led Penetration Testing (TLPT)

An advanced, intelligence‑driven red‑team style test mandated by DORA for certain entities, emulating real‑world threat actors against live production systems supporting critical or important functions, coordinated with supervisors and using qualified external testers.

Critical or Important Function (CIF)

A function whose disruption would materially impair the financial entity’s services or activities, have significant impact on financial markets, or threaten the entity’s safety and soundness; TLPT and other intensive tests focus on CIFs.

Scenario‑Based Testing

Testing based on realistic disruption scenarios (e.g., ransomware, data centre outage, cloud provider failure) that combines technical and organisational responses to evaluate resilience end‑to‑end.

BCP/DR Testing

Exercises and technical tests that validate the effectiveness of Business Continuity Plans and Disaster Recovery capabilities, including failover, backup restoration, and operation from alternate sites.

Independence of Testers

The requirement that individuals or teams conducting tests (especially TLPT) are operationally independent from those responsible for designing, operating, or owning the systems tested, to ensure objectivity and realism.

ICT Third‑Party Arrangement

Any contractual relationship between a financial entity and an external provider for ICT services (including cloud, software, infrastructure, and support), regardless of whether it is labelled as outsourcing and regardless of criticality.

Critical or Important Function

A function whose disruption would materially impair the FE’s soundness, continuity of services, or regulatory compliance. Under DORA, ICT arrangements supporting such functions trigger stricter contractual and governance requirements.

Critical ICT Third‑Party Provider (CTTP)

An ICT provider designated at EU level (on JOF proposal and Commission decision) as systemically important for the financial sector, subject to a specific oversight regime by a Lead Overseer.

Concentration Risk (ICT Context)

The risk arising from excessive dependence on a limited number of ICT providers, locations, or technologies, such that a failure at one provider or location could have disproportionate impact on the FE or the financial system.

Exit Strategy

A documented and feasible plan to terminate an ICT third‑party arrangement (voluntarily or involuntarily), including data migration, transition of services, and maintenance of critical operations during and after the exit.

Sub‑outsourcing

The situation where an ICT provider further outsources part of the contracted services to another provider. Under DORA, this must be controlled contractually, especially when critical or important functions are involved.

Voluntary threat notification (under DORA)

An optional communication from a financial entity to competent authorities or relevant bodies about **significant cyber threats or vulnerabilities**, even when they do not yet qualify as reportable major incidents. Intended to support **early warning and sector‑wide resilience**.

Information‑sharing arrangement / trusted community

A structured mechanism (e.g., ISAC, PPP) where vetted members exchange **cyber threat and vulnerability information** under **clear governance rules** on membership, confidentiality, data protection, and permitted uses.

Data minimization in threat intel sharing

The GDPR principle that only the **personal data strictly necessary** for the security purpose should be shared, often achieved by **anonymization, pseudonymization, or aggregation** of incident data.

Antitrust risk in cyber information sharing

The possibility that a security‑focused community of competitors may **inadvertently facilitate anti‑competitive behavior** (e.g., price‑fixing, boycotts). Managed by limiting discussions to security topics, using governance rules, and avoiding commercial coordination.

Operational integration of shared intelligence

The process of feeding external threat intel into **SOC workflows, detection rules, risk registers, and testing programs**, ensuring that shared information leads to **concrete control changes** and improved resilience.

National Competent Authority (NCA)

A Member State authority responsible for supervising financial entities under DORA (e.g., central banks, financial supervisory authorities). NCAs have primary responsibility for inspections, remedial orders, and administrative sanctions against financial entities.

European Supervisory Authorities (ESAs)

EBA, ESMA, and EIOPA. They develop technical standards, coordinate supervisory practices, and, for critical ICT third‑party providers, act as Lead Overseers with direct oversight powers at EU level.

Critical ICT Third‑Party Provider (CTPP)

An ICT provider designated by the European Commission as critical due to its systemic importance for EU financial entities. Subject to direct EU‑level oversight, inspections, and potential periodic penalty payments under DORA.

Periodic Penalty Payment

A recurring financial penalty (e.g., daily fine) imposed to compel compliance with a supervisory order or instruction, used both for financial entities (via NCAs) and for CTPPs (via Lead Overseers).

Management Body Accountability

The principle that the board or equivalent governing body of a financial entity bears ultimate responsibility for ensuring DORA compliance, including approval of ICT risk frameworks and oversight of operational resilience.

Supervisory Convergence

The process by which NCAs align their supervisory practices, tools, and enforcement approaches, driven by ESAs’ guidelines, RTS/ITS, and joint exercises, reducing cross‑border inconsistencies in DORA enforcement.

DORA gap assessment

A structured, evidence-based comparison of an institution's current ICT risk management, incident reporting, testing, third-party risk, and information-sharing practices against DORA requirements, typically scored by maturity and compliance.

Critical or important function (CIF)

A function whose disruption would materially impair the financial institution's services, financial performance, or regulatory obligations; used by DORA to scope ICT risk, testing, and third-party oversight.

Prioritization dimensions under DORA

Risk criticality, regulatory impact, dependency/enabler role, and resource/time constraints; used together to rank remediation actions into high/medium/low priority.

DORA Steering Committee (SteerCo)

A senior cross-functional body (ICT, Risk, Compliance, Operations, Business) that oversees DORA implementation, approves priorities, allocates resources, and monitors KPIs/KRIs.

Integration with NIS2

Aligning ICT/cyber risk management, incident classification, and reporting so that one set of controls and records can satisfy both DORA and NIS2, minimizing duplication while respecting differing thresholds and channels.

Milestone vs KPI vs KRI

A milestone is a time-bound outcome (e.g., 100% of critical services mapped by Q2). A KPI measures implementation or process performance (e.g., % of updated contracts). A KRI signals residual risk (e.g., number of critical incidents per quarter).

Operating Model (in the context of DORA)

The integrated set of governance structures, processes, roles, controls, and tools through which an institution achieves and sustains ongoing compliance with DORA in day-to-day operations.

Control (Regulatory / DORA context)

A specific, testable activity or mechanism designed to prevent, detect, or correct failures to meet DORA requirements (e.g., an approval step, a system configuration, a reconciliation, or a monitoring alert).

Evidence Catalogue

A structured register that maps DORA controls and requirements to specific evidence artifacts (documents, logs, tickets, reports), including their location, owner, and retention rules.

Three Lines of Defense

A model in which the 1st line owns and manages risks and controls, the 2nd line provides oversight and challenge, and the 3rd line (internal audit) provides independent assurance over the overall framework.

Assurance Map

A tool that shows which DORA requirements or risk areas are covered by which assurance activities across the three lines (self-assessments, monitoring, audits), highlighting gaps and overlaps.

BAU Embedding of DORA

The integration of DORA requirements into existing business-as-usual processes (e.g., change management, vendor onboarding, incident handling) so that compliance is achieved through normal operations, not parallel or ad-hoc processes.

Proportionality under DORA

DORA allows scaling of **how** requirements are implemented (depth, frequency, documentation detail) based on size, risk profile, and complexity, but not **whether** core requirements (e.g., governance, incident reporting, basic testing) are met.

Critical or Important Functions (CIFs)

Functions whose disruption could have **material impact** on the entity’s services, financial performance, or customers, or on **financial stability**. Correct scoping of CIFs drives the intensity of **testing** and **third‑party oversight**.

CTPP (Critical ICT Third‑Party Provider)

An ICT provider designated as critical at EU level. Financial entities must have **enhanced risk management, contractual safeguards, and oversight** for services relying on such providers, including exit strategies and testing of resilience.

Common Pitfall: Copy‑Pasting Old Outsourcing Policies

Many firms reuse pre‑DORA outsourcing policies without adding DORA’s **ICT‑specific clauses**, **concentration risk assessments**, and **CTPP considerations**, leaving gaps in contracts and oversight.

Common Pitfall: Over‑Broad CIF Mapping

Classifying almost everything as a CIF may seem safe but often **dilutes focus**, overwhelms testing and reporting, and makes proportionality hard to demonstrate. A **risk‑based, justified mapping** is expected.

Success Factor: Integration with Existing Frameworks

Strong programs integrate DORA into **existing risk (Basel/Solvency II), cyber, and outsourcing frameworks**, reusing controls and evidence instead of building parallel structures.

ICT Third‑Party Service Provider

Any external provider delivering ICT services (e.g., cloud, software, infrastructure, security) that support the ICT systems of an EU financial entity under DORA.

Critical ICT Third‑Party Provider (CTPP)

An ICT provider designated at EU level as critical due to its systemic importance, lack of substitutability, and concentration of services to financial entities. Subject to direct oversight by a Lead Overseer under DORA.

Lead Overseer

One of the European Supervisory Authorities (EBA, ESMA, or EIOPA) appointed to coordinate and perform oversight of a Critical ICT Third‑Party Provider’s ICT risk management and resilience for services to EU financial entities.

RTO and RPO

Recovery Time Objective (maximum acceptable downtime) and Recovery Point Objective (maximum acceptable data loss window). Key metrics FEs must align with DORA and expect ICT providers to support.

Shared Responsibility Model

A documented allocation of security and resilience responsibilities between an ICT/cloud provider and the financial entity, clarifying who manages which controls (e.g., physical security vs. IAM configuration).

Fourth‑Party Risk

Risk arising from the subcontractors and sub‑service providers of an ICT provider (from the FE perspective, these are ‘providers of their provider’). DORA requires visibility and controls over such chains.

Key Performance Indicator (KPI) in a DORA context

A quantitative measure of how effectively ICT operations support digital resilience objectives (e.g., service availability, MTTR), focused on performance and outcomes rather than just compliance.

Key Risk Indicator (KRI) in a DORA context

A forward‑looking metric that signals changes in exposure to ICT and operational risk (e.g., number of critical vulnerabilities > 30 days, cloud concentration index), helping anticipate incidents before they materialize.

DORA‑reportable incident

An ICT‑related incident that meets thresholds defined in DORA and its RTS (e.g., impact on critical services, duration, number of users affected) and must be reported to competent authorities within specified timelines.

Testing coverage metric

A measure of how much of your critical/important functions, systems, and third‑party dependencies are exercised through resilience tests (e.g., % of critical services tested against severe‑but‑plausible scenarios in the last 12 months).

Lessons‑learned loop

A structured process that takes incidents, test results, and audit findings, performs root cause analysis, and feeds improvements back into controls, procedures, training, and metrics to strengthen resilience over time.

Cloud concentration risk metric

An indicator that quantifies dependency on specific cloud or ICT providers (e.g., % of critical workloads on one provider or HHI), used to assess resilience and exit strategy feasibility.