Artifact GuideEU

EU DORA Requirements

A requirements map you can translate into controls, owners, and evidence.

Structured by how teams implement DORA: controls, reporting, testing, and third-party governance.

Back to main artifact Review sources

Author

Sorena AI

Published

Feb 23, 2026

Updated

Feb 23, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published Feb 23, 2026

Updated Feb 23, 2026

Overview

DORA is an implementation regulation. The fastest way to comply is to build a requirements matrix that maps each obligation to (1) a control or workflow, (2) an owner, (3) acceptance criteria, and (4) evidence you can export on demand. This page summarizes DORA requirements by workstream and highlights the artifacts teams usually miss (statement-of-work quality, register of information, and reporting pipelines).

Section 1

Workstream 1 - ICT risk management framework (Chapter II)

DORA requires financial entities to have an internal governance and control framework that ensures effective and prudent management of ICT risk and a high level of digital operational resilience.

Think "control baseline": governance, asset inventory, protection/detection, response/recovery, business continuity, and communications.

Management body accountability: define, approve, oversee and be responsible for arrangements related to ICT risk management (Article 5/6 context).
Asset inventory and classification: identify, classify and document ICT-supported business functions, information assets, and dependencies; review at least yearly (Article 8).
Protection and prevention controls: policies/tools to safeguard availability, authenticity, integrity and confidentiality of data and services (Chapter II control layers).
Detection and monitoring: mechanisms to detect anomalous activities and ICT-related incidents (Chapter II + Article 17 interface).
Business continuity and response/recovery plans: contain incidents, restore services, and run post-incident reviews to prevent recurrence (Articles 11-13).

Section 2

Workstream 2 - ICT incident management and reporting (Chapter III)

DORA requires an ICT incident management process to detect, manage and notify incidents, record all ICT-related incidents and significant cyber threats, and report major ICT-related incidents to competent authorities.

This is both an operational workflow and a data/reporting pipeline.

Incident management process: early warning indicators, tracking/logging/classification, roles and responsibilities, communication plans, and response procedures (Article 17).
Classification: classify incidents by priority/severity and criticality of services impacted; apply criteria and thresholds specified in DORA and RTS (Article 18 + RTS).
Reporting: submit initial notification, intermediate updates, and final report within RTS time limits; include information needed to assess significance and cross-border impacts (Article 19 + RTS).
Client communications: inform clients without undue delay where major incidents impact financial interests; inform potentially affected clients about protection measures for significant cyber threats where applicable (Article 19).

Section 3

Workstream 3 - Digital operational resilience testing and TLPT (Chapter IV)

DORA requires an ongoing testing program for ICT tools, systems and processes, including vulnerability assessments, scenario-based tests, and penetration testing.

For certain entities, DORA introduces advanced threat-led penetration testing (TLPT) on live production systems at least every three years.

Testing program: run tests appropriate to risk profile and criticality; ensure independence for non-microenterprises; remediate and validate weaknesses (Articles 24-25).
TLPT: advanced testing at least every 3 years for identified entities; cover critical or important functions; performed on live production systems; scope validated by competent authorities (Article 26).
Tester suitability: highest suitability and reputability; threat intelligence + penetration testing expertise; independence assurance; professional indemnity insurance (Article 27 context).

Section 4

Workstream 4 - ICT third-party risk management (Chapter V)

DORA makes third-party risk a first-class compliance domain: financial entities remain fully responsible for compliance and must manage ICT third-party risk as part of ICT risk management.

Operationally, this workstream is procurement/legal/security combined: contracts, oversight rights, exit plans, and evidence.

Third-party strategy: adopt and regularly review an ICT third-party risk strategy (with proportionality), including policy for ICT services supporting critical/important functions (Article 28).
Register of information: maintain and update a register covering all contractual arrangements for ICT services; provide the full register or sections on request (Article 28).
Concentration risk: assess substitutability and multi-vendor dependencies; consider subcontracting chains and third-country risks (Article 29).
Contract minimum clauses: allocate rights/obligations clearly in writing; include minimum contractual elements (Article 30) and RTS contractual arrangements requirements.

Section 5

Workstream 5 - Oversight of critical ICT third-party service providers

DORA establishes an EU oversight framework for critical ICT third-party service providers (CTPPs) supporting the financial sector.

For financial entities, the practical implication is stronger contract posture and exit strategy planning. For ICT providers, it's oversight readiness and evidence maturity.

Understand designation: criteria and process for designating ICT third-party providers as critical are specified in delegated regulation (Level 2).
Plan contractual adjustments: authorities can require adjustments to avoid resilience harms; build exit strategies and transition plans as standard artifacts.
Account for oversight costs: oversight fee methodologies apply to critical providers under delegated regulation.

Section 6

Evidence mapping model (requirement -> control -> evidence)

Compliance becomes low-friction when evidence is designed-in. Use this mapping model to build an exportable evidence pack.

Aim to make every requirement verifiable via a small set of repeatable artifacts.

Policies: ICT risk management policy set, incident management policy, testing policy, third-party risk strategy, exit strategy policy.
Procedures/runbooks: notice/reporting runbooks, escalation paths, TLPT runbooks, vendor onboarding/checklists, contract clause playbooks.
Records/logs: asset inventory, incident records, reports submitted, remediation tickets, test results, register of information exports.
Governance evidence: management body approvals, periodic reviews, proportionality decisions, and KPI dashboards.

Recommended next step

Turn EU DORA Requirements into an operational assessment

Assessment Autopilot can take EU DORA Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents.

Assessment workflow

Open Assessment Autopilot for EU DORA Requirements

Start from EU DORA Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints.

Explore next step

Talk to Sorena

Talk through EU DORA

Review your current process, evidence gaps, and next steps for EU DORA Requirements.

Explore next step

Primary sources

References and citations

Commission Delegated Regulation (EU) 2024/1773 - Contractual arrangements for ICT services supporting critical or important functions (RTS)

eur-lex.europa.eu

Referenced sections

Level 2 RTS specifying detailed contractual requirements for ICT services supporting critical or important functions.

Commission Delegated Regulation (EU) 2024/1774 - ICT risk management tools and simplified framework (RTS)

eur-lex.europa.eu

Referenced sections

Level 2 RTS specifying ICT risk management tools, methods, processes, policies, and the simplified framework referenced by DORA.

Regulation (EU) 2022/2554 (DORA) - Official Journal

eur-lex.europa.eu

Referenced sections

Primary DORA requirements across the four main workstreams: ICT risk management (Chapter II), incident reporting (Chapter III), testing/TLPT (Chapter IV), and ICT third-party risk including contract clauses and the register of information (Chapter V).

Related guides