SentriKat is live, launch pricing and hands-on onboarding for founding customers. Get started
All articles

NIS2 Risk Analysis & Security Policies (Article 21(2)(a)): The Foundation

NIS2 Article 21(2)(a) requires a management-approved security policy and a maintained risk assessment. Here's what 'good enough' looks like for an essential or important entity, without the enterprise bureaucracy.

Denis Sota · · 3 min read

Article 21(2)(a) is listed first for a reason: risk analysis and information-system security policies are the foundation every other NIS2 measure stands on. If you can’t say what you’re protecting, from what, and who decided, the other nine measures are just disconnected controls.

This is general guidance, not legal advice. NIS2 is transposed nationally (in Italy via D.Lgs. 138/2024, administered by the ACN). Confirm the exact obligations with your national authority.

What the measure actually asks for

Two things, plainly:

  1. An information-security policy, approved by management. A document that states how your organisation manages cyber risk, scope, responsibilities, acceptable use, and the high-level rules everyone must follow. The “approved by management” part matters: NIS2 makes management bodies accountable, so leadership has to see, understand, and sign off on it.
  2. A risk assessment that is maintained. A periodic, documented exercise that identifies what could go wrong (threats), how likely it is, and the impact, so you can prioritise. “Maintained” means it isn’t a one-off PDF from two years ago; it’s reviewed when things change.

What “good enough” looks like for an SMB

You don’t need a 90-page ISMS to satisfy this. A defensible baseline is:

  • A short, readable policy (a handful of pages) covering scope, roles, access rules, acceptable use, incident reporting, and review cadence, dated and signed by a director.
  • An asset-aware risk register: your important systems and data, the main threats to each, a simple likelihood × impact rating, and the treatment decision (mitigate / accept / transfer). A spreadsheet is fine to start.
  • A review rhythm: at minimum annually, plus whenever you add a major system, change suppliers, or after any incident.

The goal isn’t paperwork for its own sake, it’s that decisions about risk are made deliberately and written down, so an auditor (and your own team) can follow the reasoning.

Where vulnerability data feeds the risk picture

A risk assessment is only as current as the information behind it. The fastest-moving input is your technical exposure: which of your systems carry vulnerabilities attackers are actively exploiting. Feeding that live signal into your risk register keeps the “likelihood” column honest instead of guessed. This is the narrow, honest place SentriKat helps, exploited-first vulnerability management gives you a current, evidence-backed view of technical risk that plugs straight into your Article 21 documentation.

Start here

Write the one-page policy, get it signed, build a 20-row risk register of your most important systems, and put a recurring annual review in the calendar. That single afternoon moves you from “no documented risk management” to a defensible foundation.

Not sure which of the ten NIS2 measures you’re weakest on? The free, anonymous NIS2/DORA readiness check gives you an indicative per-domain gap analysis in about five minutes.

Ready to automate your vulnerability management?

Deploy SentriKat on-premises in minutes. Track CISA KEV vulnerabilities, generate NIS2 compliance reports, and protect your infrastructure.

Request a Demo