NIS2 went from "EU directive on the horizon" to "the regulator at your door" the moment Romania transposed it through Law 124/2025. The five-page summary your CIO read in 2023 is no longer enough — DNSC inspectors are reading the same Article 21 you are, and they expect the security operating model to look the way the directive describes it.
This article is the version we wish someone had handed us before the first NIS2 audit. It assumes you already know the directive exists. It focuses on what Article 21, Article 23 and the management-body provisions practically demand, and what evidence holds up when the inspector arrives.
Article 21 in operating terms
Article 21 lists ten "appropriate and proportionate technical, operational and organisational measures." Translated into a security programme, that means at minimum:
- A vulnerability management programme that runs on a cycle, with documented prioritisation and time-bound remediation. Annual scans dropped into a PDF do not satisfy this.
- A documented incident response process with named roles, on-call rotations and tested playbooks. The directive uses the phrase "policies and procedures to assess the effectiveness" — meaning a static IR policy is insufficient; you have to be able to show it has been exercised.
- Supply-chain security: an inventory of critical ICT providers, an assessment of their security posture, and contractual provisions that allow you to demand the same from them. Article 21(2)(d) is unambiguous about this.
- Cyber-hygiene practices and basic awareness training across the workforce, with documented attendance and assessment. Click-through compliance e-learning is, by this writer's reading, not enough.
- Cryptography and access-control policies that match the asset criticality, including MFA on privileged access. The wording deliberately does not mandate specific algorithms; it mandates proportionality, which is what the auditor will probe.
The 24-hour clock — Article 23 incident reporting
Three timelines, one incident:
- Early warning within 24 hours of becoming aware. This is meant as a notification, not a full report. Best practice: a one-page early-warning template, pre-agreed with DNSC, that you can fire from a tabletop.
- Notification within 72 hours, including initial assessment of severity and impact. Drafting this from scratch under incident pressure is brutal; have a template that pulls from your forensic timeline output.
- Final report within 1 month, including root cause and remediation taken. The auditor will read this against your IR policy. Inconsistencies surface fast.
The 24-hour early warning is the clause most organisations underestimate. By the time you understand the incident well enough to write a real notification, you are already late.
Personal accountability of the management body
Article 20 makes the management body — board members, executive directors — personally accountable for compliance with Article 21 and for approving the risk management measures. Romanian transposition keeps this teeth-on. In our engagements with public-sector and large private-sector entities, this single clause moves more budget than any technical argument did in five years of pre-NIS2 GDPR work.
What DNSC inspectors actually ask for
Drawing from the DNSC inspections we have supported as technical advisor — without naming the entities involved:
- The asset register. Not a CMDB dump — a register that ranks assets by business criticality and links each one to an owner. If your asset register has unclaimed servers, the inspection ends there for a few hours.
- The vulnerability backlog by age. Time-since-discovery and time-since-fix-deployment, segmented by severity. We have seen "100% of critical findings remediated" claims dismantled in five minutes by a sample query against the SLA dashboard.
- Incident response logs from the last twelve months — even if you had no incidents. The absence of incidents needs to be visible: the alerts that fired and were closed as benign also count as evidence the programme is working.
- The training matrix: who got which training, when, and what they scored. Watch out for the "everyone did the e-learning" answer; modern inspectors ask which roles got role-specific training, including the management body.
- A list of critical ICT third parties, with the contractual clauses that satisfy Article 21(2)(d), and a sample of recent assessments. This is the most common gap we observe.
The two-year programme that survives an inspection
A defensible NIS2 programme is not a project — it is a programme that runs continuously and produces evidence as a side effect. The minimum viable two-year cadence:
- Quarter 1: asset register baseline + initial vulnerability sweep + IR playbook v1 + management body briefing.
- Quarter 2: critical-supplier assessment + first IR tabletop + remediation cycle 1.
- Quarter 3: pentest of the highest-risk asset cluster + workforce training v1 + KPIs published.
- Quarter 4: vulnerability programme review + supplier follow-up + management body re-briefing with metrics.
- Year 2 mirrors year 1 with deeper red team, deeper supplier breadth, and fully role-specific training.
Where Sandline fits
We run the technical layer of this programme — vulnerability assessment on Centraleyezer, penetration testing tied to specific Article 21 clauses, IR retainers with NIS2-aligned reporting templates, and the workforce training that satisfies Article 21(2)(g). We will not be your DPO and we will not write your governance charter; we will produce the evidence the auditor needs to read.