NIS2 Compliance for DevOps Teams: What You Need to Do

NIS2 isn't some abstract regulation being cooked up in Brussels that might become relevant someday. It's binding law with concrete technical requirements, hard deadlines, and personal liability for executives. Organizations still running legacy infrastructure will find that retrofitting often costs more than migrating to a compliance-ready cloud environment — and those who miss the window will pay for it in more ways than one.

What Is NIS2 and Who Is Affected?

NIS2 stands for the second version of the EU Directive on Network and Information Security (Network and Information Security Directive). It replaces the original NIS Directive from 2016 and significantly tightens cybersecurity requirements for businesses and public institutions. In Germany, it was transposed into national law through the NIS2 Implementation Act (NIS2UmsuCG).

The most important change from NIS1: the scope of affected organizations has expanded dramatically. While the first version mainly targeted critical infrastructure operators, NIS2 now covers many mid-sized companies across a wide range of sectors — including digital infrastructure, IT service providers, hosting companies, healthcare, energy, transport, and financial services.

The directive distinguishes between two categories:

• Essential entities: Organizations in particularly critical sectors with more than 250 employees or more than €50M in annual revenue.
• Important entities: Organizations in other relevant sectors with more than 50 employees or more than €10M in annual revenue.

Essential entities face stricter oversight obligations and higher fines. But important entities are also subject to concrete security requirements that must be implemented both technically and organizationally.

Important vs. Essential Entities

The difference primarily lies in the intensity of supervision and potential sanctions. For essential entities, authorities can proactively audit without an incident being reported. For important entities, controls are primarily reactive — but the technical implementation requirements are comparable in both cases.

For DevOps teams, the categorization matters less than the question: what actually needs to be implemented technically?

What NIS2 Compliance Demands from DevOps Teams Technically

The directive specifies concrete areas of measures that must be implemented. In practice, this means for DevOps teams:

Patch management and vulnerability handling: Systems must be patched promptly. This sounds trivial but is a real problem in many environments — especially when production systems can't be updated automatically and patch cycles require manual coordination.

Logging and monitoring: NIS2 requires that security-relevant events are logged and monitorable. This means: centralized log management, traceable audit trails, and the ability to produce complete log data in case of an incident. Many existing environments lack a centralized SIEM or have insufficiently structured logs.

Incident response: There must be a defined process for handling security incidents, including reporting obligations. Significant incidents must be reported to the competent authority (in Germany, the BSI) within 24 hours, with a full report following within 72 hours.

Access controls and network segmentation: Principle of least privilege, separation of network segments, multi-factor authentication for privileged access. Organizations still working with shared admin passwords or flat networks have structural catching up to do.

Encryption and data protection: Data must be encrypted in transit and at rest. This sounds obvious but is frequently not consistently implemented in legacy infrastructures.

Business continuity: Backup concepts, disaster recovery plans, and their regular testing are mandatory. Not a paper concept that was never tested, but demonstrably functioning recovery processes.

Documentation and Accountability Requirements

What many underestimate: NIS2 doesn't just require that these measures exist — it requires that they're demonstrable. Authorities can request documentation, and in case of an incident, they'll verify whether the organization fulfilled its duty of care.

This means: configuration management, change logs, patch records, and access reports must not only exist but be retrievable and structured. In Kubernetes-based environments, this can be automated far more easily than in heterogeneous on-prem landscapes.

The Problem with Existing Data Centers

On-prem infrastructure isn't inherently NIS2-incompatible. But many existing data centers were built at a time when compliance requirements of this kind weren't a priority — and the architectural decisions from back then make retrofitting expensive today.

Specific weaknesses that DevOps teams regularly encounter in legacy environments:

• No centralized identity and access management. User accounts are spread across different systems without unified policy enforcement.
• Manual patch management. Many systems can't be updated automatically because dependencies are unclear or changes could have production-critical impacts.
• Incomplete or unstructured logs. Logs exist but not centrally, not in a uniform format, and not with sufficient retention periods.
• Flat networks. Internal systems communicate without segmentation, making lateral movement by attackers easier.
• No systematic vulnerability scanning. Without continuous scanning, you don't know which CVEs are active in your environment.

Retrofitting these points is possible, but the effort is substantial. Every tool must be evaluated, integrated, operated, and documented. And unlike cloud platforms that already include many of these capabilities, the integration must be built manually.

Why Cloud Infrastructure Makes NIS2 Compliance Easier

Modern cloud platforms — especially those built on Kubernetes — address many NIS2 requirements structurally. This doesn't mean a cloud migration automatically creates compliance, but the starting point is significantly better.

What Kubernetes platforms typically already provide:

• RBAC (Role-Based Access Control) as a native concept, with the ability to manage permissions granularly and traceably.
• Audit logs for API calls and configuration changes — machine-readable, centralized, timestamped.
• Automated patch management through rolling updates of node images and container base images, without manual coordination.
• Network policies for segmentation at the pod level, enforcing the principle of minimal communication.
• Secrets management with integration options for external vault systems.
• Encryption in service-to-service communication via mTLS (e.g., through a service mesh).

Sovereignty as a Technical Requirement

One point that German companies in particular should keep in mind under NIS2: the question of where logs, data, and configurations are stored isn't just a GDPR question — it's also NIS2-relevant.

US hyperscalers are subject to the CLOUD Act, which under certain circumstances grants US authorities access to data regardless of where that data is physically stored. For organizations processing NIS2-regulated data, this can represent a real legal risk.

European cloud infrastructure operated exclusively in Germany or the EU, combined with certifications like BSI C5 or ISO 27001, has a structural sovereignty advantage here.

NIS2 Compliance for DevOps: First Concrete Steps

If you're unsure whether and to what extent NIS2 applies to your organization, start with a structured applicability assessment. The BSI provides guidance for this. Many industry associations and law firms also offer compact checklists.

After the applicability assessment comes the gap analysis: which of the required measures are already implemented? Where is documentation missing? Where are there technical gaps?

This analysis produces a prioritized roadmap. It makes sense to start with the items that carry the highest risk and require the least implementation effort — for example, introducing MFA for privileged access or centralizing logs.

For teams already considering a migration to a cloud platform, NIS2 can be the trigger to plan that step concretely. A platform that structurally includes compliance requirements significantly reduces ongoing effort because less needs to be manually configured, maintained, and documented.

lowcloud operates a Kubernetes DaaS platform hosted in Germany, designed for GDPR-compliant, sovereign cloud infrastructure.

NIS2 isn't a topic that resolves itself by waiting — and it requires board-level cloud governance, not just technical fixes. For financial sector organizations, DORA imposes additional requirements on top of NIS2. The EU AI Act adds further obligations for anyone deploying AI workloads. The requirements are defined, deadlines are running, and the question isn't whether but how quickly and with what infrastructure implementation succeeds. Existing data centers can be retrofitted, but anyone making a platform decision now should treat compliance as an architectural requirement — not a retrofit project.