DORA ICT Risk Management Framework Explained

DORA ICT risk management is the most extensive obligation imposed by the Digital Operational Resilience Act on financial entities in the European Union. Articles 5 through 16 of Regulation (EU) 2022/2554 establish a prescriptive framework for identifying, protecting against, detecting, responding to, and recovering from ICT-related risks.

This article explains the full structure of the DORA ICT risk management framework, the governance obligations that attach at board level, each functional component, the simplified regime available to smaller firms, and how these requirements interact with ISO 27001 and GDPR.

What Does DORA Require for ICT Risk Governance?

DORA places ICT risk governance squarely on the management body of each financial entity. Article 5 establishes that the board of directors or equivalent governing body bears ultimate responsibility for defining, approving, overseeing, and being accountable for the implementation of the ICT risk management framework.

This is not a delegable obligation. While day-to-day execution may be assigned to senior management or a dedicated ICT risk function, Article 5(2) specifies that the management body must:

• Define the entity’s risk appetite with respect to ICT risk
• Approve and periodically review the ICT risk management framework
• Approve and review the ICT business continuity policy and ICT disaster recovery plans
• Allocate and periodically review the budget dedicated to fulfilling ICT risk management needs
• Ensure adequate training and awareness of ICT risks for all staff, including board members themselves

Article 5(4) requires members of the management body to maintain sufficient knowledge and skills to understand and assess ICT risks. Competent authorities may require evidence of ongoing training.

The GDPR accountability principle also requires demonstrable compliance, but Article 5(2) GDPR assigns responsibility to the controller; it does not create the same board-governance regime as DORA.

How Is the ICT Risk Management Framework Structured?

Article 6 requires financial entities to establish, maintain, and continuously update a sound, comprehensive, and well-documented ICT risk management framework. This framework must be integrated into the entity’s overall risk management system and must include strategies, policies, procedures, ICT protocols, and tools necessary to protect all information assets and ICT assets.

The framework must achieve three structural properties:

1. Completeness — covering all ICT-supported business functions, information assets, and ICT assets
2. Documentation — recorded in a manner that is auditable and available to competent authorities on request
3. Continuous improvement — reviewed at least annually (periodically for microenterprises) and following relevant incidents, supervisory instructions, tests or audit conclusions

Under Article 6(4), entities other than microenterprises assign ICT-risk management and oversight to an appropriately independent control function. The general framework also requires appropriate segregation and independence of risk-management, control and internal-audit functions. Apply the relevant exclusions explicitly rather than assuming that every small entity needs an identical organisation chart.

Identification (Article 8)

Article 8 mandates a comprehensive identification process. Financial entities must identify, classify, and document all ICT-supported business functions, roles, and responsibilities. They must also identify and document all sources of ICT risk, including those arising from dependencies on ICT third-party service providers.

Specifically, entities must maintain an up-to-date inventory of:

• All information assets and ICT assets, including remote sites, network resources, and hardware
• The configuration of ICT assets and the interconnections between them
• All processes that depend on ICT third-party service providers

This inventory requirement has a direct parallel in GDPR compliance. Organisations subject to both frameworks will find that the Record of Processing Activities (ROPA) under GDPR Article 30 and the ICT asset inventory under DORA Article 8 overlap substantially, particularly regarding data flows and third-party dependencies.

Article 8(1)–(2) requires review of the classification/documentation and relevant risk scenarios at least yearly, alongside continuous identification of risk sources. Article 8(3) requires entities other than microenterprises to assess major infrastructure, process or procedure changes; Article 8(7) separately addresses legacy-system assessments. Keep those triggers distinct in the review calendar.

Protection and Prevention (Article 9)

Article 9 requires entities to deploy appropriate ICT security tools, policies, and procedures to ensure the resilience, continuity, and availability of ICT systems. The protection measures must be designed in accordance with a risk-based approach.

Key requirements include:

• Policies governing access rights management and the principle of least privilege
• Mechanisms for network security management, including segmentation and segregation
• Policies and procedures for patch and update management
• Strong authentication mechanisms, including multi-factor authentication
• Cryptographic controls for data in transit and at rest
• Physical security of ICT infrastructure

Detection (Article 10)

Article 10 requires financial entities to establish mechanisms to promptly detect anomalous activities. Detection capabilities must cover ICT-related incidents, threats, and vulnerabilities. Entities must implement:

• Multiple layers of control, including monitoring rules and alerting thresholds
• Mechanisms to detect misuse of access and anomalous network behaviour
• Processes for testing detection capabilities

Detection mechanisms must be tested periodically. The testing obligation under Article 10 feeds into the broader resilience testing programme mandated by DORA Chapter IV (Articles 24-27), creating a continuous feedback loop between detection and testing.

Response and Recovery (Articles 11-14)

Articles 11 through 14 address the entity’s ability to respond to and recover from ICT incidents. Article 11 requires a documented ICT business continuity policy that covers:

• Arrangements for the continuity of critical or important functions outsourced to ICT third-party service providers
• Response and recovery plans that are specific, well-documented, and regularly tested
• Estimated recovery times and recovery points for critical functions

Article 12 mandates backup policies and procedures, specifying that entities must determine the frequency of backups based on criticality of functions, and that restoration from backups must be periodically tested. Article 13 requires entities to maintain arrangements for learning and evolving from both ICT incidents and resilience testing, feeding insights back into the risk management framework.

Article 14 establishes communication obligations. Entities must have crisis communication policies for both internal and external stakeholders, including procedures for communicating with clients and counterparties during disruptions.

What Documentation Must Financial Entities Maintain?

Financial quantification is a separate analytical choice: an input register for cyber-loss assumptions records event frequency, loss categories and sensitivity without treating a single amount as a DORA requirement.

DORA imposes extensive documentation requirements throughout Articles 5-16. At a minimum, entities must maintain written records of:

• The ICT risk management framework itself, including all strategies, policies, and procedures
• An inventory of ICT assets and information assets, updated continuously
• Risk assessment results, including identified vulnerabilities and remediation timelines
• ICT business continuity and disaster recovery plans
• Backup and restoration policies
• Incident response plans and post-incident review reports
• Results of resilience testing and remediation actions taken
• Evidence of board approval and oversight of the framework

This documentation must be available to competent authorities at any time. Article 6(6) requires regular internal audit of the ICT risk management framework for entities other than microenterprises, with suitable ICT-risk knowledge, skills and independence.

For entities that also maintain GDPR compliance documentation, there is considerable overlap. Both regimes require documented policies, risk assessments, incident response plans, and evidence of governance oversight. Organisations can achieve efficiencies by aligning their DORA and GDPR documentation programmes, particularly for records relating to ICT security measures, third-party assessments, and incident management.

Who Is Eligible for the Simplified Framework?

Article 16(1) lists eligible categories: small and non-interconnected investment firms, certain exempted payment and electronic-money institutions, specified institutions exempted under the banking directive where the national option applies, and small institutions for occupational retirement provision. Microenterprise status alone is not eligibility for Article 16. The exclusions in Article 2 must also be checked before deciding which framework applies.

Eligible entities still maintain a documented ICT risk management framework, monitor systems, minimise ICT risk, support continuity, test plans and controls, and learn from incidents. Delegated Regulation (EU) 2024/1774 specifies both the general framework’s requirements and the simplified framework. It is a concrete control regime, not a waiver obtained by self-describing the firm as a startup.

Keep a scope decision naming the legal entity, licence category, relevant statutory exemption and supporting evidence. Reassess after a licence change, acquisition or change in regulatory category. Separately record any provision-specific microenterprise relief that applies. This avoids applying a headcount shortcut to incident reporting or other obligations that remain in force.

How Does DORA ICT Risk Management Relate to ISO 27001?

DORA does not reference ISO 27001 as a mandatory standard, but the structural alignment between the two is substantial. ISO 27001’s information security management system (ISMS) approach — plan, implement, monitor, improve — maps closely to DORA’s framework structure across Articles 5 through 16.

Map the current version and actual scope of the organisation’s ISMS to DORA obligations. Useful control areas include asset management, access control, cryptography, monitoring, continuity and incident handling. Avoid copying Annex A numbering from an older ISO edition into a current compliance register.

For each DORA requirement, record the existing control, its owner, operating evidence, remaining gap and review frequency. A certificate only establishes what its stated scope and audit cover; it does not establish all DORA reporting, governance or testing obligations.

Entities with a mature ISO 27001-certified ISMS will find that they have already addressed a significant portion of the DORA ICT risk management requirements. However, DORA goes further in several areas — particularly regarding board-level governance, specific recovery time requirements, and the mandatory testing of backup restoration procedures. An ISO 27001 certification alone does not constitute DORA compliance.

Where Do DORA and GDPR Overlap on Security Measures?

DORA Article 9 and GDPR Article 32 both require organisations to implement appropriate technical and organisational measures to ensure the security of ICT systems and personal data respectively. For financial entities processing personal data, both obligations apply simultaneously.

The overlap is significant. Measures such as encryption, access controls, pseudonymisation, regular security testing, and incident response capabilities satisfy requirements under both instruments. A detailed examination of these intersections is provided in our DORA vs GDPR overlap analysis.

However, there are important differences. GDPR Article 32 applies a risk-based standard calibrated to the nature of the personal data being processed. DORA imposes sector-specific requirements calibrated to the criticality of business functions and the systemic importance of the entity. An entity may meet GDPR’s standard for a particular processing operation while still falling short of DORA’s requirements for the underlying ICT system.

Assess the NIS2 interaction through DORA Article 1(2) and NIS2 Article 4. DORA acts as the sector-specific regime for the corresponding obligations of covered financial entities. A separate supplier or group entity may still have NIS2 obligations; do not assume every financial entity must duplicate all three regimes.

What Role Does Resilience Testing Play in the Framework?

While detailed resilience testing is addressed in DORA Chapter IV (Articles 24-27), the ICT risk management framework under Chapter II establishes the foundation. Article 10 requires detection capabilities to be tested. Article 12 requires backup restoration to be tested. Article 11 requires business continuity and disaster recovery plans to be tested.

The testing obligation within the ICT risk management framework is distinct from the advanced threat-led penetration testing required of significant entities. Apply the relevant general or simplified framework and the provision-specific microenterprise treatment. Testing is a recurring control, not evidence supplied once at implementation. Test results must be documented, reported to the management body, and used to update the framework.

Close a recovery gap with operating evidence

Suppose a critical service has a four-hour internal recovery objective but the last restore exercise took seven hours. Preserve the test scope, starting conditions and dependency delays. A revised policy stating “four hours” does not resolve the gap. Identify whether the bottleneck is backup retrieval, infrastructure provisioning, supplier response or data reconciliation.

The remediation record should contain the business effect, control owner, proposed fix, interim protection, target date and retest criterion. Escalate the remaining risk to the appropriate decision-maker; management acceptance cannot waive a legal requirement. Connect an outsourced dependency to the third-party review and an incident finding to the reporting process.

After implementation, rerun a comparable recovery exercise, retain measured timings and confirm data integrity with the service owner. Update the resilience testing programme and the framework review with what changed. This creates a traceable sequence from risk to control, test result, corrective action and verified outcome.

How Should Financial Entities Approach DORA ICT Risk Management Implementation?

Implementing the DORA ICT risk management framework is not a one-time project. It requires sustained organisational commitment, starting with governance and extending through every operational layer. Practical steps include:

1. Establish board-level governance — ensure the management body formally approves the framework and receives regular reports on ICT risk posture
2. Conduct a comprehensive asset inventory — identify all ICT assets, information assets, and third-party dependencies
3. Perform a gap analysis — compare current ICT security controls against the specific requirements of Articles 5-16
4. Implement protection, detection, and response measures — deploy controls proportionate to the entity’s risk profile and the criticality of its functions
5. Document everything — maintain auditable records of policies, risk assessments, test results, and governance decisions
6. Test and iterate — test continuity plans, backup restoration, and detection mechanisms regularly, and update the framework based on findings

Entities already holding ISO 27001 certification or maintaining mature compliance programmes under GDPR or NIS2 will have a significant head start. The key is to identify and address the DORA-specific gaps — particularly board accountability, mandatory testing frequencies, and the prescriptive documentation requirements that go beyond what existing frameworks demand.

For a broader view of the full regulation, including the other four pillars, see our complete DORA compliance guide.

FAQ

Does DORA ICT risk management apply to all financial entities equally?

No. Establish scope and exclusions under Article 2, apply Article 4 proportionality and check the categories listed in Article 16(1). Microenterprise relief exists in particular provisions, but fewer than ten employees does not by itself place an entity in the simplified framework.

Can ISO 27001 certification satisfy DORA ICT risk management requirements?

ISO 27001 covers substantial ground, but it is not sufficient on its own. DORA imposes specific obligations that go beyond ISO 27001, including mandatory board-level governance, prescribed testing frequencies for backup restoration, and detailed requirements for ICT asset inventory and third-party dependency mapping. Certification is a strong foundation, not a complete answer.

How does DORA ICT risk management interact with GDPR security obligations?

DORA Article 9 and GDPR Article 32 both require technical and organisational security measures. For financial entities processing personal data, both apply. Many controls — encryption, access management, incident response — satisfy both. However, the risk calibration differs: GDPR focuses on the sensitivity of personal data, while DORA focuses on the criticality of business functions and systemic risk. See our DORA vs GDPR overlap analysis for a full breakdown.

What happens if a financial entity fails to implement the DORA ICT risk management framework?

Competent authorities can impose administrative penalties, require remediation actions, and in severe cases restrict or suspend activities. Article 50 empowers supervisory authorities to impose periodic penalty payments to compel compliance. The specific penalty amounts are determined by national law, but DORA sets the floor for supervisory powers across all Member States.

Does the simplified framework under Article 16 exempt micro-enterprises from DORA?

Article 16 eligibility depends on the listed regulatory categories, not microenterprise size alone. Eligible entities retain a simplified but substantive risk framework. Other small in-scope entities apply the general framework with any specific relief that actually applies.

Applying the workflow in a startup team

When a small finance team translates its risk framework into a purchasing brief, it needs clear owners, usable evidence and an implementation plan. The startup DORA software selection workflow connects those operational questions to procurement. Headcount alone does not establish eligibility for Article16; confirm the entity-specific conditions separately.