NIS2 Article 21(2) requires ten areas of cybersecurity measures, from risk analysis and incident handling to supply chain security, multi-factor authentication and encryption. It does not list technical controls. Engineering teams must choose proportionate measures, apply them, and keep evidence that they work. This checklist maps each area to concrete tasks.
What does the law actually require?
Article 21(1) asks for "appropriate and proportionate technical, operational and organisational measures", based on an all-hazards approach. Article 21(2) then names ten areas, (a) to (j). Article 21(4) adds that if you find you do not comply, you take corrective measures without undue delay. Article 20 puts approval and oversight of these measures on the management body.
Two practical consequences. First, your national transposition law and your sector regulator can add detail, so read them before you finalise scope. Second, for certain digital entities such as cloud and managed service providers, Commission Implementing Regulation (EU) 2024/2690 spells out technical and methodological requirements.
Which engineering tasks map to each area?
Work through the lettered areas in order. Owners in brackets are suggestions.
(a) Risk analysis and security policies. Keep an asset inventory of systems, services and data flows, and a risk register tied to it. [Security lead] Evidence: register with dated reviews.
(b) Incident handling. Write a runbook with severity levels, on call rota and an explicit test for "significant incident". Article 23 sets the clock: early warning within 24 hours, incident notification within 72 hours, final report within one month of the notification. [Engineering manager] Evidence: runbook, tabletop notes, a drill timeline.
(c) Business continuity. Define backup scope, restore targets and a crisis contact tree. Restore a backup on a schedule and record the time it took. [Infrastructure lead] Evidence: restore test logs.
(d) Supply chain security. Article 21(3) tells you to weigh each direct supplier's vulnerabilities, product quality and secure development practices. Inventory suppliers, tier them, collect their security documentation, and generate an SBOM for what you ship. [Security and procurement] Evidence: supplier register, review notes.
(e) Secure acquisition, development and maintenance, including vulnerability handling and disclosure. Enforce code review and protected branches, run dependency and code scanning in CI, set remediation targets by severity, and publish a way for researchers to report issues. [Engineering] Evidence: pipeline config, scan history, ticket closure times.
(f) Assessing effectiveness. Schedule internal reviews, penetration tests and control tests, and track findings to closure. [Security lead] Evidence: reports and closure tickets.
(g) Cyber hygiene and training. Patch cadence, device baselines, onboarding and annual training with completion records. [IT and HR]
(h) Cryptography. Write a short standard: approved algorithms, key storage, rotation, TLS configuration, encryption at rest. [Infrastructure] Evidence: configuration exports.
(i) HR security, access control, asset management. Role based access, joiner mover leaver steps, periodic access review. [IT and HR] Evidence: dated review exports.
(j) MFA, secured communications, emergency communications. Enforce MFA on identity provider, remote access and admin consoles. Define an out of band channel for use when email or chat is down. [IT] Evidence: identity provider policy screenshots or exports.
What do engineers most often skip?
- Writing down why. Proportionality means you can choose differently from a peer, and that holds up when the reasoning is documented.
- Backups never restored. A backup that has not been restored is a hope.
- Supplier reviews that stop at a questionnaire. Article 21(3) points at how suppliers develop software, which you can partly observe from their advisories and release behaviour.
- No management sign off. Article 20 makes the board or equivalent accountable, so they need regular, specific reports.
- Incident clock ambiguity. Decide in advance who declares "significant" and who files.
How big is the downside?
Article 34 sets maximum administrative fines for breaches of Articles 21 and 23 of at least 10 million euros or 2 percent of worldwide turnover for essential entities, and at least 7 million euros or 1.4 percent for important entities. Member States set the actual national rules.
What to do
- Confirm whether you are an essential or important entity under your national law, and which authority supervises you.
- Build the asset and supplier inventories first. Everything else depends on them.
- Assign an owner to each lettered area and agree evidence per area.
- Close the cheap gaps: MFA everywhere, protected branches, restore tests, a written incident clock.
- Run one incident drill against the 24 hour, 72 hour and one month deadlines.
- Brief the management body with one page: risks, open findings, drill results, decisions needed.
- Review quarterly and record corrective actions.
Quick check
Does NIS2 name specific technical controls?
No. Article 21 names ten areas and requires appropriate and proportionate measures. You select the controls and document why they fit your risk. Implementing acts add detail for some digital service providers.
What are the NIS2 incident reporting deadlines?
For a significant incident, Article 23 requires an early warning within 24 hours of becoming aware, an incident notification within 72 hours, and a final report no later than one month after the notification.
How Safeguard helps automate this
Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence for areas (d) and (e) comes from connected systems and code rather than screenshots, and monitoring runs between reviews. Technical evidence comes from your actual dependencies: scans, SBOMs and reachability show what you ship and which findings matter. Safeguard's agent can open tested fix pull requests for vulnerable dependencies and other findings. It is off by default, every category starts on Manual, and you choose which categories run automatically and the approval level. Safeguard helps prepare and keep evidence ready; your supervisory authority and any assessor make the compliance call.
Open the framework mapping demo or book a call.
Sources
- NIS 2 Directive, Article 21
- NIS 2 Directive, Article 23
- NIS 2 Directive, Article 20
- NIS 2 Directive, Article 34
- Directive (EU) 2022/2555 on EUR-Lex
Article texts come from an unofficial reproduction of the Directive. The official text is on EUR-Lex.
Last reviewed: 18 October 2026.
