Control BaselineEU DORA

EU DORA ICT Risk Management Control Baseline

This baseline helps translate DORA's ICT risk management framework into concrete controls, records, tests, and review evidence.

Built for financial-entity management bodies, ICT risk teams, security operations, resilience owners, procurement, outsourcing, legal, incident response, internal audit, and control owners supporting critical or important functions.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 25, 2026
Overview

DORA has applied since 17 January 2025 and requires an ICT risk management framework with operating controls and retained evidence. Most financial entities follow the general Chapter II framework; the categories in Article 16 follow a , while microenterprises receive separate adjustments to specified duties and frequencies. This baseline keeps those legal scope decisions separate from the controls for governance, inventory, protection, detection, response, recovery, testing, third-party links, and evidence.

Section 1

Baseline scope and governance

Start by deciding which framework applies. Article 6 governs the general ICT risk management framework; Article 16 sets a simplified framework for specified entity categories, with detailed controls in Chapter VI of Delegated Regulation (EU) 2024/1774. The simplified route still requires governance, information-security measures, critical-function and asset classification, ICT risk management, continuity, incident management, and testing, but it should not be represented as the full Article 6 control set.

A useful baseline therefore names the accountable management-body forum, the ICT risk control function, the first-line system and service owners, the internal audit touchpoint, and the senior-management owner for ICT third-party arrangements. If verification of ICT risk management requirements is outsourced, keep the outsourcing record separate from accountability: DORA says the financial entity remains fully responsible.

  • Record the DORA control area, owner, approving body, applicable entity or group scope, and whether the applies.
  • If Article 16 applies, cite the qualifying entity category and map the baseline to the simplified-framework provisions; if it does not, record the general Chapter II basis.
  • Record microenterprise status separately from Article 16 status, then apply only the adjustments that DORA assigns to that status.
  • Link the digital operational resilience strategy to ICT risk tolerance, impact tolerance for ICT disruption, information-security objectives, KPIs, KRIs, reference architecture, incident communication, and testing.
  • Keep evidence of annual or periodic framework review, event-driven review after major ICT incidents, supervisory instructions, testing findings, audit findings, and remediation follow-up.
  • Separate ICT risk management, control, and internal audit responsibilities under the three-lines model or the entity's equivalent risk and control model.
  • Retain evidence that management-body members regularly update the knowledge and skills needed to understand and assess ICT risk, with training proportionate to the ICT risk being managed.
Section 2

Asset, function, and dependency map

The baseline should not begin with control names. It should begin with what each control protects. DORA Article 8 requires financial entities to identify, classify, and document ICT-supported business functions, roles and responsibilities, information assets, ICT assets, dependencies, remote-site assets, network resources, hardware, critical assets, asset configuration, links between assets, and processes dependent on ICT third-party service providers.

Delegated Regulation 2024/1774 makes the inventory more operational. It expects records such as a unique ICT asset identifier, physical or logical location, classification, asset owner, supported business functions or services, continuity requirements including recovery time and recovery point objectives, internet or external-network exposure, interdependencies, and support end dates where ICT third-party support is relevant.

  • Maintain a function-to-asset-to-service view for every critical or important function instead of a flat infrastructure inventory.
  • Map information assets, ICT assets, network resources, remote sites, configuration links, service dependencies, and ICT third-party interconnections.
  • Flag critical assets and legacy ICT systems so risk assessments, patching, access reviews, testing, backup, and recovery controls can be prioritised.
  • Update inventories periodically and whenever a major infrastructure, process, procedure, service, supplier, or system change affects ICT-supported functions.
Section 3

Protection and prevention controls

For protection and prevention, DORA Article 9 requires controls that preserve availability, authenticity, integrity, and confidentiality of data and ICT systems, especially systems supporting critical or important functions. Treat this baseline area as a set of linked controls rather than a single information-security policy.

The minimum control set should cover information security rules, network and infrastructure management, access rights, strong authentication, cryptographic controls, change management, data and system security, logging, network segmentation, secure information in transit, ICT project management, ICT acquisition, development and maintenance, vulnerability management, patch management, physical and environmental security, and human-resource security responsibilities.

  • Access control: apply need-to-know, need-to-use, least privilege, segregation of duties, identifiable users where possible, controlled emergency access, and periodic access-right reviews.
  • Vulnerability and patching: monitor trusted vulnerability sources, scan ICT assets in line with classification and risk profile, prioritise remediation, verify closure, and keep escalation procedures when patch deadlines cannot be met.
  • Data and system security: define secure configuration baselines, authorised software controls, malware controls, media controls, endpoint controls, secure deletion, decommissioning, data-loss prevention, and third-party-operated service requirements.
  • Network security: document network connections and data flows, segregate or segment ICT systems by criticality and classification, control unauthorised connections, review firewall rules and connection filters, and encrypt network connections based on data classification and ICT risk assessment.
  • Change and project controls: record, test, assess, approve, implement, verify, and document ICT changes; keep fall-back procedures; report critical-function ICT projects and associated risks to the management body.
Section 4

Detection, response, and recovery controls

DORA separates detection from response and recovery, so the baseline should do the same. Detection controls should identify anomalous activities, ICT network performance issues, ICT-related incidents, and potential material single points of failure. Response and recovery controls should then activate documented arrangements, plans, procedures, and mechanisms that contain incidents, limit damage, prioritise resumption, estimate impacts, manage communication, and report where required.

The evidence should show that detection is not limited to logs. Delegated Regulation 2024/1774 requires analysis of internal and external factors, logs, business and ICT function information, user-reported issues, cyber-threat scenarios, threat intelligence, and ICT third-party incident notifications that may affect the financial entity.

  • Define detection roles, alert thresholds, incident-response triggers, automated alerts for critical or important assets, alert prioritisation, and tamper-resistant anomaly records.
  • Keep incident evidence, significant-or-recurring incident analysis, root-cause records, escalation records, communication records, and lessons learned.
  • Maintain ICT business continuity, response, and recovery plans aligned to business impact analysis, mapped functions, assets, dependencies, and third-party services.
  • Document backup scope, minimum backup frequency by data criticality or confidentiality, restoration methods, segregated restore systems, integrity checks, recovery time objectives, and recovery point objectives.
  • Include continuity measures for failures of ICT third-party service providers supporting critical or important functions.
Section 5

Testing, audit, and review evidence

A DORA ICT risk management baseline is incomplete unless every control has a test or review path. DORA requires ICT business continuity and response and recovery plans to be tested at least yearly for ICT systems supporting all functions and after substantive changes to ICT systems supporting critical or important functions. The testing plan should include cyber-attack scenarios and switchovers between primary ICT infrastructure and redundant capacity, backups, and redundant facilities for entities in scope of that requirement.

Delegated Regulation 2024/1774 also expects an ICT security testing plan to validate the effectiveness of security measures and a review report that can summarise the current and near-term ICT risk profile, threat landscape, control effectiveness, security posture, weaknesses, remediation measures, residual-risk acceptance, past reviews, audits, compliance assessments, digital operational resilience testing, and, where applicable, TLPT results.

What evidence proves a DORA ICT risk management control baseline is implemented?

Useful evidence includes the approved ICT risk management framework, digital operational resilience strategy, risk tolerance, asset and dependency inventories, information-security policy, access-control reviews, vulnerability and patch records, secure configuration checks, logs and detection rules, incident records, BIA records, continuity and recovery plans, backup and restore tests, ICT security testing results, audit findings, remediation plans, and management-body approvals.

How should DORA control owners connect ICT assets to third-party risk?

Control owners should link each critical or important function to its supporting ICT assets, information assets, ICT services, direct ICT third-party provider, supply-chain providers where applicable, contractual arrangement reference, substitutability assessment, exit plan, audit evidence, and the impact of discontinuing the ICT service.

  • Define the test method for each control family: design review, operating effectiveness test, vulnerability scan, restore test, switchover exercise, tabletop, incident simulation, audit, or control self-assessment.
  • Link each test to the protected function, asset, information asset, supplier service, risk scenario, BIA assumption, recovery objective, and expected evidence.
  • Document deficiencies, severity, owner, remediation action, expected implementation date, implementation status, control retest, and management-body reporting.
  • Feed incident lessons, test results, audit recommendations, supervisory findings, and relevant external information back into the ICT risk assessment and framework review.
Section 7

Control baseline checklist

This checklist helps decide whether the DORA ICT risk management baseline is concrete enough to operate, test, and evidence. Each item should point to an owner, a control record, a test or review record, and a cited reason for inclusion.

  • Governance: management-body approvals, ICT risk tolerance, digital operational resilience strategy, ICT audit plan, budget, third-party policy, communication channels, and training responsibilities are documented.
  • Framework: ICT risk management responsibilities, control-function independence, internal audit coverage, review triggers, remediation follow-up, and competent-authority-ready review report content are defined.
  • Inventory: ICT-supported business functions, information assets, ICT assets, critical assets, remote sites, configurations, interdependencies, third-party processes, and legacy systems are identified and reviewed.
  • Protect and prevent: information security, access control, authentication, cryptography, data and system security, network security, vulnerability management, patch management, ICT operations, change management, project management, acquisition and development, and physical security controls are documented.
  • Detect: anomalous-activity detection uses logs, business and ICT reports, user reports, threat intelligence, external inputs, and ICT third-party incident notifications, with thresholds and response triggers.
  • Respond and recover: BIA, continuity plans, response and recovery plans, crisis communications, backup scope and frequency, restore procedures, redundant capacity, recovery objectives, and third-party failure scenarios are maintained.
  • Test and improve: ICT security tests, continuity tests, restore tests, switchover exercises, audit results, incident lessons, deficiencies, remediation actions, and management-body reporting are retained.
  • Third parties: contract-policy lifecycle, due diligence, provider resources, audit and access rights, subcontractor chains, exit plans, register fields, substitutability, discontinuity impact, and alternatives are linked to critical or important functions.
Primary sources

References and citations

eur-lex.europa.eu8 citations
Referenced sections
  • Primary DORA source for management-body responsibility, the ICT risk management framework, identification, protection, detection, response, recovery, backup, restoration, learning, communication, testing, and third-party risk links.
  • Supports the baseline's governance structure: management-body duties in Article 5 and the ICT risk management framework requirements in Article 6.
  • Supports the asset, function, dependency, and inventory requirements in DORA Article 8.
Show 5 more
  • Supports the protection and prevention objectives in DORA Article 9.
  • Supports the detection, business continuity, response, recovery, backup, restoration, and learning requirements in DORA Articles 10 to 13.
  • Supports the annual and change-driven continuity and response testing requirements, learning loop, and review of the ICT risk management framework.
  • Supports the requirement to map third-party dependent processes and interconnections with providers supporting critical or important functions.
  • Supports the checklist's core control areas across DORA Chapter II: governance, ICT risk management, identification, protection, detection, response, recovery, learning, and communication.
"digital operational resilience"
More quoted passages
"sound, comprehensive and well-documented"
"identify, classify and adequately document"
"Protection and prevention"
"Response and recovery"
"test the ICT business continuity plans"
"ICT third-party service providers"
"ICT risk management framework"
eur-lex.europa.eu7 citations
Referenced sections
  • Detailed RTS source for the ICT security policies, procedures, protocols, tools, simplified framework, control testing, continuity testing, response and recovery plans, and review-report evidence used in the baseline.
  • Specifies the detailed ICT security policies, procedures, protocols, tools, simplified framework, and review-report content used to turn DORA's framework into controls.
  • Supports the detailed ICT asset-management record fields and criticality assessment criteria.
Show 4 more
  • Supports the detailed control topics for ICT asset management, encryption, operations, vulnerability and patch management, data and system security, logging, network security, access control, change management, and project management.
  • Supports detailed incident policy, anomalous-activity detection, business continuity testing, and ICT response and recovery plan content.
  • Supports the control-testing plan and the required content of the ICT risk management framework review report.
  • Supports the detailed implementation checks for policies, procedures, tools, access, logging, network controls, testing, continuity, response and recovery, and review reports.
"ICT risk management tools"
More quoted passages
"policy on management of ICT assets"
"ICT security policies"
"ICT-related incident management"
"report on the review"
"policies, procedures, protocols"
eur-lex.europa.eu3 citations
Referenced sections
  • RTS source for contract-policy governance, risk assessment, due diligence, monitoring, documentation, access rights, exit strategies, and termination for ICT services supporting critical or important functions.
  • Supports the policy lifecycle for ICT services supporting critical or important functions, including risk assessment, due diligence, monitoring, documentation, exit, and access rights.
  • Supports the checklist items for ICT third-party contract-policy lifecycle, due diligence, monitoring, documentation, exit, and access rights.
"ICT services supporting critical"
More quoted passages
"contractual arrangements"
"critical or important functions"
eur-lex.europa.eu3 citations
Referenced sections
  • ITS source for register-of-information fields used as evidence of ICT third-party providers, supply chains, service types, substitutability, audits, exit plans, reintegration, discontinuity impact, and alternatives.
  • Supports the register-of-information evidence fields for ICT service providers, supply chains, substitutability, audits, exit plans, reintegration, discontinuity impact, and alternative providers.
  • Supports the checklist items that use register-of-information fields as third-party dependency and exit evidence.
"register of information"
More quoted passages
"standard templates"
Show all related guides (33)

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

Map DORA register fields to official templates for ICT contracts, provider chains, critical functions, dates, statuses, reporting, and evidence.

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

Test DORA applicability against official sources for financial-entity scope, ICT services, critical or important functions, exclusions, proportionality, and evidence.

EU DORA Compliance Checklist for Financial Entities

Check DORA operating evidence against official sources for ICT risk governance, major-incident reporting, resilience testing, TLPT, third-party contracts, and the register of information.

EU DORA Compliance Obligations and Evidence Guide

Map DORA obligations to official sources and operating evidence for ICT risk management, incident reporting, testing, third-party risk, registers, governance, and oversight.

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 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 Requirements Overview: ICT risk, incidents, testing, and third-party risk

An official source overview of the main EU DORA requirements for financial entities: governance, ICT risk management, incident reporting, resilience testing, TLPT, ICT third-party risk, register of information, oversight, proportionality, and 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 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.

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

How does proportionality work under EU DORA?

DORA proportionality explained from official sources: what can be scaled, simplified-framework eligibility, supporting evidence, and duties that remain mandatory.