NIS2 is the EU's cybersecurity law for essential and important organisations, and it has applied since October 2024. It never uses the words "threat model". What it asks for, in Article 21, is cybersecurity risk-management measures that are appropriate and proportionate to the risks your systems face, approved by management and based on a policy of risk analysis. You can't show a measure is proportionate to a risk you never identified.
That makes threat modeling one of the most direct ways to produce the evidence NIS2 expects. This guide covers who NIS2 applies to (including SaaS vendors who aren't in scope themselves), what Article 21 actually requires, how a threat model maps to each measure, and what it doesn't cover.
The short version: NIS2 Article 21 requires risk-based security measures, management approval under Article 20, and incident reports within 24 hours, 72 hours and one month under Article 23. A threat model gives you the risk analysis behind Article 21(2)(a), the supplier risks behind 21(2)(d), the secure-development evidence behind 21(2)(e), and a ranked register management can approve. It doesn't replace your incident process, continuity plans or HR controls.
NIS2 in two minutes
- What it is: Directive (EU) 2022/2555, which replaced the original NIS Directive. As a directive, it takes effect through each EU country's national law, so the exact obligations, registration steps and supervisors vary by country.
- When: member states had to transpose it by 17 October 2024. Several missed that deadline, so check where your national law stands.
- Who: medium and large organisations (generally 50 or more employees, or more than €10 million in annual turnover and balance sheet) in 18 sectors. Annex I covers sectors of high criticality, such as energy, transport, banking, health, digital infrastructure (including cloud and data centre providers), ICT service management and public administration. Annex II covers other critical sectors, such as manufacturing, food, chemicals, postal services and digital providers like online marketplaces. Some entities are in scope regardless of size, for example DNS providers and trust service providers.
- Two tiers: essential entities face proactive supervision and fines of up to €10 million or 2% of worldwide annual turnover, whichever is higher. Important entities face supervision after the fact and fines of up to €7 million or 1.4%.
- Personal accountability: under Article 20, management bodies must approve the risk-management measures, oversee them and follow cybersecurity training, and they can be held liable for failures.
Does it apply to you? Two ways in
Directly. If your organisation falls into one of the sectors and meets the size threshold, NIS2 applies to you, and your national authority expects you to register and implement Article 21. SaaS companies should look closely at "cloud computing service providers" in Annex I: depending on how your country interprets it, a SaaS product can fall within it. Check your national law or ask your supervisor rather than assuming.
Through your customers. Article 21(2)(d) makes in-scope organisations responsible for supply chain security, "including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers". In practice that becomes security questionnaires, contract clauses and requests for evidence sent to every vendor they rely on. Many SaaS companies that aren't in scope themselves will be asked to show NIS2-grade risk management to win and keep EU customers.
Either way, the question you'll be asked is the same: how do you know your controls match your risks? A threat model is the clearest answer.
Where threat modeling meets Article 21
Article 21(1) sets the principle: measures must be appropriate and proportionate, taking into account the state of the art, the cost of implementation, the entity's exposure to risk and the likelihood and severity of incidents. Article 21(2) then lists ten minimum measures. Here is how a threat model supports each one, and what it leaves to other processes.
| Article | Requirement | What a threat model provides |
|---|---|---|
| 21(1) | Appropriate and proportionate measures | Every control is tied to a scored threat, so you can show why it exists and why it's sized as it is. Likelihood × impact is the "likelihood and severity" the article names. |
| 21(2)(a) | Policies on risk analysis and information system security | The core match. A repeatable method (DFD, STRIDE, attack trees, scoring) applied to each critical system is the risk analysis. |
| 21(2)(b) | Incident handling | Attack trees describe how incidents would unfold, which helps write detection rules and playbooks. The incident process itself is separate. |
| 21(2)(c) | Business continuity, backups, disaster recovery, crisis management | Threats to availability and to backups (ransomware deleting them, restores never tested) show where continuity planning matters most. |
| 21(2)(d) | Supply chain security | Strong match. Suppliers drawn as external entities and integrations, with the threats against each dependency scored and owned. |
| 21(2)(e) | Security in acquisition, development and maintenance, including vulnerability handling and disclosure | Strong match. Threat modeling at design time is secure development; re-modeling on change is maintenance. |
| 21(2)(f) | Assessing the effectiveness of measures | A register with treatments, owners and status shows which risks are closed and which remain. Re-scoring after a fix shows the effect. |
| 21(2)(g) | Cyber hygiene and training | Running threat modeling sessions is itself training for engineers. The wider awareness programme is separate. |
| 21(2)(h) | Cryptography and encryption | Information disclosure threats show where encryption is needed, and in transit or at rest. The cryptography policy is separate. |
| 21(2)(i) | HR security, access control, asset management | The DFD is an asset and data-flow inventory; elevation of privilege threats drive access control decisions. |
| 21(2)(j) | MFA, secured communications, emergency communications | Spoofing threats on sign-in and admin paths show exactly where MFA is mandatory. |
Two more articles benefit. Article 20 needs something management can actually approve: a ranked risk register with owners is far easier to sign off than a list of policies. Article 23 sets reporting deadlines (an early warning within 24 hours of becoming aware of a significant incident, a notification within 72 hours, a final report within one month). Deciding quickly whether an incident is "significant" is much easier when you already know which systems hold what data and what an attacker could reach from each one.
A worked example
Our free Teamscope example is a multi-tenant HR analytics app that processes EU employee data across Azure and Google Cloud. Here are four of its threats mapped to NIS2, the way you'd record them as evidence.
| Threat | Score | Treatment | NIS2 |
|---|---|---|---|
| AI answers reveal data beyond the user's access | 16 Critical | Row-level security before data reaches the prompt | 21(2)(i) access control, 21(2)(e) secure development |
| Static Google service-account key leaks | 15 High | Workload identity federation only; block key creation by policy | 21(2)(h) cryptography and keys, 21(2)(i) |
| Customers' HRIS tokens readable by one job | 10 High | Read-only scopes, per-tenant secrets, rotation | 21(2)(d) supply chain, 21(3) supplier risk |
| Google Cloud attacks go unseen in the SIEM | 9 Medium | Stream Cloud Audit Logs into Sentinel; alert on impersonation | 21(2)(b) incident handling, Art. 23 reporting |
Each row answers the questions an auditor or a customer's security team will ask: what's the risk, how serious is it, what did you do about it, who owns it, and which obligation does it support. If you keep the mapping on the threat itself rather than in a separate spreadsheet, it stays right when the threat is rescored or the fix changes.
Building the programme, step by step
- Pick the services that matter. Start with what an outage or breach would turn into a significant incident: the systems behind your core service, and anything holding customer or personal data.
- Model each one. Draw a data flow diagram with trust boundaries and every supplier the service depends on, walk it with STRIDE, and decompose the serious goals into attack trees.
- Score and decide. Rate likelihood and impact with written scales (our risk matrix guide has a starting set), then give every risk a treatment and an owner.
- Map to Article 21. Tag each mitigation with the measure it supports. Gaps in the mapping show you which measures have no risk analysis behind them.
- Take it to management. Present the ranked register for approval, record the decision, and repeat at a fixed interval. That's your Article 20 evidence.
- Re-model on change. New suppliers, new data flows and major releases change the risk. Our guide on when to re-threat-model lists the triggers.
- Keep the history. Supervisors and customers will want to see that the analysis is ongoing, not a one-off. Dated versions or snapshots of the model do that.
What threat modeling won't cover
NIS2 is broader than risk analysis, and it's worth being honest about the edges. A threat model won't give you:
- an incident response process, on-call rota or reporting workflow for Article 23,
- tested business continuity and disaster recovery plans,
- HR security processes, background checks or an awareness programme,
- your national registration with the competent authority,
- the detailed technical requirements of Implementing Regulation (EU) 2024/2690, if you're a cloud, data centre, managed service or other digital infrastructure provider it applies to.
What it does is connect them: it tells you which of those processes protect against which risks, and where the gaps are.
Common mistakes
- Treating NIS2 as a checklist. Ticking off the ten measures without a risk analysis misses the point of Article 21(1). The measures have to be proportionate to your risks.
- Leaving suppliers off the diagram. Article 21(2)(d) is explicit. If your payment provider, identity provider or HR system isn't on the model, neither are the risks you carry through them.
- Modeling once for the audit. A model from last year describes last year's system. Supervisors and customers expect the analysis to keep up with change.
- Keeping the evidence in slides. Management approval is much stronger when it points at a register with scores, owners and status than at a presentation.
- Assuming ISO 27001 settles it. An ISO 27001 risk process is a strong foundation, and our ISO 27001 risk register guide shows how a threat model feeds it. But certification doesn't automatically mean NIS2 compliance; check what your national law and supervisor accept.
Frequently asked questions
Does NIS2 require threat modeling?
Not by name. Article 21 requires risk-management measures based on risk analysis and proportionate to the risks, approved by management under Article 20. Threat modeling is one of the most direct ways to produce that risk analysis and to show each measure matches a real risk.
Is my SaaS company in scope of NIS2?
It depends on your size, your sector and your country's transposition. SaaS providers may fall under "cloud computing service providers" in Annex I, so check your national law. Even if you're not in scope, in-scope customers will ask you for security evidence under their supply chain obligations in Article 21(2)(d).
What is the difference between NIS2 and DORA?
DORA (Regulation (EU) 2022/2554) is the sector-specific rulebook for financial entities' digital operational resilience. For those entities, DORA's ICT risk management, incident reporting and testing rules take precedence over the equivalent NIS2 provisions. Most other sectors follow NIS2.
What are the NIS2 incident reporting deadlines?
For a significant incident: an early warning within 24 hours of becoming aware of it, an incident notification within 72 hours, and a final report within one month of the notification. Your national law sets the exact process and the authority or CSIRT you report to.
Running critical infrastructure such as energy or water? See threat modeling for critical infrastructure. In financial services, DORA applies instead: see threat modeling for fintech.