Article 21(2) of NIS2 lists ten categories of security measure. The first one is the risk analysis policy, and its position is not decorative: every other measure on that list is supposed to follow from it. Incident handling, business continuity, supply chain, cryptography, access control — the law expects each to be a response to something you identified and scored, not a control you bought because a vendor suggested it.
Which is where most mid-market organisations get stuck. The frameworks that do this properly assume a risk function you do not have. The alternative on offer is usually a downloadable template that an auditor will recognise as a downloadable template. Between those two lies a method that a two-person IT team can actually execute in a few weeks and defend afterwards.
This guide sets out that method: how to scope it, how to score without inventing precision, how to link every finding to the article it satisfies, and what the evidence pack needs to contain when the CCB, a conformity assessor or an insurer’s forensic team asks to see it.
What the law actually asks for
Three texts govern this. Article 21(1) of Directive (EU) 2022/2555 requires appropriate and proportionate technical and organisational measures, judged against the state of the art, the cost of implementation and your own exposure. Article 21(2)(a) names the first mandatory measure: a policy on risk analysis and information system security. And Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 specifies what that framework has to contain.
Two details in there change the shape of the work. First, the chapeau of article 21(2) demands an all-hazards approach: you are protecting network and information systems and their physical environment, which explicitly pulls in physical, human and supply-chain hazards alongside cyber ones. A register containing only ransomware and phishing is incomplete on its face. Second, the implementing regulation requires a documented risk treatment plan, allows risk acceptance only in exceptional and explicitly justified cases, and — where you perform a business impact analysis — expects maximum tolerable downtime, recovery time objectives and recovery point objectives to be recorded.
Worth separating what is obligatory from what is merely good practice, because conflating them is how small teams end up buying tooling they do not need:
| Element | Required by law | Good practice, not required |
|---|---|---|
| Risk analysis policy | Documented and approved by the management body | Automated GRC platform |
| Scope of hazards | All-hazards: cyber, physical, human, supply chain | Full integration with enterprise risk management |
| Scoring | A method that prioritises risks for treatment | Quantitative modelling in monetary values |
| Board involvement | Approval and oversight of measures under article 20 | Monthly KPI dashboards |
| Supplier risk | Assessment of suppliers and ICT service providers | On-site audits at every supplier |
Choosing a method you can finish
Four frameworks are defensible. ISO/IEC 27005:2022 is thorough and expensive in hours — an exhaustive asset inventory with vulnerabilities mapped per asset runs well past a hundred hours per cycle. NIST SP 800-30 is strong on threat modelling but American in origin and missing the NIS2 article structure. ENISA’s risk management framework is well aligned to European regulation but thin on Belgian specifics. And CyFun’s ID.RA controls are the official Belgian reference, established by the royal decree of 9 June 2024 and scaled deliberately for organisations without compliance departments — which is why, if you are Belgian, that is the compass to align to. Our guide to the CyFun framework covers how those levels work.
The bigger decision is not which standard to name but which shape to use.
Asset-based analysis starts from an inventory: every server, laptop, switch and application, each with its threats and vulnerabilities. For a 200-person organisation this produces thousands of rows that age badly and that auditors routinely dismiss as non-operational, because nobody maintains them.
Scenario-based analysis starts from the business. Identify your five to ten critical processes — order processing, ERP and finance, production line, R&D storage, physical access control — then identify the macro-scenarios that could disrupt them. The register lands at roughly 15 to 25 scenarios: small enough to explain to a board, review quarterly and actually revisit after an incident. For the mid-market, this is the version that survives contact with reality.
The method, in eight steps
| Step | What you produce | Who is involved |
|---|---|---|
| 1. Scope and justify exclusions | Scope statement with written justification for anything excluded | IT lead, compliance, business leads |
| 2. Group processes and dependencies | Register of critical processes with their IT, supplier and physical dependencies | IT operations, system owners |
| 3. Build the all-hazards catalogue | Threat list across cyber, physical, human and supply chain | IT lead, facilities, HR |
| 4. Score likelihood and impact | Inherent risk scores on the 4×4 scale | Cross-functional workshop |
| 5. Document the register | Central risk register with owners | Compliance lead, IT lead |
| 6. Decide treatment, map to article 21(2) | Risk treatment plan with explicit article references | IT lead, security advisor |
| 7. Obtain board approval | Signed decision and board minutes | Management body |
| 8. Set review cadence and triggers | Review calendar plus documented event triggers | IT lead, management body |
On scope: everything supporting the service that brings you into NIS2 is in. Exclusions are allowed only where a network is genuinely physically or logically separated from your critical processes, and they need a written justification note in the audit trail. “We didn’t get to it” is not an exclusion. If you are still unsure whether you are in scope at all, that is a separate exercise — see our NIS2 scope check.
On the all-hazards catalogue, walk all four categories deliberately, because IT teams left alone produce four cyber scenarios and nothing else. Cyber: ransomware, credential theft, exploitation of unpatched systems. Physical: fire, water in the server room, burglary, a contractor cutting a fibre. Human: phishing of an administrator, untrained staff, a departing employee with lingering access. Supply chain: a breach at your managed service provider, a compromised software update, the failure of a cloud platform you cannot replace quickly.
Scoring without pretending to be precise
Use a 4×4 matrix. Four levels rather than five removes the safe middle option, and qualitative anchors beat invented percentages — if you do not have the loss data to support “13.7% likelihood and €42,300 impact”, do not produce that number.
| Likelihood | Anchor | Impact | Anchor |
|---|---|---|---|
| 1 — Rare | Needs exceptional skill and resources; no known sector incidents | 1 — Minor | Non-critical disruption under 2 hours; under €10,000 |
| 2 — Possible | Technically feasible; comparable organisations affected | 2 — Significant | A primary process down under 8 hours; €10,000–€100,000 |
| 3 — Likely | Frequent in the sector; the vulnerability exists in our configuration | 3 — Serious | Core activity halted 1–3 days; €100,000–€500,000; reportable incident |
| 4 — Almost certain | Actively exploited; publicly known and unmitigated here | 4 — Critical | Critical service down over 3 days; over €500,000; national attention |
Multiply the two. Scores of 1–4 may be accepted by management. Scores of 6–9 require a treatment plan within six months. Scores of 12–16 go to the board immediately with acute mitigation. When a workshop cannot agree between two levels, take the higher one and note the disagreement — conservatism is cheap here, and score deflation to avoid asking for budget is the single most visible failure mode in an audit.
What the register has to contain
Twelve fields make a register auditable: a unique risk ID; the hazard category; the scenario description covering threat, vulnerability and chain of events; the affected business process; existing controls; likelihood; impact; the resulting inherent score; the treatment strategy (mitigate, transfer, accept, avoid); the specific article 21(2) sub-paragraph it maps to; the action owner with a deadline; and the residual risk after the planned measures.
The article mapping is the field people skip and the one that does the most work in an audit, because it turns a technical document into a legal one. Mitigating a supplier-access risk maps to 21(2)(d); adding multi-factor authentication maps to 21(2)(j); isolating an unpatchable system maps to 21(2)(e) and (i); improving your backups maps to 21(2)(c). Two things do not work as treatments: transfer does not move your legal responsibility, whatever your cyber policy says, and acceptance of a high score without written justification and a board decision is the finding an inspector will lead with.
A worked example
A manufacturer outsources server management to an MSP, which holds a permanent management tunnel into the internal network. The threat: attackers compromise the MSP and use that legitimate tunnel to deploy ransomware. Existing control: an IPsec VPN with a password and no multi-factor authentication on the administrative account.
Scoring: likelihood 3 — supply-chain intrusions of this shape are frequent and the vulnerability is present as configured. Impact 4 — production stops. Inherent risk 12, critical, straight to the board.
Treatment: mitigate. Enforce multi-factor authentication on all administrative access, mapping to article 21(2)(j). Replace the permanent flat tunnel with brokered, time-limited, per-application access with session logging, mapping to 21(2)(i). Add security requirements and audit rights to the MSP contract, mapping to 21(2)(d) and 21(3). Residual risk: likelihood 1, impact 3, score 3. Evidence generated: the amended MSP agreement, the MFA enforcement logs, and the register line signed off by the board.
Two more scenarios in compressed form:
| Scenario | Inherent | Treatment and mapping | Residual |
|---|---|---|---|
| Critical ERP runs on an operating system past end of support; flat network, no segmentation | L4 × I3 = 12 | Isolate behind identity-gated access, 21(2)(e) and (i); document a funded migration plan; daily immutable offline backups, 21(2)(c) | L2 × I2 = 4 |
| Administrator’s session token stolen through adversary-in-the-middle phishing; SMS-based MFA in place | L3 × I4 = 12 | Replace SMS with phishing-resistant authentication, 21(2)(j); least privilege and conditional access, 21(2)(i); role-based training, 21(2)(g) | L1 × I3 = 3 |
The first of those is the one most estates actually contain, and the compensating-control architecture behind it is set out in our guide to end-of-life systems under NIS2. The second connects directly to device posture checks, and the technical measures across all three map onto the control set we describe in NIS2 security measures and SASE controls.
The evidence pack
Five documents, and the metadata on them matters as much as the content:
- The risk analysis policy — the method, the matrix, your acceptance thresholds and review frequency. Versioned, dated, signed by the management body, and demonstrably approved before the assessment was carried out.
- The risk register — all scenarios including physical, human and supply chain, with inherent and residual scores and named owners. Kept in something with change history, so it visibly evolves.
- The risk treatment plan — budgets, deadlines, status per action, and the explicit article 21(2) mapping.
- Board minutes and the signed decision — direct evidence of the article 20 duty, including any accepted residual risks.
- Proof of board training — dated attendance or certificates, naming the provider and content. Article 20(2) makes this explicit and it is trivially easy to fail on.
The failures assessors see most often are predictable: a register whose file properties show it has not been opened in eleven months; technical documents that were never put in front of the board; registers with no physical or human hazards in them at all; and a red risk accepted by an IT lead with no written justification. Each of those is visible in seconds, and each undermines the presumption that your measures were proportionate.
The objections, answered honestly
“This is bureaucracy that produces no security.” True if you pick a heavyweight asset-based framework and spend your quarter maintaining an inventory. Not true of a scenario-based register, which is a prioritisation instrument: without it, budget goes to whatever was most recently pitched to you rather than to what is most likely to hurt. Article 21(4) also obliges you to remedy identified shortcomings without undue delay, and the register is the record showing those decisions were made on evidence.
“Our cyber insurance questionnaire already covers this.” It does not, for three reasons. It is an underwriting instrument scoped to the insurer’s exposure rather than your processes. It contains no treatment plan with internal ownership. And completing a third party’s form is not the same as your management body adopting an internal policy, which is what article 20 requires.
“We’re 80 people — formal risk management is too heavy.” Proportionality is written into article 21(1) precisely for this, and the Belgian route through CyFun Basic is scaled for organisations without compliance teams. In practice the scenario-based method costs 20 to 30 person-hours for the first cycle at a 150-person organisation: roughly four hours of scoping, two workshops of three hours, eight hours writing up the register and four hours preparing the board decision.
“We’re ISO 27001 certified, so this is covered.” It is a strong foundation and it grants a presumption of conformity under Belgian law, but three gaps recur. Certificate scope is often narrower than the systems supporting your in-scope service. NIS2 article 21(3) goes further on supplier assessment than the corresponding ISO annex controls. And article 20 requires demonstrable board training and oversight with personal liability attached, which an ISO audit does not test in those terms. Our supply chain obligations guide covers the widest of those gaps.
Start with the workshop, not the template
Block three hours with your IT lead, one business owner and someone who knows the building and the suppliers. Work through the four hazard categories against your five most critical processes. You will end the session with fifteen or so scenarios, an uncomfortable number of them scoring 9 or higher — and that list, scored and owned, is the substance of your NIS2 risk analysis. The policy document and the board decision are what you wrap around it afterwards.
What tends to come out of that session, over and over, is the same cluster of treatments: remove flat network access for suppliers, put identity and device posture in front of everything reachable from outside, isolate what cannot be patched, and log it centrally. Jimber delivers exactly that set — ZTNA network isolation, secure web gateway and firewall-as-a-service — from a single EU-sovereign platform, which means one treatment project rather than four, and access logs your evidence pack can actually use. Book a demo and bring your top five scenarios; we will show you which of them the platform closes. If your next step is the audit itself, work through our NIS2 compliance checklist for IT managers.
Frequently asked questions
What does NIS2 article 21 require for risk analysis?
Article 21(2)(a) requires a documented policy on risk analysis and information system security, built on the all-hazards approach set out in the chapeau of article 21(2). The analysis must cover cyber, physical, human and supply-chain hazards, and its output determines which technical and organisational measures the organisation implements.
How does a mid-market organisation do this without a risk department?
Use a scenario-based approach instead of an asset inventory. Identify five to ten critical business processes, then the macro-scenarios that could disrupt them, and score those in a cross-functional workshop using a 4×4 matrix. That produces roughly 15 to 25 register entries, typically 20 to 30 person-hours of work for a first cycle.
Which risk methodology is recognised for NIS2 in Belgium?
The CCB’s CyberFundamentals framework is the official Belgian reference, established by the royal decree of 9 June 2024, with its ID.RA controls structuring the risk analysis. ISO/IEC 27005 and NIST SP 800-30 are also defensible, provided they are adapted to the specific measure categories of article 21(2).
What does the all-hazards approach actually mean?
It means protecting network and information systems and their physical environment against all relevant incidents, not only cyberattacks. In practice your register must include physical hazards such as fire and power loss, human hazards such as phishing and insider risk, and supply-chain hazards such as a breach at a service provider.
How often must the risk assessment be repeated?
At least annually, plus an immediate reassessment on defined triggers: major IT changes such as a cloud migration, any significant security incident, a reported breach at a supplier, or the disclosure of a critical vulnerability in deployed infrastructure. A register with no changes in twelve months is itself an audit finding.
Who has to sign off the risk assessment?
The management body. Under article 20, the board or executive directors must approve the risk-management measures, oversee their implementation and undergo cybersecurity training. The technical work is owned by the IT or compliance lead, but the formal approval of the methodology, the treatment plan and any accepted residual risk sits with the board.
Is quantitative scoring better than a qualitative matrix?
Not for mid-market organisations. Quantitative models need detailed statistical data on frequencies and losses that most organisations do not have, so the output becomes invented precision. A qualitative 4×4 matrix with clear operational anchors gives the best balance of accuracy and feasibility, and is easier to defend.
How do we assess SaaS providers we have no technical control over?
Treat it as supply-chain and dependency risk under article 21(2)(d). Request third-party assurance such as ISO 27001 or SOC 2 Type II reports, enforce your own access controls with multi-factor authentication and conditional access, and arrange an independent backup of the data held in the service so continuity does not depend solely on the provider.
