NIS2 Risk Assessment: A Practical Guide for SMEs

Article 21(1) of the NIS2 Directive requires every in-scope organisation to implement cybersecurity risk management measures based on an “all-hazards approach.” Before you can implement access controls, incident response procedures, or backup policies, you need to know what risks you face. The risk assessment is the foundation — everything else in your NIS2 compliance programme flows from it. If you are still establishing whether your organisation falls under NIS2, see our overview of NIS2 requirements.

For many SMEs, this is the first time doing a formal information security risk assessment. It can feel overwhelming — especially when vendor solutions range from expensive consultancy engagements to complex software platforms built for enterprise security teams. The good news: NIS2 does not mandate any specific methodology. A structured, documented approach using a spreadsheet is entirely sufficient for a 50–200 person company.

This guide walks you through the full process in plain business English. By the end, you will understand exactly what NIS2 requires, which methodology is right for your organisation, and how to complete a risk assessment that satisfies your national supervisory authority. We cover each step with practical tables, a fully worked example for a manufacturing SME, and links to the NIS2 templates that do the heavy lifting.

This article provides general information only and does not constitute legal or regulatory advice. NIS2 implementation varies by member state and organisation type — always verify requirements against your national transposition law and applicable authority guidance.

What NIS2 Requires for Risk Management

Article 21(1): The Legal Obligation

Per Article 21(1) of the NIS2 Directive (EU) 2022/2555, member states shall ensure that essential and important entities take “appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems which those entities use for their operations or for the provision of their services.” It explicitly requires an “all-hazards approach” aimed at protecting network and information systems and their physical environment from incidents.

Three phrases in that text deserve attention:

• Appropriate and proportionate — your measures must match the actual risk you face. A 60-person logistics company is not expected to implement the same controls as a national energy provider. This is a legal principle, not a get-out clause: supervisory authorities will scrutinise whether your risk assessment accurately reflects your threat landscape and whether your controls actually address the identified risks.
• Technical, operational and organisational — risk management is not purely an IT matter. Policies, procedures, governance structures, and physical controls all count.
• All-hazards approach — critically, NIS2 does not limit risk assessment to cyber threats. You must consider the full range of hazards that could cause an incident.

CIR 2024/2690 Annex 2.1: Implementing Requirements

Per CIR 2024/2690, Annex 2.1, organisations must establish, implement, and maintain a documented risk assessment process that includes: identification of assets and their criticality; identification of applicable threats and vulnerabilities; assessment of the likelihood and potential impact of incidents; and determination of risk treatment options. These are binding technical requirements for essential and important entities in the sectors covered by the Implementing Regulation.

The ENISA Technical Implementation Guidance (section 2.1.1) further clarifies that the risk assessment must be the basis for selecting and sizing all other security measures. In other words, you cannot implement controls first and assess risks later — the assessment drives the controls. For a detailed walkthrough of ENISA’s implementation guidance, see our practical summary.

Note: The CIR currently applies to specific digital infrastructure and ICT service management sectors. Other sectors may face additional or different technical requirements under their national transposition. Confirm with your national competent authority which technical standards apply to your organisation.

All-Hazards: The Five Threat Categories You Must Address

An NIS2-compliant risk assessment must explicitly consider threats across five categories (recommended practical framework based on Art. 21 and CIR Annex 2.1):

• Physical and environmental threats — fire, flood, extreme weather, power outage, physical theft or damage to equipment
• Technical and hardware threats — server failure, network equipment fault, software bug, storage failure
• Human accidental threats — misconfiguration by staff, accidental deletion of data, lost or misplaced devices, unintentional disclosure
• Human deliberate threats — ransomware, phishing, insider theft, denial of service attacks, targeted intrusion
• Supply chain and third-party threats — vendor security breach, compromised software update, supplier service outage, third-party data exposure

Many SMEs make the mistake of treating information security risk assessment as synonymous with “IT risk.” NIS2 does not permit this. A fire that destroys your server room is an incident. A flood that cuts your power and network connectivity is an incident. Your risk assessment must address these physical scenarios as explicitly as it addresses ransomware. The ENISA Threat Landscape report (updated annually) identifies the most active threat categories in the EU — use it to validate your threat catalogue.

Review Frequency

Per Article 21 and CIR Annex 2.1, your risk assessment is not a one-time exercise. Organisations must review and update their risk assessments regularly — at a minimum, annually and after any significant change. Significant changes include: deployment of new systems or services, changes in the threat landscape (major new vulnerability, attack campaigns targeting your sector), material changes to the organisation (merger, new major customer, significant staff reduction), or any security incident that reveals an unidentified risk.

Note: National transposition laws may impose stricter review frequencies or additional trigger events. Check your country’s implementing legislation for sector-specific requirements.

Choosing a Risk Assessment Methodology

NIS2 is deliberately methodology-agnostic. Your risk assessment must be documented, systematic, and proportionate — but you choose the approach. The four main options for SMEs are compared below.

Methodology	Best For	Complexity	Cost	NIS2 Alignment
ISO 27005:2022	Organisations pursuing ISO 27001 certification; larger entities	High	High (specialist knowledge or consultant required)	Excellent — directly aligned with CIR requirements
NIST Cybersecurity Framework	US-linked organisations; technology companies	Medium–High	Medium (free framework, but requires adaptation to EU context)	Good — covers all-hazards but requires mapping to NIS2 requirements
OCTAVE (Carnegie Mellon)	Asset-focused organisations new to risk management	Medium	Medium (workshop-based, time-intensive)	Good — strong on asset identification, weaker on quantification
Simplified 5×5 Matrix	SMEs with limited security resources; organisations starting from scratch	Low	Low (spreadsheet-based, no specialist tools needed)	Sufficient — meets all NIS2 documentation requirements when properly structured

For most SMEs in scope of NIS2, the simplified 5×5 matrix approach is the right starting point. It can be implemented in a spreadsheet in days rather than months; it requires no external consultants or specialist software; it produces the documented outputs — risk register, treatment plan, management sign-off — that supervisory authorities expect to see; and it can mature into a full ISO 27005 process as your security programme develops. The steps below follow this approach.

Step-by-Step Risk Assessment Process for SMEs

This section provides a recommended practical framework based on NIS2 Article 21 and CIR Annex 2.1. Adapt the steps to your organisation’s size, sector, and existing security maturity.

Step 1: Identify and Classify Your Assets

An asset is anything that has value to your organisation and that you need to protect. NIS2 risk management covers six asset categories: hardware (servers, workstations, network equipment, industrial control systems), software (operating systems, business applications, cloud services), data (customer records, financial data, intellectual property, operational data), services (internet connectivity, email, cloud platforms your business depends on), people (employees and their skills, knowledge, and access), and premises (offices, data centres, server rooms).

Build an asset register that records each asset with a criticality rating. Criticality reflects how severely your operations would be affected if this asset were unavailable, compromised, or destroyed. Use a 1–5 scale (1 = minimal impact, 5 = catastrophic impact on operations).

Asset Name	Type	Owner	Location	Classification	Criticality
ERP System (SAP B1)	Software/Service	Finance Director	On-premises server room	Restricted	5
Customer Database	Data	Sales Director	On-premises / cloud backup	Confidential	4
Production OT Network	Hardware/Software	Head of Production	Factory floor	Restricted	5
Corporate Email (Microsoft 365)	Service	IT Manager	Cloud (Microsoft datacentres)	Confidential	4
File Server	Hardware/Data	IT Manager	On-premises server room	Confidential	3
Internet Connection (primary)	Service	IT Manager	ISP infrastructure	Internal	4
HR Records	Data	HR Manager	Cloud HR system	Restricted	3
Server Room	Premises	IT Manager	Building A, Ground Floor	Restricted	4
Employee Laptops	Hardware	IT Manager	Office / remote	Internal	3
IT Admin Credentials	Data	IT Manager	Password manager	Restricted	5

Focus your initial risk assessment on assets with criticality 4–5. These are your highest-value targets and the ones regulators will expect you to have considered first.

Step 2: Identify Threats and Vulnerabilities

A threat is a potential cause of an incident. A vulnerability is a weakness in an asset or control that a threat could exploit. Use a structured threat catalogue to ensure you have considered all five all-hazards categories. Map each relevant threat to the assets it could affect.

Category	Example Threats	Typical Vulnerabilities Exploited
Natural / Environmental	Flood, fire, extreme heat, power outage, storm damage	No offsite backup, inadequate physical barriers, single power source
Technical / Hardware	Server hardware failure, network equipment fault, software bug, storage failure	No redundancy, end-of-life hardware, missing patches
Human — Accidental	Misconfiguration, accidental deletion, lost/stolen device, unintentional data disclosure	Insufficient training, lack of access controls, no data classification
Human — Deliberate	Ransomware, phishing, credential theft, insider data exfiltration, DDoS, social engineering	Weak passwords, no MFA, unpatched systems, excessive access rights
Supply Chain	Vendor security breach, compromised software update, cloud provider outage, third-party credential misuse	No supplier security requirements, no monitoring of third-party access

You do not need to list every conceivable threat. Identify the threats that are plausible for your organisation, your sector, and your geography. The ENISA Threat Landscape report identifies the most active threat categories in the EU — use it to validate your threat catalogue.

Step 3: Assess Impact

Impact measures the severity of consequences if a threat materialises against an asset. Use a five-level scale and apply it consistently across all risks in your register. Anchor each level to concrete business outcomes — financial figures and downtime thresholds prevent assessors from defaulting to subjective judgements.

Level	Label	Business Consequences
1	Negligible	Minor inconvenience; no measurable financial loss; resolved within 1 hour with no service degradation
2	Minor	Limited disruption under 4 hours; financial impact below €10,000; manageable with existing team
3	Moderate	Significant disruption 4–24 hours; financial loss €10,000–100,000; service degradation affecting customers; potential regulatory notification
4	Major	Severe disruption 24–72 hours; financial loss €100,000–500,000; customer-facing impact; likely supervisory authority interest
5	Critical	Catastrophic disruption over 72 hours; financial loss exceeding €500,000; reputational damage; regulatory action; potential personal liability for management under NIS2 penalty provisions

Consider all dimensions of impact: operational (service availability), financial (direct costs, fines, lost revenue), reputational (customer trust, market position), legal and regulatory (NIS2 penalty exposure, GDPR notification requirements), and safety (relevant for manufacturing, healthcare, and critical infrastructure).

Step 4: Assess Likelihood

Likelihood measures how probable it is that a given threat will materialise within a defined period. Use a consistent 12-month reference period for all assessments. Base your likelihood ratings on observed industry data, sector threat intelligence, and your own incident history — not gut feel.

Level	Label	Definition	Guidance
1	Rare	Expected once in five years or less frequently	Highly sophisticated targeted attack with no prior indicators; major natural disaster in low-risk region
2	Unlikely	Expected once in two to five years	Targeted attack requiring significant attacker resources; physical threat in moderate-risk environment
3	Possible	Expected approximately once per year	Opportunistic attack; typical hardware failure rate; common human error in normal operations
4	Likely	Expected several times per year	Prevalent threats in current landscape (e.g., ransomware targeting SMEs); recurring process failures
5	Almost Certain	Expected monthly or more frequently	Active ongoing campaign against your sector; known exploited vulnerability in unpatched system

Step 5: Calculate Risk Level

Risk level is calculated by multiplying Impact by Likelihood: Risk = Impact × Likelihood. This produces a score from 1 to 25, which maps to four risk levels. The heat map below shows how scores translate to risk levels and required response timescales.

	Impact 1 Negligible	Impact 2 Minor	Impact 3 Moderate	Impact 4 Major	Impact 5 Critical
L5 — Almost Certain	5	10	15	20	25
L4 — Likely	4	8	12	16	20
L3 — Possible	3	6	9	12	15
L2 — Unlikely	2	4	6	8	10
L1 — Rare	1	2	3	4	5

Score	Risk Level	Required Response
1–4	Low	Accept or monitor. Document the decision. Review at next annual assessment.
5–9	Medium	Plan treatment. Implement controls within 6 months. Assign a responsible owner.
10–15	High	Prioritise treatment. Implement controls within 3 months. Escalate to management.
16–25	Critical	Immediate action required. Treat before progressing to lower-priority risks. Board-level awareness.

Step 6: Define Risk Treatment

For each identified risk, you must decide how to treat it. NIS2 and the CIR recognise four treatment options, which can be combined:

• Avoid — eliminate the risk by discontinuing the activity or decommissioning the asset. For example, retiring a legacy system that cannot be patched. This option is only available if the activity itself can be stopped without disrupting essential services.
• Reduce — implement controls that lower the impact, the likelihood, or both. This is the most common treatment. Controls can be technical (endpoint detection and response software, MFA, network segmentation, offsite backup), organisational (policies, staff training, access reviews), or physical (fire suppression, UPS, physical access controls).
• Transfer — shift some or all financial consequences to a third party. Examples: cyber insurance (transfers financial impact), outsourcing to a managed security service provider (transfers operational risk), or contractual liability clauses with suppliers. Note that legal accountability under NIS2 cannot be transferred — management remains responsible even when risk is transferred commercially.
• Accept — management formally decides to accept the residual risk without additional treatment. This is permissible for low-risk items where the cost of controls exceeds the risk value. Acceptance must be documented with explicit management sign-off — undocumented acceptance is treated by supervisory authorities as ignorance, not deliberate decision.

For each risk you decide to treat (Reduce option), your risk register entry must specify: the control or controls you will implement; the person responsible for implementation; the implementation deadline; and the expected residual risk score after the control is in place.

Step 7: Obtain Management Acceptance

This step is non-negotiable. Per Article 20(1) of the NIS2 Directive, the management bodies of in-scope organisations must approve the cybersecurity risk management measures. The risk register and risk treatment plan must be presented to and formally signed off by senior management before implementation begins.

Document the management review session: the date, attendees, risks presented, treatment decisions ratified, and the sign-off itself. This documentation is what supervisory authorities will request in an audit or following an incident. If you cannot produce evidence of management approval, you are exposed to personal liability provisions under NIS2 Article 20 — which may allow member states to hold individual managers accountable, subject to national implementing law and supervisory authority discretion.

Note: The scope of management liability and enforcement mechanisms varies by member state. Some national transposition laws impose stricter personal accountability than the directive’s minimum requirements. Confirm the specific provisions that apply in your jurisdiction.

Worked Example: Manufacturing SME Risk Assessment

Organisation: PressTech Engineering — 75 employees, precision parts manufacturer supplying automotive OEMs across three EU member states. Classified as important entity under NIS2 (manufacturing sector, medium-size threshold met). First formal risk assessment. (Interpretation: this is a fictitious worked example to illustrate the methodology.)

Following the seven steps above, the team identified 23 risks across five asset categories. Three critical and high risks are shown in detail below to illustrate the completed risk register format.

Risk ID	Asset	Threat	Impact	Likelihood	Score	Level	Treatment	Owner	Deadline
R-001	ERP System	Ransomware attack via phishing email	4	4	16	Critical	Reduce	IT Manager	60 days
R-002	OT Production Network	Lateral movement from IT network following initial compromise	5	2	10	High	Reduce	IT Manager & Head of Production	90 days
R-003	Customer Database	Accidental deletion by IT administrator	3	2	6	Medium	Reduce	IT Manager	30 days

R-001: ERP Ransomware — Treatment Detail

The ERP system holds all production orders, supplier records, and financial data. A successful ransomware attack would halt order processing and invoicing immediately. At 75 employees with €18M annual revenue, a 48-hour shutdown represents approximately €150,000 in lost production plus recovery costs.

Treatment controls selected: MFA enforced on all ERP user accounts; endpoint detection and response (EDR) software deployed on all workstations and the ERP server; daily encrypted backup to an offline/offsite location with monthly restore testing; quarterly phishing simulation and staff awareness training. Expected residual risk: Impact 4, Likelihood 2 = Risk 8 (Medium). Rationale: EDR and MFA significantly reduce likelihood; backup testing ensures recovery is viable if attack succeeds.

R-002: OT Network Compromise — Treatment Detail

The production OT network controls CNC machines and quality inspection systems. A compromise that caused incorrect instructions to be sent to machines could result in scrapped production batches, equipment damage, and potential safety incidents. Recovery time from a major OT compromise in manufacturing typically exceeds 72 hours. Even at likelihood 2 (unlikely), the catastrophic impact makes this a High risk requiring priority treatment.

Treatment controls selected: network segmentation creating an air-gapped or tightly firewalled boundary between the corporate IT network and the OT network; industrial firewall deployed at the IT/OT boundary; OT-specific patch management schedule established; all remote vendor access to OT systems restricted to a managed jump server with full session recording. Expected residual risk: Impact 5, Likelihood 1 = Risk 5 (Medium).

R-003: Customer Database Accidental Deletion — Treatment Detail

The customer database contains 2,400 customer records including pricing agreements, order history, and contact details. An accidental deletion by an administrator with broad database permissions could require 12–24 hours to restore and result in data temporarily unavailable to the sales team. This is a medium risk but simple to mitigate.

Treatment controls selected: implement role-based access control so only the database administrator can delete records (not all IT staff); daily automated backup with tested point-in-time restore; change management procedure requiring a second approval for any database modification in production. Expected residual risk: Impact 3, Likelihood 1 = Risk 3 (Low). Controls implemented within 30 days at negligible cost.

Templates You Need

A complete NIS2 risk assessment programme requires three core documents. These are included in the NIS2 templates bundle, pre-populated with NIS2-specific threat catalogues, impact scales, and treatment plan structures.

Document	Template	Purpose
Risk Assessment Methodology	Doc 05	Defines your chosen approach, the 5×5 scales, the four threat categories, and the frequency of review. Must be approved by management before assessment begins. This is the document that proves to a supervisory authority that your risk assessment is systematic, not ad hoc.
Risk Register	Doc 06	Captures every identified risk with: asset, threat, impact score, likelihood score, risk level, treatment decision, responsible owner, implementation deadline, and residual risk. Pre-populated with 40+ common NIS2 threat scenarios across all five all-hazards categories.
Risk Treatment Plan	Doc 10	Tracks implementation of controls for all Medium, High, and Critical risks. Links each control to the risk it addresses, the responsible person, the deadline, and the status. Used for management reporting and supervisory authority audit evidence.

Doc 08 (Acceptance of Residual Risks) provides the management sign-off form required by Article 20(1). Doc 09 (Risk Assessment and Treatment Report) consolidates the full risk assessment into a single board-ready document. Together these five templates constitute a complete, audit-ready risk management programme. To track all other NIS2 security measures alongside your risk assessment, use the NIS2 compliance checklist as your implementation tracker.

Common Mistakes to Avoid

• Choosing a methodology that is too complex for your organisation. ISO 27005 is excellent, but it takes 3–6 months to implement properly in an SME with no dedicated security team. Starting with a 5×5 matrix and completing the assessment in four weeks beats spending six months on a sophisticated methodology that never gets finished.
• Not involving asset owners. The IT manager alone cannot accurately assess the business impact of losing the ERP system, the HR records, or the production OT network. Asset owners — the Finance Director, HR Manager, Head of Production — must be involved in impact scoring. Risk assessments completed in isolation by IT routinely underestimate business impact.
• Assessing risks in isolation. Risks interact. A ransomware attack on the ERP system (R-001) that spreads laterally to the OT network (R-002) is a compound scenario that produces much higher impact than either risk individually. Consider cascading failure paths, especially for your highest-criticality assets.
• Failing to obtain management sign-off. Article 20(1) is explicit. A risk register approved only by the IT manager is not compliant. Management sign-off is a legal requirement, not a formality. If your organisation has a supervisory board, the risk register must be presented to it.
• Treating risk assessment as a one-off exercise. A risk assessment completed in 2025 is not compliant in 2026 if you have deployed new cloud services, experienced an incident, or if the threat landscape has materially changed. Build an annual review into your security programme calendar from the start.
• Not updating after significant changes. Adding a new ERP system, migrating to a new cloud provider, onboarding a major new supplier with system access, or acquiring another company — all of these trigger a partial re-assessment under NIS2. Waiting for the annual review in these circumstances leaves a compliance gap.

Frequently Asked Questions

How often must we repeat the NIS2 risk assessment?

At a minimum, annually. The CIR and ENISA guidance also require a review after any significant change to your organisation or systems — including deploying new critical systems, experiencing a security incident, or material changes to your supply chain. Build a formal annual review into your security programme calendar, plus an event-triggered partial review process for significant changes. National transposition laws may impose additional frequency requirements — check with your competent authority.

Do we need to use a specific risk assessment methodology for NIS2?

No. NIS2 and the CIR are methodology-agnostic. Your risk assessment must be documented, systematic, and proportionate to your organisation’s size and risk profile — but you choose the approach. What matters is that your chosen methodology is defined in a documented Risk Assessment Methodology document (Doc 05) before the assessment begins.

Can we conduct our NIS2 risk assessment in a spreadsheet?

Yes. A spreadsheet is entirely sufficient for SMEs. The NIS2 Directive and CIR require a documented, systematic, and repeatable process — they do not require specialist risk management software. A well-structured Excel risk register that captures assets, threats, impact and likelihood scores, risk levels, and treatment decisions meets all documentation requirements. The NIS2 templates bundle provides pre-built Excel templates for this purpose.

What qualifies as an all-hazards approach under NIS2?

An all-hazards approach means your risk assessment considers all categories of threat that could cause an incident — not just cyber threats. Physical and environmental threats, human accidental threats, human deliberate threats, and supply chain threats must all be explicitly considered. A risk assessment covering only IT or cyber risks does not satisfy NIS2 Article 21(1).

Do we need external consultants to complete a NIS2 risk assessment?

No. External consultants are not required. An SME with an IT manager and engaged business owners can complete a compliant risk assessment using structured templates and a documented methodology. External support adds value if your organisation has no internal security expertise, operates complex OT environments, or is pursuing simultaneous ISO 27001 certification. For most SMEs starting a first formal assessment, the NIS2 template bundle and this guide are sufficient.

Sources

1. European Parliament and Council. Directive (EU) 2022/2555 on Measures for a High Common Level of Cybersecurity (NIS2 Directive) — Articles 20 and 21. EUR-Lex
2. European Commission. Implementing Regulation (EU) 2024/2690 — Technical and Methodological Requirements for Cybersecurity Risk Management (Annex Section 2.1). EUR-Lex
3. ENISA. NIS2 Technical Implementation Guidance on Cybersecurity Risk Management Measures, Version 1.0. ENISA
4. ENISA. ENISA Threat Landscape 2024 — Annual Report on Cybersecurity Threats in the EU. ENISA
5. ISO/IEC. ISO/IEC 27005:2022 — Guidance on Managing Information Security Risks. ISO