NIS2 Art. 21: the 10 measures, translated into technical controls

Article 21 of Directive (EU) 2022/2555 requires essential and important entities to take appropriate and proportionate technical, operational and organisational measures to manage the risks to their network and information systems. In Romania the requirement comes through OUG 155/2024, approved by Law 124/2025 — see the complete NIS2 guide for Romania for scoping.

Two ideas matter for the technical team. First, the approach is all-hazards — not just attacks, but also failures, human error and power cuts. Second, proportionality takes into account the state of the art, relevant standards, cost, entity size and risk exposure. That does not exempt any point, but it explains why a 60-person company does not need its own round-the-clock SOC.

Approving these measures is the management body's responsibility under Art. 20 — more in the article on management accountability.

The table is not an exhaustive list of controls but a starting point. ENISA guidance and standards such as ISO/IEC 27001 give more granularity if you need a reference framework.

Risk analysis starts with an inventory: you cannot assess risk on a server you do not know exists. Link every risk to concrete assets (servers, applications, accounts, suppliers) and to an owner. A risk register that mentions no real asset is hard to defend in front of an auditor.

Incident handling means three technical things: seeing (central logs, detection at the perimeter and on endpoints), reacting (procedure, roles, blocking) and recording (a timestamped log). The last point ties directly into the DNSC reporting deadlines.

Continuity is proven by restores, not by backups. A backup job that has been “green” for two years without a single test restore proves nothing. Keep at least one offline or immutable copy — modern ransomware goes for the backups first, as the anatomy of a ransomware attack shows.

Point (d) concerns the relationship with direct suppliers and service providers. Technically that means: a supplier register showing what access each one has, named (not shared) accounts for third parties, remote access only through controlled and logged channels, and prompt revocation when the contract ends.

On the contractual side, ask critical suppliers to tell you about incidents that may affect you, to describe how they protect their own access to your systems and to accept a periodic assessment. You do not need 200-question questionnaires: a short list applied consistently is worth more than a complete form nobody reads. Prioritise by access — a supplier with administrator rights on your servers matters more than one delivering office supplies.

Point (e) covers acquisition, development and maintenance, including vulnerability handling and disclosure. A reasonable minimum:

• regular scans of exposed services and web applications;
• correlating published CVEs with the software actually installed, not a generic list;
• internal remediation deadlines by severity, tracked to closure;
• a public channel for reporting vulnerabilities (for example a security.txt file).

Cyber hygiene (g) is basic hardening: patched systems, unnecessary services off, secure configurations. For servers, the CIS checklist for Linux is a good starting point. Training belongs to the same point — including awareness of modern phishing.

Cryptography (h) asks for policies, not just algorithms: which data is encrypted, with what, who holds the keys, how certificates are rotated. A certificate inventory with expiry dates prevents both breaches and availability incidents. Longer-term planning also includes post-quantum cryptography.

HR, access control and assets (i) means that when an employee leaves, all their accounts close the same day, and that rights are reviewed periodically. Multi-factor authentication (j) has the best effort-to-effect ratio on the whole list: start with remote access (VPN, RDP, SSH), administrator accounts and email.

Point (f) is what turns the other nine from statements into reality: you need policies and procedures to assess the effectiveness of the measures. In practice that means recurring checks and dated evidence.

1. Define a verifiable indicator for each measure (for example “share of privileged accounts with MFA”).
2. Automate collection where possible — manual evidence goes stale quickly.
3. Review results periodically with management and record the decisions.
4. Treat deviations as actions with an owner and a deadline, not footnotes.

Essential entities are supervised ex ante, so they can be checked at any time; important entities are generally supervised ex post, typically after an incident or on the basis of evidence. Either way, evidence prepared in advance is what counts.