Zum Inhalt springen

NIS2 für Entwicklung & Betrieb

Richtlinien schreiben ist der leichte Teil. Wir sorgen dafür, dass deine Technik sie auch einhält.

Seit Dezember 2025 gilt das neue BSI-Gesetz. Rund 30.000 Unternehmen müssen jetzt nachweisen, dass Backups, Patches, Zugriffe und Software-Lieferkette sicher aufgestellt sind. Wir übersetzen die Anforderungen in Architektur, Pipelines und Betrieb, und zwar so, dass dein System die Nachweise selbst liefert.

Schreib uns Was konkret zu tun ist

Wen es trifft

Mehr Unternehmen, als denken, dass sie betroffen sind.

Ob du direkt unter NIS2 fällst, hängt von Sektor und Größe ab. Wichtiger für die Praxis: Auch wer nicht selbst betroffen ist, bekommt die Anforderungen über seine Kunden auf den Tisch. Und die Verantwortung liegt nicht mehr allein bei der IT.

  • 01

    Direkt betroffen

    Ab 50 Beschäftigten oder 10 Mio. € Umsatz in Sektoren wie Energie, Wasser, Gesundheit, Verkehr, digitale Infrastruktur oder Produktion (§ 28 BSIG).

  • 02

    Indirekt über Kunden

    Betroffene Unternehmen müssen ihre Lieferkette absichern. Softwarehersteller und IT-Dienstleister werden nach SBOM, Patch-Zusagen und Sicherheitsnachweisen gefragt.

  • 03

    Geschäftsleitung in der Pflicht

    Sie muss die Maßnahmen billigen, ihre Umsetzung überwachen und sich schulen lassen. Bei schuldhaften Versäumnissen haftet sie (§ 38 BSIG).

  • 04

    Melden unter Zeitdruck

    Erhebliche Sicherheitsvorfälle müssen schnell beim BSI landen: erste Meldung binnen 24 Stunden, Details binnen 72 Stunden (§ 32 BSIG).

Von § 30 BSIG zur Technik

Was das Gesetz verlangt und wie es in deinem System aussieht.

§ 30 BSIG zählt die Risikomanagement­maßnahmen auf. Für Entwicklungs- und Betriebsteams laufen sie auf sechs Baustellen hinaus.

  1. § 30 Abs. 2 Nr. 3 BSIG

    Aufrechterhaltung des Betriebs: Backup-Management und Wiederherstellung nach einem Notfall

    Backup & Wiederherstellung

    Festgelegte RPO und RTO, Backups, die ein Angreifer nicht löschen kann, und Restore-Tests, die regelmäßig wirklich laufen. Nicht nur ein Job, der „erfolgreich“ meldet.

    Zum Artikel: Backup nach § 30 BSIG →
    • RPO/RTO
    • Immutable Backups
    • Restore-Tests

  2. § 30 Abs. 2 Nr. 5 BSIG

    Sicherheit bei Erwerb, Entwicklung und Wartung, einschließlich Umgang mit Schwachstellen

    Schwachstellen & Patches

    Abhängigkeiten und Container-Images automatisch scannen, Funde nach Risiko priorisieren und Patch-Fristen festlegen, die das Team im Alltag auch einhalten kann.

    • Dependency-Scanning
    • Container-Scanning
    • Patch-SLAs

  3. § 30 Abs. 2 Nr. 4 BSIG

    Sicherheit der Lieferkette, auch gegenüber Lieferanten und Dienstleistern

    Software-Lieferkette

    Wissen, was in jedem Release steckt: SBOM aus der Pipeline, signierte Artefakte und eine Build-Umgebung, die selbst kein Einfallstor ist. Genau das fragen deine Kunden bald ab.

    • SBOM
    • Signierte Artefakte
    • Pipeline-Härtung

  4. § 30 Abs. 2 Nr. 9 und 10 BSIG

    Zugriffskontrolle und Multi-Faktor-Authentifizierung

    Zugriffe & Identitäten

    MFA überall, wo Menschen auf Systeme zugreifen, minimale Rechte für Menschen und Maschinen und Secrets in einem Vault statt in Repos und CI-Variablen.

    • MFA
    • Least Privilege
    • Secrets-Management

  5. § 30 Abs. 2 Nr. 2, § 32 BSIG

    Bewältigung von Sicherheitsvorfällen und Meldung an das BSI

    Erkennen & Melden

    Zentrales Logging, Alarme, auf die jemand reagiert, und ein geprobter Meldeweg. Ohne das ist die 24-Stunden-Frist in der Praxis kaum zu halten.

    • Observability
    • Alerting
    • Runbooks

  6. § 30 Abs. 2 Nr. 6 BSIG

    Bewertung der Wirksamkeit der Risikomanagementmaßnahmen

    Nachweisbarkeit

    Policy-as-Code, nachvollziehbare Pipelines und dokumentierte Architekturentscheidungen. So entsteht der Nachweis für das Audit nebenbei statt in einer Excel-Liste.

    • Policy-as-Code
    • GitOps
    • ADRs

Aus der Praxis

Die Lücken, die wir am häufigsten sehen.

  1. 01

    Backups, die nie zurückgespielt wurden.

    Der Backup-Job läuft seit Jahren grün. Ob sich daraus in vertretbarer Zeit ein laufendes System machen lässt, hat noch niemand ausprobiert.

  2. 02

    Niemand weiß, was in Produktion läuft.

    Ohne SBOM dauert die Antwort auf „Sind wir von dieser Schwachstelle betroffen?“ Tage statt Minuten. Und genau diese Frage stellen dir Kunden und Prüfer.

  3. 03

    Secrets an Orten, an denen sie nichts zu suchen haben.

    Passwörter und Tokens in Repositories, CI-Variablen und Konfigurationsdateien, oft mit mehr Rechten als nötig und ohne Rotation.

  4. 04

    Logs, die da sind, aber keiner liest.

    Es wird viel gesammelt, aber nichts schlägt an. Ein Vorfall fällt dann erst nach Tagen auf, und die Meldefrist ist längst vorbei.

  5. 05

    Maßnahmen im Dokument statt im System.

    Das Sicherheitskonzept beschreibt einen Soll-Zustand, den die Technik nicht durchsetzt. Im Audit muss dann jemand von Hand belegen, was eigentlich automatisch gelten sollte.

So starten wir

Vom ehrlichen Blick zur dauerhaften Begleitung.

  1. 1 Einstieg

    Review mit NIS2-Fokus

    Wir prüfen Architektur, Plattform und Pipelines gegen die technischen Anforderungen aus § 30 BSIG und liefern eine priorisierte Liste der Lücken. Mehr zum Architektur-Review.

  2. 2 Umsetzung

    Lücken gemeinsam schließen

    Wir setzen mit deinem Team um, was das Review ergeben hat: von Restore-Tests über SBOM in der Pipeline bis zum Secrets-Management.

  3. 3 Begleitung

    An Bord bleiben

    Als Ansprechpartner für neue Anforderungen, Audits und Kundenfragen zur Lieferkette, im Rahmen unseres Advisory.

Wir ersetzen weder dein ISMS noch deine Rechtsberatung. Wir sorgen dafür, dass die Technik hält, was deine Richtlinien versprechen, und arbeiten dafür gern direkt mit deinem ISB zusammen.

Referenzen

Projekte aus diesem Bereich

Alle Referenzen →
Versicherung

Eine IT-Strategie, die Wachstum und Aufsicht standhält.

Analyse von Infrastruktur, Architektur und Entwicklungsprozess einer mittelständischen Versicherung, inklusive Maßnahmenkatalog, hybrider Zielarchitektur und klarem Blick auf VAIT, DORA und NIS2.

  • IT-Strategie
  • Kubernetes
  • Hybrid Cloud
  • VAIT
  • DORA
  • NIS2
Öffentliche Verwaltung

Kubernetes unter strengsten Sicherheits­auflagen.

SRE und Platform Engineering für eine hochregulierte Behörde: Red Hat OpenShift und SUSE Rancher/RKE2, durchgängige Observability und Infrastruktur als Code sowie Third-Level-Support für das interne DevOps-Team.

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

Zwei Kubernetes-Cluster auf Amazon EKS migriert, ohne Ausfallzeit.

Für ein kleines, lange etabliertes Biotech-Unternehmen haben wir zwei Kubernetes-Cluster von RKE1 auf Amazon EKS migriert, Jenkins in die Cloud geholt und die Deployments auf GitOps mit Rancher Fleet und HashiCorp Vault umgestellt.

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

Releases für drei CPU-Architekturen und viele Distributionen – voll­automatisch.

Für eine Appliance- und Middleware-Lösung entstehen alle Release-Varianten automatisch: signiert, getestet und direkt an die Community des Kunden ausgeliefert.

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

Wissen

Mehr zum Thema

Alle Artikel →
Regulatorik 13 Min. Lesezeit

NIS2 und BSIG: Backup-Management, das im Ernstfall trägt

Seit Dezember 2025 gilt das neue BSI-Gesetz. Was § 30 BSIG für Backup, Wiederherstellung und Krisenmanagement verlangt, was du im Audit vorzeigen musst und wie dein Backup einen Ransomware-Angriff übersteht.

Steven ·
GitOps 6 Min. Lesezeit

GitOps mit Argo CD und Helm: Struktur und Image-Promotion

Wie du ein GitOps-Repository für viele Umgebungen strukturierst und neue Docker-Images automatisch in die richtige Umgebung bringst, mit Argo CD, Helm und GitHub Actions.

Christopher ·

FAQ

Häufige Fragen

Woher weiß ich, ob wir unter NIS2 fallen?
Entscheidend sind Sektor und Größe nach § 28 BSIG. Einen schnellen ersten Eindruck gibt die Betroffenheitsprüfung des BSI. Wenn du unsicher bist, schauen wir gern gemeinsam drauf, die rechtliche Bewertung bleibt aber bei deiner Rechtsabteilung oder Kanzlei.
Wir sind nicht selbst betroffen. Warum sollte uns NIS2 interessieren?
Weil deine Kunden es sind. Wer betroffen ist, muss seine Lieferkette absichern und fragt Lieferanten nach SBOM, Patch-Fristen und Sicherheitsnachweisen. Wer das schon sauber liefern kann, hat im Vertrieb einen klaren Vorteil.
Baut ihr unser ISMS oder macht ihr Rechtsberatung?
Nein. Wir kümmern uns um die technische Seite: Architektur, Plattform, Pipelines und Betrieb. Mit deinem ISB, deinem Datenschutz und deiner Kanzlei stimmen wir uns gern direkt ab.
Reicht eine ISO-27001-Zertifizierung?
Sie ist eine gute Grundlage, weil sie viele Prozesse abdeckt, die NIS2 verlangt. Ob die Technik diese Prozesse auch durchsetzt, steht auf einem anderen Blatt. Genau das schauen wir uns an.
Läuft bei uns Kubernetes. Ist das ein Problem?
Im Gegenteil: Mit GitOps, Policy-as-Code und sauberen Pipelines lassen sich viele Anforderungen dort besonders gut automatisieren und nachweisen. Vorausgesetzt, die Plattform ist selbst sicher aufgesetzt.

Lass uns über deine NIS2-Baustellen sprechen.

Schreib uns, wo dein Team gerade steht und was dir Sorgen macht. Wir sagen dir ehrlich, wo die größten technischen Lücken liegen und womit du anfangen solltest.

Schreib uns

Du bekommst innerhalb eines Werktags eine Antwort. Das Erstgespräch ist kostenlos und unverbindlich.