DORA's ICT risk management pillar is the regulatory requirement to have a robust, well-governed approach to managing technology risk. It sits at the foundation of everything else the regulation requires: the incident reporting timelines, the resilience testing programme, and the third-party governance framework all depend on the organisation having a sound ICT risk management system from which they flow.
DORA's approach to ICT risk reflects a recognition that previous EU financial services regulation addressed technology risk inconsistently, often treating it as a secondary concern within broader operational risk requirements rather than a distinct discipline warranting its own governance framework and board-level accountability. The regulation's effect is to elevate ICT risk to a position of explicit, evidenced, board-level governance that was not uniformly required before.
Every in-scope entity must have a documented ICT digital resilience strategy aligned with and supporting its overall business strategy. This is not a general information security policy. It is a forward-looking strategic document that sets the objectives and priorities for how the organisation will develop and maintain its ICT resilience over time, and that the board has approved and periodically reviews.
The strategy requirement signals something important about DORA's approach: it treats ICT risk management as a governance and strategic matter rather than purely a technical one. A technology team producing a strategy document that the board then signs off on without substantive engagement is not meeting this requirement.
Entities must maintain a current, complete inventory of all ICT assets, covering hardware, software, data, and the third-party services on which operations depend. Critically, the inventory must include a mapping of the dependencies and interconnections between these assets, because risk cannot be meaningfully assessed against systems whose relationships to other systems are unknown.
This mapping requirement is more demanding than it sounds. Most organisations have reasonably good records of their primary systems and applications. The mapping of the dependencies between them, including how failures in one system propagate through interconnected systems, and the documentation of which important business functions each system supports, is typically much less complete.
The EBA's DORA regulatory technical standards specify what the asset inventory must contain and how dependencies must be documented. Organisations building or updating their asset inventories should work from the technical standards rather than from general descriptions of the requirement.
DORA requires continuous identification and assessment of ICT risks rather than periodic point-in-time assessment. This means having processes that identify new risks and vulnerabilities as they emerge, monitor changes in the threat environment that affect risk assessments, and update the risk picture as the organisation's technology environment changes.
In practice, continuous ICT risk management requires a combination of automated monitoring tools that provide real-time visibility of the technical environment, regular vulnerability assessments and penetration testing, threat intelligence that keeps the risk assessment current with the external threat landscape, and defined processes for escalating new or changed risk assessments to the appropriate governance level.
The ICT risk management framework must include specific technical and organisational measures for protecting the ICT environment. These cover access management, ensuring only authorised individuals can access systems and data at appropriate privilege levels; change management, ensuring system changes are properly authorised, tested, and deployed with appropriate controls; network security, controlling access to networks and monitoring for anomalous activity; and data security, protecting sensitive data at rest and in transit through appropriate encryption and access controls.
Physical security of ICT infrastructure is also included, reflecting the recognition that access to physical systems is a route to ICT risk that network security controls alone cannot address.
Entities must have a dedicated ICT business continuity policy that specifically addresses how ICT services and capabilities will be maintained or restored in the event of disruption. This is distinct from general business continuity planning, though it should be aligned with it.
The policy must include defined recovery time and recovery point objectives for critical ICT systems. Crucially, these objectives must be tested. DORA does not accept untested recovery plans as evidence of adequate ICT business continuity capability. The testing must be genuine, not a desktop walkthrough, and the testing results must be documented and used to improve the recovery arrangements where weaknesses are identified.
The management body, meaning the board or equivalent governing body, must explicitly approve the ICT risk management framework, review it periodically at least annually, and approve significant updates. Beyond approval, the management body is required to maintain awareness of the ICT risks the entity faces and to ensure the framework is adequate to manage them.
This is materially different from the governance expectation that existed in many financial services organisations before DORA, where technology risk was typically managed within the IT function with periodic reporting to the board and governance approval of the overall risk management policy.
DORA's requirement means the board cannot legitimately treat ICT risk as a technical matter that it receives reports about. It requires the board to have sufficient knowledge and skill to understand and scrutinise ICT risk, and to engage with ICT risk governance in a way that would satisfy a supervisory examination.
Under DORA, individual members of the management body bear responsibility for ICT risk governance. Where the board approves an inadequate ICT risk framework, or where ICT risks that should have been escalated to board level were not, the individuals who make up the management body may face personal consequences under the enforcement provisions that national competent authorities have implemented.
This is a significant departure from the position where board-level failure in technology risk governance was primarily an organisational liability rather than an individual one. Organisations that have not yet reviewed how their board engages with ICT risk governance need to treat that as a priority rather than a future aspiration.
DORA does not treat third-party ICT risk as a separate, siloed discipline. It treats the risks arising from ICT third-party relationships as integral to the core ICT risk management framework, requiring the same identification, assessment, and management discipline that applies to the organisation's own ICT systems.
This means the ICT risk register should include the risks arising from significant third-party dependencies, assessed with the same rigour as internal technology risks. The recovery objectives and continuity planning should address scenarios in which critical third-party services are unavailable, not only scenarios involving the organisation's own infrastructure.
Within the third-party risk dimension of the ICT framework, DORA requires a Register of Information covering all ICT third-party contractual arrangements, maintained in a machine-readable format using EBA-prescribed data fields. This register is one of DORA's most operationally demanding deliverables, as discussed in detail in our dedicated DORA compliance guide.
The ICT risk framework must include assessment of whether the entity has excessive concentration of ICT risk with a single provider or through the supply chains of multiple providers. Where concentration is identified, it must be assessed and managed as a risk, not accepted by default.
Organisations that have already implemented information security management systems based on ISO 27001 or the NIST Cybersecurity Framework will find that DORA's substantive ICT risk management requirements align closely with what those frameworks require. The risk identification, assessment, and treatment disciplines are consistent with both ISO 27001 and NIST. Many of the specific technical and organisational measures map directly to ISO 27001 Annex A controls or NIST CSF categories.
What DORA adds beyond existing good practice is three things: legal force with specific financial penalties, detailed technical standards specifying what evidence of compliance looks like, and explicit board-level governance accountability with personal liability for management body members.
The most material practical difference between operating to ISO 27001 or NIST voluntarily and operating to DORA as a legal requirement is the evidence standard. Certification bodies and internal audit teams assess compliance against professional standards. Regulatory supervisors from national competent authorities assess compliance with legal requirements, and the evidence standards they apply can be more demanding.
Organisations building their DORA ICT risk management framework should be explicit about what governance evidence will be available for supervisory review: board minutes showing ICT risk discussion, approved framework documentation with version history, testing reports and follow-up action tracking, and asset inventory maintenance records. These evidence requirements should inform how the framework is governed, not be assembled retrospectively when a supervisory enquiry arrives.
