Applies to: EU-established entities that fall in scope of NIS2 as essential or important entities, and the infrastructure teams that serve them. This is not legal advice — it is an infrastructure-focused reading of Article 21’s risk-management measures, intended to be operationally useful. Use it alongside formal legal review, not instead of it.
Why this matters
NIS2 — the Network and Information Security Directive, Directive (EU) 2022/2555 — is the regulation a lot of sysadmins are told to “comply with” without ever being told what that means at the level of files, configurations, and procedures. The directive is short by EU standards and intentionally outcome-focused: it lists ten risk-management measure areas in Article 21(2) and asks each entity to implement “appropriate and proportionate” measures in each.
This guide does two things:
- Restates each of the ten measures in plain language.
- Lists, for each, the concrete infrastructure work and documentation that satisfies it — pointing at the implementation guides on this site.
The aim is not to produce a checklist that survives an external audit on its own. It is to remove the ambiguity that paralyses small teams when they read Article 21 for the first time.
Am I in scope?
Briefly:
- Essential entities — the larger / more critical operators in sectors listed in Annex I (energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management B2B, public administration, space).
- Important entities — operators in Annex II sectors (postal, waste management, chemicals, food, manufacturing, digital providers, research) and smaller operators in Annex I sectors.
- Size thresholds — generally, medium-sized (50+ employees, €10m+ turnover) or above. Some sectors apply regardless of size.
A more reliable, jurisdiction-aware assessment is what the NIS2 applicability checker (planned) at tools.stackharden.com is for. For formal classification, talk to qualified counsel — supervisory authorities differ in how they read the marginal cases.
The ten measures of Article 21(2), translated
(a) Policies on risk analysis and information system security
Plain reading. You must have a written information security policy and a written risk-analysis methodology, both approved by management.
What this looks like infra-side. A documented baseline (this site’s Ubuntu / RHEL guides are templates), a documented process for deviating from it, and a risk register that lists the infrastructure-level risks the team owns.
(b) Incident handling
Plain reading. You must be able to detect, respond to, and recover from security incidents.
What this looks like infra-side. An on-call rotation, logging that makes detection possible (see (c) and (g)), a written incident-response playbook, post-incident review documents. The breach-readiness section of the privacy guide covers the GDPR side; the NIS2 side adds significant incident reporting deadlines (see “Reporting” below).
(c) Business continuity, backups, crisis management
Plain reading. You must be able to keep operating — or to recover quickly — when something fails.
What this looks like infra-side. Encrypted off-site backups
(postgres-backups planned; encrypted-backups-restic in backlog),
tested restoration drills, documented RPO and RTO targets, and a
written crisis-management plan that names roles, not just people.
(d) Supply chain security
Plain reading. You must understand the security posture of your suppliers, particularly the ones with access to your systems.
What this looks like infra-side. A processor / supplier register (the table in the privacy-by-design guide is a starting point), with each entry recording: what they touch, where they operate, and the security commitments in their DPA / contract.
(e) Security in network and information systems acquisition, development and maintenance
Plain reading. Buy and build systems securely. Patch and maintain them. Disclose and fix vulnerabilities.
What this looks like infra-side. A documented hardening baseline
applied to every new system (the
Ubuntu /
RHEL baselines), automated patching
(unattended-upgrades on Debian-family /
dnf-automatic on RHEL-family), and a
vulnerability-handling process — including for components you operate
(WordPress plugins, OS packages, language runtimes).
(f) Policies and procedures to assess the effectiveness of risk-management measures
Plain reading. You must check that your own controls actually work.
What this looks like infra-side. Periodic baseline scans
(lynis,
oscap), restoration drills, tabletop
exercises, and external penetration testing for in-scope services. The
results feed back into the risk register from (a).
(g) Basic cyber hygiene practices and cybersecurity training
Plain reading. Your people are part of the system. Train them and enforce hygiene.
What this looks like infra-side. Documented onboarding /
offboarding procedures, mandatory MFA on every privileged interface,
key rotation policies, secrets-manager use, and recurring training. The
SSH hardening guide is the technical half;
documented quarterly authorized_keys reviews and an offboarding
checklist are the organisational half.
(h) Policies and procedures regarding the use of cryptography and, where appropriate, encryption
Plain reading. When you use cryptography, do it consistently and correctly. Where data needs to be encrypted, encrypt it.
What this looks like infra-side. A documented cryptographic baseline (Nginx TLS is the public-facing piece; PostgreSQL TLS, Redis TLS, SSH crypto from the same guides extend it internally). At-rest encryption for storage. Encrypted backups. Key-management documentation — where keys live, who has access, how they rotate.
(i) Human resources security, access control policies and asset management
Plain reading. Know who has access to what, why, and how that access ends.
What this looks like infra-side. Per-human accounts (no shared admin or root logins), least-privilege grants in every system (PostgreSQL, Redis, WordPress), an asset inventory that lists every server and what it runs, and a documented joiners/movers/leavers process that includes credential revocation.
(j) Multi-factor authentication or continuous authentication, secured communications, and emergency communication
Plain reading. Use MFA where it matters. Encrypt communications. Have a way to coordinate during an incident when normal channels are down.
What this looks like infra-side. MFA on every administrative interface (cloud provider portals, code repositories, CI/CD, WordPress admin, database admin tools). TLS for everything that crosses a network boundary. An out-of-band incident comms channel — Signal group, designated phone numbers, escalation list — that does not depend on the systems an incident might have taken down.
Reporting obligations (Article 23)
These are not infrastructure measures, but they shape what infra teams must be ready to do. For a significant incident:
| Deadline | Action |
|---|---|
| 24 hours | “Early warning” notification to the competent authority — initial assessment, indication of whether the incident is suspected to be caused by unlawful or malicious acts. |
| 72 hours | Update to the early warning, with initial assessment of severity and impact, and indicators of compromise where available. |
| 1 month | Final report — including detailed description, root cause, mitigation, and any cross-border impact. |
“Significant” is defined in Article 23(3): a) operational disruption / financial loss above a threshold; or b) impact on others. National transpositions vary in the thresholds. Document the timeline you would follow before you need it; the 24-hour window starts at awareness, not at containment.
Documentation expected by an auditor
A NIS2 auditor will typically want to see:
- Risk register. Linked to (a).
- Information security policy. Approved by management.
- Documented baseline. This site’s hardening guides are an acceptable starting point if applied and dated.
- Asset inventory. What hosts, what runs on them, what data they process.
- Processor / supplier register. Linked to (d).
- Incident-response playbook. Linked to (b) and Article 23.
- Training records. Linked to (g).
- Audit log retention policy. And evidence of compliance with it.
- Backup and restoration records. Including drill results.
Most of these documents can be short. They cannot be missing.
Common misconceptions
“We have ISO 27001 so we’re done”
ISO 27001 and NIS2 overlap heavily, but they are not interchangeable. ISO 27001 is a framework; NIS2 is a directive with specific reporting and governance obligations. A current ISO 27001 certification is strong evidence for (a)–(i) but does not automatically satisfy Article 23.
“We’re a small company so it doesn’t apply”
Size is one factor; sector is another. A small managed service provider can be in scope as an important entity regardless of headcount. Confirm via formal review.
“We can outsource compliance to our hosting provider”
Hosting providers are processors. They can provide the underlying infrastructure attestations (SOC 2, ISO 27001) and a DPA, but the controller — you — remains responsible for the risk-management measures at the application and operational layer. NIS2 does not let you delegate compliance.
“Reporting after 72 hours is fine if we’re not sure”
The 24-hour and 72-hour windows are obligations to report what you know at the time. A correct early warning saying “we are still investigating” is acceptable. A late report because you wanted to investigate first is not.
Companion checklist
A technical self-assessment mapping each Article 21(2) measure to
specific, verifiable checks on the box lives at
/checklist/nis2-readiness/ — commands,
config flags, and file checks for hardening, cryptography, access
control, logging, backups, and external verification, with a short
closing section for the governance and reporting obligations that do
not appear on a host.
What this guide deliberately does not cover
- Article 20 — governance / management body obligations. Flag to leadership.
- Sector-specific obligations — Annex I/II sectors may have additional requirements beyond the horizontal NIS2 baseline.
- National transposition details — every Member State has its own implementing law with its own thresholds and authorities. Use this guide as a baseline; map your obligations against your national competent authority’s published guidance.