SkarpChapter 7 of 15
DORA Regulation (EU) 2022/2554 — Governance, Identification, Protection, and Detection
Operational resilience begins before an incident occurs. Articles 5–10 move from management accountability to an auditable ICT framework, resilient systems, asset knowledge, protective controls, and rapid anomaly detection.
1. The Prevention Chain: Articles 5-10
A prevention chain
Articles 5-10 move from accountability to an ICT framework, resilient systems, asset knowledge, protective controls, and anomaly detection.
Read in order
Article 5 governs people and oversight. Articles 6-7 establish the framework and systems. Articles 8-10 identify, protect, and detect.
Current scope of this lesson
As at 24 July 2026, no amendment identified changes Articles 5-10. The listed proposals concern Article 2 and Article 19, not this module.
2. Article 5 — Governance and Organisation
The accountability rule
Article 5(2) makes the management body responsible for defining, approving, overseeing, and implementing arrangements for the Article 6(1) framework.
Ultimate responsibility
The management body shall bear the ultimate responsibility for managing the financial entity’s ICT risk. Delegation does not remove that stated responsibility.
What the management body approves
Its approvals and reviews include the resilience strategy, continuity and recovery arrangements, ICT audit plans, resilience budget, and third-party ICT-service policy.
Corporate reporting channels
The management body must be duly informed of provider arrangements, planned material changes, their potential impact, and at least major ICT-related incidents.
People and competence
Other than microenterprises, entities need a monitoring role or designated senior manager for third-party ICT risk. Management-body members shall train regularly.
3. Checkpoint — Article 5 Accountability
Choose the best answer
A bank asks an external consultancy to monitor its ICT risk. Under Article 5, which statement is correct?
Who bears the ultimate responsibility for managing the bank's ICT risk?
- The management body of the financial entity
- The external consultancy because it performs monitoring
- The ICT third-party service provider
- The internal-audit function alone
Show Answer
Answer: A) The management body of the financial entity
Article 5(2)(a) states that the management body shall "bear the ultimate responsibility for managing the financial entity’s ICT risk". Article 5 also requires governance, reporting, training and oversight; it does not transfer ultimate responsibility to a provider or adviser.
4. Article 6 — Build, Review, Audit and Improve the Framework
Framework baseline
Financial entities shall have a sound, comprehensive and well-documented ICT risk management framework as part of their overall risk management system.
What it protects
The framework includes strategies, policies, procedures, protocols, and tools protecting information and ICT assets, as well as relevant physical infrastructure.
Independence by design
Other than microenterprises, entities shall use an independent control function and segregate risk management, control, and internal audit.
Review triggers
The framework is reviewed at least once a year, or periodically in the case of microenterprises, and also after stated incident, supervisory, testing, or audit triggers.
Audit follow-up
Regular internal audit is required for entities other than microenterprises. Critical ICT-audit findings need timely verification and remediation under a formal process.
Strategy inside the framework
The resilience strategy covers risk tolerance, architecture, security objectives, detection and protection mechanisms, testing, incident evidence, and communication.
5. Article 7 — Systems Must Withstand Normal and Stressed Conditions
Four required characteristics
Article 7 requires updated systems, protocols, and tools that are proportionate, reliable, sufficiently capable, and technologically resilient.
Capacity is contextual
Capacity must accurately process necessary data and support timely services, including peak order, message, or transaction volumes as needed.
Stress test in plain language
A system that works only in ordinary conditions may fail Article 7 if it cannot handle additional processing needs in stressed markets or adverse situations.
What Article 7 does not select
Article 7 does not choose a vendor or architecture. It requires outcomes: reliable, appropriately scaled, capable, and resilient ICT tools.
6. Article 8 — Build an ICT Asset and Dependency Map
Article 8 — Identification
Article 8 turns asset knowledge into a recurring control activity.
Your task
Imagine a mobile-banking service. Before reading the answer, make a quick list of:
- two ICT-supported business functions;
- three information or ICT assets supporting them;
- one remote-site, network or hardware asset;
- one ICT third-party-service dependency; and
- one possible interconnection that supports a critical or important function.
Compare your list with Article 8
Article 8(1) requires financial entities, as part of the Article 6(1) framework, to identify, classify and adequately document all ICT-supported business functions, roles and responsibilities; the information assets and ICT assets supporting them; and their roles and dependencies in relation to ICT risk. Financial entities shall review as needed, and at least yearly, the adequacy of this classification and of any relevant documentation.
Article 8(2) requires continuous identification of all ICT-risk sources, particularly risk exposure to and from other financial entities. Entities shall assess cyber threats and ICT vulnerabilities relevant to their ICT-supported business functions, information assets and ICT assets. They shall review risk scenarios regularly and at least yearly.
For entities other than microenterprises, Article 8(3) requires an ICT-risk assessment upon each major change in network and information-system infrastructure, or in processes or procedures affecting ICT-supported business functions, information assets or ICT assets.
Article 8(4) requires identification of all information and ICT assets, including remote sites, network resources and hardware equipment, and mapping of those considered critical. Entities shall map configurations and links and interdependencies among assets.
Article 8(5) requires identification and documentation of every process dependent on ICT third-party service providers, and identification of interconnections with providers supporting critical or important functions.
Under Article 8(6), entities shall maintain relevant inventories and update them periodically and whenever a major change under Article 8(3) occurs. Under Article 8(7), entities other than microenterprises shall regularly, and at least yearly, perform a specific ICT-risk assessment of all legacy ICT systems and, in any event, before and after connecting technologies, applications or systems.
7. Article 9 — Protection and Prevention Controls
Protection is continuous
Article 9(1) requires continuous monitoring and control of the security and functioning of ICT systems and tools, alongside measures that minimise ICT-risk impact.
Data in every state
Article 9(2) addresses resilience, continuity, and availability, while maintaining data availability, authenticity, integrity, and confidentiality at rest, in use, and in transit.
Security outcomes
Article 9(3) covers secure data transfer, reduced corruption and access risk, prevention of availability and confidentiality failures, and data-management risks.
Access, authentication, and keys
The Article 9(4) control set includes least-needed physical or logical access, strong authentication, and cryptographic-key protection under stated conditions.
Controlled change
ICT changes must be recorded, tested, assessed, approved, implemented, and verified in a controlled manner. Patch and update policies must be documented.
Contain contagion
Network connection infrastructure shall allow instantaneous severance or segmentation to minimise and prevent contagion, especially for interconnected financial processes.
8. Checkpoint — Change Management and Network Segmentation
Choose the best answer
Which option most accurately reflects Article 9(4)?
A financial entity plans a firmware change to a system supporting a critical function. What does Article 9(4)(e) require?
- The change must be recorded, tested, assessed, approved, implemented and verified in a controlled manner, under a risk-assessment-based change-management process.
- The change can be implemented immediately if the vendor recommends it.
- Only software changes, not firmware changes, require change management.
- Internal audit must personally approve every technical change.
Show Answer
Answer: A) The change must be recorded, tested, assessed, approved, implemented and verified in a controlled manner, under a risk-assessment-based change-management process.
Article 9(4)(e) expressly covers changes to software, hardware, firmware components, systems and security parameters. The process must be risk-assessment based, integral to overall change management, approved by appropriate lines of management, and supported by specific protocols.
9. Rapid Review — Core Article 5-9 Controls
Flip each card
Use these cards to distinguish mandatory controls, review frequencies, and conditions that apply only to entities other than microenterprises.
- Article 5: ultimate ICT-risk responsibility
- The management body shall "bear the ultimate responsibility for managing the financial entity’s ICT risk".
- Article 6(1): framework requirement
- Financial entities shall have a sound, comprehensive and well-documented ICT risk management framework as part of their overall risk management system.
- Article 6(4): independence model
- Other than microenterprises, entities shall assign ICT-risk oversight to a control function and ensure segregation and independence according to the three lines of defence model, or an internal risk management and control model.
- Article 6(5): review timing
- The framework is reviewed at least once a year, or periodically in the case of microenterprises, plus after specified incidents, supervisory instructions, testing conclusions or audit conclusions.
- Article 8(1): classification review
- Financial entities shall review as needed, and at least yearly, the adequacy of this classification and of any relevant documentation.
- Article 8(7): legacy systems
- Other than microenterprises, entities shall assess all legacy ICT systems regularly and at least yearly, and in any case before and after connecting technologies, applications or systems.
- Article 9: network containment
- Network connection infrastructure shall allow instantaneous severance or segmentation to minimise and prevent contagion, especially for interconnected financial processes.
10. Article 10 — Detection: Find Anomalies Before They Escalate
The detection duty
Financial entities shall have in place mechanisms to promptly detect anomalous activities, including network-performance issues and ICT-related incidents.
Detect weak points too
Article 10(1) also requires mechanisms to identify potential material single points of failure. All listed detection mechanisms shall be regularly tested.
Thresholds and automatic alerts
Detection mechanisms shall provide multiple control layers, alert thresholds, response-trigger criteria, and automatic alerts for relevant response staff.
People and provider-specific systems
Entities shall devote sufficient monitoring resources and capabilities. Data reporting service providers also need trade-report completeness and error-checking systems.
From governance to detection
Articles 5-10 create a connected chain: accountable governance, documented framework, resilient systems, mapped assets, protective controls, and tested detection.
Key Terms
- ICT assets
- Assets including computer software, hardware and servers that Article 6 and Article 8 require financial entities to protect, identify, classify, document and map.
- management body
- The body that Article 5 makes responsible for defining, approving, overseeing and implementing arrangements related to the ICT risk management framework.
- control function
- For financial entities other than microenterprises, the function assigned responsibility for managing and overseeing ICT risk under Article 6(4), with appropriate independence.
- information assets
- Assets that Article 6 and Article 8 require financial entities to protect, identify, classify, document and map; Articles 5-10 do not provide a separate definition.
- legacy ICT systems
- Systems for which financial entities other than microenterprises must conduct a specific ICT-risk assessment regularly and at least yearly under Article 8(7).
- three lines of defence model
- One of the models Article 6(4) permits for appropriate segregation and independence of ICT risk management, control and internal-audit functions.
- ICT risk management framework
- The Article 6(1) framework that must be sound, comprehensive and well documented as part of the overall risk management system.
- critical or important functions
- Functions referenced in Articles 5, 8 and 9 when addressing third-party dependencies, impact, and ICT systems supporting those functions.
- ICT third-party service provider
- A provider whose ICT-service arrangements, dependencies, interconnections, planned changes and related risk exposure are addressed in Articles 5, 6 and 8.
- material single point of failure
- A potential single point of failure that Article 10(1) requires detection mechanisms to identify.
- digital operational resilience strategy
- The Article 6(8) component of the ICT risk management framework explaining how that framework shall be implemented.