Article 21(1) of Directive (EU) 2022/2555 requires essential and important entities to take "appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems". Article 21(2) lists the ten categories those measures must cover.
The phrase that does the heavy lifting is risk-based. Recital 79 of the directive frames the entire chapter as a risk-management exercise: measures must be calibrated to the risk faced by the entity and its services. The artefact that operationalises this calibration is the risk register.
Most NIS2-scope entities already keep one. Most do not, in their current form, pass the regulator's smell test. The gap is rarely the volume of risks logged — it is the absence of five specific fields that an inspector expects to find. This is the retrofit guide.
Field 1 — Asset, scoped to the NIS2 perimeter
Every risk register entry needs an asset — the thing at risk. For NIS2 purposes, the asset must be tied to the entity's NIS2 perimeter: the network and information systems that support the services the entity provides as an essential or important entity.
A risk on the office printer fleet is not in the perimeter. A risk on the SIEM that monitors the production payment platform is. The distinction is not academic — it is what allows the inspector to map the register against the entity's classification under Article 3 and the sector-specific scoping rules.
The retrofit: add a column "NIS2 scope" to your existing register. Mark each entry as In scope, Out of scope, or Adjacent (touches the perimeter but does not host service data). Inspectors look at the in-scope subset; everything else is informative only.
Field 2 — Threat and vulnerability, paired
NIS2 does not name a methodology. ENISA's published risk management framework, drawing on ISO/IEC 27005 and ISO 31000, treats risk as a threat–vulnerability pair: a threat actor (or natural event) that could exploit a specific vulnerability, leading to harm.
Logging "ransomware" as a risk is not enough. The register entry should pair it with the vulnerability it would exploit — for example "ransomware exploiting unpatched edge VPN appliance" — because the treatment differs entirely from "ransomware delivered via phishing of finance staff".
The retrofit: split your existing single-column "risk" into two columns, threat and vulnerability. Some entries will collapse cleanly; some will fan out into two or three. Both outcomes are signs the register is now usable.
Field 3 — Likelihood × impact, with method documented
Article 21(2)(a) explicitly requires "policies on risk analysis". Analysis implies a method. The register must show, for each entry, an estimated likelihood and impact, derived from a documented method that does not change between entries.
Three methods are accepted by European national competent authorities:
- A 5×5 qualitative matrix (Very Low → Very High on each axis), with band definitions written down once for the whole register.
- A 3-band quantitative method for impact (financial loss in € bands) combined with qualitative likelihood.
- A FAIR-aligned method for organisations with the maturity to support it.
What is not accepted: a single "criticality" column with no derivation. The retrofit: pick one of the three methods, write its definitions on a single page that lives next to the register, and re-score every existing entry against the chosen method. Yes, this is tedious. It is also the smallest atomic action that lifts the register from "list" to "analysis".
Field 4 — Treatment, with owner and due date
Recital 78 of the directive frames the choice of measures as proportionate to the risk. In register terms, this is the treatment decision: Accept, Mitigate, Transfer, or Avoid.
For Mitigate — the most common — the register must record:
- the measure being deployed (mapped to Article 21(2), see field 5),
- the owner (a named role, not a team),
- the due date for the measure to be in place,
- the residual risk expected after the measure (re-scored on the same likelihood × impact method).
For Accept, the entry must show the acceptance authority — the named role with the seniority to formally accept the residual risk on behalf of the entity. For most NIS2-scope risks, this is the management body itself, per Article 20(1).
The retrofit: add columns Treatment, Owner, Due date, Residual. For pre-existing entries with no treatment, mark them Pending review and put them on the next risk committee agenda.
Field 5 — Article 21(2) category mapping
This is the field that turns a generic register into a NIS2 register. Article 21(2) lists ten categories of measures:
- policies on risk analysis and information system security,
- incident handling,
- business continuity (backups, disaster recovery, crisis management),
- supply chain security,
- security in network and information systems acquisition, development and maintenance,
- policies and procedures to assess effectiveness,
- basic cyber hygiene practices and cybersecurity training,
- cryptography,
- human resources security, access control policies, asset management,
- multi-factor authentication, secured voice/video/text communications, secure emergency communications.
Every register entry in the NIS2 scope should map to at least one of those categories. The mapping is what lets the inspector verify, in one pass, that the register exercises all ten categories — and conversely, that none of the ten is silent.
The retrofit: add a final column "Article 21(2) category". Tag each in-scope entry. If a category has zero entries, that is itself a finding to bring to the next risk committee.
What good looks like
Across the published inspection notes from European national competent authorities, three signals consistently come up:
- The register has a dated version history. Each version is signed off — typically quarterly — by the security committee, with the management body informed.
- Every in-scope entry has the five fields above, populated. Empty cells are a red flag; "TBD" with a due date is acceptable.
- The mapping to Article 21(2) categories shows non-zero coverage of all ten. A register where category 7 (basic cyber hygiene) is empty is, in regulator terms, a register that has not actually been done.
The register is not the security programme. It is the document that proves the security programme exists, is calibrated to risk, and is owned at the right level. The retrofit, done well, takes a competent team three to four weeks. The alternative, done at the moment of inspection, takes a regulatory finding.
Sources
- Directive (EU) 2022/2555, Article 21(1) and 21(2) (cybersecurity risk-management measures).
- Directive (EU) 2022/2555, recitals 78 and 79 (risk-based, proportionate measures).
- Directive (EU) 2022/2555, Article 20(1) (management body approval and oversight).
- ISO/IEC 27005 (information security risk management) and ISO 31000 (risk management — principles and guidelines).
- ENISA, Risk Management Methodology and the NIS2 Implementation Guidance.
- Published guidance from national competent authorities: ANSSI (FR), BSI (DE), INCIBE (ES), ACN (IT), NCSC-IE (IE).
