DORA Article 9 (Regulation (EU) 2022/2554) sets out the protection-and-prevention pillar of the ICT risk-management framework that financial entities must run. It binds "financial entities" — banks, investment firms, insurers, crypto-asset service providers, and the rest of the DORA scope. The obligation rows do not record a separate deadline; DORA has applied since 17 January 2025, and Article 9 has applied alongside the rest.
What Article 9 requires
The article moves from continuous monitoring to specific data-state protections to risk-minimising solution selection. There is no single "do this once" duty in Article 9 — every row is continuous.
Obligation breakdown
Continuous monitoring of ICT systems
"Financial entities shall continuously monitor and control the security and functioning of ICT systems and tools." The action verb is monitor, and "continuously" is doing real work — point-in-time annual reviews do not satisfy this row.
Minimise ICT risk impact
"Financial entities shall minimise the impact of ICT risk on ICT systems through the deployment of appropriate ICT security tools, policies and procedures." The verb is deploy: tools, policies and procedures, all three. A policy without tooling — or tooling without procedure — is a partial deployment.
Implement resilience policies
"Financial entities shall design, procure and implement ICT security policies, procedures, protocols and tools that aim to ensure the resilience, continuity and availability of ICT systems." Three lifecycle steps are named: design, procure, implement. Buying alone is not implementation.
Maintain availability, authenticity, integrity, confidentiality
"Financial entities shall maintain high standards of availability, authenticity, integrity and confidentiality of data, whether at rest, in use or in transit." Three data states are explicitly listed; an entity that protects data at rest but not in use is not Article 9-compliant.
Secure transfer of data
"Financial entities shall use ICT solutions and processes that are appropriate in accordance with Article 4 to ensure the security of the means of transfer of data." Article 4 carries the proportionality principle into Article 9: "appropriate" is calibrated to the entity's size and risk profile, not absolute.
Minimise corruption, loss, unauthorised access
"Financial entities shall use ICT solutions and processes that minimise the risk of corruption or loss of data, unauthorised access and technical flaws that may hinder business activity." Three risk categories are listed cumulatively; the row does not let an entity trade off one against another.
Prevent unavailability and confidentiality breach
"Financial entities shall use ICT solutions and processes that prevent the lack of availability, the impairment of the authenticity and integrity, the breaches of confidentiality and the loss of data." This is the closing prevention clause — the same four data properties as the maintenance row, restated as a prevention duty.
What this means in practice
The seven rows interlock. Continuous monitoring (row 1) feeds the risk-minimisation deployment (row 2); the deployment is then framed by resilience policies (row 3) and tested against the four data properties (rows 4 and 7). Articles 4 and 9 should be read together — Article 4 sets the proportionality lens through which "appropriate" in Article 9 is judged. For overlap with the AI Act: where a financial entity also deploys a high-risk AI system, AI Act Article 17 (provider QMS) and DORA Article 9 (operational ICT-risk controls) sit in different directions, but a credit-scoring deployment touches both.
Related Fontvera pages
- AI Act for fintech and credit scoring — the sector view that combines DORA Article 9 with AI Act provider duties.
- AI Act vs DORA — the regulation-on-regulation comparison that places Article 9 in context.
- NIS2 vs DORA — the cybersecurity-side overlap that financial entities must reconcile alongside Article 9.