DORA Regulatory Glossary

The policies and mechanisms that restrict access to ICT systems, data, and facilities to authorized users with appropriate privileges. Under Art. 9, DORA requires the principle of least privilege (granting users only the minimum access necessary to perform their role), strong authentication including multi-factor authentication for critical systems, and regular access rights reviews. Access control is one of the most frequently examined areas during DORA audits because it directly impacts the confidentiality and integrity of financial data. DORA expects that access control policies cover: user identity management (provisioning, modification, deprovisioning), authentication mechanisms (passwords, MFA, certificates), authorization models (role-based or attribute-based), privileged access management (dedicated accounts, session recording, just-in-time elevation), and periodic access certification (reviewing whether existing access rights remain appropriate). Access to systems supporting critical or important functions requires enhanced controls, and access by third-party providers must be governed through dedicated procedures with time-limited, monitored access.

A documented policy specifying the scope, frequency, methods, and retention requirements for data and system backups. DORA requires under Art. 12 that backup systems be physically and logically separated from source systems to prevent simultaneous compromise, particularly from ransomware attacks that target both production and backup infrastructure. The backup policy must define backup types (full, incremental, differential), frequencies aligned with RPO requirements, retention periods, encryption standards for backup data, and restoration testing schedules. Financial entities must regularly verify that backups can be successfully restored within the timeframes needed to meet recovery objectives. A critical DORA requirement is the separation principle: backup infrastructure must be isolated such that a compromise of the production environment cannot propagate to backups. This addresses the growing trend of ransomware attacks specifically targeting backup systems to prevent recovery. Institutions must also document and test the procedures for restoring from backups under various scenarios, including complete site loss.

A process for assessing the potential impact of ICT-related disruptions on a financial entity's business functions, identifying critical or important functions, determining recovery priorities, and establishing recovery time and recovery point objectives. The BIA is the foundational exercise that drives nearly every other DORA requirement: it determines which functions are critical (triggering enhanced testing, third-party oversight, and reporting obligations), what recovery targets are appropriate, and how business continuity and disaster recovery plans should be structured. Under Art. 11, the BIA must consider financial impact (revenue loss, penalties, compensation costs), customer impact (number affected, service degradation), regulatory impact (reporting obligations, authorization conditions), and reputational impact. BIA results must be reviewed at least annually and updated whenever significant changes occur in the ICT environment, the business model, or the threat landscape. A well-executed BIA is what separates a compliance-driven approach from a genuinely risk-informed resilience strategy.

The national supervisory authority designated by each EU Member State to ensure and monitor compliance with DORA by financial entities within their jurisdiction. For credit institutions, this is typically the national banking supervisor (such as the ACPR in France, BaFin in Germany, or DNB in the Netherlands); for insurance undertakings, the national insurance supervisor; and for investment firms, the national securities regulator. Competent authorities have the power to conduct inspections, request information, issue administrative penalties, and require remedial measures. Under Art. 50, they can impose administrative sanctions and remedial measures for DORA breaches, with the specifics varying by member state. For critical ICT third-party service providers, the ESAs (EBA, EIOPA, ESMA) serve as the competent oversight authority through the Lead Overseer mechanism established in Art. 31-44, creating a novel EU-level supervisory framework for systemically important technology providers.

The formal agreements between financial entities and ICT third-party service providers that must include mandatory provisions as defined by DORA under Art. 30, covering service levels, security requirements, audit rights, data location, subcontracting conditions, exit strategies, and termination rights. For arrangements supporting critical or important functions, Art. 30 specifies additional mandatory clauses: full service level descriptions with quantitative and qualitative targets, the provider's obligation to assist the financial entity during incidents, audit and access rights (including on-site inspections), data location requirements, security measures and encryption standards, subcontracting notification and approval procedures, guaranteed exit assistance including data portability, and termination rights triggered by material breach or change of circumstances. These contractual provisions are not merely best practice recommendations — they are regulatory requirements, and contracts signed before DORA that lack these provisions must be renegotiated to achieve compliance. Supervisors examine contractual arrangements during Pillar IV assessments, and missing or inadequate provisions generate findings requiring remediation.

An ICT third-party service provider designated as critical by the European Supervisory Authorities based on its systemic importance to the financial sector, the degree of reliance by financial entities, the substitutability of the provider, and the number of member states affected. The designation criteria under Art. 31 also consider the degree of dependency of the broader financial market infrastructure on the provider's services. Once designated, a critical provider is subject to direct oversight by a Lead Overseer (one of the three ESAs), who can conduct inspections, issue recommendations, and — as a last resort — request that financial entities suspend or terminate arrangements with the provider. This oversight framework recognizes that the failure of a systemically important ICT provider could create contagion effects across the EU financial system. For example, a major cloud hyperscaler hosting core banking workloads for dozens of European banks could be designated as critical, subjecting it to EU-level regulatory oversight for the first time.

A function the disruption of which would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities, or the discontinued, defective or failed performance of that function would materially impair the continuing compliance of a financial entity with its authorization conditions and obligations or with its other obligations under applicable financial services law. This concept is central to the proportionality principle in DORA: many requirements (such as TLPT under Art. 26, exit strategies under Art. 30, and enhanced third-party oversight under Art. 31) apply specifically to functions classified as critical or important. Institutions must identify and document these functions through a business impact analysis, mapping them to the ICT assets, third-party services, and recovery objectives that support them. For instance, a payment processing function that handles interbank settlements would typically be classified as critical, triggering enhanced resilience testing, more stringent recovery targets, and mandatory exit strategies for supporting third-party arrangements.

Any potential circumstance, event or action that could damage, disrupt or otherwise adversely impact network and information systems, the users of such systems and other persons, including through unauthorized access, destruction, disclosure, modification of data, or denial of service. DORA adopts this definition from the EU Cybersecurity Act (Regulation 2019/881), ensuring alignment across EU cybersecurity legislation. Cyber threats are distinct from ICT risks in that they represent the intentional or unintentional actions of external or internal actors, whereas ICT risk encompasses the broader set of circumstances that could compromise systems. Under DORA, financial entities must integrate cyber threat intelligence into their ICT risk management framework (Art. 13), establish capabilities to detect anomalous activities indicative of cyber threats (Art. 10), and participate in voluntary information-sharing arrangements to exchange threat intelligence with peers (Art. 45). The threat landscape directly shapes the scope of TLPT exercises, where scenarios are derived from current threat actor profiles targeting the financial sector.

The property that data has not been altered or destroyed in an unauthorized manner, ensuring accuracy, completeness, and consistency of data throughout its lifecycle. Data integrity is one of the four pillars of information security alongside confidentiality, availability, and authenticity, and it is explicitly referenced in the DORA definition of ICT-related incidents (Art. 3(8)), which covers events that adversely impact the "availability, authenticity, integrity or confidentiality of data." Financial entities must implement controls to detect and prevent unauthorized data modification, including access controls, checksums, audit trails, and encryption. Under Art. 9, ICT security policies must address data integrity protection as part of the broader security framework. Data integrity failures can have severe consequences in the financial sector — for example, corruption of transaction records, manipulation of risk calculations, or alteration of audit logs could lead to incorrect financial reporting, regulatory breaches, or undetected fraud.

The ability of a financial entity to build, assure, and review its operational integrity and reliability by ensuring, either directly or indirectly through the use of services provided by ICT third-party service providers, the full range of ICT-related capabilities needed to address the security of the network and information systems which a financial entity uses, and which support the continued provision of financial services and their quality. In practice, digital operational resilience means that a bank, insurer, or payment provider can absorb ICT disruptions — whether from cyberattacks, system failures, or third-party outages — and continue serving customers without material impact. This concept is the cornerstone of the entire DORA regulation: every requirement across all five pillars ultimately serves the goal of strengthening this resilience. Achieving it requires an integrated approach spanning ICT risk management (Art. 5-16), incident handling (Art. 17-23), resilience testing (Art. 24-27), third-party oversight (Art. 28-44), and information sharing (Art. 45-49).

The process of assessing preparedness for handling ICT-related disruptions through a range of tests including vulnerability assessments, network security assessments, scenario-based testing, compatibility testing, performance testing, and threat-led penetration testing. Art. 24 requires all financial entities to establish, maintain, and review a digital operational resilience testing programme as part of the ICT risk management framework, with tests conducted proportionate to the entity's size, business, and risk profile. The testing programme must cover all ICT systems supporting critical or important functions and be conducted at least annually. Testing methodologies range from basic vulnerability scanning and open-source analysis (applicable to all entities) to advanced TLPT exercises (required for systemically important entities under Art. 26). Each test must produce evidence that is documented, preserved, and available for supervisory review, and any findings must be formally tracked through remediation to closure.

A documented plan for transitioning away from an ICT third-party service provider, including timelines, resource requirements, data migration procedures, and fallback arrangements. DORA requires under Art. 30 that exit strategies be developed for all arrangements supporting critical or important functions, ensuring that financial entities can terminate a provider relationship without disruption to services. An effective exit strategy must address data portability (how to extract data from the provider's systems in usable formats), transition period (the timeline for migrating to an alternative solution), resource requirements (staff, infrastructure, budget), interim arrangements (how services will be maintained during the transition), and testing (validating that the alternative solution meets operational requirements before switchover). Exit strategies must be realistic and periodically tested — a common audit finding is that exit strategies exist on paper but have never been validated through a migration exercise or even a tabletop simulation. The strategy should also address the scenario where the provider fails unexpectedly, not just planned departures.

A software or hardware asset in the network and information systems used by the financial entity. This includes servers, network devices, databases, applications, middleware, operating systems, and all technology components supporting business processes. Under Art. 8, financial entities must maintain a comprehensive and up-to-date inventory of all ICT assets, classified by criticality and linked to the business functions they support. This inventory forms the foundation of the ICT risk management framework: without knowing what assets you have, you cannot assess the risks they face. The asset register must include ownership information, data classification, lifecycle status, and dependency mappings showing how assets interconnect. Regulators expect this to be a living register that reflects the current technology landscape, not a static document updated annually — any major change in the ICT environment should trigger an inventory update.

A comprehensive policy establishing the framework for maintaining or quickly restoring ICT-supported business operations during and after a disruption. Under Art. 11, the policy must cover all critical or important functions, define the governance structure for activating continuity arrangements, and be tested at least annually through realistic scenarios. The ICT business continuity policy sits at the top of a hierarchy that includes ICT business continuity plans (detailed procedures for specific functions), disaster recovery plans (technical recovery procedures), and communication plans (stakeholder notification protocols). DORA requires that these plans be based on business impact analysis results, aligned with recovery objectives (RTO/RPO), and subject to regular review and improvement based on testing outcomes, incident lessons learned, and changes in the threat landscape. A common audit finding is that institutions have well-written policies but untested plans — DORA closes this gap by mandating that testing validates the actual recovery capability, not just the existence of documentation.

The process for controlling modifications to ICT systems, ensuring that changes are properly authorized, tested, documented, and reversible. Effective change management prevents unauthorized or untested changes from introducing vulnerabilities or disrupting operations. Under Art. 9, DORA requires that ICT security policies include provisions for change management that cover the entire change lifecycle: request, risk assessment, authorization, testing, implementation, verification, and rollback procedures. In the financial sector, change management failures are a leading cause of incidents — an untested database migration, a misconfigured firewall rule, or a poorly coordinated software deployment can disrupt critical services and create security vulnerabilities. DORA expects that change management processes are proportionate to the criticality of the systems being modified, with more rigorous approval and testing requirements for changes affecting systems supporting critical or important functions. Changes must be logged as part of the audit trail, and significant changes should trigger a review of the related risk assessment.

An exposure to individual or multiple related critical ICT third-party service providers creating a degree of dependency on such providers so that the unavailability, failure or other type of shortfall of the provider may endanger the ability of a financial entity to deliver critical or important functions, or cause other types of adverse effects including large losses, up to and jeopardizing the financial stability of the Union as a whole. ICT concentration risk is one of the most significant systemic risks identified by DORA, reflecting the reality that the financial sector has become heavily dependent on a small number of cloud providers and technology platforms. Under Art. 29, financial entities must assess concentration risk as part of their third-party risk strategy, considering factors such as the number of critical functions supported by a single provider, the availability of substitutes, and the difficulty of migrating to alternative solutions. For example, if 80% of a bank's workloads run on a single cloud provider, a prolonged outage of that provider could simultaneously affect payment processing, risk management, and customer-facing services — creating a concentration risk that demands mitigation through multi-cloud strategies, exit planning, and enhanced resilience testing.

A documented plan that details the procedures and resources needed to recover ICT systems, applications, and data following a disaster or major disruption. Disaster recovery plans must be tested at least annually under Art. 11 and must cover scenarios affecting critical or important functions. While the ICT business continuity policy addresses the governance framework and strategic priorities, disaster recovery plans focus on the technical execution: which systems to recover first, what recovery procedures to follow, where recovery infrastructure is located, and how to verify that recovered systems function correctly. DORA requires that DR plans address specific scenario types including cyberattacks, ransomware, infrastructure failures, and third-party outages. Plans must specify switchover procedures to secondary sites, data restoration sequences, and validation checkpoints. Importantly, Art. 11 requires that DR plans be maintained in a state of operational readiness and that recovery tests measure actual recovery times against stated RTOs, generating deviations when targets are missed.

Any reasonably identifiable circumstance in relation to the use of network and information systems which, if materialised, may compromise the security of the network and information systems, of any technology-dependent tool or process, of the operations and processes, or of the provision of services by producing adverse effects in the digital or physical environment. ICT risk is broader than cybersecurity risk alone — it encompasses hardware failures, software bugs, configuration errors, capacity exhaustion, and third-party service disruptions. Under DORA, financial entities must identify and assess ICT risks on a continuous basis (Art. 6), not merely during annual reviews. For example, a bank relying on a single cloud provider for its core banking platform faces ICT risk from both technical failures and concentration dependency, requiring mitigation through redundancy, exit strategies, and regular testing.

A comprehensive, documented framework encompassing strategies, policies, procedures, ICT protocols and tools necessary to duly and adequately protect all relevant ICT assets and infrastructure against ICT risks. Under Art. 6, the framework must be reviewed at least annually, improved continuously based on lessons learned from incidents and testing, and approved by the management body. The ICT risk management framework is the central governance construct in DORA — it connects all five pillars into a coherent management system. It must include: risk identification and assessment processes (Art. 8), protection and prevention measures (Art. 9), detection capabilities (Art. 10), response and recovery mechanisms (Art. 11), and learning and improvement processes (Art. 13). Financial entities must ensure the framework is proportionate to their size and risk profile, but even entities eligible for the simplified framework (Art. 16) must maintain core risk management capabilities. A well-implemented framework is not a static document but an operational system: risks are identified continuously, controls are monitored through assertions, incidents inform risk updates, testing validates recovery capabilities, and third-party arrangements are governed through the same risk lens.

A documented policy defining the rules, procedures, and technical standards for protecting the confidentiality, integrity, and availability of information and ICT assets. Under Art. 9, DORA requires entities to implement ICT security policies covering access control, encryption, network security, patch management, and change management. The security policy must be a living document, reviewed and updated at least annually, and must address both preventive controls (reducing the likelihood of incidents) and detective controls (identifying incidents when they occur). Art. 9 specifically mandates policies on: strong authentication and cryptographic key management, network segmentation and traffic monitoring, data-in-transit and data-at-rest encryption, logging and monitoring of security events, and management of privileged access accounts. The policy must be approved by the management body and communicated to all staff. Compliance with the security policy is often validated through the resilience testing programme (Art. 24-27), where vulnerability assessments and penetration tests specifically verify that the controls mandated by the policy are actually implemented and effective.

Digital and data services provided through ICT systems to one or more internal or external users on an ongoing basis, including hardware as a service, software as a service, and other cloud or non-cloud technology services. Under DORA, this broad definition ensures that all technology services supporting financial operations fall within the regulatory scope, regardless of their delivery model. This includes not only externally procured services but also internally developed applications and infrastructure. Financial entities must map ICT services to the business functions they support, assess their criticality through business impact analysis, and ensure that adequate recovery capabilities exist for each service. The distinction between a critical ICT service and a non-critical one has significant regulatory consequences: services supporting critical or important functions trigger enhanced contractual requirements (Art. 30), mandatory exit strategies, and more stringent testing obligations.

An undertaking providing ICT services, including digital and data services provided through ICT systems to one or more internal or external users on an ongoing basis. This encompasses providers of cloud computing services, software, data analytics services, and data centre services. DORA applies this definition broadly — it covers not only traditional outsourcing relationships but also SaaS platforms, managed security service providers, infrastructure-as-a-service providers, and even intra-group ICT service arrangements. Under Pillar IV (Art. 28-44), financial entities must maintain a register of all contractual arrangements with ICT third-party providers, classify each arrangement by criticality, and ensure that contracts include mandatory provisions covering service levels, audit rights, data location, subcontracting notification, and exit clauses. The designation of a provider as "critical" under Art. 31 triggers direct oversight by a Lead Overseer from the European Supervisory Authorities.

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 an adverse impact on the availability, authenticity, integrity or confidentiality of data, or on the services provided by the financial entity. This definition is deliberately broad, covering everything from a database corruption event to a denial-of-service attack or an accidental data exposure. Not every ICT-related incident qualifies as "major" — DORA distinguishes between general incidents and major incidents (Art. 3(10)) based on classification criteria such as the number of clients affected, duration, geographic spread, and economic impact. Financial entities must have processes to detect, manage, and log all ICT-related incidents, while applying the mandatory reporting framework only to those meeting the materiality thresholds defined in the regulatory technical standards.

The mandatory process of notifying competent authorities about major ICT-related incidents. DORA establishes under Art. 19 a three-phase reporting framework: initial notification (within four hours of classifying the incident as major), intermediate report (within 72 hours, with updated details on impact assessment and response actions), and final report (within one month, with comprehensive root cause analysis and remediation measures). This harmonized reporting framework replaces the patchwork of national reporting requirements that previously existed across EU member states, reducing the reporting burden while ensuring supervisors receive timely and consistent information. Financial entities must have internal processes to rapidly assess whether an incident meets the classification thresholds (Art. 18) and trigger the reporting workflow within the prescribed timelines. The initial notification must include key details: the nature of the incident, affected services, estimated number of impacted clients, and preliminary impact assessment. Missing reporting deadlines or submitting incomplete reports can itself constitute a compliance finding.

A collection of information, either tangible or intangible, that is worth protecting. In the DORA context, this encompasses any data set or information resource that supports business functions and must be classified, protected, and tracked as part of the ICT risk management framework. Information assets include customer databases, transaction records, risk models, configuration data, cryptographic keys, and intellectual property. Under Art. 8, financial entities must classify information assets according to their sensitivity and criticality, applying appropriate protection measures proportionate to the classification level. The relationship between information assets and ICT assets is important: an information asset (such as customer data) resides on ICT assets (such as databases and storage systems), and the risk profile of the information asset determines the required security controls for the ICT assets that host it.

Voluntary arrangements between financial entities for exchanging cyber threat intelligence, indicators of compromise, tactics, techniques and procedures, and other security-relevant information within trusted communities, subject to data protection and competition law safeguards. Art. 45 establishes the legal framework for these arrangements, providing legal certainty for participants and addressing concerns about antitrust liability and data protection compliance that previously discouraged information sharing. Participants may share anonymized information about threats, vulnerabilities, and incidents they have experienced, enabling peer institutions to strengthen their defenses proactively. These arrangements operate under strict rules: shared information must be protected from unauthorized access, participants must respect confidentiality obligations, and personal data must be handled in compliance with GDPR. In practice, information-sharing arrangements often take the form of sector-specific Information Sharing and Analysis Centers (ISACs), such as the European Financial ISAC, where members exchange threat intelligence through standardized formats (STIX/TAXII) and secure communication channels.

One of the three European Supervisory Authorities (EBA, EIOPA, or ESMA) designated to conduct direct oversight of a critical ICT third-party service provider. The Lead Overseer is selected based on which financial sector (banking, insurance, or securities) is most dependent on the designated provider's services, as determined by the criteria in Art. 31. The Lead Overseer framework represents one of DORA's most innovative governance mechanisms: for the first time, EU supervisors can directly oversee technology companies that are systemically important to the financial sector, even though these providers are not themselves financial entities. The Lead Overseer's powers under Art. 35 include conducting inspections (including on-site at the provider's premises), issuing recommendations that the provider must address, and — as an ultimate measure — requesting that financial entities terminate or suspend arrangements with a non-compliant provider. The oversight framework also establishes a Joint Examination Team composed of staff from the Lead Overseer and relevant national competent authorities, ensuring coordinated supervision across the EU.

An ICT-related incident that has a high adverse impact on the network and information systems that support critical or important functions of the financial entity, meeting or exceeding the materiality thresholds defined in the classification criteria. The classification criteria established under Art. 18 include factors such as the number of clients affected (typically exceeding 10% of all clients or specific absolute thresholds), the duration of the disruption, the geographic spread across member states, data losses sustained, the criticality of affected services, and the economic impact. Major ICT-related incidents trigger the three-phase mandatory reporting obligation under Art. 19: initial notification within four hours of classification, an intermediate report within 72 hours, and a final report with root cause analysis within one month. For example, a ransomware attack that encrypts a bank's payment processing systems for eight hours, affecting 50,000 customers across three EU member states, would clearly qualify as a major incident.

The governing body of a financial entity that has the ultimate decision-making authority and bears the responsibility for the entity's strategy, risk management and internal governance. Under Art. 5, the management body has specific, non-delegable obligations regarding ICT risk management: it must approve the ICT risk management framework, set the institution's risk appetite for ICT risk, allocate adequate budget and resources to digital operational resilience, and ensure that senior management maintains sufficient knowledge of ICT risk. DORA places personal accountability on management body members for compliance failures, reflecting the regulatory trend toward board-level responsibility for operational resilience. Art. 13(5) requires the management body to be informed of the results of post-incident reviews and resilience testing, and to approve remediation plans for significant findings. In practice, this means boards must engage with ICT risk at a strategic level, not merely sign off on policies they have not read. Supervisors increasingly assess whether management body members have adequate ICT literacy to fulfill their DORA obligations.

A mandatory review conducted after significant ICT disruptions to analyze the root causes, assess the effectiveness of the response, identify areas for improvement, and generate recommendations. Under Art. 13, results must be reported to the management body and integrated into the ICT risk management framework, creating a feedback loop that drives continuous improvement. Post-incident reviews go beyond root cause analysis by examining the entire incident lifecycle: detection speed, escalation effectiveness, communication quality, response adequacy, and recovery performance. They should assess whether existing controls operated as designed, whether the incident was detected through automated monitoring or manual observation, and whether recovery times met stated RTO/RPO targets. Recommendations from post-incident reviews should be specific, actionable, and assigned to owners with deadlines, and they should be tracked to completion as formal deviations requiring remediation. DORA expects that lessons learned from one incident improve the institution's ability to handle similar incidents in the future, and supervisors assess whether post-incident reviews actually result in measurable improvements or merely produce reports that gather dust.

The principle that DORA requirements should be implemented in a manner proportionate to the financial entity's size, overall risk profile, and the nature, scale and complexity of its services, activities and operations. Art. 4 establishes proportionality as a cross-cutting principle affecting how institutions interpret and apply DORA requirements. Smaller or less complex entities may apply simplified requirements (Art. 16 provides a simplified ICT risk management framework) while maintaining core obligations such as incident reporting and third-party risk management. However, proportionality is not an exemption mechanism — it does not allow entities to ignore requirements but rather to calibrate their implementation. For example, a small payment institution is not required to conduct TLPT (which targets systemically important entities), but it must still maintain a testing programme that includes vulnerability assessments proportionate to its risk profile. Supervisors assess proportionality based on objective criteria: total assets, number of employees, nature of services provided, interconnectedness with the financial system, and the criticality of functions performed. The burden of proving that a proportionate implementation is adequate rests with the entity.

The maximum acceptable amount of data loss measured in time. It defines the point in time to which data must be recovered after a disruption, determining the minimum frequency of data backups required to protect critical or important functions. An RPO of 1 hour means that, following a disruption, the organization must be able to recover data to a state no older than 1 hour before the disruption occurred, requiring at minimum hourly backups or continuous replication. Under DORA, RPOs must be established through business impact analysis (Art. 11), aligned with the criticality of the function and the sensitivity of the data involved. Financial transaction data, for example, typically demands an RPO approaching zero (real-time replication), while reporting data might tolerate an RPO of several hours. Art. 12 further requires that backup systems be physically and logically separated from source systems to prevent simultaneous compromise, particularly from ransomware attacks that target both production and backup infrastructure.

The maximum acceptable time period within which a critical or important function must be restored after a disruption to meet business continuity requirements. RTO is a key parameter in business continuity planning under DORA and must be established through business impact analysis (Art. 11), validated through regular testing (Art. 25), and documented in ICT business continuity plans and disaster recovery plans. The RTO for each function should be calibrated based on the function's criticality, the financial impact of prolonged disruption, the number of customers affected, and any regulatory reporting obligations. For instance, a payment processing function might have an RTO of 2 hours, while a regulatory reporting function might tolerate a 24-hour recovery window. Critically, DORA requires that RTOs are not merely documented targets but tested and measurable outcomes — institutions must demonstrate through actual testing that they can recover within stated timeframes, and any test that exceeds the RTO must generate a deviation requiring remediation.

A method of testing the security of an organization by simulating attacks by an adversary using realistic tactics, techniques and procedures. In the DORA context, red team testing forms the core of TLPT exercises under Art. 26 and must be conducted against live production systems supporting critical functions. The red team is an external provider selected for its expertise in offensive security and its knowledge of the threat actors targeting the financial sector. They operate based on the scenarios defined in the Targeted Threat Intelligence Report (TTIR), using the same tools and techniques that real adversaries would employ. Critically, the institution's blue team (security operations) is not aware that a test is underway, ensuring that the test validates real detection and response capabilities, not rehearsed procedures. After the active testing phase, red and blue teams come together in a "purple team" exercise to collaboratively analyze findings, share attack paths, and identify gaps in detection and response. Red team testing is the most resource-intensive form of resilience testing under DORA, but it provides the most realistic assessment of an institution's ability to withstand sophisticated adversaries.

A comprehensive register maintained by financial entities documenting all contractual arrangements with ICT third-party service providers. Under Art. 28(3), the register must include details on the provider, services covered, criticality classification, relevant jurisdictions, and must be made available to competent authorities upon request. The register serves as the primary supervisory tool for assessing an institution's third-party dependency landscape and concentration risk exposure. It must distinguish between arrangements supporting critical or important functions and those that do not, as the former trigger enhanced contractual requirements under Art. 30. The EBA has published Implementing Technical Standards (ITS) specifying the exact format and content of the register, ensuring consistency across the EU. Financial entities must update the register promptly when arrangements change, are renewed, or are terminated. In practice, the register is the first document supervisors request during a DORA examination of Pillar IV compliance, making its accuracy and completeness a high-priority compliance obligation.

A structured investigation method to determine the underlying cause of an ICT-related incident, going beyond surface-level symptoms to identify the fundamental factors that allowed the incident to occur. DORA mandates root cause analysis for all major incidents as part of the final report under Art. 17, which must be submitted to the competent authority within one month of the incident. Root cause analysis is not simply asking "what happened" but systematically investigating "why it happened" and "what systemic factors contributed." Methods commonly used include the "5 Whys" technique, fault tree analysis, and the Ishikawa (fishbone) diagram. The analysis should identify not just technical causes (such as a software bug or a hardware failure) but also organizational factors (such as inadequate testing, insufficient monitoring, or poor change management). The results of root cause analysis must feed back into the ICT risk management framework (Art. 13), driving improvements to controls, processes, and testing scenarios. Without effective root cause analysis, institutions risk addressing symptoms while the underlying vulnerabilities persist, leading to recurring incidents.

A less complex version of the ICT risk management framework available to certain smaller or less interconnected financial entities as defined in Art. 16. While maintaining core risk management capabilities, it allows for proportionate governance, documentation, and reporting obligations. Entities eligible for the simplified framework include small and non-interconnected investment firms, payment institutions exempted under the Payment Services Directive, and institutions exempted under the Electronic Money Directive. The simplified framework still requires entities to maintain sound ICT risk management, with appropriate security measures, incident detection and response capabilities, business continuity planning, and testing. However, the documentation requirements are reduced, the governance structure can be simpler, and certain advanced testing obligations (such as TLPT) do not apply. It is important to note that the simplified framework does not exempt entities from incident reporting obligations (Art. 17-23) or third-party risk management requirements (Art. 28-44) — these apply to all in-scope entities. Entities using the simplified framework must still be prepared for supervisory examinations and must be able to demonstrate that their proportionate implementation adequately addresses their specific risk profile.

The practice by an ICT third-party service provider of delegating parts of its contracted services to another provider (subcontractor). DORA requires under Art. 30 that financial entities maintain visibility and control over subcontracting chains, particularly for services supporting critical or important functions. Contractual arrangements must include provisions requiring the provider to notify the financial entity of any intended subcontracting of services supporting critical functions, enabling the entity to assess whether the subcontracting arrangement introduces new risks. Subcontracting chains can create hidden concentration risk — for example, multiple providers may subcontract their infrastructure to the same cloud hyperscaler, creating a single point of failure that is invisible at the primary contract level. Financial entities must ensure that their contractual rights (audit, data access, security requirements) flow down to subcontractors and that exit strategies account for subcontracting dependencies. The regulatory expectation is clear: a financial entity cannot outsource its regulatory obligations through subcontracting chains.

The degree to which an ICT third-party service provider can be replaced by another provider or by bringing the service in-house without significant cost, delay, or disruption to operations. Substitutability is a key factor in assessing ICT concentration risk under Art. 29 and in determining whether a provider should be designated as critical under Art. 31. Low substitutability indicates high dependency and therefore higher concentration risk, requiring more robust exit planning and potentially triggering enhanced oversight. Factors affecting substitutability include the degree of customization, proprietary data formats, integration complexity, contractual lock-in periods, the availability of alternative providers with equivalent capabilities, and the time and cost required for migration. For example, a bank using a proprietary core banking platform with deep integration into hundreds of internal systems has low substitutability for that provider — migration could take years and cost millions. DORA requires institutions to formally assess substitutability as part of their pre-contractual analysis for arrangements supporting critical or important functions.

Evidence-based knowledge, including context, mechanisms, indicators, implications and actionable advice, about an existing or emerging menace or hazard to ICT assets. DORA encourages the voluntary exchange of threat intelligence among financial entities within trusted communities under Art. 45, recognizing that cyber threats targeting the financial sector are often systemic in nature and that shared awareness improves collective defense. Under Art. 13, financial entities must integrate threat intelligence into their ICT risk management framework, using it to inform risk assessments, calibrate detection capabilities, and shape testing scenarios. Threat intelligence feeds directly into TLPT exercises (Art. 26), where the Targeted Threat Intelligence Report (TTIR) produced by the intelligence provider determines the attack scenarios the red team will execute. Effective threat intelligence covers multiple levels: strategic (threat landscape trends), tactical (threat actor profiles, TTPs), operational (campaign details, IOCs), and technical (specific malware signatures, IP addresses). Financial entities should consume intelligence from multiple sources, including commercial feeds, sector-specific ISACs, and peer sharing arrangements.

A framework that mimics the tactics, techniques and procedures of real-life threat actors perceived as posing a genuine cyber threat, delivering a controlled, bespoke, intelligence-led red team test of the financial entity's critical live production systems. TLPT must be based on current threat intelligence specific to the tested entity and is governed by the TIBER-EU framework and its national implementations (TIBER-FR, TIBER-DE, TIBER-NL, TIBER-LU). Unlike standard penetration testing, TLPT is conducted against live production systems — not staging environments — and uses a three-team structure: a white team (internal coordinators), a red team (external attackers), and a blue team (defenders unaware of the test). Under Art. 26, entities identified by competent authorities must conduct TLPT at least every three years, covering all critical or important functions over the testing cycle. The results must be shared with the competent authority, and remediation of findings is tracked through a formal process. TLPT typically spans 6 to 12 months from scoping through remediation closure.

A systematic examination of ICT systems, networks, and applications to identify security weaknesses and potential entry points for threat actors. Vulnerability assessments are a baseline testing requirement under Art. 25 of DORA and must be conducted at frequencies proportionate to the risk profile of the systems tested. Unlike penetration testing, which actively exploits vulnerabilities to assess their real-world impact, vulnerability assessments focus on identification and classification of weaknesses. Under DORA, they form part of the minimum testing toolkit available to all financial entities, including those exempt from TLPT requirements. Results must be documented, with identified vulnerabilities prioritized by severity and tracked through remediation. Financial entities are expected to maintain vulnerability scanning as a continuous activity, not a periodic event, particularly for internet-facing systems and those supporting critical or important functions.