The Digital Operational Resilience Act (DORA) has applied to EU financial entities since 17 January 2025. The first wave of work was about registers of information and incident reporting. Supervisors are now asking a different question: show us how you identify and assess ICT risk for the functions that matter, and how you redo that when your systems change.
DORA never says "threat model", but Article 8 describes one: map the business functions and the ICT assets and providers behind them, find the cyber threats and vulnerabilities that apply, and assess the risk again after every major change. This post builds that assessment for a fictional e-money institution: a data flow diagram of its payments function, an article-by-article mapping, an attack tree and a scored register its management body can approve.
The short version: DORA's ICT risk management framework (Articles 5 to 16, detailed in Delegated Regulation (EU) 2024/1774) expects you to identify your ICT-supported business functions, map the assets and third-party providers behind them, assess the threats to them and treat the risks. You have to review the risk scenarios at least yearly, reassess after each major change and assess legacy systems at least yearly. A threat model per critical or important function covers that. The diagram is your Article 8 map, the attack tree is your risk scenarios and the register is your treatment record. Put availability threats next to security ones, because DORA is about keeping the service running, not only keeping data safe. Draw your ICT providers as dependencies. Your entity stays fully responsible for them, even the 19 the EU designated as critical.
Where DORA stands on 29 October 2026
DORA is Regulation (EU) 2022/2554. It applies to around twenty types of financial entity, including banks, payment and e-money institutions, investment firms, insurers, crypto-asset service providers and trading venues. A handful of the smallest, such as payment and e-money institutions exempted under the payment services and e-money directives, can use the simplified framework in Article 16. Everyone else needs the full framework. For financial entities, DORA's ICT risk rules take the place of the equivalent NIS2 provisions.
| Date | What happened |
|---|---|
| 17 Jan 2025 | DORA applies, together with the technical standards on the ICT risk management framework (Delegated Regulation 2024/1774) and incident classification (2024/1772). |
| 2025 | First registers of information on ICT third-party contracts submitted to supervisors. The standard on incident report content and deadlines (2025/301) and the standard on threat-led penetration testing (2025/1190) are published. |
| 18 Nov 2025 | The European Supervisory Authorities designate the first 19 critical ICT third-party service providers, including the three largest cloud providers, for direct EU oversight. |
| Now | Supervision has moved from "do you have a framework?" to "show us it works": asset maps, risk assessments, tested recovery plans and evidence that change triggers reassessment. |
What DORA actually asks for
Strip out the legal phrasing and the parts of DORA that a threat model answers are these:
- Identify and classify your ICT-supported business functions, the information and ICT assets that support them, and their dependencies (Article 8(1)). Map the critical assets, their configuration and how they connect (8(4)).
- Identify the sources of ICT risk and assess the cyber threats and ICT vulnerabilities relevant to those functions and assets, and review the risk scenarios that affect you at least yearly (8(2)).
- Assess risk upon each major change to your network, information systems or the processes around them (8(3)).
- Assess legacy ICT systems at least yearly, and before and after connecting new technologies to them (8(7)).
- Identify the processes that depend on ICT third-party providers, especially those supporting critical or important functions (8(5)), and assess the risks of a contract before you sign it, including concentration risk (28(4)).
- Treat the risks with protection, detection, response, recovery and backup measures (Articles 9 to 12), under a framework the management body approves and oversees (Article 5).
Points 1 and 2 are ordinary threat modeling: what are we running, what can go wrong. Points 3 and 4 are what make DORA different from a one-off assessment. Point 5 is where most teams' models stop too early, at the edge of their own network. Point 6 is the register.
Two DORA terms shape the scope. A critical or important function is one whose disruption would materially impair your financial performance, the soundness or continuity of your services, or your compliance with your licence (Article 3(22)). DORA expects deeper analysis, testing and contract terms for these, so start your threat models there. And ICT risk covers availability as much as confidentiality and integrity. A threat model that only asks how data could leak misses half of what DORA is about.
The example: Payvio's payments function
Payvio is a fictional e-money institution authorised in the EU. It offers business accounts and SEPA credit transfers, including SEPA Instant, to about 40,000 small businesses through a web and mobile app. It's not exempt, so it runs the full DORA framework, but it hasn't been designated for threat-led penetration testing.
Payvio's list of critical or important functions has three: onboarding, account services and payments. This post models payments, because its disruption is the one customers notice within minutes. Its systems have three histories. The app, API and payments service run on a large cloud provider in an EU region. The core banking ledger is a 2014 system in Payvio's own data centre that nobody wants to touch. KYC checks, fraud scoring and the connection to the SEPA payment rail come from three ICT third-party providers.
Step 1: Map the function, not the network
Start from the business function and draw every ICT asset it needs to run, wherever it lives. That gives Article 8 its map in one picture: the assets (8(1) and 8(4)), how they depend on each other, and the processes that depend on third-party providers (8(5)). Put a trust boundary around each hosting environment and one around the providers, because each is a different owner, a different contract and a different way to fail.
Three things the diagram makes plain that an asset inventory doesn't:
- The legacy ledger sits on the critical path. Every payment posts to it (flow 7). Article 8(7) wants it assessed at least yearly and before and after connecting anything new to it, and the cloud-hosted payments service is exactly that kind of connection.
- The function has three external dependencies, and only one has an obvious alternative. Payvio can hold payments if fraud scoring is slow. It can't send any without the rail gateway.
- Staff can move money too. The back-office console (flow 9) is as much a payment channel as the app, and it's usually less tested.
Step 2: Read the model against DORA, article by article
Find threats the usual way first. Walk each element and flow with STRIDE, and give the Denial of Service letter real weight, since an outage is a DORA incident whether or not anyone attacked you. Then turn the result round and read it against the articles. The last column gives the register IDs from Step 4.
| DORA | Asks for | What Payvio's threat model supplies | Register |
|---|---|---|---|
| Art. 8(1), (4) | Functions, assets and dependencies identified and mapped | The data flow diagram above, one per critical or important function, versioned with each release. | None |
| Art. 8(2) | Sources of ICT risk, threats and vulnerabilities, scenarios reviewed yearly | The attack tree in Step 3, with each leaf a risk scenario. Reviewed every year at the annual framework review. | D1 to D7 |
| Art. 8(3) | Risk assessment upon each major change | A change to any element or flow on the diagram is a trigger to re-threat model before go-live. | D4 |
| Art. 8(5), 28(4) | Third-party dependencies and pre-contract risk assessment, including concentration | Each provider is an element with its own threats, including "provider unavailable". The concentration row is written before renewal. | D3, D8 |
| Art. 8(7) | Legacy systems assessed at least yearly | The ledger has its own branch in the tree and a named owner for its yearly assessment. | D2 |
| Art. 9 | Protection and prevention: access control, strong authentication, segmentation, change management, patching | Treatments for the authorisation, phishing, patching and change leaves. | D1, D2, D4, D5 |
| Art. 10 | Detection of anomalous activity | Alerts on payee changes, unusual back-office approvals and payment-file edits. | D1, D5 |
| Art. 11, 12 | Response and recovery plans, and backups restored from segregated systems | Failover and restore treatments for the availability leaves, each with a test date. | D3, D6, D7 |
| Art. 17 to 19 | Classify incidents and report major ones | The diagram tells the incident team which function, clients and providers an incident touches, which is what the classification criteria ask. | None |
| Art. 24, 25 | A resilience testing programme, with yearly tests of systems that support critical or important functions | Attack tree paths become test scenarios. The highest-scoring leaves are tested first. | D1, D7 |
| Art. 5 | The management body approves and oversees the framework | The register, with owners and accepted risks, goes to the board's risk committee once a year. | D8 |
Two rows have no register entry, and that's fine. The diagram is evidence for Article 8(1) on its own, and incident classification is a process the model feeds rather than a risk with a score. The table still says so, because a supervisor reads it to see that you've thought about each article, not only the ones with problems.
Step 3: An attack tree for the function
Most attack trees have a security goal: steal the data, take over the account. For DORA, make the root the business function failing, in either of the two ways it can: it stops, or it moves money it shouldn't. That puts outages, fraud and data corruption in one tree, which is how a supervisor will look at it. Leaves are scored likelihood × impact on a 5×5 risk matrix.
The highest-scoring leaf is a plain IDOR: the API lets one customer change the payee on another customer's scheduled payment by changing an ID. It needs no special skill and moves real money. The more interesting result is the middle branch. Three different ways to stop payments score 10 to 12, and none of them needs an attacker to be clever. That's DORA's point: operational resilience is mostly about dependencies and recovery, and a threat model that only looks for attackers would have scored them all as out of scope.
The tree also changes how Payvio reads "ransomware". The question isn't whether the ledger can be encrypted, but whether the backups can be too. If they're reachable from the same domain, the restore plan in Article 12 is fiction.
Step 4: Score it and build the register
Every leaf becomes a row in the risk register, with a treatment, an owner and the DORA articles it supports. D8 isn't in the tree. It came from looking at the providers together rather than one at a time, which is the concentration question Article 28(4)(c) and Article 29 ask.
| # | Threat | L × I | Treatment | DORA | Owner |
|---|---|---|---|---|---|
| D1 | Payee changed via another customer's ID | 3 × 5 = 15 | Mitigate: the server checks that every payment, payee and scheduled order belongs to the caller's account. Payee changes need step-up authentication and trigger an alert. Tests call every endpoint as a second customer. | 9(4)(c), (d), 10, 25 | Backend lead |
| D2 | Known flaw in the legacy ledger left unpatched | 3 × 4 = 12 | Mitigate: the ledger is reachable only from the payments service over one port. Its OS moves to a supported version this quarter, with a yearly legacy assessment owned by name. | 8(7), 9(4)(b), (f) | Infrastructure lead |
| D3 | SEPA rail gateway down, no fallback route | 3 × 4 = 12 | Mitigate: a contract with a second gateway for SEPA credit transfers, switch-over tested twice a year. Payments queue safely and customers see the delay. | 11, 28(4)(c), 28(8) | Head of payments |
| D4 | Untested change posts wrong balances | 3 × 4 = 12 | Mitigate: changes to the ledger or payments service need a reviewed change ticket, a run against production-like data and a daily reconciliation that stops payments on a mismatch. | 8(3), 9(4)(e) | Engineering manager |
| D5 | Ops login phished, payment file altered | 2 × 5 = 10 | Mitigate: phishing-resistant MFA on the back-office console. Payment files are signed when created and checked before sending. Releases above a threshold need a second approver. | 9(4)(c), (d), 10 | Security lead |
| D6 | Ransomware reaches the ledger and its backups | 2 × 5 = 10 | Mitigate: immutable backups in a separate account with separate credentials, and a full restore tested every six months against a target time. | 9(4)(b), 11, 12 | Infrastructure lead |
| D7 | Region outage, failover never tested | 2 × 5 = 10 | Mitigate: a warm standby in a second EU region, failed over in a planned test at least once a year, with results reported to the risk committee. | 11, 12, 24 | Infrastructure lead |
| D8 | Hosting, fraud scoring and KYC all depend on one cloud provider | 2 × 4 = 8 | Accept: moving providers would add more risk than it removes. Documented exit plan for the payments function, reviewed at each contract renewal, and the residual risk approved by the management body. | 28(8), 29, 5 | Chief risk officer |
D8 is the honest row. Payvio has found that two of its providers run on the same cloud provider it does, so a regional outage at one company takes out three dependencies at once. It doesn't pretend it can fix that. It writes the residual risk down, keeps an exit plan and gets the management body to accept it. That's what Article 5 means by the management body bearing final responsibility.
Step 5: Keep it alive
A DORA risk assessment is never finished. The framework is reviewed at least once a year, risk scenarios are reviewed yearly, and every major change needs a fresh assessment. The threat model is what makes those cycles cheap:
- Change. When the payments service gets a new provider, a new region or a new way to initiate payments, update the diagram, re-run the affected branch of the tree and record the date. That's your Article 8(3) evidence. See when to re-threat model for the other triggers.
- Incidents. Under the incident reporting standard, an initial notification for a major ICT-related incident is due within 4 hours of classifying it as major, and no later than 24 hours after you became aware of it. An intermediate report follows within 72 hours of the initial notification, and a final report within a month of the latest intermediate report. Classification asks how many clients, which services and how long. The diagram answers that faster than anyone's memory. Afterwards, Article 13 wants lessons learned, so add the incident's path to the tree if it wasn't already there.
- Testing. Article 24 wants tests of the systems behind critical or important functions at least yearly. Choose scenarios from the top of the register, not from a scanner's default profile.
- Providers. Each new ICT contract for a critical or important function gets its own threat-model pass before signature. The same element types and threats make concentration easy to spot across contracts.
What threat modeling can't do here
- It can't make you DORA-compliant. It produces the identification and risk assessment evidence. You still need the governance, policies, testing programme, incident process, register of information and contracts DORA requires.
- It isn't threat-led penetration testing. TLPT under Article 26 is a live red-team test of production systems, at least every three years, for entities the authorities designate, run under Delegated Regulation 2025/1190 and the TIBER-EU framework. A threat model helps scope it. It isn't one.
- It doesn't move responsibility to your providers. Under Article 28(1)(a) you remain fully responsible for your obligations when you use ICT providers. That applies to the 19 designated as critical too: EU oversight of them doesn't replace your own risk assessment of what you buy from them.
- It can't settle classification questions. Which functions are critical or important, and whether you qualify for the simplified framework, are judgements for your risk and compliance teams. Record the reasoning next to the model.
A checklist for your DORA ICT risk assessment
- List your critical or important functions, with the reasoning for each.
- For each one, draw every ICT asset and provider it depends on, with trust boundaries around each hosting environment and around third parties.
- Mark legacy systems, and give each a yearly assessment with an owner.
- Find threats on every element and flow, including outages, failed changes and provider failures, not only attacks.
- Build an attack tree whose root is the function failing or being misused, and score the leaves.
- Map every treatment to the DORA articles it supports, and to PCI DSS or other standards where the same control counts twice.
- Look at providers together for concentration risk, and write exit plans for the functions that need them.
- Give every treatment an owner, and take accepted risks to the management body.
- Set the triggers: yearly review, every major change, every new ICT contract, every major incident.
- Use the top of the register to choose the scenarios for your yearly resilience tests.
Sources, as of 29 October 2026: Regulation (EU) 2022/2554 (Articles 3, 5 to 13, 16, 17 to 19, 24 to 26 and 28 to 29), the ICT risk management framework standard (Delegated Regulation 2024/1774), the ESAs' announcement of 18 November 2025 and their list of designated providers, and Article 5 of Delegated Regulation 2025/301 for the reporting deadlines. This post isn't legal advice. Check scope and classification questions with your compliance team or counsel.
Frequently asked questions
Does DORA require threat modeling?
Not by name. Article 8 requires financial entities to identify their ICT-supported business functions and the assets and providers behind them, assess the cyber threats and vulnerabilities that apply, and assess the risk again after every major change. A threat model of each critical or important function, with a diagram, scored threats and owned treatments, is a practical way to produce that assessment and keep it current.
How often do you need to do a DORA ICT risk assessment?
Continuously, with fixed points. The risk scenarios that affect you must be reviewed at least yearly, the whole ICT risk management framework at least yearly, legacy ICT systems at least yearly, and a risk assessment is required upon each major change to your network, systems or processes. Smaller entities on the simplified framework in Article 16 have lighter rules.
What is a critical or important function under DORA?
A function whose disruption would materially impair the entity's financial performance, the soundness or continuity of its services, or its continuing compliance with its authorisation and financial services law (Article 3(22)). Payments, account access and onboarding are typical examples. DORA asks for more for these functions: deeper risk analysis, yearly testing, exit strategies and specific contract terms with ICT providers.
Does DORA apply to cloud providers and other ICT vendors?
Indirectly for most, directly for a few. Financial entities must manage the risk of every ICT provider through contracts, assessments and exit plans. On 18 November 2025 the European Supervisory Authorities also designated 19 critical ICT third-party service providers, including the largest cloud providers, for direct EU oversight. Designation doesn't reduce the financial entity's own responsibility for what it buys from them.
Is threat modeling the same as DORA threat-led penetration testing?
No. Threat-led penetration testing (TLPT) under Article 26 is a live, intelligence-led red-team test against production systems that support critical or important functions, required at least every three years for entities the authorities designate. Threat modeling is the design-time analysis that tells you which functions, assets and attack paths matter. It's a good input to scoping a TLPT, and to the yearly tests every entity runs under Article 24.