DORA ICT Risk Assessment: Running Article 8

"DORA risk assessment" is a search that assumes Regulation (EU) 2022/2554, the Digital Operational Resilience Act (DORA), prescribes a methodology. It does not. What it does is name the steps, in a defined sequence, inside Articles 6 and 8, and leave the choice of method to the financial entity. The risk assessment that a competent authority will accept is the one that follows that sequence, keeps the artefacts the articles call for, and uses the output to decide where protection effort goes. This article walks the sequence.

What Article 8 actually requires

Article 8 is titled Identification, and it has seven paragraphs. Together they describe a continuous activity, not a once-a-year exercise. The paragraphs chain in a specific order, and most defective risk assessments fail by running them in parallel or by skipping one.

Delegated Regulation (EU) 2024/1774 develops the methodology around those paragraphs, in particular the content of the inventories, the way sources of risk are classified, and the way the resulting ICT risk register is maintained. The regulation plus the RTS are the two texts to have open while you build the sequence.

Step 1: Settle scope before you measure anything

The output of a risk assessment is only as useful as the scope it declared. Three decisions govern the depth of every later step, so settle them first and record them in writing.

• Entity scope. Which legal entities and which business lines are inside the assessment, and under which Article 2 category each one sits.
• Function scope. Which functions have been designated critical or important under Article 3(22), which have been assessed and found not critical, and which have not yet been assessed. A function in the third group is a gap, not an exclusion.
• Framework scope. Whether the assessment is run under the full framework or the simplified Article 16 framework, and the reasoning that made that proportionate.

Our guide to identifying critical or important functions works through the Article 3(22) definition, and the CIF decision record sets out what the written designation contains. Without those two artefacts, the depth of everything below is unsettled.

Step 2: Build the asset and function inventory (Art. 8(1), 8(4))

Article 8(1) requires you to identify, classify and document ICT-supported business functions, and the information assets and ICT assets supporting them. Article 8(4) widens the asset side: all assets, including remote sites, network resources and hardware, with configuration and interdependencies mapped for the critical subset. In practice this is the step where most teams underestimate the work.

Three joins have to hold at the end of this step:

1. Every ICT-supported business function has at least one asset mapped to it.
2. Every critical asset has at least one function mapped to it, and inherits the highest classification among them.
3. Every asset carries a classification by confidentiality, integrity and availability, which is what Article 9 then protects.

An inventory that lists assets without the function join is not an Article 8(1) inventory. Our walkthrough of mapping ICT assets and functions covers the sequence of fields and the queries that validate the joins.

Step 3: Map third-party dependencies (Art. 8(5))

Article 8(5) is the paragraph most often left to the procurement team, which is the wrong team for it. The requirement is to identify and document all processes dependent on ICT third-party service providers, and the interconnections with providers supporting critical or important functions. The two documents that answer it are different: an inventory of processes with their providers, and a map of the interconnections (what talks to what, with what identity, over what channel).

Both feed Article 28 (the pre-contractual regime), Article 29 (concentration risk) and the Register of Information. Our guide to the third-party risk register methodology covers the fields; what matters at this step is that the inventory produced here is the authoritative source, and the register is a view onto it.

Step 4: Identify sources of ICT risk (Art. 8(2) first limb)

Article 8(2) opens by requiring continuous identification of all sources of ICT risk, including the risk exposure to and from other financial entities. Sources are categories, not events: process failures, people, external attack, systems and technology, legal and compliance, and external events such as supplier failure or infrastructure disruption. The RTS at Article 3 of Delegated Regulation (EU) 2024/1774 sets out the taxonomy and the obligation to document it.

Keep the source list short and governed. A taxonomy with sixty entries is a taxonomy that nobody uses consistently, and an assessment that classifies the same event into three different categories across its iterations is an assessment that cannot be audited.

Step 5: Assess cyber threats and vulnerabilities (Art. 8(2) second limb)

Threats and vulnerabilities are different objects and have to be assessed separately. Threats are what someone or something could do: credential theft, ransomware deployment, insider misuse of privilege, supplier failure, denial-of-service traffic. Vulnerabilities are the weaknesses that would let a threat succeed: an unpatched system, a dormant admin account, a flat network, a backup channel left open.

Three practical rules:

• Threat and vulnerability pairs are what you score, not threats alone.
• Scoring runs on the asset and function join from Step 2, so a severe vulnerability on a non-critical asset is not the same risk as the same vulnerability on an asset that supports a critical or important function.
• External threat intelligence feeds this step and is why Article 13 and Article 45 arrangements exist. A pair that never surfaces in your intelligence feed is a pair you have decided not to monitor.

Step 6: Review the risk scenarios at least yearly (Art. 8(2) last limb)

Scenarios are the step most teams fold into testing, which is a different pillar. Scenario review inside Article 8(2) is about the plausibility of the pairs: has anything in the business, the technology or the threat landscape made a pair that was far-fetched last year realistic this year, and vice versa. The output is a dated scenario catalogue with the pairs ranked, which then feeds the testing plan under Articles 24 to 27 and the response and recovery plans under Article 11(3).

Step 7: Risk assessment on major changes (Art. 8(3))

Article 8(3) requires a risk assessment on each major change in the ICT infrastructure, processes or procedures. "Major" is defined by its effect, not its size: a change is major if it changes the risk profile of a function or an asset in the inventory. A platform migration counts, a new third-party connection counts, a change to the identity model counts; a routine patch does not.

The artefact that closes this paragraph is a change-triggered risk assessment attached to the change record itself. Change control that produces an approval without a risk assessment on major changes passes the Article 9 change management test and fails Article 8(3). The two have to hold together, which is why our guide to database change governance under DORA treats both as one chain.

Step 8: Legacy systems (Art. 8(7))

Article 8(7) singles out legacy ICT systems: at least yearly, and in any case before and after connecting new technologies, applications or systems to them. Legacy is defined by its state (unsupported, vendor-decommissioned, undocumented) rather than its age; a system in production can be legacy on arrival if its support model does not meet the framework.

The practical consequence: an inventory flag for legacy, a short dedicated risk assessment per legacy system or per legacy cluster, and a connection check whenever one is wired into a modernisation project. The assessment feeds the retirement roadmap, which is where legacy risk actually gets reduced.

Step 9: Treatment and the ICT risk register

The output of the sequence is not a report. It is the ICT risk register, which Article 6(1) and the RTS require to be maintained. For each pair you have scored, the register carries the asset, the function join, the source category, the threat and vulnerability, the likelihood and impact scoring, the treatment decision (reduce, retain, transfer, avoid), the owner, the control that implements the decision, the residual rating and the review date.

Residual risks above tolerance route to the management body under the framework governance, which is where Article 5(2) accountability becomes concrete. A register that does not surface residual risk against a declared tolerance is a register that lets the framework hover above the business without touching it.

What to do next

Open your current risk assessment and run the nine-step chain against it. Three questions settle most gaps: does the asset and function join hold at Step 2, does the third-party inventory of Step 3 feed the Register of Information, and does the risk register at Step 9 have a residual rating against tolerance for every pair. If any of the three is "no", that is where to start, and it is where a competent authority will start too.

Our guide to setting defensible impact tolerances covers the thresholds residual risk is measured against, and the third-party risk guide covers how Step 3 outputs feed the fourth pillar end to end.