NIS2 in practice

Positioning — what NIS2 is and whom it affects

The NIS2 directive (Directive (EU) 2022/2555) succeeds NIS1 from 2016. It dramatically widens the circle of affected organisations, harmonises requirements across the EU, and introduces binding sanctions — up to personal liability of management. In Germany, the directive is transposed via the NIS-2-Umsetzungs- und Cybersicherheitsstärkungs­gesetz (NIS2UmsuCG), which adjusts the BSI law and various sectoral statutes accordingly.

Three properties make NIS2 a turning point rather than a routine update. First: the scope grows tenfold. Where NIS1 only covered "operators of essential services" and a handful of digital service providers, NIS2 brings significantly more sectors and smaller companies into scope. Estimates for Germany cite around 30,000 affected entities — against a few thousand under NIS1. Second: the requirements are concrete. Article 21 lists ten minimum measures every affected organisation must implement; clear reporting and evidence duties follow. Third: management is personally liable. A simple "delegate and forget" no longer works — boards must approve measures, monitor them, and be accountable in an incident.

For Tenvias' target industries, the picture is clear: energy and banking are directly covered as essential entities; insurers fall in through their listing in Annex I; municipal utilities are caught through digital infrastructure, drinking water, waste water, and public transport; and the public administration is explicitly listed at federal and state level. Anyone asking today whether their organisation falls under NIS2 mostly arrives at "yes" — the open question is whether as an essential or important entity.

This article does not aim at legal interpretation — that is what law firms are for — but at the technical translation. What does a software team actually have to do? What measures follow from the abstract articles? Where does NIS2 overlap with existing standards (ISO 27001, BSI IT-Grundschutz, BAIT/VAIT) so that work already done counts? And what does a pragmatic entry path look like that does not collapse into compliance theatre?

Scope — who falls under NIS2

The directive knows two categories: essential entities (Annex I) and important entities (Annex II). The distinction is not academic — sanctions, supervisory intensity, and some specific duties differ.

Sectors in Annex I (essential entities)

Energy (electricity, gas, district heating, oil, hydrogen), transport (air, rail, water, road), banking, financial-market infrastructure, health, drinking water, waste water, digital infrastructure (DNS service providers, TLD registries, cloud computing services, data-centre operators, content-delivery networks, trust service providers), management of ICT services (MSPs, MSSPs), public administration (central governments and, at member-state discretion, regional administrations), and space.

Sectors in Annex II (important entities)

Postal and courier services, waste management, production and trade of chemicals, food production and trade, manufacturing (medical devices, computer hardware, electrical equipment, machinery, motor vehicles and other transport), providers of digital services (online marketplaces, online search engines, social networking platforms), and research organisations.

Thresholds

In most sectors NIS2 only applies once one of the following size thresholds is crossed:

• Medium-sized companies (applies to both important and essential entities): ≥ 50 staff or annual turnover / balance sheet > 10 million euro.
• Large companies (typically essential entities when in Annex I): ≥ 250 staff or annual turnover > 50 million euro or balance sheet > 43 million euro.

Regardless of size, certain entities are caught — qualified trust service providers, TLD registries, DNS service providers, the federal public administration, and a handful of special cases. "We are too small" is therefore a safe argument for most sectors only below 50 staff and 10 million euro turnover — and in regulated sectors not necessarily even then.

Self-identification and registration

Unlike under NIS1, affected entities must register themselves with the BSI — no individual notification is sent. The deadline after entry into force is tight (in Germany typically three months). Missing self-identification triggers a fine on its own, regardless of the actual security level. The self-assessment of NIS2 applicability and category therefore belongs at the very front of any roadmap.

Article 21 — the ten minimum measures

Article 21 of the NIS2 directive lists ten minimum measures every affected entity must implement. The list is deliberately abstract — meant to apply across sectors, sizes, and technologies. Anyone who seriously implements it ends up with a complete Information Security Management System (ISMS). Below the ten points with their practical interpretation.

(a) Risk analysis and security policies

A continuous risk analysis — not a one-off exercise but a process. It identifies assets, threats, vulnerabilities, and evaluates risk. Results feed into security policies that are formally approved and regularly reviewed. Technical: an inventory of all applications and systems as a baseline (asset management), threat modelling per application (e.g. STRIDE), a documented risk-assessment method.

(b) Incident handling

A documented incident-response process — from detection through containment and eradication to recovery and lessons learned. Technical: a Security Operations Centre (SOC) or an external MSSP, defined escalation paths, runbooks for the most common incident types, regular tabletop exercises.

(c) Business continuity (BCM and backups)

Business Continuity Management plus backup and recovery strategies. Technical: 3-2-1 backup rule as the minimum (three copies, two media, one offsite or offline), tested restore procedures with measurable RTO/RPO, a disaster-recovery concept with annual test.

(d) Supply-chain security

Assessment and management of risks in the supply chain — meaning direct suppliers, service providers, and third-party IT providers. Technical: SBOM (Software Bill of Materials) for your own products and critical third-party components, regular CVE reconciliation, contract clauses on security requirements and audit rights, defined criteria for supplier selection.

(e) Security in procurement, development, and maintenance

A secure Software Development Lifecycle (SDLC). Technical: security-by-design mandatory in architecture, static and dynamic code analysis in CI, vulnerability scans (SCA for dependencies, DAST for applications — see our article on web application security with OWASP ZAP), structured patch management with severity-based SLAs (critical < 7 days, high < 30 days).

(f) Effectiveness measurement

Policies to assess the effectiveness of the chosen cybersecurity measures. Technical: KPIs for security maturity (Mean Time to Detect, Mean Time to Respond, patch compliance, phishing-click rate), regular audits, external penetration tests on an annual cadence.

(g) Cyber hygiene and training

Basic cyber-hygiene practices plus training for all staff, including management. Technical: mandatory annual awareness training, phishing simulations, onboarding modules for new joiners, dedicated training of the management board on IT risks.

(h) Cryptography and encryption

Policies and procedures for the use of cryptography. Technical: transport encryption (TLS 1.2+) across the board, data encryption at rest (disk and database encryption), key management with clear rotation cycles, a register of cryptographic algorithms in use with a migration path away from outdated schemes (RC4, MD5, SHA-1, TLS 1.0/1.1).

(i) Personnel security, access control, asset management

Policies for secure personnel changes, access rights on a need-to-know basis, end-to-end asset management. Technical: joiner-mover-leaver processes with automated de-provisioning, role-based access management (RBAC), regular recertification of permissions, a central identity-and-access-management platform such as Keycloak that manages permissions consistently across application boundaries.

(j) Multi-factor authentication and secure communication

MFA, continuous authentication, secured voice, video, and text communication for internal emergency communication. Technical: MFA for all administrative access as a non-negotiable minimum (ideally phishing-resistant via WebAuthn/FIDO2), MFA for all employee access to business applications, a secured out-of-band channel for crisis communication (e.g. a dedicated messenger with its own authentication that keeps working even when the main infrastructure is compromised).

Reporting duties — the 24/72/1 workflow

Reporting is the point at which NIS2 becomes most directly tangible. A significant security incident triggers a clearly timed workflow with three mandatory milestones.

What counts as a "significant incident"

An incident is reportable as soon as it is significant — meaning it causes or could cause serious operational disruption, or causes other natural or legal persons substantial material or immaterial harm. The threshold is deliberately wide; when in doubt, you report. A ransomware attack on production systems, a confirmed data breach involving customer or staff data, a compromise of an administrative account in critical infrastructure: all significant.

The ZAC and the single-reporting-point principle

The report does not go directly to each sectoral supervisor but to the Central Cybersecurity Contact Point (ZAC) at BSI. It forwards the report to the relevant authorities — including across national borders to the EU CSIRT network where needed. The single-reporting-point principle avoids the situation where a reporting organisation has to serve multiple authorities in parallel during the first hours of an incident.

Mapping onto ISO 27001 and BSI IT-Grundschutz

Anyone running an established ISMS on the basis of ISO 27001 or the BSI IT-Grundschutz already covers most NIS2 measures — that is the good news. The bad: NIS2 has its own emphases that an ISO-certified ISMS does not automatically address.

High overlap with ISO 27001:2022

The ISO 27001 Annex A controls — reduced and restructured from 114 to 93 in the 2022 revision — cover most NIS2 requirements directly. Risk management, access control, cryptography, personnel security, supplier relationships, incident handling, business continuity — all are mandatory under both ISO 27001 and NIS2 Article 21. An ISO 27001 certification can be used as the basis of the NIS2 evidence.

BSI IT-Grundschutz

The BSI IT-Grundschutz compendium is the German counterpart. It is more concrete (close to 100 building blocks with detailed measures) and has historically been the standard for public administration. For NIS2, Grundschutz is the most natural docking point — the BSI as supervisor accepts this methodology as evidence without question.

Where NIS2 goes beyond the standards

Three areas are weaker in ISO 27001: (1) reporting duties with their tight time windows — an audit-grade ISMS process does not automatically mean "a BSI report formulated within 24 hours"; (2) personal liability of management — ISO requires management commitment, but not personal criminal liability; (3) supply-chain requirements — Annex A.5.20 (Information Security in Supplier Relationships) is more general than NIS2 Article 21(d). An ISO 27001-certified organisation has about 80 percent of NIS2 measures documented — but the remaining 20 percent is exactly the kind that hurts most in a real incident.

Supply chain and third-party providers

One of the most consequential novelties of NIS2 is the explicit responsibility for the own supply chain. Anyone counted as an essential or important entity must check direct suppliers — cloud providers, SaaS services, MSPs, IT consultants, security-relevant software vendors — for their security practice, document the results, and follow up regularly.

Practically this means: a supplier register with security classification, an onboarding questionnaire that probes NIS2-relevant measures (commonly aligned with VdS 3473 or TISAX questionnaires), contract clauses on security requirements and reporting duties towards your own organisation, and where appropriate audit rights. For IT-relevant suppliers, an additional element is added: a Software Bill of Materials (SBOM) in a machine-readable format (CycloneDX or SPDX) that makes transparent which open-source and third-party components a delivered product contains. Without SBOM, a CVE reconciliation after a publicly disclosed vulnerability (Log4Shell as the canonical lesson) is practically impossible.

Tenvias itself is, as a software supplier to regulated industries, directly affected by this dynamic. Our clients already demand SBOMs for delivered components and ask for details on patch cycles, code-review processes, and incident-notification duties towards them. An IT supplier that cannot meet these contractual demands is out of tenders — regardless of whether their own organisation falls under NIS2 at all.

Concrete tech tasks for software teams

From the abstract articles, a tangible task list follows that a software team can put on a regular roadmap. The list below is not exhaustive, but it covers the 80 percent that shows up in most audits.

Asset inventory

A central register of all production applications, databases, external interfaces, container images, and critical cloud resources. Without a complete list, you cannot assign risk. Tools: a simple Git-versioned YAML inventory is enough for small setups; in larger environments a CMDB or a tool like ServiceNow or Snipe-IT is appropriate.

Identity and access management

A central IAM for staff and service identities. Keycloak is our default recommendation for setups that need to stay self-hosted — a dedicated article on it follows next in this series. MFA for administrative access is non-negotiable; ideally phishing-resistant (WebAuthn, FIDO2, Yubikeys).

Logging with correlation

Structured logs with a consistent trace ID, centrally aggregated (ELK, Loki, Splunk), with retention sufficient for forensic analysis (at least 90 days, in regulated sectors often longer). Details in our article on logging in the enterprise.

Vulnerability and patch management

SCA (Software Composition Analysis) on every pull request with a block on critical findings. DAST against the most important applications weekly. Patch SLAs: critical within 7 days, high within 30 days, documented exceptions with risk approval.

Secret management

No secrets in Git, anywhere. Managed through Vault, AWS Secrets Manager, Azure Key Vault, or a comparable solution. Rotation of critical credentials at least annually, ideally automated.

Backups with test restore

3-2-1 rule as the minimum. Quarterly documented restore tests — a backup that has never been restored is conceptually not a backup. An offline or air-gapped copy as protection against ransomware.

Incident-response runbook

A written plan for the most common incident types — ransomware, data leak, compromised admin access, DDoS. Escalation chains, phone list, predefined communication templates. Annual tabletop exercises with the management board.

Monitoring and detection

End-to-end infrastructure monitoring (see our articles on Gatus and Zabbix + Grafana), a SIEM connection for security-relevant events (Wazuh, Splunk Enterprise Security, or a managed SOC service). Detection rules documented and versioned.

SBOM pipeline

Generation of a CycloneDX or SPDX SBOM with every build. Stored as a build artefact. Automated reconciliation against OSV and NVD in CI. On hits: a defined process for assessment and response.

Management training

A duty under NIS2 that gets neglected in many organisations. The management board must approve the measures, monitor their effectiveness, and be capable of acting in an incident. A mandatory two- to three-hour annual training focused on decision-making situations (what to do when the CISO calls at 11 p.m.?) belongs on the calendar.

Sanctions and management liability

NIS2 is not toothless. The sanctions framework follows the GDPR model and applies, for most organisations, at this level for cybersecurity duties for the first time.

For essential entities, the directive provides fines of up to 10 million euro or 2 percent of global annual turnover — whichever is higher. For important entities, the frame is up to 7 million euro or 1.4 percent of turnover. These amounts are not merely theoretical; EU member states are obliged to impose "effective, proportionate, and dissuasive" sanctions in practice.

A clear tightening compared with NIS1 is the personal liability of management. A managing director or board member who has not properly approved, monitored, and ensured implementation of cybersecurity measures can be held personally liable — up to a temporary ban from holding management positions in particularly severe cases. The legislator's message is unambiguous: cybersecurity is a board matter, not delegable.

From that liability logic follows a practical consequence: the training duty for management explicitly required by Article 20(2). A board that cannot demonstrate in an audit that it has been trained on IT risks itself has a problem — irrespective of how well the technical team is positioned.

A pragmatic start — what should happen on Monday

The most common mistake with NIS2 programmes is to spend months in concept phases before anything concrete happens. We recommend a pragmatic phased plan that delivers visible results within a few weeks.

Phase 1: stocktaking (weeks 1–4)

Self-assessment of NIS2 applicability (Annex I or II, essential or important?). Registration with BSI as soon as the national deadline requires. An asset inventory is created or extracted from existing CMDBs. A gap analysis against the ten Article 21 measures is performed — typically about half of the points are already covered in some form.

Phase 2: quick wins (weeks 5–12)

The most obvious gaps are closed: MFA everywhere, password policies, backup restore test, logging with appropriate retention, an incident-response runbook in a first version, a tabletop exercise. These measures are not technically hard but raise the security level rapidly and provide evidence for the first audit.

Phase 3: structural measures (months 4–9)

SBOM pipeline, SIEM integration, supplier questionnaires with returns, formal risk management, IT security concept with board resolution, training for the management board, external penetration tests. This phase decides whether the organisation can truly stand in front of an authority or has only built a superficial compliance façade.

Phase 4: steady state (from month 10)

The ISMS becomes routine. Quarterly reviews, an annual effectiveness assessment, continuous improvement, ongoing adaptation to new threats. NIS2 is not a one-off exercise — ongoing maintenance is the real effort.

In most of the setups we work in, the greatest challenge is not technology. The building blocks — IAM, logging, monitoring, MFA, backups — are available on the market and established in regulated industries for years. The challenge is the consistency of execution: no "later", no exceptions for favourite applications, no business units that escape discipline. NIS2 enforces that consistency legally — turning cybersecurity into what it should always have been: an engineering topic with full attention from the management board.