DORA Glossary: Key Terms and Definitions for EU Fintechs

In this article ↓

Short answer
The Regulation and scope
DORA
Digital operational resilience
Financial entity (DORA scope)
Proportionality
ICT risk management
ICT risk
ICT risk management framework
Management body
Critical or important function
Business continuity and recovery plans
Incident management
ICT-related incident
Major ICT-related incident
Significant cyber threat
Incident reporting timeline
ICT third-party risk
ICT third-party service provider
Critical ICT third-party service provider (CTPP)
Register of Information
ICT concentration risk
Article 30 contractual provisions
Exit strategy
Resilience testing
Digital operational resilience testing
Threat-led penetration testing (TLPT)
Oversight Framework
Oversight Framework
Lead Overseer
Technical standards
RTS — Regulatory Technical Standards
ITS — Implementing Technical Standards
Further reading
Primary sources

Last reviewed: 1 June 2026

Key takeaways

DORA — Regulation (EU) 2022/2554 — defines core terms in Article 3; substantive obligations run from Articles 5 to 45.
Every definition here is sourced from the Regulation as it has applied since 17 January 2025.
Precise DORA vocabulary is required for NCA interactions, incident reporting, Register of Information submissions and third-party contract reviews.
Proportionality applies: smaller, less complex entities may use a simplified ICT risk management framework under Article 16.

Short answer

A DORA glossary covers the core defined terms in Regulation (EU) 2022/2554 — the Digital Operational Resilience Act — that EU financial entities and their advisors use in compliance programmes, supervisory interactions and third-party contracts.

The most operationally important terms are: ICT risk, critical or important function, major ICT-related incident, Register of Information, ICT concentration risk, critical ICT third-party service provider (CTPP) and TLPT. Each entry below is self-contained and AI-citable, linked where applicable to the full working guide.

The Regulation and scope

DORA

DORA is Regulation (EU) 2022/2554 of the European Parliament and of the Council, adopted on 14 December 2022 and applying in full since 17 January 2025. It creates a binding, uniform framework for ICT risk management, incident reporting, digital operational resilience testing, ICT third-party risk management and information sharing across EU financial entities. DORA is a Regulation — it applies directly in all EU Member States without national transposition.

Digital operational resilience

Defined in Article 3 of DORA: the ability of a financial entity to build, assure and review its operational integrity and reliability by ensuring the full range of ICT-related capabilities needed to address the security of the network and information systems that support the continued provision of financial services and their quality, including during disruptions. Under DORA, digital operational resilience is a continuous operating discipline, not a project outcome.

Financial entity (DORA scope)

Article 2 of DORA lists the entity types subject to the Regulation. Common EU fintech categories include credit institutions, payment institutions (PIs), electronic money institutions (EMIs), investment firms, crypto-asset service providers (CASPs) authorised under MiCA, and certain insurance undertakings. Each regulated legal entity in a group is assessed against scope separately; group membership does not automatically bring all entities in or out of scope.

Proportionality

The proportionality principle in DORA allows obligations to be calibrated to the size, risk profile and operational complexity of the financial entity. Article 16 creates a simplified ICT risk management framework for entities identified as smaller or less complex; proportionality also applies to the depth of resilience testing and third-party oversight expectations. Proportionality does not remove the obligation — it adjusts the expected governance depth, documentation and testing frequency.

ICT risk management

ICT risk

Defined in Article 3 of DORA: any reasonably identifiable circumstance in relation to the use of network and information systems which, if materialised, may compromise the security of those systems, of any technology-dependent tool or process, of operations and processes, or of the provision of financial services — producing adverse effects in the digital or physical environment. ICT risk encompasses availability, authenticity, integrity and confidentiality risks across data and services.

ICT risk management framework

The ICT risk management framework is the structured set of strategies, policies, procedures, protocols and tools that a financial entity must maintain under Article 6 of DORA to identify, protect against, detect, respond to, recover from and learn from ICT-related risks and incidents. The management body must approve and maintain oversight of the framework; it must connect to a live ICT risk register, control ownership and remediation tracking — not operate as a static policy document.

Management body

Under Article 5 of DORA, the management body — whether a board of directors, supervisory board or equivalent governing body — bears ultimate responsibility for setting ICT risk strategy, approving the ICT risk management framework and receiving regular ICT risk reporting. This governance obligation cannot be fully delegated to technical functions; the management body must demonstrably exercise oversight as part of the DORA compliance record.

Critical or important function

Defined in Article 3 of DORA: a function whose disrupted, defective or failed performance would materially impair a financial entity's continuing compliance with the conditions and obligations of its authorisation, or its financial performance, or the soundness or continuity of its services and activities. The classification of which functions are critical or important is the foundation for scoping the Register of Information, resilience testing and contractual requirements for third-party providers. For practical scope mapping, see the DORA gap analysis guide.

Business continuity and recovery plans

Articles 11 and 12 of DORA require financial entities to maintain ICT business continuity plans (BCPs) and ICT disaster recovery plans (DRPs) with documented recovery time objectives (RTO) and recovery point objectives (RPO), tested periodically and updated after material changes or incidents. Plans must address the financial entity's critical or important functions and the ICT systems that support them. See DORA Business Continuity and Disaster Recovery: Articles 11–12 Roadmap.

Incident management

Defined in Article 3 of DORA: a single event, or a series of linked events, unplanned by the financial entity, that compromises the security of the network and information systems and has or may have an adverse impact on the availability, authenticity, integrity or confidentiality of data, or on the services provided by the financial entity. Not every ICT-related incident is a major ICT-related incident — Article 18 requires classification of each event before any reporting obligation is triggered.

Defined in Article 3 of DORA as an ICT-related incident that has a high adverse impact on the network and information systems supporting critical or important functions of the financial entity. A major ICT-related incident triggers the mandatory three-stage NCA reporting process under Article 19: initial notification, intermediate report and final report within prescribed timelines. Classification criteria and impact thresholds are set through regulatory technical standards under Article 18. See the DORA incident reporting guide.

Significant cyber threat

Defined in Article 3 of DORA: a cyber threat with the characteristics to seriously disrupt the operations of a financial entity, including its critical or important functions, or to cause material financial losses. Financial entities may voluntarily notify their NCA of a significant cyber threat under Article 19(2) even where it has not yet materialised into a reportable incident; voluntary notification does not start the mandatory reporting clock.

Incident reporting timeline

Under Article 19 of DORA, a financial entity must submit three reports after classifying an event as a major ICT-related incident: an initial notification within 4 hours of major classification (and no later than 24 hours after first awareness); an intermediate report within 72 hours of the initial notification; and a final report within one month of the latest intermediate report. The submission channel and template are set by the relevant national competent authority. See DORA incident reporting for the full timeline and jurisdiction-specific channels.

ICT third-party risk

ICT third-party service provider

Defined in Article 3 of DORA: an undertaking providing digital and data services — including cloud computing, software, data analytics and data centre services — to one or more financial entities, excluding providers of hardware components. Financial entities remain fully responsible for DORA compliance even when ICT services are delivered by a third party; the provider's own compliance posture does not substitute for the financial entity's obligations under Chapter V of DORA.

Critical ICT third-party service provider (CTPP)

An ICT third-party service provider designated as critical by the Joint Committee of the European Supervisory Authorities under Article 31 of DORA, based on systemic importance, number of financial entity clients, substitutability and cross-border impact. CTPPs are subject to direct EU-level oversight under the Oversight Framework (Articles 31–44); their designation creates specific operational obligations for the financial entities that use them, including cooperation with the Lead Overseer and remediation of oversight findings.

Register of Information

The Register of Information is the structured inventory maintained under Article 28 of DORA for all ICT third-party service arrangements. It must document:

the ICT service provider;
the service or function supported;
whether the function is critical or important;
subcontracting arrangements;
the contract lifecycle;
the geographic locations of services and data processing.

The Register is the primary supervisory evidence artefact for ICT third-party risk — it must be kept current and available for NCA review. For a complete field guide, see DORA Register of Information and DORA Third-Party ICT Risk.

ICT concentration risk

Under Article 29 of DORA, financial entities must identify and assess concentration risk — the risk arising from dependence on a single ICT third-party provider or a small number of providers — before entering a new ICT arrangement that supports a critical or important function. The assessment must consider substitutability, single points of failure and cross-sector concentration where the same provider serves multiple financial entities. Evidence of the pre-contractual concentration risk assessment is a required element of the third-party due diligence record.

Article 30 contractual provisions

Article 30 of DORA sets mandatory contract terms for all ICT third-party service arrangements, with a deeper set of requirements for arrangements supporting a critical or important function. Required provisions include:

full description of services and quality levels;
audit and access rights for the financial entity and its supervisors;
incident notification obligations;
business continuity support obligations;
subcontracting conditions and change notification rights;
data portability, return and deletion rights;
termination rights.

A clause-by-clause gap tracker is the standard evidence artefact. See DORA Third-Party ICT Risk: Articles 28–30.

Exit strategy

Article 28 of DORA requires financial entities to maintain a documented exit strategy for ICT arrangements supporting critical or important functions. The strategy must address contractual termination triggers, data portability and return procedures, realistic transition or insourcing options, and continuity of the critical function during migration. An exit strategy that exists only as a document, without operational feasibility analysis, will not withstand supervisory scrutiny.

Resilience testing

Digital operational resilience testing

Article 24 of DORA requires all in-scope financial entities to maintain a digital operational resilience testing programme, proportionate to their size, risk profile and function criticality. Tests must include vulnerability assessments, backup and restore tests, disaster recovery tests and incident response exercises, producing documented findings, remediation owners and closure evidence. Testing without remediation follow-through does not satisfy DORA.

Threat-led penetration testing (TLPT)

TLPT is advanced resilience testing based on live threat intelligence, required under Article 26 of DORA only for financial entities identified by competent authorities — it is not a universal DORA obligation. TLPT must be performed at least every three years by approved testers and follows the TIBER-EU methodology in the EU context. Entities not identified for TLPT still need a proportionate testing programme; representing TLPT as mandatory for all entities is a common and consequential misstatement. See DORA TLPT guide.

Oversight Framework

Articles 31–44 of DORA establish a direct EU-level supervisory regime for critical ICT third-party service providers (CTPPs). The framework is administered by the Joint Committee of EBA, ESMA and EIOPA; each designated CTPP is assigned to a Lead Overseer. The Oversight Framework applies to the CTPP directly — it does not replace NCA supervision of the financial entity, but financial entities using a CTPP must cooperate with oversight requests and act on recommendations issued to their provider.

Lead Overseer

The Lead Overseer is the European Supervisory Authority (EBA, ESMA or EIOPA) assigned under Article 33 of DORA to exercise ongoing oversight of a specific critical ICT third-party service provider. The Lead Overseer can issue recommendations, request information, conduct investigations and carry out inspections of the CTPP. Financial entities using a CTPP must cooperate with Lead Overseer information requests and report on the outcome of the CTPP's implementation of oversight findings.

Technical standards

RTS — Regulatory Technical Standards

Regulatory Technical Standards are binding technical rules developed by EBA, ESMA or EIOPA under specific DORA mandates and adopted by the European Commission as Delegated Regulations. Major DORA RTS packages cover ICT risk management framework requirements (Article 15), incident classification and reporting (Articles 18 and 20), Register of Information data requirements (Article 28), TLPT requirements (Article 26) and key contractual provisions (Article 30). RTS have the same binding legal force as DORA itself.

ITS — Implementing Technical Standards

Implementing Technical Standards specify the standard forms, templates and procedures for DORA compliance activities. Key ITS packages cover major ICT-related incident reporting templates (Article 20 mandate), Register of Information data fields and submission formats (Article 28) and TLPT procedural requirements (Article 26). ITS are adopted by the European Commission as Implementing Regulations and define the exact formats used in supervisory exchanges between financial entities and NCAs.

Need a DORA gap analysis that maps your actual posture?

A 90-day programme run by a CISO who has delivered DORA for EMIs, PIs and CASPs under EU and UK financial-sector supervision — no pitch, just where you stand.

Book a free 15-min call →

Andrey Gubarev

Related reading