NIS2: Technical Security Measures at Platform Level
NIS2 Article 21: ten categories of technical security measures. None of them end with "We have a policy for that".
NIS2 does not prescribe specific tools or configurations. It defines what must be demonstrably achieved. The gap between "we have a security policy" and "here is the documented evidence of our hardened platform state" is exactly where organisations fail NIS2 audits.
lennlay closes this gap with defined platform baselines, automated compliance scans, and a change history that has an answer to every question an auditor can ask.
What the ten requirement categories mean at server level
NIS2 describes requirement categories, not implementation blueprints. What must be demonstrably in place at platform level is determined by the auditor. Six of the ten categories are directly addressable at platform level.
Risk analysis and security policies
Which platforms exist? What is their security state? Every deviation from a defined target state is a documented risk. Without a defined baseline there is no target state, and therefore no defensible risk analysis.
Incident handling
What was the configuration state at the time of the security incident? Without Git-based configuration management: unknown. With GitOps it is a single query returning author, timestamp, and the reason for every change.
Business continuity and disaster recovery
Platforms must be recoverable from a defined, reproducible state. Golden Images and Ansible Collections deliver exactly that: reproducibility based on a documented target state, not on manual memory.
Security in system acquisition and development
New servers must meet the defined hardening standard from day one, not after the first incident report. GIaaS delivers hardened baselines as the starting point, not as a remediation measure applied after the fact.
Effectiveness assessment of security measures
The automated compliance scan verifies whether defined measures are actually in place, not as a one-time check but continuously. Without a scanner, effectiveness remains a claim rather than evidence.
Access control and asset management
Every server is documented. Every configuration change is attributed to an author, with timestamp and justification. Git-based configuration management is asset management and change evidence in a single artefact.
Categories (d) supply chain security, (g) cybersecurity hygiene and training, (h) cryptography, and (j) multi-factor authentication fall outside the platform hardening scope and are addressed through complementary measures.
Who falls under NIS2
The NIS2 Directive distinguishes two categories of affected entities with different size thresholds and supervisory requirements. Classification determines the level of oversight and the severity of sanctions.
- Energy (electricity, gas, district heating, oil, hydrogen)
- Transport (road, rail, air, maritime)
- Banking and credit institutions
- Financial market infrastructure
- Health (hospitals, laboratories, pharmaceuticals)
- Drinking water supply
- Wastewater management
- Digital infrastructure (IXPs, DNS, TLDs, cloud, data centres)
- ICT services (managed services, managed security)
- Public administration (federal and state level)
- Space
- Postal and courier services
- Waste management
- Chemicals
- Food production and distribution
- Manufacturing: medical devices, electronics, vehicles, machinery
- Digital services (online marketplaces, search engines, social networks)
- Research organisations
Essential entities are subject to proactive supervisory oversight and must register with the national authority. Important entities fall under reactive supervision. Article 21 obligations apply equally to both categories.
Which lennlay measure fulfils which Article 21 obligation
Article 21 defines what must be evidenced. lennlay delivers the technical artefacts that make that evidence possible.
| lennlay measure | Article 21 | What is evidenced |
|---|---|---|
| Defined baselines (CIS L1/L2 or custom policy) | (a) + (e) | Versioned policy artefact with control IDs, date, scope, and exception log |
| Automated compliance scan and reports | (f) | Structured report: target state, actual state, deviations, exceptions with risk rating |
| Git-based configuration management | (b) + (i) | Audit trail with author, timestamp, and justification for every configuration change |
| GIaaS Golden Images | (c) + (e) | Reproducible recovery state and standardised starting point for every new system |
| Drift detection | (f) | Deviations become visible before they surface in an audit or an incident |
| Lifecycle management | (e) | Traceable patch status with documented end-of-support dates and upgrade timelines |
Six building blocks for auditable NIS2 evidence at platform level
Defined platform baselines
CIS Level 1 or Level 2 as a versioned policy artefact. Every platform has a documented target state with control IDs, date, scope, and exception log. Not a description: a machine-readable, evidenceable ruleset.
Automated NIS2 evidence
The lennlay compliance scanner runs live against defined policies. The report contains target state, actual state, deviations, and exceptions with risk ratings. Ready to hand to an auditor or internal review board.
Change history as proof
Git commits as audit trail. Every configuration change carries author, timestamp, and justification. For the Article 21(b) requirement, the question "what state was active at the time of the incident?" is a Git query, not a manual reconstruction.
GIaaS for reproducible systems
Hardened baselines for RHEL, Tomcat, Apache HTTP Server, and JBoss EAP as managed, policy-governed artefacts. New systems start in the defined target state, not in a raw, unconfigured state.
Drift detection
Continuous or scheduled scanning compares the live state against the defined baseline. Deviations surface before they become relevant in an audit or an incident, not after.
EaaS for NIS2 projects
Marcel König (RHCA/RHCE) and Matthias Siegl for NIS2 readiness assessment, baseline definition, and scanner setup. Point-in-time engagement or ongoing support, depending on the project phase.
From baseline definition to audit report: four steps
NIS2 compliance is not a project milestone you tick off once. It is a continuous demonstration that the measures actually work. The following chain makes that demonstration structural.
Define the baseline
A written policy specifying which standard applies (CIS L1/L2, NIST, internal), which exceptions exist, and the documented reason for each. The policy artefact is the foundation of every subsequent piece of evidence.
Implement
Install and configure Ansible Collections according to the baseline. GIaaS image as the starting point. Every action is versioned and attributed to an author.
Assess
Compliance scanner runs against production instances. Structured output: pass/fail per control, deviations with severity, exceptions with risk rating. No manual effort, no room for interpretation.
Evidence
Report for the auditor: current compliance status, documented deviations, exceptions with justification, full change history. One structured document, ready for the review without further preparation.
NIS2 asks for evidence, not intent. lennlay delivers the artefacts that hold up under regulatory scrutiny.
