DORA ICT Risk Management Framework: Pillar 1 Requirements Deep Dive

Introduction to Pillar 1

Pillar 1 — ICT Risk Management — is the cornerstone of DORA. Spanning Articles 5 through 16 of Regulation (EU) 2022/2554, it establishes the requirements for a comprehensive, documented, and continuously evolving ICT risk management framework that financial entities must implement and maintain.

Unlike many regulatory frameworks that define objectives and leave the choice of controls to the entity, DORA is notably prescriptive. It specifies not only what the ICT risk management framework must achieve but, in many cases, how it must achieve it. The associated Regulatory Technical Standards (RTS) developed by the Joint Committee of the European Supervisory Authorities (ESAs) add further prescriptive detail.

This guide provides a comprehensive walkthrough of every Article within Pillar 1, explains the practical implications for financial entities, identifies common implementation challenges, and maps the requirements to the supplementary RTS obligations. Whether you are building a DORA-compliant ICT risk management framework from scratch or adapting an existing one, this guide provides the technical depth you need.

ICT Risk Governance — Management Body Responsibilities (Article 5)

Article 5 establishes what is arguably DORA's most distinctive requirement: direct, non-delegable responsibility of the management body for ICT risk management. This goes significantly beyond most existing regulatory frameworks where ICT risk is typically delegated to operational management.

Specific Management Body Duties

The management body must:

• Define, approve, and oversee the implementation of all arrangements related to the ICT risk management framework, including the digital operational resilience strategy
• Bear ultimate responsibility for managing ICT risk — this responsibility cannot be delegated to committees or operational staff
• Set and approve the financial entity's ICT risk appetite, including tolerance levels for ICT disruption
• Approve, oversee, and periodically review the entity's ICT business continuity policy and ICT disaster recovery plans
• Approve and review the entity's ICT internal audit plans and ICT audits
• Allocate and review the adequate budget for fulfilling ICT risk management needs, including security awareness training
• Approve and review the entity's policy on ICT third-party service arrangements
• Be informed of ICT-related incidents and response activities, including incident impacts and response measures

Management Body Knowledge Requirements

Article 5(4) introduces a personal competence requirement: members of the management body must maintain sufficient knowledge and skills to understand and assess ICT risk and its impact on the entity. This means:

• Regular training on ICT risk topics must be provided to board members
• Training must be proportionate to the ICT risk of the entity
• Training records must be maintained as evidence
• Training should cover evolving ICT risks, emerging threats, and regulatory developments

Practical Implications

For many financial entities, Article 5 requires a significant uplift in how boards engage with ICT risk. Gone are the days when ICT risk was a standing item buried in the risk committee agenda. DORA demands that the management body actively shapes, approves, and monitors ICT risk strategy. Board papers must include clear, non-technical summaries of ICT risk posture, incident trends, third-party dependencies, and resilience testing results.

ICT Risk Management Framework Structure (Articles 6-7)

Article 6 defines the overarching structure of the ICT risk management framework, while Article 7 establishes requirements for the framework's ICT systems, protocols, and tools.

Framework Components (Article 6)

The ICT risk management framework must include:

• Strategies: A digital operational resilience strategy defining how the entity achieves and maintains resilience
• Policies: ICT security policies covering all aspects of ICT risk, including access control, change management, incident response, and BCP/DR
• Procedures: Operational procedures implementing the policies at a working level
• ICT protocols and tools: Technical standards and tools for detection, monitoring, and response

Digital Operational Resilience Strategy

The resilience strategy is a key framework document that must include:

• How the framework supports business strategy and objectives
• ICT risk tolerance levels and risk appetite statement
• Information security objectives including key performance indicators and metrics
• The entity's ICT architecture and how it supports resilience
• Key dependencies on ICT third-party service providers
• A multi-vendor strategy to avoid excessive concentration risk
• Mechanisms for detecting and responding to ICT-related incidents
• Digital operational resilience testing approach
• Communication strategy for incidents and vulnerabilities

Framework Review and Update

The framework must be reviewed at least annually — or more frequently following:

• Major ICT-related incidents
• Supervisory findings or recommendations
• Significant changes to the entity's ICT landscape or risk profile
• Findings from digital operational resilience testing
• Conclusions from post-incident reviews

ICT Systems, Protocols, and Tools (Article 7)

Article 7 requires entities to use and maintain updated ICT systems, protocols, and tools that are:

• Appropriate to the scale of operations and the criticality of functions they support
• Reliable and capable of processing data needed for operations and services
• Technologically resilient to withstand additional needs under stressed conditions

Identification (Article 8)

Article 8 establishes comprehensive requirements for identifying, classifying, and documenting all ICT-supported business functions, roles, assets, and dependencies. This is the foundational requirement upon which all other Pillar 1 controls are built.

Business Function Mapping

Financial entities must identify, classify, and document:

• All business functions supported by ICT systems and services
• The ICT systems and services supporting each business function
• Information assets and their classification
• The roles and responsibilities of all personnel involved in ICT risk management

ICT Asset Inventory

The ICT asset inventory is a core requirement. It must include:

• Hardware assets: Servers, endpoints, network equipment, storage devices, mobile devices
• Software assets: Operating systems, applications, middleware, databases, development tools
• Network assets: Network architecture, connections, segments, external interfaces
• Data assets: Data repositories, data flows, data classification
• Cryptographic assets: Encryption keys, certificates, cryptographic protocols

For each asset, document:

• Asset owner and custodian
• Classification (criticality and sensitivity)
• Location (physical and logical)
• Business functions supported
• Interconnections and dependencies with other assets and systems
• End-of-life or end-of-support dates

Dependency Mapping

Article 8 places particular emphasis on understanding dependencies:

• Dependencies between ICT systems and between ICT systems and business processes
• Dependencies on ICT third-party service providers, including identifying all ICT services supporting critical or important functions
• Interconnections with external systems, networks, and infrastructure
• Legacy system dependencies and migration risks

Risk Identification and Assessment

Based on the asset inventory and dependency mapping, entities must:

• Identify all sources of ICT risk, both internal and external
• Assess the potential impact of ICT disruptions on business functions
• Conduct risk assessments at least annually and upon significant changes
• Maintain a risk register documenting identified risks, likelihood, impact, and treatment decisions
• Perform specific risk assessments before connecting to new ICT systems or networks

Protection and Prevention (Article 9)

Article 9 mandates specific protective measures to ensure the security, resilience, and continuity of ICT systems. The RTS adds further prescriptive detail on implementation requirements.

ICT Security Policies

Entities must develop, document, and implement ICT security policies addressing:

• Access control: Principle of least privilege, strong authentication, identity and access management, privileged access management, regular access reviews
• Network security: Network segmentation, perimeter security, intrusion prevention, secure remote access, network monitoring
• Encryption: Data-at-rest and data-in-transit encryption, key management, cryptographic controls proportionate to data classification
• Patch management: Timely deployment of security patches, risk-based prioritisation, testing before deployment to production, tracking patch status
• Physical security: Data centre security, access controls, environmental protection, equipment protection

Secure Development and Change Management

• ICT systems must be developed following secure development lifecycle practices
• ICT projects and change management must be governed by documented procedures
• Changes must be assessed for risk before implementation
• Segregation of development, testing, and production environments is required
• Testing must include security testing before deployment

Human Resources Policy

The RTS adds specific human resources requirements:

• Background checks for ICT staff in critical roles
• Security awareness training for all staff
• Specialised training for ICT risk management roles
• Competence requirements for key ICT positions
• Succession planning for critical ICT roles

Detection (Article 10)

Article 10 requires mechanisms to promptly detect anomalous activities, including ICT network performance issues and ICT-related incidents. Detection must enable early identification of threats and allow the entity to respond before significant impact occurs.

Detection Requirements

• Monitoring capabilities: Continuous monitoring of ICT systems and networks for anomalous behaviour, unusual traffic patterns, and security events
• Multi-layer detection: Detection mechanisms at network, application, and endpoint levels providing defence-in-depth monitoring
• Logging and alerting: Comprehensive logging of security-relevant events with automated alerting for predefined thresholds and anomalies
• Threat intelligence integration: Incorporation of cyber threat intelligence into detection rules and processes to identify emerging threats
• Regular review: Detection mechanisms must be periodically tested and updated based on lessons learned, threat landscape changes, and test results

Detection-Specific RTS Requirements

The RTS specifies additional detection requirements:

• Entities must define detection criteria and thresholds proportionate to their risk profile
• Detection processes must be operational 24/7 for critical and important functions
• Correlation of events from multiple sources must be implemented
• Sufficient retention of logs for investigation and forensic purposes
• Detection capabilities must cover ICT third-party service provider interfaces

Response and Recovery (Articles 11-12)

Articles 11 and 12 establish requirements for ICT business continuity management, including response and recovery capabilities. These requirements are among the most operationally demanding in Pillar 1.

ICT Business Continuity Policy (Article 11)

Financial entities must establish a comprehensive ICT business continuity policy that:

• Is approved by the management body and subject to periodic review
• Covers all critical and important business functions and their supporting ICT systems
• Defines recovery time objectives (RTOs) and recovery point objectives (RPOs) for each critical function
• Is consistent with the entity's overall business continuity management framework
• Accounts for ICT third-party dependencies in continuity planning

Response Requirements

• Early warning indicators must be established to detect potential disruptions before they escalate
• Incident response procedures must be documented with clear roles, escalation paths, and communication protocols
• Response activation criteria must be defined and tested
• Response teams must be identified and trained, with contact information maintained and accessible
• Response procedures must include preservation of evidence for forensic analysis

ICT Business Continuity Plans

Financial entities must develop and maintain ICT business continuity plans that:

• Address a wide range of disruption scenarios, including cyber attacks, natural disasters, and third-party failures
• Consider the potential impact of simultaneous disruptions to multiple systems
• Include switchover procedures to backup systems and alternative processing sites
• Address communication requirements during disruptions
• Are subject to regular testing (at least annually for critical functions)

ICT Disaster Recovery Plans (Article 12)

• Recovery plans must be separate from, and consistent with, business continuity plans
• Plans must define specific recovery procedures for each critical ICT system
• Backup procedures must ensure data and ICT system backups are maintained securely and are regularly tested for restorability
• Backup data must be stored in geographically separate locations with adequate physical and logical security
• Recovery capabilities must be tested regularly, with test results reported to the management body
• Recovery from backups must not compromise security or integrity of the restored systems

Response and Recovery Testing

Learning and Evolving (Article 13)

Article 13 requires financial entities to have capabilities to learn from ICT-related incidents, vulnerabilities, threat intelligence, and resilience testing to continuously evolve the ICT risk management framework.

Post-Incident Review

• Conduct post-incident reviews for all major ICT-related incidents
• Identify root causes, contributing factors, and areas for improvement
• Document lessons learned and track implementation of improvement actions
• Share relevant findings across the organisation and, where appropriate, with peer financial entities
• Report post-incident review conclusions to the management body

Threat Landscape Monitoring

• Monitor the evolving cyber threat landscape continuously
• Incorporate threat intelligence into risk assessments and detection capabilities
• Assess the potential impact of emerging threats on the entity's ICT systems and operations
• Update the ICT risk management framework to address emerging risks

Framework Evolution

• Findings from incidents, testing, audits, and threat intelligence must drive framework improvements
• The entity must track and measure the effectiveness of framework improvements
• ICT risk metrics must be regularly reported to the management body showing trend data
• The entity should benchmark its practices against industry standards and peer institutions

Communication (Article 14)

Article 14 requires financial entities to establish communication plans and policies for ICT-related incidents and vulnerabilities, addressing both internal and external stakeholders.

Internal Communication

• Crisis communication procedures for escalation within the organisation
• Staff awareness of their roles during ICT-related incidents
• Communication channels that remain operational during ICT disruptions
• Management body notification procedures for major incidents

External Communication

• Client notification procedures when services are affected by ICT incidents
• Regulatory reporting channels to competent authorities (linked to Pillar 2)
• Public disclosure policies for significant ICT vulnerabilities or incidents
• Communication with ICT third-party service providers during incidents affecting shared services
• Designated spokesperson and communication approval process

Vulnerability Disclosure

Entities should establish responsible vulnerability disclosure policies covering:

• How to receive vulnerability reports from external parties
• Internal vulnerability assessment and prioritisation processes
• Coordination with affected third parties and vendors
• Public disclosure timelines and procedures

Simplified ICT Risk Management Framework (Article 16)

Article 16 provides a simplified version of the Pillar 1 requirements for eligible entities, primarily micro-enterprises and certain smaller financial entities. The simplified framework maintains core requirements while reducing complexity and documentation burden.

Simplified Framework Scope

Entities using the simplified framework must still:

• Have a sound and documented ICT risk management framework appropriate to their size and risk profile
• Maintain an ICT asset inventory (in simplified format)
• Implement proportionate protection and detection measures
• Have ICT business continuity and disaster recovery arrangements
• Conduct periodic reviews of the framework

What Is Simplified

• The governance structure need not include a separate ICT risk management function
• Documentation can be less formal and less detailed
• Testing requirements are scaled to the entity's ICT risk exposure
• Reporting to the management body can be less frequent but must still occur
• The digital operational resilience strategy can be embedded in the overall business strategy

RTS Requirements for ICT Risk Management

The RTS on ICT risk management framework, published by the Joint Committee of ESAs, significantly expands on the Level 1 requirements. Key areas addressed by the RTS include:

Implementation Approach

Implementing DORA Pillar 1 requires a systematic approach. We recommend the following phased implementation:

Phase 1: Assessment and Planning (Weeks 1-4)

• Conduct gap assessment against Pillar 1 requirements (Regulation and RTS)
• Identify existing controls that can be mapped to DORA requirements
• Develop remediation plan with prioritised work packages
• Secure management body endorsement and resource allocation

Phase 2: Governance and Documentation (Weeks 5-12)

• Establish ICT risk governance structure with clear roles and responsibilities
• Develop or update the digital operational resilience strategy
• Create or update ICT security policies aligned with RTS requirements
• Implement management body reporting processes
• Establish board training programme on ICT risk

Phase 3: Core Controls (Weeks 8-20)

• Complete ICT asset inventory with dependency mapping
• Conduct risk assessments for all critical and important functions
• Implement or enhance detection and monitoring capabilities
• Update BCP and DR plans; define RTO/RPO for critical functions
• Develop incident response procedures aligned with Pillar 2 reporting timelines

Phase 4: Testing and Validation (Weeks 16-24)

• Test BCP and DR plans
• Conduct incident response exercises
• Validate detection capabilities
• Perform internal audit of Pillar 1 controls
• Report findings to management body and update framework as needed

Pillar 1 is not a one-time implementation. The learning and evolving requirement (Article 13) mandates that the framework continuously improves based on incidents, testing, audits, and the evolving threat landscape. Build continuous improvement into your implementation from the start.

Frequently Asked Questions

What is the DORA ICT risk management framework?

The DORA ICT risk management framework is the comprehensive set of strategies, policies, procedures, ICT protocols, and tools required under Articles 5-16 of Regulation (EU) 2022/2554. It must cover governance, identification, protection, detection, response, recovery, learning, and communication across all ICT systems supporting the financial entity's operations.

What are the management body's responsibilities under DORA?

Under Article 5, the management body must define, approve, oversee, and be accountable for the ICT risk management framework. Specific duties include setting the ICT risk appetite, approving the digital operational resilience strategy, allocating adequate ICT budget, approving BCP/DRP policies, and ensuring members maintain sufficient ICT risk knowledge through regular training.

What must be included in the ICT asset inventory?

Article 8 requires an inventory of all ICT assets including hardware, software, network components, and data assets. Each asset must be classified, ownership assigned, and dependencies mapped to the business functions they support. The inventory must identify assets supporting critical or important functions and be updated following any significant change.

How does DORA's ICT risk framework differ from ISO 27001?

While both address information security risk, DORA's framework is prescriptive about specific controls (not just objectives), mandates management body accountability with personal consequences, requires specific response and recovery time objectives, includes mandatory external reporting, and focuses specifically on operational resilience. ISO 27001 provides a good foundation but requires supplementation for full DORA compliance.

What RTS supplements Pillar 1 requirements?

The Joint Committee of ESAs published RTS on ICT risk management framework covering detailed requirements for ICT security policies, human resources policies, access control, detection and response, business continuity management, ICT project and change management, encryption and cryptography, and ICT operations security. The RTS specifies minimum technical and organisational measures that supplement the Level 1 regulation.