Skip to content

NIS2 for development & operations

Writing policies is the easy part. We make sure your systems actually follow them.

Germany’s new BSI Act has applied since December 2025. Around 30,000 companies now have to prove that backups, patching, access and their software supply chain are secure. We turn the requirements into architecture, pipelines and operations, built so that your system produces the evidence itself.

Get in touch What actually needs doing

Who it affects

More companies than think they are.

Whether NIS2 applies to you directly depends on your sector and size. What matters more in practice: even companies outside its scope get the requirements passed on by their customers. And responsibility no longer sits with IT alone.

  • 01

    Directly in scope

    From 50 employees or €10m turnover in sectors such as energy, water, health, transport, digital infrastructure or manufacturing (§ 28 BSIG).

  • 02

    Indirectly, through customers

    Companies in scope have to secure their supply chain. Software vendors and IT service providers get asked for SBOMs, patch commitments and security evidence.

  • 03

    Management is accountable

    Management has to approve the measures, oversee their implementation and take part in training. It is liable for culpable failures (§ 38 BSIG).

  • 04

    Reporting under time pressure

    Significant security incidents have to reach the BSI fast: an early warning within 24 hours, details within 72 hours (§ 32 BSIG).

From § 30 BSIG to engineering

What the law requires and what it looks like in your system.

§ 30 BSIG lists the risk management measures. For development and operations teams, they come down to six areas.

  1. § 30 (2) no. 3 BSIG

    Business continuity: backup management and disaster recovery

    Backup & recovery

    Defined RPO and RTO, backups an attacker cannot delete, and restore tests that actually run on a schedule. Not just a job that reports “success”.

    Read: backup under § 30 BSIG →
    • RPO/RTO
    • Immutable backups
    • Restore tests

  2. § 30 (2) no. 5 BSIG

    Security in acquisition, development and maintenance, including vulnerability handling

    Vulnerabilities & patching

    Scan dependencies and container images automatically, prioritise findings by risk and set patch deadlines your team can actually meet day to day.

    • Dependency scanning
    • Container scanning
    • Patch SLAs

  3. § 30 (2) no. 4 BSIG

    Supply chain security, including suppliers and service providers

    Software supply chain

    Know what is in every release: an SBOM from the pipeline, signed artefacts and a build environment that is not an attack vector itself. Exactly what your customers will soon ask about.

    • SBOM
    • Signed artefacts
    • Pipeline hardening

  4. § 30 (2) nos. 9 and 10 BSIG

    Access control and multi-factor authentication

    Access & identities

    MFA wherever people access systems, least privilege for people and machines, and secrets in a vault instead of in repositories and CI variables.

    • MFA
    • Least privilege
    • Secrets management

  5. § 30 (2) no. 2, § 32 BSIG

    Incident handling and reporting to the BSI

    Detection & reporting

    Central logging, alerts someone responds to, and a rehearsed reporting path. Without them, the 24-hour deadline is hard to meet in practice.

    • Observability
    • Alerting
    • Runbooks

  6. § 30 (2) no. 6 BSIG

    Assessing the effectiveness of risk management measures

    Evidence

    Policy as code, traceable pipelines and documented architecture decisions. That way the audit evidence comes as a by-product, not from a spreadsheet.

    • Policy as code
    • GitOps
    • ADRs

From practice

The gaps we see most often.

  1. 01

    Backups that were never restored.

    The backup job has been green for years. Whether it can turn into a running system in reasonable time, nobody has ever tried.

  2. 02

    Nobody knows what runs in production.

    Without an SBOM, answering “are we affected by this vulnerability?” takes days instead of minutes. And that is exactly what customers and auditors ask.

  3. 03

    Secrets where they don’t belong.

    Passwords and tokens in repositories, CI variables and config files, often with more rights than needed and never rotated.

  4. 04

    Logs that exist but nobody reads.

    Lots gets collected, but nothing alerts. An incident is noticed days later, long after the reporting deadline has passed.

  5. 05

    Measures on paper, not in the system.

    The security concept describes a target state the systems don’t enforce. Come the audit, someone has to prove by hand what should apply automatically.

How we start

From an honest look to ongoing support.

  1. 1 Start

    Review with a NIS2 focus

    We check architecture, platform and pipelines against the technical requirements of § 30 BSIG and hand you a prioritised list of gaps. More about our architecture review.

  2. 2 Delivery

    Closing the gaps together

    We implement what the review found together with your team: from restore tests to SBOMs in the pipeline to secrets management.

  3. 3 Support

    Staying on board

    As your contact for new requirements, audits and customer questions about the supply chain, as part of our advisory.

We don’t replace your ISMS or your legal advice. We make sure your systems deliver what your policies promise, and we’re happy to work directly with your information security officer.

Case studies

Projects in this area

All case studies →
Insurance

An IT strategy built for growth and regulators alike.

Analysis of infrastructure, architecture and development process at a mid-sized insurance company, with a catalogue of measures, a hybrid target architecture and a clear view of VAIT, DORA and NIS2.

  • IT strategy
  • Kubernetes
  • Hybrid cloud
  • VAIT
  • DORA
  • NIS2
Public administration

Kubernetes under the strictest security requirements.

SRE and platform engineering for a highly regulated public authority: Red Hat OpenShift and SUSE Rancher/RKE2, end-to-end observability and infrastructure as code, plus third-level support for the internal DevOps team.

  • Red Hat OpenShift
  • SUSE Rancher
  • RKE2
  • Grafana Enterprise
  • Prometheus
  • Loki
  • Thanos
  • Terraform
  • Terragrunt
  • Ansible
  • Proxmox
Biotechnology

Two Kubernetes clusters migrated to Amazon EKS, without downtime.

For a small, long-established biotech company, we migrated two Kubernetes clusters from RKE1 to Amazon EKS, moved Jenkins to the cloud and switched deployments to GitOps with Rancher Fleet and HashiCorp Vault.

  • Amazon EKS
  • AWS
  • RKE1
  • Rancher Fleet
  • GitOps
  • Jenkins
  • HashiCorp Vault
  • Amazon EC2
IT communications

Fully automated releases for three CPU architectures and many distributions.

For an appliance and middleware solution, every release variant is now built automatically: signed, tested and delivered straight to the customer's community.

  • CI/CD
  • Jenkins
  • Ansible
  • Docker
  • Package signing
  • C
  • Java

Knowledge

More on this topic

All articles →
Regulation 14 min read

NIS2 and BSIG: backup management that holds up when it counts

The new German BSI Act has applied since December 2025. What Section 30 BSIG requires for backup, recovery and crisis management, what you need to show in an audit and how your backup survives a ransomware attack.

Steven ·
GitOps 6 min read

GitOps with Argo CD and Helm: structure and image promotion

How to structure a GitOps repository for many environments and get new Docker images into the right environment automatically with Argo CD, Helm and GitHub Actions.

Christopher ·

FAQ

Frequently asked questions

How do I know whether NIS2 applies to us?
It depends on sector and size under § 28 BSIG. The BSI’s applicability check gives you a quick first answer. If you’re unsure, we’re happy to look at it with you, but the legal assessment stays with your legal department or law firm.
We’re not in scope ourselves. Why should NIS2 matter to us?
Because your customers are. Companies in scope have to secure their supply chain and ask suppliers for SBOMs, patch deadlines and security evidence. If you can already deliver that cleanly, you have a clear edge in sales.
Do you build our ISMS or give legal advice?
No. We take care of the technical side: architecture, platform, pipelines and operations. We’re happy to coordinate directly with your security officer, data protection and law firm.
Is an ISO 27001 certification enough?
It’s a good foundation because it covers many processes NIS2 requires. Whether your systems actually enforce those processes is another matter. That’s exactly what we look at.
We run Kubernetes. Is that a problem?
Quite the opposite: with GitOps, policy as code and clean pipelines, many requirements are particularly easy to automate and prove there. Provided the platform itself is set up securely.

Let’s talk about your NIS2 gaps.

Tell us where your team stands and what worries you. We’ll tell you honestly where the biggest technical gaps are and where to start.

Get in touch

You'll hear back from us within one working day. The first conversation is free and non-binding.