Requirements OverviewEU

EU DORA Requirements

EU DORA is built around governance, ICT risk management, incident reporting, resilience testing, ICT third-party risk, and supervision of critical ICT third-party providers.

This overview helps map the main requirement areas to accountable owners, registers, policies, incident files, testing records, contract evidence, and proportionality decisions.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
Sections
6

Structured answer sets in this page tree.

Primary sources
10

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 24, 2026
Overview

has applied since 17 January 2025 to the financial entities listed in Article 2, subject to specific exclusions. It also reaches ICT third-party service providers through contractual risk management and, for providers designated as critical, Union oversight. The work covers management-body accountability, ICT risk controls, incident classification and reporting, resilience testing including TLPT for selected entities, ICT third-party risk management, and the register of information. DORA is a binding EU regulation, not a certification scheme.

Section 1

What DORA requires financial entities to organize

requires financial entities to manage ICT risk through an internal governance and control framework. The management body defines, approves, oversees, and remains responsible for the ICT risk management framework and the digital operational resilience strategy.

A useful requirements map starts with governance: which entity is in scope, whether Article 16 assigns it to the simplified ICT risk management framework, which management body approves the applicable framework, which functions own ICT risk, incident response, business continuity, testing, procurement, legal, and outsourcing, and how exceptions and residual risks are escalated.

The regulation and the delegated and implementing regulations cited on this page are binding. Suggested ownership maps, evidence packs, and implementation sequences are Sorena's practical explanation of how a financial entity can make those duties reviewable; they are not prescribed templates unless the text identifies an official form.

  • Keep the scope record tied to the financial entity type, business services, critical or important functions, ICT assets, and ICT third-party dependencies.
  • Record the management-body approval of ICT risk policies, risk tolerance, business continuity policy, response and recovery plans, and ICT third-party risk strategy.
  • Separate operational ownership from review and control responsibilities so ICT risk decisions are not only documented by the teams that implement them.
  • Use proportionality explicitly: size, overall risk profile, and the nature, scale, and complexity of services affect how the requirements are applied, but do not remove the need for a reasoned record.
  • Do not merge proportionality with the Article 16 legal test: only the categories named there use the simplified ICT risk management framework, and that framework does not erase other applicable chapters.
Section 2

ICT risk management and control evidence

's ICT risk management work should be traceable from business function to ICT asset, threat, vulnerability, risk treatment, residual risk, recovery requirement, and control evidence. Delegated Regulation (EU) 2024/1774 adds detail on ICT security policies, procedures, protocols, tools, asset management, risk assessment methodology, risk treatment, monitoring, and review.

For search visitors comparing what to build first, the durable evidence is the framework itself: approved policies, asset records, business-function mappings, risk tolerance, treatment decisions, residual-risk acceptance, continuity and recovery records, logging and security controls, and review history.

  • Maintain ICT asset records with identifiers, owners, locations, classifications, supported business functions or services, continuity requirements, external exposure, dependencies, and third-party support end dates where applicable.
  • Document the risk assessment method for vulnerabilities and threats affecting supported business functions, ICT systems, and ICT assets.
  • Keep treatment decisions linked to the approved ICT risk tolerance and record accepted residual risks with justifications and review evidence.
  • Show how ICT security policies preserve availability, authenticity, integrity, and confidentiality of data and how exceptions are monitored.
Section 3

Incident classification and reporting requirements

separates incident handling from incident reporting. Financial entities need processes to detect, manage, classify, and report major ICT-related incidents, and they may voluntarily notify significant cyber threats. Classification is not an informal severity label: Delegated Regulation (EU) 2024/1772 specifies criteria covering clients, financial counterparts and transactions, reputational impact, duration and service downtime, geographical spread, data losses, critical services affected, and economic impact.

The reporting evidence should preserve both the operational timeline and the regulatory classification. Implementing Regulation (EU) 2025/302 provides standard forms and data fields for initial notification, intermediate report, final report, and significant cyber-threat notification.

  • Capture when the incident was detected, when it was classified as major, the affected Member States, how it was discovered, whether a business continuity plan was activated, and whether a third-party provider or another financial entity was involved.
  • For intermediate reporting, preserve affected clients, financial counterparts, transactions, duration, downtime, data losses, critical services affected, affected functional areas, affected infrastructure, temporary recovery measures, and indicators of compromise where applicable.
  • For final reporting, preserve root-cause classification, resolution summary, dates for root-cause remediation and incident resolution, recurring non-major incident analysis, and cost or loss data where required.
  • Keep GDPR or other personal-data breach notifications separate but cross-referenced when the same event triggers both and data-protection workflows.
  • Run the reporting clock from the legal trigger, not an internal severity label: submit the initial notification as early as possible and within four hours after classifying the incident as major, and no later than 24 hours after becoming aware of it; submit the intermediate report within 72 hours after the initial notification; and submit the final report no later than one month after the intermediate report or latest updated intermediate report.
Section 4

Resilience testing and TLPT

requires financial entities, other than microenterprises, to maintain and review a digital operational resilience testing programme as part of the ICT risk management framework. The programme can include vulnerability assessments, scans, network security assessments, gap analyses, scenario-based tests, compatibility testing, performance testing, end-to-end testing, and penetration testing.

Threat-led penetration testing is narrower and more demanding. defines TLPT as intelligence-led red-team testing of critical live production systems, and selected financial entities perform TLPT against several or all critical or important functions. Delegated Regulation (EU) 2025/1190 sets criteria and process expectations for identifying entities required to perform TLPT, the use of internal testers, scope, methodology, results, closure, remediation, and supervisory cooperation.

  • Keep a testing programme inventory showing test type, scope, systems, critical or important functions covered, findings, remediation owner, due date, retest result, and management reporting.
  • Do not treat TLPT as an annual vulnerability scan; it is a controlled, intelligence-led test involving defined participants such as the control team, blue team, red team, threat intelligence provider, TLPT authority, and test managers.
  • For TLPT, preserve scoping decisions, authority validations, provider selection, risk management measures, flags, test summary report, remediation plan, closure evidence, and lessons learned.
  • Record why an entity is or is not within TLPT scope using the impact, systemic character, ICT risk profile, maturity, and financial-stability criteria supported by the TLPT RTS.
Section 5

ICT third-party risk and the register of information

treats ICT third-party risk as part of ICT risk management. Financial entities must maintain and update a register of information on contractual arrangements for ICT services provided by ICT third-party service providers, including at entity level and, where relevant, sub-consolidated and consolidated levels.

For critical or important functions, the third-party risk work extends beyond vendor onboarding. It includes a strategy and policy for ICT third-party risk, due diligence, contract lifecycle controls, rights of access and audit, service levels, security requirements, business continuity, exit strategies, subcontracting controls, concentration risk, and the ability to provide the register or sections of it to competent authorities on request.

  • Use the register to connect entities, branches, contractual arrangements, ICT services, supported functions, direct providers, intra-group providers, subcontractors, supply chains, and criticality or importance of functions.
  • Before concluding or materially changing an ICT contract supporting a critical or important function, preserve the business need, risk assessment, due diligence, approval, contract clauses, access rights, audit rights, exit strategy, and termination logic.
  • For subcontracting, assess the chain of subcontractors, data location, service location, concentration, transferability, continuity impact, provider monitoring, material-change notices, and termination rights.
  • Do not assume an intra-group ICT provider is out of scope; the third-party contract RTS treats ICT intra-group service providers as ICT third-party service providers for the policy.
Section 6

Oversight, proportionality, and evidence reviewers should expect

creates an oversight framework for ICT third-party service providers designated as critical. Designation is performed by the ESAs using criteria such as systemic impact, systemic character or importance of the financial entities relying on the provider, criticality or importance of the functions supported, and degree of substitutability. The register of information is important evidence for this assessment because it exposes ICT dependency patterns across the sector.

Financial entities should avoid unsupported thresholds, penalty figures, and deadline claims in internal summaries unless those claims are traced to the applicable legal text or supervisory communication. For this page, the official source evidence is the set of policies, registers, reports, tests, contracts, approvals, and review records that demonstrate how each workstream is implemented proportionately.

What are the main EU requirements?

The main requirement areas are management-body governance, ICT risk management, ICT-related incident management and reporting, digital operational resilience testing, ICT third-party risk management, register-of-information maintenance, and oversight of critical ICT third-party service providers.

Does require every financial entity to perform TLPT?

No. requires a broader resilience testing programme for financial entities other than microenterprises, while TLPT applies to financial entities identified for advanced testing using criteria such as impact, systemic character, ICT risk profile, and maturity.

What is the register of information?

The register of information is the structured record of contractual arrangements for ICT services provided by ICT third-party service providers. The implementing regulation provides standard templates that connect entities, contracts, ICT services, providers, functions, and ICT service supply chains.

  • Evidence for governance: management-body approvals, risk tolerance, resilience strategy, budget or investment decisions, training records, and reporting to the management body.
  • Evidence for ICT risk: policies, asset inventory, risk assessments, risk treatment, residual-risk acceptance, continuity and recovery plans, monitoring records, and reviews after material changes.
  • Evidence for incidents: classification analysis, initial notification, intermediate report, final report, root-cause analysis, recovery actions, client or authority communications, and recurring incident review.
  • Evidence for testing and TLPT: testing programme, scope, results, remediation, retesting, TLPT authority interactions, test summary reports, closure records, and lessons learned.
  • Evidence for third-party risk: register templates, contract inventory, due diligence, access and audit rights, subcontracting chain records, concentration analysis, exit plans, material-change notices, and management-body review of critical-function dependencies.
Primary sources

References and citations

eur-lex.europa.eu
Referenced sections
  • Shows why register data matters for internal ICT risk management, competent-authority supervision, and the oversight of critical ICT third-party providers.
"essential for the financial entities’ internal ICT risk management"
eur-lex.europa.eu
Referenced sections
  • Core source for the DORA oversight framework, proportionality principle, supervisory powers, and administrative penalties being left to Member State legal frameworks.
"Union Oversight Framework"
Related guides

Explore more topics

DORA Critical or Important Functions: mapping ICT dependencies and evidence
How DORA critical or important functions affect ICT service mapping, third-party contracts, register-of-information records, incidents, testing, and evidence.
DORA deadlines and compliance calendar for financial entities
Track DORA dates and recurring evidence: 17 January 2025 application, incident reporting clocks, register updates, annual reporting, TLPT cadence, and critical-provider oversight milestones.
DORA ICT Third-Party Contract Remediation Workflow
A DORA workflow for remediating ICT third-party contracts covering critical or important functions, subcontracting, audit rights, exits, register updates, and evidence.
DORA ICT Third-Party Contracts FAQ
What DORA requires in ICT third-party contracts, including critical or important functions, audit and access rights, termination, exit, subcontracting, register updates, and evidence.
DORA ICT third-party risk and contract clauses guide
Official source DORA guide for financial entities in scope, ICT third-party risk, contract clauses, subcontracting controls, register evidence, audit rights, exit planning, and oversight.
DORA incident classification forms: criteria, fields, and reporting clocks
Official source guide to DORA ICT incident classification forms: major-incident criteria, significant cyber-threat notifications, report fields, time limits, evidence, and reclassification records.
DORA incident clock workflow: classification, reports, deadlines, and evidence
Official source DORA workflow for starting the major-incident reporting clock, classifying ICT incidents, submitting initial, intermediate, and final reports, and preserving authority evidence.
DORA major ICT incident reporting: classification, reports, and timing
Official source DORA guide to major ICT-related incident classification, initial notifications, intermediate and final reports, competent authority routing, and significant cyber threat notifications.
DORA major ICT incident thresholds: what triggers reporting?
FAQ on DORA major ICT-related incident classification thresholds, recurring incidents, reporting triggers, and evidence inputs based on EU DORA RTS and ITS texts.
DORA Register of Information FAQ: ICT Third-Party Arrangements
FAQ on the DORA register of information: who maintains it, which ICT third-party arrangements it covers, template fields, critical functions, reporting, data quality, and evidence.
DORA Register of Information Import and Build Workflow
Build a DORA register of information from procurement, vendor, contract, service, function, and subcontractor data using the official register templates and validation checks.
DORA Register of Information Template: ICT Provider Fields and Evidence
An official source DORA register of information template for ICT third-party contracts, provider hierarchy, critical functions, dates, statuses, reporting, and evidence.
DORA TLPT selection: who can be required to test?
FAQ on DORA threat-led penetration testing selection: who identifies financial entities, what criteria are used, what the TLPT authority validates, and what evidence to keep.
DORA vs EBA outsourcing guidelines: ICT third-party risk comparison
Compare binding DORA ICT third-party risk duties with the EBA outsourcing baseline for registers, critical functions, contracts, subcontracting, exit, incident reporting, and evidence.
DORA vs ISO 22301: ICT resilience and business continuity compared
Compare DORA's binding ICT operational resilience duties for financial entities with ISO 22301's business continuity management system requirements.
DORA vs ISO/IEC 27001: legal ICT resilience obligations and ISMS controls
Compare EU DORA and ISO/IEC 27001 across scope, governance, incident reporting, testing, ICT third-party risk, certification, evidence, overlap, and gaps.
DORA vs NIS2: financial-sector obligations, overlap, and evidence
Compare DORA and NIS2 for financial entities, ICT providers, incident reporting, management accountability, third-party risk, supervisory routes, and reusable evidence.
DORA vs PSD2 incident reporting: major ICT and payment incidents
Compare DORA major ICT-related incident reporting with PSD2 major operational or security payment incident reporting, including scope, triggers, report stages, recipients, and evidence.
EU DORA Applicability Test for Financial Entities and ICT Providers
An official source DORA applicability test for financial-entity scope, ICT third-party services, critical or important functions, exclusions, proportionality, and evidence.
EU DORA Compliance Checklist for Financial Entities
An official source DORA checklist covering ICT risk governance, major incident reporting, resilience testing, TLPT, ICT third-party contracts, register-of-information records, and audit evidence.
EU DORA Compliance Obligations and Evidence Guide
An official source DORA compliance guide covering ICT risk management, incident reporting, resilience testing, TLPT, ICT third-party risk, registers, governance, oversight, and evidence.
EU DORA FAQ: scope, incidents, ICT contracts, testing, and evidence
Concise DORA FAQ covering who is in scope, proportionality, ICT third-party contracts, register-of-information records, major ICT incident thresholds and reporting, TLPT, testing, enforcement, and evidence.
EU DORA ICT risk management control baseline
An official source DORA control baseline for ICT risk governance, asset and dependency mapping, protection, detection, response, recovery, testing, third-party risk, and evidence.
EU DORA ICT subcontracting chain controls for critical functions
DORA guide to ICT subcontracting chains for critical or important functions: prior assessment, contract conditions, register fields, monitoring, exit rights, and evidence.
EU DORA penalties and fines: enforcement powers and limits
Official source guide to DORA enforcement: competent-authority powers, administrative penalties, remedial measures, publication rules, and Lead Overseer penalty payments for critical ICT third-party providers.
EU DORA Register of Information Data Model: templates, fields, and evidence
Field-level guide to the EU DORA register of information data model: templates B_01 to B_07, provider identifiers, contract links, subcontracting chains, critical-function assessments, dates, and export evidence.
EU DORA Scope and Covered Entities: financial entities and ICT providers
Classify whether DORA applies to a financial entity, ICT third-party provider, group arrangement, branch, or critical ICT service dependency.
EU DORA Scope and Proportionality Workflow
Classify DORA covered entities, simplified-framework status, critical or important functions, ICT dependencies, evidence records, and governance approvals.
EU DORA testing and TLPT readiness guide
An official source DORA guide for resilience testing, TLPT eligibility, authority interaction, test evidence, remediation plans, and avoiding unsupported testing cadence.
EU DORA TLPT eligibility workflow for financial entities
Check how DORA TLPT authorities identify financial entities for threat-led penetration testing and what evidence supports scope, readiness, providers, and governance.
EU DORA TLPT Runbook: scope, providers, reports, and remediation
Build a DORA threat-led penetration testing runbook around authority coordination, scope validation, provider controls, active testing, closure reports, remediation, and attestation.
How does proportionality work under EU DORA?
An official source FAQ on DORA proportionality: what can be scaled, who may use the simplified ICT risk framework, what evidence supports the decision, and which duties cannot be waived.
How to build a DORA register of information
Build a DORA register of information from contracts, ICT services, providers, functions, subcontractors, risk assessments, audit evidence, exit plans, and export checks.