Art.21.1NIS2Last reviewed 20 September 2026

NIS2 Art.21.1: Cybersecurity Risk Management Framework

Article 21(1) sets the basis for cybersecurity risk management: measures must address the risks to the systems used in operations and service delivery, and reduce the effects of incidents. Start with the services people depend on. An inventory of laptops and servers is useful, but it will not reveal a recovery dependency on a supplier or a control system missing from the IT team's scope.

Start a 10-question NIS2 readiness check to identify priorities. Use the reference guides and workbook for a wider review.

Start my free NIS2 assessmentNo account · No credit card · Save when useful

Requirement summary

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, and to prevent or minimise the impact of incidents on recipients of their services and on other services.

Check the source wording and scope in NIS2 Directive on EUR-Lex. The guidance below explains how to approach a review.

In Plain Language

A useful review connects a risk to an operating decision. If loss of a particular identity service would stop production access, establish how that dependency is protected and how recovery would work. Keep the assumptions visible: which users are affected, how long the service can be unavailable and whether the recovery procedure has been tested. Those details let management decide what needs attention.

Proportionality is a reasoned choice, not an exemption for a small security budget. Consider exposure, size, the likelihood and severity of incidents, their wider effects and the available measures. Record why the selected approach is suitable. Management approval and oversight are addressed in Article 20; effectiveness assessment also appears among the Article 21(2) measures. Read these provisions together and check the national implementing law.

The practical test is whether your assessment changes what the organisation does. A register that lists risks but has no owner, decision or evidence of follow-up is difficult to use for that purpose.

From the Auditor's Bench

Reading risk registers is bread and butter for an auditor. In my broader business risk reviews, I expect anything capable of shutting down or seriously disrupting the company to be recognised, with a strategy for dealing with it. That includes dependencies the company feels comfortable with.
One company we audited had a business model heavily dependent on Google. They had a friendly relationship with the Google team, were invited to events and felt the relationship was excellent. We flagged the dependency as a risk, much to the company's dismay.
Three months after our audit, a single management decision at Google eliminated the market the company operated in. The company did not survive. That reliance had not been in its risk register, and it had no plan B.
This was a business-model dependency, rather than a cybersecurity incident. The lesson I take from it is to look beyond confidence in a relationship and examine the dependency itself. If another organisation can make a decision that stops your business, I want to see that risk recognised and a credible response considered. A good relationship does not give you control over the other party's decisions.

How to Implement

Define the review boundary in terms of services, systems and dependencies. Include cloud and outsourced services, operational technology where relevant, and the people needed to run or recover them. Record any excluded area and why it is outside the scope. Check the boundary with operations and service owners, rather than relying only on an IT inventory.

Agree a repeatable way to describe and assess risks. State the event, affected service and consequence before assigning a rating. Define what the scale means and who can accept a risk. A recognised methodology can help, but the directive does not prescribe one universal scoring model. Avoid giving a risk a precise numerical value when the underlying assumptions are uncertain.

For each material risk, document the treatment decision, owner and next review point. Distinguish existing safeguards from planned work. If a recovery control is part of the treatment, retain the test result as well as the plan. If a supplier is responsible, identify the evidence or contractual commitment on which you rely and what remains your responsibility.

Bring unresolved decisions to management with a clear request: funding, a deadline, an owner or explicit acceptance within the applicable rules. Record the decision and follow the action to completion. Revisit the assessment after material changes or incidents, and choose a scheduled review frequency that reflects the service's risks. Use effectiveness checks to establish whether the treatment works; closing a task is not enough on its own.

Evidence to review

Scope record identifying services, systems, dependencies and exclusions
Risk assessment method and defined decision authority
Risk register with assumptions, owners and treatment decisions
Management approval and follow-up records
Evidence that selected measures operate, such as restore tests or access reviews
Review records showing how material changes and incidents affected the assessment

Common Mistakes

The inventory covers IT assets but omits service and supplier dependencies
Risk ratings have no explanation or inconsistent meanings between reviewers
Planned safeguards are recorded as if they already operate
Management receives a status report without the decisions it needs to make

Related Controls Across Frameworks

Framework	Control ID	Relationship
ISO 27001	ISO 27001 A.5.1: Policies for information security	Related
SOC 2	SOC 2 CC3.1: COSO Principle 6: Specifies Suitable Objectives	Related

Frequently Asked Questions

What does 'proportionate' mean in the context of NIS2 risk management?

It means your measures should be reasonable given your organisation's size, the likelihood and severity of potential incidents, the criticality of the services you provide, and current best practices. A small essential entity does not need the same security budget as a large enterprise, but it still needs a structured, risk-based approach. Proportionality is about demonstrating thoughtful decision-making, not spending the least possible.

Do we need to use a specific risk management standard?

NIS2 does not mandate a particular standard, but picking a recognised framework like ISO 27005 or the NIST RMF is strongly recommended. It shows rigour, gives you a repeatable process, and makes compliance audits significantly smoother than defending a homegrown approach.

Track NIS2 compliance in one place

Start a 10-question NIS2 readiness check to identify priorities. Use the reference guides and workbook for a wider review.

Start Free Assessment

Start without an account · Sign up only to save

Start my free NIS2 assessment