EU DORA ICT Risk Management Control Baseline

Start the baseline at DORA Article 6: the ICT risk management framework must sit inside the financial entity's overall risk management system and include strategies, policies, procedures, ICT protocols, and tools. The management body remains central because DORA assigns it responsibility for approving the digital operational resilience strategy, risk tolerance, business continuity policy, response and recovery plans, ICT audit plans, budget, and ICT third-party policy.

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.

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.

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.

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.

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.

DORA's ICT risk management baseline has to connect internal controls to ICT third-party dependencies. DORA Article 8 requires documentation of processes dependent on ICT third-party service providers and interconnections with providers that support critical or important functions. Delegated Regulation 2024/1773 adds the contract-policy layer for ICT services supporting critical or important functions: business need, ex-ante risk assessment, due diligence, approval, monitoring, documentation, exit, and termination.

The register of information is a practical source of evidence for this link. The standard templates require financial entities to identify ICT third-party service providers, intra-group providers, subcontractors, ultimate parent undertakings, ICT service supply chains, type of ICT service, substitutability, reasons for difficult substitution, last audit date, exit-plan existence, reintegration possibility, impact of discontinuing services, and whether alternative providers have been identified.

Use this checklist to 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 source-linked reason for inclusion.