NIS2 aus Engineering-Sicht: Was Software-Teams 2026 technisch vorbereiten sollten

Stand: Mai 2026 · Lesezeit: ca. 13 Minuten · Engineering-Perspektive · Keine Rechtsberatung

Das NIS2-Umsetzungsgesetz verändert die technische Bestandsaufnahme in deutschen Engineering-Teams seit Anfang 2026 spürbar — nicht nur in direkt regulierten Unternehmen, sondern über die Lieferkette auch bei SaaS-Anbietern, B2B-Plattformen und mittelständischen Software-Teams, die an betroffene Kunden liefern. Dieser Beitrag beschreibt, welche Architektur-, Code- und Prozessentscheidungen aus Engineering-Sicht jetzt anders ausfallen als noch vor zwei Jahren — und welche nicht. Er ist bewusst eine technische Einordnung, kein juristisches Gutachten.

Wichtigste Erkenntnisse

Worum es in diesem Artikel geht — und worum nicht

H-Studio ist eine Engineering-Agentur, keine Anwaltskanzlei. Dieser Artikel beschreibt typische technische Muster, die wir aus Gesprächen mit B2B-Engineering-Teams und SaaS-Unternehmen in der DACH-Region rund um das Thema NIS2-Umsetzungsgesetz beobachten. Wir geben damit eine technische Einordnung — kein juristisches Gutachten.

Was Sie hier finden: eine engineering-orientierte Beschreibung von Architektur-, Code- und Prozessentscheidungen, die unter den Vorzeichen des NIS2-Umsetzungsgesetzes in vielen Teams sinnvoll wirken. Was technisch in einer Plattform implementiert sein kann und was sinnvollerweise in eine ISMS-Dokumentation gehört. Welche technischen Investitionen erfahrungsgemäß den meisten Hebel haben.

Was Sie hier ausdrücklich nicht finden: eine Bewertung, ob Ihr konkretes Unternehmen vom NIS2-Umsetzungsgesetz erfasst ist. Eine Aussage darüber, ob bestimmte Maßnahmen in Ihrem Fall ausreichen. Eine Auslegung Ihrer Pflichten gegenüber Kunden oder Aufsichtsbehörden. Für diese Fragen ist eine auf IT-Recht spezialisierte Kanzlei der richtige Ansprechpartner. Den ausführlichen Hinweis dazu finden Sie am Ende des Artikels.

Stand des Gesetzes in wenigen Sätzen

Das NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) wurde Anfang Dezember 2025 im Bundesgesetzblatt veröffentlicht und trat am 6. Dezember 2025 in Kraft. Es reformiert das BSI-Gesetz grundlegend und setzt die EU-Richtlinie NIS2 in nationales Recht um. Nach den öffentlich verfügbaren Informationen gingen zentrale Pflichten mit Inkrafttreten des Gesetzes in die Umsetzung; für die konkrete Fristen- und Pflichtenlage Ihres Unternehmens sollten Sie eine rechtliche Prüfung einholen.

Für Einrichtungen, die seit Inkrafttreten betroffen waren, ergab sich nach Angaben des BSI eine Registrierungsfrist bis zum 6. März 2026. Wer später erstmals oder erneut in den Anwendungsbereich kommt, muss sich nach BSI-Angaben spätestens drei Monate nach Eintritt der Betroffenheit registrieren.

Nach öffentlich verfügbaren Schätzungen sind rund 29.500 Unternehmen in achtzehn Sektoren erfasst. Das Gesetz unterscheidet zwischen besonders wichtigen und wichtigen Einrichtungen, an die unterschiedliche Rechtsfolgen geknüpft sind. Die Einstufung Ihres Unternehmens ist eine rechtliche Bewertung, die wir hier nicht vornehmen.

Wen es technisch wirklich betrifft — die unbequeme Antwort

Selbst wenn Ihr Unternehmen nicht direkt in den Anwendungsbereich des Gesetzes fällt, kommen die Anforderungen über die Lieferkette mit hoher Wahrscheinlichkeit auf Sie zu. Wenn Sie B2B-Software, SaaS-Produkte oder digitale Dienstleistungen an Versicherungen, Energieversorger, Logistiker, Krankenhäuser oder mittlere bis große Industriebetriebe verkaufen, wird Ihr Kunde voraussichtlich Nachweise zu Ihrer IT-Sicherheitsarchitektur von Ihnen verlangen — vertraglich, nicht direkt gesetzlich.

Daraus ergibt sich eine praktische Konsequenz: Engineering-Teams sollten das Thema nicht mehr allein an Rechts- oder Compliance-Funktionen delegieren. Seit Anfang 2026 sehen wir bei B2B-Kunden teils umfangreiche Audit-Fragebögen mit achtzig bis zweihundert Punkten, von denen ein erheblicher Teil nur durch Engineering beantwortbar ist: Welche Verschlüsselung wird eingesetzt? Wie funktioniert das Backup? Welche Drittanbieter sind in der Lieferkette? Wie werden Logs aufbewahrt? Wie wird auf Schwachstellen reagiert?

Aus unseren Gesprächen mit Teams: Selbst kleinere SaaS-Anbieter mit zehn bis dreißig Mitarbeitern, die selbst nicht in den Anwendungsbereich fallen, bekommen diese Anfragen — und sie technisch sauber beantworten zu können, kann eine Voraussetzung dafür sein, im B2B-Geschäft mit Mittelstand und regulierten Kunden weiter Geschäft zu machen.

Was sich in Architektur und Code in der Praxis verschiebt

In den letzten Monaten haben wir mehrere Engineering-Teams begleitet, deren Architekturentscheidungen sich unter dem Einfluss von Kundenanforderungen und Audit-Fragen verändert haben. Hier sind die wiederkehrenden Muster, die heute anders ausfallen als noch vor zwei Jahren.

Logging und Aufbewahrung

Wo bisher Logs vor allem für Debugging und Monitoring betrieben wurden, sehen wir jetzt eine Verschiebung in Richtung forensisch verwertbar. In der Praxis heißt das: zentralisierte Aggregation, Append-Only-Schreibmuster oder WORM-Storage zur Sicherung der Integrität, Korrelationsmöglichkeiten zwischen Application-, Infrastructure- und Authentication-Logs. Ein Log, das man nachträglich verändern könnte, hat in einem Audit-Gespräch deutlich weniger Beweiskraft.

Aufbewahrungsfristen

Wo viele Teams bisher mit dreißig Tagen Log-Retention gearbeitet haben, sehen wir jetzt typische Kundenanforderungen von sechs bis zwölf Monaten — branchenabhängig auch länger. Das hat unmittelbare Auswirkungen auf S3-Lifecycle-Policies, auf Storage-Kosten und auf die Frage, was unter DSGVO-Gesichtspunkten so lange aufbewahrt werden kann. Die beiden Regulierungen können in dieser Frage in Spannung zueinander stehen, und der praktische Weg führt meistens über technische Maßnahmen: Pseudonymisierung, Trennung personenbezogener und rein technischer Logs, klar dokumentierte und durchgesetzte Löschkonzepte.

Backup-Architektur

Aus unserer Beobachtung sind die wirksamsten Hebel: eine 3-2-1-Strategie (drei Kopien, zwei Medien, eine off-site), mindestens ein Backup-Pfad, der logisch von der Produktivumgebung getrennt ist (Ransomware-Resilienz), und — der Punkt, den viele Teams in der Eile übersehen — regelmäßige, dokumentierte Restore-Tests. Ein Backup ohne dokumentierten Restore-Test ist in Audits schwer belastbar. Wir empfehlen mindestens quartalsweise einen vollständigen Restore-Test in einer Sandbox-Umgebung mit protokolliertem Ergebnis.

Identitäts- und Zugriffsmanagement

MFA wird in Audits und Kundenanforderungen zunehmend als Standard erwartet. Wichtiger noch: viele Audit-Fragebögen verlangen einen revisionsfähigen Audit-Trail darüber, wer wann was sehen, ändern oder exportieren konnte. Wenn Ihre Anwendung Kundendaten verarbeitet, sollte diese Information aus Ihren eigenen Application-Logs herausziehbar sein — nicht nur aus dem Audit-Log Ihres Cloud-Providers. Das ist eine Architekturentscheidung mit Konsequenzen für jedes neue Feature, das Lese- oder Schreibzugriff auf sensible Daten anbietet.

Verschlüsselung und Schlüsselverwaltung

Encryption at rest und Encryption in transit werden in jedem Audit-Fragebogen vorausgesetzt. Was sich verschoben hat, ist der Fokus auf die Schlüsselverwaltung selbst: Wer hat Zugriff auf die KMS-Keys? Wie wird dieser Zugriff dokumentiert? Wie und in welchen Intervallen rotieren Schlüssel? Wer hat im Notfall Recovery-Möglichkeiten? Das sind Themen, die Engineering-Teams häufig implizit an den Cloud-Provider abgeben — bei einem Kunden-Audit muss aber das eigene Unternehmen die Antworten haben.

Schwachstellen-Management

Auch hier sehen wir eine Verschiebung von informeller Praxis zu dokumentiertem Prozess: Dependabot oder Renovate als Bot in der Pipeline, automatische Vulnerability-Scans (Snyk, Trivy, npm audit für JavaScript-Stacks, OWASP Dependency-Check), und eine Policy, was bei einem CVE-Befund konkret passiert. Software Bill of Materials (SBOM) in den Formaten CycloneDX oder SPDX werden bei vielen Audits inzwischen explizit verlangt.

Das Meldeverfahren aus Engineering-Sicht

Das Gesetz sieht ein gestuftes Meldeverfahren vor — eine frühe Meldung mit ersten Hinweisen, eine detailliertere Folgemeldung und einen Abschlussbericht. Die konkrete Anwendung hängt vom Einzelfall, von der Art des Vorfalls und von der Einstufung des Unternehmens ab. Aus Engineering-Sicht ist die größte Herausforderung weniger das Schreiben der Meldung selbst, sondern das überhaupt rechtzeitige Erkennen eines potenziell meldepflichtigen Vorfalls.

In der Praxis braucht es drei Bausteine:

Erkennung

SIEM oder zumindest zentralisiertes Log-Aggregation mit Alerting auf relevante Events. Viele Teams arbeiten heute reaktiv und erfahren von einem Vorfall durch Kunden- oder Forscher-Meldungen. Für regulierte Unternehmen kann das perspektivisch nicht ausreichen. Tools wie Datadog Security Monitoring, Wazuh, Elastic Security oder die Security-Module der großen Cloud-Provider bringen Teams in wenigen Wochen auf ein vorzeigbares Niveau.

On-Call und Eskalation

Wer entscheidet, ob ein Vorfall als meldepflichtig einzustufen ist? Wer informiert wen? Wer schreibt die Meldung? Wer kommuniziert mit betroffenen Kunden? Diese Runbooks gehören in eine Dokumentation, die im Ernstfall an einem Sonntag um drei Uhr morgens auffindbar ist — idealerweise als Markdown im selben Repository wie der Code oder als klar verlinktes Notion/Confluence, das auch ohne aktive E-Mail-Infrastruktur erreichbar ist.

Redundante Kommunikationspfade

Wenn das eigene E-Mail-System Teil des Vorfalls ist (Ransomware, kompromittierte Konten, DNS-Probleme), brauchen Sie alternative Kommunikationskanäle. Sichere Out-of-Band-Kanäle — Signal, Threema, ausgedruckte Telefonliste — gehören in den Incident-Response-Plan.

Aus unserer Beobachtung sind die meisten Engineering-Teams in den ersten Monaten nach Inkrafttreten des Gesetzes damit beschäftigt, ihren Incident-Response-Prozess von informellem Bauchgefühl auf dokumentierte und testbare Prozesse zu heben. Das ist überraschend viel Arbeit, und nichts davon ist im Code direkt sichtbar — in Audit- oder Kundenprüfungen gehört es jedoch häufig zu den ersten Themen.

ISMS und Plattform — die Trennung, die viele übersehen

Eine Unterscheidung, die in der Praxis viel Verwirrung stiftet: Was muss in Ihrer Software tatsächlich technisch vorhanden sein, und was muss in einer organisatorischen ISMS-Dokumentation stehen?

Faustregel aus unserer Erfahrung:

Der häufigste Fehler in mittelständischen Setups: Engineering versucht, organisatorische Maßnahmen in Code zu pressen — „Wir bauen ein internes Compliance-Dashboard" — während das Management technische Maßnahmen in PowerPoint dokumentiert — „Wir haben eine Verschlüsselungsrichtlinie". Beides funktioniert nicht. Ein Dashboard ersetzt keine Risikoanalyse, und eine Folie ersetzt keine technisch implementierte Verschlüsselung.

Was funktioniert: technische Maßnahmen werden technisch implementiert und durch Tests, Monitoring und automatisierte Berichte überprüfbar gemacht. Organisatorische Maßnahmen werden dokumentiert, an klare Verantwortlichkeiten gekoppelt und durch regelmäßige Reviews lebendig gehalten. Die Schnittstelle zwischen beiden Welten ist das Reporting — ein Engineering-Team, das monatlich automatisierte Reports zu Patch-Status, Backup-Erfolg, Incident-Statistik und Vulnerability-Findings liefert, macht der Geschäftsleitung die Wahrnehmung ihrer Aufsichtspflichten deutlich leichter.

Supply Chain Security in der praktischen Umsetzung

Das Thema Lieferkettensicherheit ist eines der Felder, in denen sich aus Kundenanforderungen ein klares Anforderungsprofil ableiten lässt. Für ein typisches Next.js-Projekt, eine SaaS-Plattform oder eine moderne Webapplikation sehen wir vier wiederkehrende Bausteine:

Dependency-Hygiene. Ein dokumentiertes Update-Konzept — Dependabot oder Renovate als Bot, der automatisch Pull Requests öffnet, plus eine klare Policy, wer diese PRs in welchem Zeitrahmen reviewt und merged. In Projekten, in denen jede Woche fünf bis zehn Dependabot-PRs aufgemacht und ignoriert werden, ist die Bot-Einrichtung aus Audit-Sicht eher hinderlich — sie dokumentiert, dass die Schwachstelle bekannt war und nichts geschehen ist. Lieber weniger Automatisierung mit klarer Verantwortlichkeit als viel Automatisierung ohne Reaktion.

SBOM-Erzeugung. CycloneDX oder SPDX, automatisch bei jedem Build erzeugt und mindestens zwölf Monate archiviert. Wenn ein Kunde fragt, was in Ihrem Container läuft, sollten Sie das innerhalb von Stunden, nicht Tagen, beantworten können. Für Node.js-Projekte lässt sich das mit @cyclonedx/cyclonedx-npm direkt in die CI-Pipeline einbinden, für Docker-Images mit syft.

Lieferanten-Audit. Sie selbst sind Lieferant Ihrer Kunden, und Sie haben Lieferanten: Hosting (AWS, Azure, GCP, Hetzner, IONOS), CI/CD (GitHub Actions, GitLab CI), Monitoring (Datadog, Grafana Cloud, Sentry), Auth-Provider (Auth0, Clerk, Keycloak), CDN, E-Mail-Versand, Analytics. Jeder davon sollte in Ihrer ISMS-Dokumentation auftauchen, mit einer einfachen Risikoeinschätzung. Ein managed Auth-Provider und ein selbstgehostetes Keycloak können dabei in unterschiedliche Risikokategorien fallen — Sie sollten es bewertet und dokumentiert haben.

Vertragliche Anbindung. Wenn Sie auf einem Hyperscaler bauen, decken die Standardverträge der Anbieter (AWS Cybersecurity Addendum, Microsoft Online Services Terms, Google Cloud Data Processing Terms) viele der relevanten Klauseln ab. Diese Verträge aktiv einzubeziehen ist eine vertragliche Aufgabe. Die technische Information darüber, ob sie greifen und welche Region welche Garantien hat, ist Engineering-Wissen.

Sanktionen — sachliche Einordnung statt Panik

Der Gesetzestext sieht abgestufte Bußgelder vor, deren Höhe sich nach Einstufung und Umsatz richtet. Zusätzlich sieht das Gesetz Pflichten der Geschäftsleitung im Bereich Aufsicht und Kontrolle vor. Die genaue Höhe und Anwendung im Einzelfall ist eine rechtliche Frage, die nur durch eine spezialisierte Kanzlei bewertet werden kann.

Aus Engineering-Sicht ist die wichtigere Botschaft: Wie die konkrete Bußgeldpraxis der Aufsichtsbehörden unter dem neuen Gesetz aussehen wird, lässt sich derzeit nicht belastbar prognostizieren. Verlässliche Erfahrungswerte werden erst in den kommenden zwölf bis vierundzwanzig Monaten entstehen, wenn die ersten Verfahren öffentlich werden.

Was das für Engineering-Budgets praktisch bedeutet: In vielen Fällen müssen Teams keine perfekte Lösung über Nacht bauen. Sinnvoll ist eine realistische Zwölf-Monats-Roadmap mit klaren Meilensteinen, regelmäßigen internen Reviews und transparenter Risikoaufnahme — und die Dokumentation, dass diese Roadmap ernsthaft umgesetzt wird. Aus unserer Beobachtung wirkt das in Audit-Gesprächen oft glaubwürdiger als eine überstürzte Implementierung ohne Plan und ohne Nachweise.

Vier Engineering-Schritte, die sich in den ersten 30 Tagen lohnen

Wenn Sie heute mit dem Thema starten — sei es, weil Ihr Unternehmen voraussichtlich betroffen ist, sei es, weil Ihre Kunden Sie über die Lieferkette ansprechen — sind das die Schritte, mit denen wir Teams in den vergangenen Monaten am häufigsten begleitet haben.

Eins: Inventur. Welche Services laufen in welcher Umgebung? Welche Datenströme verbinden sie? Welche Drittanbieter sind beteiligt? Eine technische Bestandsaufnahme. Kein Auditor erwartet, dass Sie das im Kopf haben — aber dass Sie es auf Anfrage in einer Stunde bereitstellen können. Ein einfaches Inventory-Repository, gepflegt im Git neben dem Code, reicht für den Anfang.

Zwei: Log-Architektur prüfen. Gibt es zentralisiertes Logging? Sind Logs forensisch verwertbar — also nach dem Schreiben unveränderlich? Sind die Aufbewahrungsfristen ausreichend? Ist das Alerting auf relevante Events eingestellt? Wenn nicht, hat dieser Punkt erfahrungsgemäß den größten Hebel. Tools wie OpenSearch, Loki mit Grafana, Datadog oder New Relic bringen Teams in zwei bis vier Wochen auf ein vorzeigbares Niveau.

Drei: Incident-Response-Plan dokumentieren. Auch wenn es zunächst nur ein einseitiges Dokument ist — wer macht was bei einem Vorfall? Welche Kommunikationskanäle? Wer entscheidet über externe Meldungen? Wer informiert Kunden? Etwa achtzig Prozent davon sind Schreibarbeit, zwanzig Prozent Tooling. Wichtig ist nicht die Eleganz, sondern dass das Dokument im Ernstfall gefunden und befolgt werden kann.

Vier: Lieferantenliste aufstellen. Welche externen Dienste werden genutzt? Welche Verträge existieren? Welche Risikoeinschätzung gibt es pro Lieferant? Zu Beginn reicht eine Tabelle mit fünf Spalten: Lieferant, Funktion, Vertragsstand, Risikoeinschätzung, letzte Überprüfung. Diese Tabelle wird im Verlauf des Jahres organisch wachsen.

Was viele Teams in den ersten dreißig Tagen bewusst nicht als Erstes starten sollten: ein vollständiges ISO-27001-Zertifizierungsprojekt. Eine solche Zertifizierung kann auf zwölf bis achtzehn Monaten Sicht sinnvoll sein, bindet aber Engineering- und Management-Kapazität, die in vielen Fällen zuerst für die unmittelbaren technischen Hebel besser eingesetzt ist. Erst Substanz, dann Zertifikat.

Wo H-Studio hier hilft — und wo nicht

Wir bauen B2B-Websites, SaaS-Plattformen und Lead-Systeme auf einer Next.js-Architektur mit Headless-CMS, CRM- und Analytics-Anbindung. Wenn Ihr Unternehmen von NIS2-Anforderungen erfasst ist oder über Lieferkettenklauseln in die Pflicht kommt, fließen die technischen Themen aus diesem Artikel in die Architektur Ihrer Plattform ein — Logging, Verschlüsselung, Authentifizierung, Backup-Strategie, Monitoring, SBOM-Erzeugung, Dependency-Hygiene. Das ist unsere Domäne.

Was wir ausdrücklich nicht tun: rechtliche Beratung zur NIS2-Einstufung Ihres Unternehmens, ISMS-Zertifizierungsbegleitung im juristischen Sinn, Vertragsgestaltung mit Ihren Kunden oder Aufsichtsbehörden, juristische Bewertung Ihrer Meldepflichten. Für diese Themen verweisen wir an auf IT-Recht und Datenschutz spezialisierte Kanzleien.

Was wir häufig tun: Engineering-Teams technisch dabei begleiten, ihre Plattform NIS2-anschlussfähig zu machen. In bestehenden Architekturen — gerade in älteren WordPress-, Webflow- oder ungewarteten Custom-Stacks — die strukturellen Lücken identifizieren. Mit Ihrem Datenschutzbeauftragten und Ihrer Rechtsabteilung an einem Strang ziehen, damit die juristische und die technische Sicht nicht aneinander vorbeireden.

Wenn Sie einen ersten technischen Blick auf Ihre aktuelle Architektur und einen klaren Zwölf-Monats-Plan für die relevanten Engineering-Themen brauchen, ist ein 30-minütiges Erstgespräch der einfachste Einstieg. Verwandte Service-Seiten: Backend-Entwicklung, DevOps & Cloud Engineering, individuelle Plattformen & Business-Apps.

Quellen und weiterführende Informationen

• Bundesgesetzblatt: Gesetz zur Umsetzung der NIS-2-Richtlinie und zur Regelung wesentlicher Grundzüge des Informationssicherheitsmanagements in der Bundesverwaltung, BGBl. 2025 I Nr. 301
• Bundesamt für Sicherheit in der Informationstechnik (BSI): NIS-2-Pflichten für regulierte Unternehmen
• Bundesamt für Sicherheit in der Informationstechnik (BSI): Allgemeine Hinweise und FAQ zur NIS-2-Umsetzung
• Europäische Union: Richtlinie (EU) 2022/2555 (NIS2-Richtlinie)

Alle Quellen sind über die offiziellen Webseiten des Bundesgesetzblatts und des BSI öffentlich zugänglich. Stand der Recherche: Mai 2026.

Wichtiger Hinweis

Dieser Artikel gibt eine technische, engineering-orientierte Einordnung von Themen rund um das NIS2-Umsetzungsgesetz wieder, basierend auf öffentlich verfügbaren Quellen mit Stand Mai 2026. Er stellt keine Rechtsberatung im Sinne des Rechtsdienstleistungsgesetzes dar, ersetzt nicht die individuelle rechtliche Bewertung Ihres konkreten Falls und begründet kein Mandatsverhältnis.

Für die rechtliche Bewertung Ihrer NIS2-Betroffenheit, die Auslegung Ihrer Pflichten nach dem reformierten BSI-Gesetz, die Bewertung Ihrer ISMS-Maßnahmen sowie für die vertragliche Gestaltung mit Ihren Kunden und Lieferanten wenden Sie sich bitte an eine auf IT-Recht und Datenschutz spezialisierte Anwaltskanzlei.

Wir geben den Stand der Gesetzgebung und der öffentlich verfügbaren Diskussion mit der bestmöglichen Sorgfalt wieder, übernehmen aber keine Gewähr für Vollständigkeit, Aktualität oder Anwendbarkeit auf Ihren spezifischen Fall. Eine Haftung für Entscheidungen, die auf Grundlage dieses Artikels getroffen werden, ist ausgeschlossen.

Bei Fragen zur technischen Umsetzung einzelner Maßnahmen — Logging, Backup, Monitoring, Architektur-Reviews, SBOM-Erzeugung, Dependency-Management — erreichen Sie uns unter hello@h-studio-berlin.de.

Über H-Studio Berlin — Wir bauen Next.js-Websites und SaaS-Plattformen für B2B-Unternehmen, SaaS-Teams und Mittelstand in der DACH-Region. Architektur-first, mit Headless-CMS, CRM-Anbindung und EU-Hosting. Mehr über uns.