NIS2 guide

NIS2 risk assessment: a practical method for small entities

Every NIS2 security measure is meant to be "appropriate and proportionate" to your risks. You cannot show that without first writing the risks down. That is why the first item in Article 21's list of measures is "policies on risk analysis and information system security". This guide explains what the Directive requires, what the more detailed EU rules for digital providers add, a method a small organisation can run in an afternoon, how often to repeat it, and what to keep as evidence.

Article numbers refer to Directive (EU) 2022/2555 (NIS2) unless the text says otherwise. "The Regulation" means Commission Implementing Regulation (EU) 2024/2690, which sets out the detail of the Article 21 measures for certain digital providers.

Last checked 10 November 2026 against the texts of the Directive and of Implementing Regulation (EU) 2024/2690 on EUR-Lex. This is general information, not legal advice. Your national law and authority may set more detailed rules.

1. The short answer

Article 21(1) requires measures that ensure "a level of security of network and information systems appropriate to the risks posed". Point (a) of Article 21(2) requires "policies on risk analysis and information system security".
The Directive does not prescribe a method. Any reasonable, written method works if it finds your risks, ranks them and leads to decisions.
For ten types of digital provider plus trust service providers, the Regulation turns this into concrete steps: a documented method, risk criteria, a risk treatment plan, management acceptance of what is left, and a review "at least annually".
For everyone else, the Regulation is a useful model of a complete risk process. A small entity can meet it with a one‑page method, a risk register and a signed approval.
Your management body must approve the measures and oversee them (Article 20(1)), so management, not only IT, signs off the result.

2. What Article 21 requires

The duty. Essential and important entities must "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, and to prevent or minimise the impact of incidents on recipients of their services and on other services" (Article 21(1)). A risk assessment is how you decide which measures are appropriate.

Proportionality. The measures must take into account "the state-of-the-art", relevant European and international standards where they apply, and "the cost of implementation". When judging proportionality, "due account shall be taken of the degree of the entity's exposure to risks, the entity's size and the likelihood of occurrence of incidents and their severity, including their societal and economic impact" (Article 21(1), second subparagraph). Likelihood and severity are the two scores in almost every risk method, so the Directive's own test points to a likelihood‑and‑impact assessment.

All hazards. The measures "shall be based on an all‑hazards approach that aims to protect network and information systems and the physical environment of those systems from incidents" (Article 21(2)). Recital 79 gives examples: "theft, fire, flood, telecommunication or power failures, or unauthorised physical access". A risk assessment that lists only hackers misses part of the duty.

Point (a). The first of the ten minimum measures is "policies on risk analysis and information system security" (Article 21(2)(a)). Recital 77 calls for "a culture of risk management, involving risk assessments and the implementation of cybersecurity risk-management measures appropriate to the risks faced". Our Article 21 checklist lists what point (a) needs alongside the other nine measures; this guide goes into the risk analysis part in depth.

Fixing gaps. An entity that finds it does not comply with the Article 21(2) measures must take "without undue delay, all necessary, appropriate and proportionate corrective measures" (Article 21(4)). Your risk treatment plan is where those corrective measures are recorded.

Management. Management bodies "approve the cybersecurity risk-management measures", "oversee its implementation" and "can be held liable" for infringements of Article 21 (Article 20(1)). Their members must follow training so that they can "identify risks and assess cybersecurity risk-management practices" (Article 20(2)). See NIS2 fines and management liability for what that liability means.

3. What Regulation 2024/2690 adds

Article 21(5) told the Commission to set the "technical and the methodological requirements" for a group of digital providers. It did so in Implementing Regulation (EU) 2024/2690 of 17 October 2024. It applies directly to DNS service providers, TLD name registries, cloud computing, data centre and content delivery network providers, managed service providers, managed security service providers, online marketplaces, online search engines, social networking platforms and trust service providers (Regulation, Article 1). If you are one of them, section 2 of its Annex is binding on you. Our guide NIS2 for managed service providers covers who counts.

Point 2.1.1 of the Annex says these entities "shall perform and document risk assessments and, based on the results, establish, implement and monitor a risk treatment plan". Risk assessment results and residual risks "shall be accepted by management bodies or, where applicable, by persons who are accountable and have the authority to manage risks", with "adequate reporting to the management bodies". Point 2.1.2 then lists what the process must do:

"follow a risk management methodology";
"establish the risk tolerance level in accordance with the risk appetite" of the entity;
"establish and maintain relevant risk criteria";
identify and document the risks, "in particular in relation to third parties", including risks to availability, integrity, authenticity and confidentiality and "the identification of single point of failures";
analyse the risks, "including threat, likelihood, impact, and risk level, taking into account cyber threat intelligence and vulnerabilities";
evaluate the risks against the criteria;
"identify and prioritise appropriate risk treatment options and measures";
"continuously monitor the implementation of the risk treatment measures";
name who implements each measure and when;
record the chosen measures in a risk treatment plan and "the reasons justifying the acceptance of residual risks in a comprehensible manner".

When choosing treatments, the entity weighs the assessment results, how well existing measures work, "the cost of implementation in relation to the expected benefit", its asset classification and its business impact analysis (point 2.1.3). Two neighbouring duties complete the picture: compliance monitoring, which reports the state of security to management at planned intervals (point 2.2), and an independent review of the whole approach (point 2.3). Where an entity is too small to have a reviewer outside the line of authority, it must "put in place alternative measures to guarantee the impartiality of the reviews" (point 2.3.2).

The Regulation also builds in proportionality. Entities must take account of their exposure, size and the likelihood and severity of incidents (Article 2(2)). Where a requirement applies only "where appropriate", "where applicable" or "to the extent feasible" and an entity decides it does not fit, it must "document its reasoning" (Article 2(2), second subparagraph).

If you are not one of those providers, the Regulation does not bind you, and your national law decides the detail. Its list is still a useful checklist, because it spells out the steps any sound risk method has.

4. A method for a small entity

This is our suggested method, built to cover each step in point 2.1.2 without needing a risk specialist. Write it down on one page; that page is your "risk management methodology". The ISO/IEC 27001 and 27005 standards describe the same cycle in more depth, and Article 25 asks countries to encourage such standards, but you do not need to buy them to start.

Set the scope. List the services you provide and the systems and suppliers they depend on: email and files, the business application, the network and internet line, laptops and phones, backups, and the IT provider and cloud services behind them. An asset list from your asset management work is the natural starting point.
Agree the scales and the tolerance. Score likelihood and impact from 1 to 5 using the table below. Multiply them for a risk score from 1 to 25. Decide in advance what each band means: for example, 15 or more needs a treatment plan approved by a director, 8 to 14 needs a decision with a written reason, and 7 or less may be accepted. That decision is your risk tolerance and your risk criteria (points 2.1.2(b) and (c)).
Identify the risks. For each important asset, ask what could go wrong, what weakness would let it happen and what already stops it. Cover the all‑hazards list: attacks, mistakes, supplier failures, theft, fire, flood, power and line failures. Look for single points of failure: one person who knows the admin password, one internet line, one backup disk.
Analyse. Score each risk's likelihood and impact as things stand today, with the controls you actually have. Use what you know about current threats, such as warnings from your national CSIRT and your own incident log.
Evaluate. Sort the register by score and put each risk in its band.
Treat. For each risk above your tolerance, choose one option: reduce it with a measure, avoid it by stopping the activity, transfer part of it (insurance or a contract), or accept it with a reason. Give every action an owner and a date (point 2.1.2(i)).
Estimate what is left. Score each risk again as if the treatment were done. That is the residual risk.
Get it accepted. Present the register, the treatment plan and the residual risks to your directors or partners. Record that they accepted them, with the date.

Score	Likelihood	Impact
1	Not expected in the next 5 years	Negligible: no effect on customers, no real cost
2	Possible once in 2 to 5 years	Minor: a few hours of disruption, small cost
3	Likely about once a year	Moderate: a day of disruption, some customers affected
4	Several times a year	Major: several days of disruption, data lost or exposed, an incident you may have to report
5	Monthly or more, or you are being targeted	Severe: threatens the business or causes serious harm to the people who use your services

Put money figures next to the impact levels that suit your size; a loss that is minor for a firm of 200 people can be severe for a firm of 15. Keep the scales the same from year to year so that scores can be compared.

Plan for about two hours. The person who runs IT leads it, a director attends because accepting risk is a management decision, and someone from each main part of the business says what would hurt them. Ten to twenty risks is a normal register for a small organisation; more than forty usually means the rows are too detailed.

5. A worked example

Four rows from a register for an imagined 25‑person firm that uses a cloud office suite, a file server in the office and an outside IT provider. The figures are ours, for illustration.

Risk	Score now	Treatment, owner, date	Residual
Phishing leads to an email account takeover and a false payment request	4 × 4 = 16, high (MFA only on admin accounts)	Reduce: MFA on every account and a call‑back rule for changed bank details. Office manager, 31 January	2 × 4 = 8, accepted by the managing director with a reason
Ransomware encrypts the file server and the backup disk attached to it	3 × 5 = 15, high	Reduce: a backup copy that is offline or cannot be changed, and a restore test every quarter. IT provider, 28 February	2 × 3 = 6, low
The IT provider is breached and its remote access tool is used against us	2 × 5 = 10, medium (contract has no security terms)	Reduce and transfer: MFA on the provider's access, a security clause and a questionnaire. Managing director, at contract renewal	2 × 4 = 8, accepted with a reason
The office's only internet line fails	3 × 2 = 6, low	Accept: staff can work from home and the business application is in the cloud. Reason recorded	6, low

Each treatment links back to another Article 21 measure: MFA to point (j), backups to point (c), the supplier clause to point (d) and Article 21(3). That is how the risk assessment drives the rest of your programme. For the supplier side, see answering a customer's NIS2 security questionnaire, which shows the same risk from the other end.

6. How often to do it

The Directive sets no frequency. The Regulation does, for the providers it covers: review and update the risk assessment results and the risk treatment plan "at planned intervals and at least annually, and when significant changes to operations or risks or significant incidents occur" (point 2.1.4). The security policy follows the same rhythm (point 1.1.2). If you are outside the Regulation, a yearly review with the same triggers is still a sensible default, because it matches the rule the EU set for the providers it covers.

Treat these as triggers for an early review:

a significant incident, or any incident that showed a risk you had scored too low (see NIS2 incident reporting);
a new critical system, cloud service or IT provider;
a new site, service line, merger or large change in staff numbers;
a public warning about a threat to software you use.

Between full reviews, look at the register for ten minutes each quarter: close finished actions, chase late ones and add anything new. Point 2.1.2(h) asks the providers it covers to "continuously monitor" their treatment measures; a quarterly check is a simple way to show that.

7. What to document

Supervisors can ask essential entities, and important entities after an indication of non‑compliance, for "documented cybersecurity policies" and for "evidence of implementation of cybersecurity policies" (Article 32(2)(e) and (g); Article 33(2)(d) and (f)). For the risk assessment, keep:

The one‑page method: scope, scales, risk tolerance and the score bands.
The risk register: each risk, its owner, the current score and the date it was last reviewed.
The risk treatment plan: each action, its owner, due date and status.
The accepted residual risks, each with the reason in plain words.
Management's acceptance with the date: minutes or a signed note.
A record of each review and what triggered it.

A spreadsheet and a dated email are enough for a small entity. What matters is that someone outside the business can follow the trail from a risk to a decision to a measure.

8. Common mistakes

Doing it once. A register last touched two years ago shows the risk process has stopped.
Only cyber attacks. The all‑hazards duty also covers power, fire, flood, theft and supplier failures.
Missing suppliers. The Regulation singles out risks "in relation to third parties" (point 2.1.2(d)). Your IT provider and main cloud services belong in the register.
Treatments without owners or dates. An action nobody owns is not a plan.
Silent acceptance. A high risk that management never saw has not been accepted. Write down who accepted it and why.
A method nobody can repeat. If next year's scorer would rank the same risk differently, the scales need clearer words.

9. Where to start

Book two hours with a director and whoever runs your IT. Bring a list of your systems and suppliers. Agree the scales and bands first, then fill in ten to twenty rows, and finish by giving every high risk an owner and a date. Send a short summary afterwards and ask the director to reply to confirm acceptance; that email is your first piece of evidence.

Our NIS2 Small-Entity Compliance Kit has this ready: its Risk Management Procedure sets out the two‑hour workshop, the 1‑to‑5 scales, the score bands and a list of threats to prompt discussion, and its Risk Register sheet has drop‑down lists and example rows. The Management Review Minutes template records the yearly acceptance.

10. Sources

Directive (EU) 2022/2555 (NIS2), EUR-Lex: recitals 77 to 82; Articles 20, 21, 25, 32 and 33.
Commission Implementing Regulation (EU) 2024/2690, EUR-Lex: Articles 1 and 2; Annex points 1.1.2, 2.1 to 2.3 and 4.1.3.