EU DORA Requirements

DORA 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 DORA requirements map should therefore start with governance: which entity is in scope, which management body approves the framework, which functions own ICT risk, incident response, business continuity, testing, procurement, legal, and outsourcing, and how exceptions and residual risks are escalated.

DORA'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.

DORA 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.

DORA 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. DORA 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.

DORA 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.

DORA 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 grounded evidence is the set of policies, registers, reports, tests, contracts, approvals, and review records that demonstrate how each DORA workstream is implemented proportionately.