NIS2 for mid-sized companies: visibility first, then compliance

Many companies respond to NIS2 with what they know from other regulations: they write policies, define processes, fill out documents. It's well-intentioned — but the wrong order. Without a reliable picture of your own production OT, any documentation is a building without a foundation.

Since the German NIS2 implementation act came into force, thousands of mid-sized companies face a new obligation: risk management, reporting duties and demonstrable security — including, and especially, in production. Unlike earlier regulations, NIS2 affects not only the classic critical-infrastructure operators but a considerably broader circle. And responsibility lies explicitly with executive management.

The understandable first reaction is to reach for templates: set up an information security management system, formulate policies, work through a catalogue of measures. That's not wrong — but it skips the decisive first step.

Risk management presupposes knowledge

The core of NIS2 is risk management. And risk management means, as a first step, knowing your own risks. Here lies the problem: in most production environments, even the basis for this is missing — a complete, reliable picture of which systems, controllers and connections actually exist in the OT network.

You can't assess a risk you don't know. You can't protect a plant you don't fully see. And you can't produce honest compliance documentation whose factual basis is full of gaps. Anyone who reverses the order and starts with documentation, at best documents an incomplete picture — and at worst one that has little to do with reality.

Why OT specifically is the gap

In classic IT, most companies have long had a certain level of inventory — asset management systems, endpoint management, network documentation. In OT it looks different. Here, plants have grown over decades, often built by different integrators, documented in wiring diagrams that rarely reflect the current state exactly.

The result: many operators don't know for certain what's actually connected in their OT network. Which controllers, which engineering workstations, which forgotten remote-maintenance access points, which connections to the outside. Precisely this not-knowing is the actual security gap — and the reason NIS2 projects in OT fail when they start in the wrong place.

The right order

A NIS2 project in production should therefore follow a clear sequence:

1. Create visibility: First, a complete, reliable picture of the OT — assets, communication relationships, interfaces to the outside. Passive and non-intrusive, so operations aren't endangered.
2. Assess risks: Only on the basis of this picture can risks be identified and prioritized at all — which systems are critical, where vulnerabilities exist, which communication paths are problematic.
3. Derive measures: From the prioritized risks follows a concrete, actionable roadmap — segmentation, monitoring, hardening, organizational measures.
4. Build evidence: Only now does documentation make sense, because it reflects a real factual basis — and that is exactly what an audit demands.

Pragmatism instead of corporate overhead

For NIS2, mid-sized companies don't need an army of consultants or a two-year project. What they need is someone who knows the right order and approaches it pragmatically: visibility first, then assessment, then measures — tailored to what is actually achievable in mid-sized companies.

The biggest mistake I see in practice is the attempt to treat NIS2 as a pure documentation project. The second biggest is scaling it so large that it never gets finished. The path in between — focused, well-grounded, in the right order — is achievable. And it always begins with the same step: seeing what's really there.