Skip to content
runtiq

NIS2-Compliance — Was dein Team 2026 wissen muss

Praktischer Guide zur NIS2-Compliance für Tech-Teams. Was die EU-Richtlinie verlangt, wann nationale Gesetze in Kraft treten, wie deine Hosting-Entscheidung die Compliance beeinflusst, und warum EU-souveräne Infrastruktur relevant ist.

Von runtiq Team

NIS2 ist in Kraft. Wenn dein Unternehmen 50+ Mitarbeiter hat oder 10M€+ Jahresumsatz macht und in der EU operiert, betrifft dich das wahrscheinlich.

Die Richtlinie (Directive 2022/2555) ist seit Januar 2023 in Kraft. Die Umsetzungsfrist war Oktober 2024. Nationale Gesetze treten jetzt in Kraft — in Deutschland seit Dezember 2025, in Österreich ab Oktober 2026, die meisten anderen EU-Länder folgen im Laufe von 2026.

Dieser Post erklärt:

  • Was NIS2 konkret verlangt und wen es betrifft
  • Wann nationale Gesetze tatsächlich in Kraft treten (Land für Land)
  • Warum deine Hosting-Entscheidung eine Compliance-Frage ist
  • Was du diese Woche tun kannst

Was ist NIS2?

NIS2 (Directive 2022/2555) ersetzt die ursprüngliche NIS-Richtlinie von 2016. Das Problem mit NIS1: zu viel Spielraum für die Mitgliedstaaten bei der Umsetzung — was zu inkonsistenten Sicherheitsstandards quer durch die EU geführt hat. NIS2 korrigiert das: breiterer Anwendungsbereich, strengere Anforderungen, echte Strafen. Für wesentliche Einrichtungen gehen die Bußgelder bis zu 10 Millionen Euro oder 2% des weltweiten Jahresumsatzes.

Das Kernziel ist, das Sicherheitsniveau von Organisationen anzuheben, die kritische oder wichtige Dienste in der EU betreiben. Stell dir NIS2 wie die DSGVO vor — aber für deine Sicherheitsoperationen statt für deine Datenverarbeitung.

Nationale Umsetzung — Wo stehen wir 2026?

Die EU-Frist zur Umsetzung von NIS2 in nationales Recht war Oktober 2024. Die meisten Mitgliedstaaten haben sie verpasst. Im Mai 2025 hat die Europäische Kommission Vertragsverletzungsverfahren gegen 19 von 27 Mitgliedstaaten eingeleitet — darunter Deutschland, Frankreich, Österreich, die Niederlande, Spanien und Polen.

Die nationalen Gesetze treten nun im Laufe von 2025 und 2026 in Kraft:

Deutschland — NIS2UmsuCG (in Kraft seit Dezember 2025)

Deutschlands NIS2-Umsetzungsgesetz (NIS2UmsuCG) wurde am 5. Dezember 2025 veröffentlicht und trat sofort in Kraft. Über 30.000 Unternehmen sind betroffen — ca. 8.250 „besonders wichtige” und 21.600 „wichtige” Einrichtungen. Es gibt keine Übergangsfristen: Pflichten gelten ab der Registrierung beim BSI, die innerhalb von 3 Monaten nach Selbstidentifikation erfolgen muss.

Österreich — NISG 2026 (in Kraft ab 1. Oktober 2026)

Österreichs NISG 2026 wurde am 23. Dezember 2025 kundgemacht und tritt am 1. Oktober 2026 in Kraft. Wichtige Meilensteine danach:

  • 1. Jänner 2027 — Registrierung bei der Behörde muss abgeschlossen sein
  • 1. Oktober 2027 — Selbstdeklaration über umgesetzte Risikomanagementmaßnahmen fällig
  • 1. Oktober 2028 — frühester Zeitpunkt, zu dem die Behörde ein unabhängiges Audit verlangen kann

Bis 1. Oktober 2026 bleibt das bestehende NISG 2018 in Kraft.

Andere EU-Länder

Belgien, Kroatien, Griechenland, Italien, Litauen, Malta, Rumänien und die Slowakei waren nicht vom Vertragsverletzungsverfahren im Mai 2025 betroffen — was darauf hindeutet, dass sie umgesetzt haben oder kurz davor stehen. Die übrigen 19 Länder (darunter Frankreich, Spanien, Niederlande, Polen und die nordischen Staaten) werden voraussichtlich im Laufe von 2026 ihre nationale Gesetzgebung finalisieren.

Wer ist betroffen?

NIS2 teilt betroffene Organisationen in zwei Kategorien.

Wesentliche Einrichtungen

Diese unterliegen den strengsten Pflichten und proaktiver Aufsicht durch Regulierungsbehörden:

  • Energie, Verkehr, Bankwesen, Finanzmarktinfrastruktur
  • Gesundheit, Trinkwasser, Abwasser
  • Digitale Infrastruktur — DNS-Anbieter, TLD-Registries, Cloud-Anbieter, Rechenzentren, CDNs
  • IKT-Dienstverwaltung — Managed Service Provider, Managed Security Service Provider
  • Öffentliche Verwaltung

Wichtige Einrichtungen

Gleiche technische Anforderungen, aber die Aufsicht ist reaktiv — Audits werden durch Vorfälle oder Beschwerden ausgelöst, nicht proaktiv:

  • Post- und Kurierdienste
  • Abfallwirtschaft
  • Chemikalien, Lebensmittelproduktion
  • Fertigung (Medizinprodukte, Elektronik, Maschinen, Kraftfahrzeuge)
  • Digitale Anbieter — Online-Marktplätze, Suchmaschinen, soziale Netzwerke

Der Schwellenwert

Der allgemeine Größenschwellenwert liegt bei 50+ Mitarbeitern oder 10M€+ Jahresumsatz. Organisationen über diesem Schwellenwert in betroffenen Sektoren sind wahrscheinlich erfasst — aber sektorspezifische Regeln variieren, und einige kritische Sektoren haben überhaupt keinen Größenschwellenwert. Prüfe Anhang I und II der Richtlinie für die vollständige Liste der betroffenen Sektoren und ihre spezifischen Kriterien.

Du kannst auch indirekt betroffen sein. Wenn dein Produkt Kunden in wesentlichen oder wichtigen Sektoren bedient, bist du Teil ihrer Lieferkette. NIS2 Artikel 21 verlangt explizit, dass betroffene Einrichtungen die Lieferkettensicherheit managen. Deine Kunden werden anfangen, dich nach deiner Sicherheitslage zu fragen. Fragebögen, vertragliche Sicherheitsklauseln und Prüfungsrechte werden Standard in Enterprise-Deals.

Kernanforderungen

1. Risikomanagement (Art. 21)

NIS2 Artikel 21 listet einen Mindestsatz an Sicherheitsmaßnahmen auf. Das sind keine Empfehlungen:

  • Risikoanalyse und Sicherheitsrichtlinien — dokumentiert, regelmäßig überprüft, nicht nur ein PDF das niemand liest
  • Incident-Handling — definierte Verfahren für Erkennung, Reaktion und Wiederherstellung
  • Business Continuity — Backup-Management, Disaster Recovery, Krisenmanagement
  • Lieferkettensicherheit — tatsächliche Bewertung der Sicherheitspraktiken deiner Lieferanten, nicht nur eine Checkbox
  • Sichere Entwicklungspraktiken — Schwachstellenmanagement, Sicherheit bei der Beschaffung von Netz- und Informationssystemen
  • Kryptografierichtlinien — Verschlüsselung im Ruhezustand und bei der Übertragung, Schlüsselmanagement
  • Personalsicherheit — Zugangskontrolle, Need-to-know-Prinzip, Sicherheitsschulungen
  • Multi-Faktor-Authentifizierung — für alle relevanten Zugangspunkte erforderlich

Das meiste davon ist Standard-Sicherheitshygiene — aber das Schlüsselwort ist dokumentiert. NIS2 verlangt, dass du deine Arbeit zeigst.

2. Meldepflichten

Das ist der operativ anspruchsvollste Teil. Erhebliche Vorfälle müssen deinem nationalen CSIRT (Computer Security Incident Response Team) innerhalb enger Fristen gemeldet werden:

  • 24 Stunden: Frühwarnung, nachdem du von einem erheblichen Vorfall Kenntnis erlangt hast
  • 72 Stunden: Vorfallsmeldung mit erster Bewertung — Schweregrad, Kompromittierungsindikatoren
  • 1 Monat: Abschlussbericht mit vollständigen Details, Ursachenanalyse und Abhilfemaßnahmen

Ein “erheblicher Vorfall” ist einer, der schwere Betriebsstörungen oder finanzielle Verluste verursacht oder verursachen könnte, oder andere Organisationen betrifft. Die Schwelle ist niedriger als du vielleicht denkst — das betrifft nicht nur große Datenpannen.

3. Lieferkettensicherheit

NIS2 verlangt explizit, dass Organisationen die Sicherheitspraktiken ihrer direkten Lieferanten und Dienstleister bewerten. Das hat einen Kaskadeneffekt durch das gesamte Ökosystem.

Für deine eigene Lieferkette musst du bewerten:

  • Deine Cloud- und Hosting-Anbieter — Jurisdiktion, Zertifizierungen, Sicherheitspraktiken
  • Drittanbieter-Software und Open-Source-Abhängigkeiten
  • Managed Service Provider mit Zugang zu deinen Systemen
  • SaaS-Tools, die sensible Daten berühren

DORA: Die Parallele für den Finanzsektor

Wenn du für Finanzdienstleistungen baust, musst du auch DORA kennen — den Digital Operational Resilience Act, der ab Januar 2025 gilt. DORA überschneidet sich erheblich mit NIS2, geht aber für Finanzunternehmen weiter: verpflichtende IKT-Risikomanagement-Frameworks, Vorfallsklassifizierung und -meldung, Tests der digitalen operativen Resilienz einschließlich Penetrationstests, und strenge Anforderungen für IKT-Drittanbieter.

Wenn du als Anbieter in den Finanzsektor verkaufst, werden die DORA-Pflichten deiner Kunden vertraglich auf dich abgewälzt. Die Infrastruktur- und Sicherheitspraktiken, die du für NIS2 brauchst, sind weitgehend dieselben, die du brauchst, um DORA-Lieferkettenanforderungen zu erfüllen.

Wie die Hosting-Wahl die NIS2-Readiness beeinflusst

Dein Infrastrukturanbieter ist Teil deiner Lieferkette. Unter NIS2 musst du seine Sicherheitspraktiken bewerten und dokumentieren. Das macht die Hosting-Entscheidung zu einer Compliance-Frage, nicht nur zu einer operativen.

Datenresidenz und Jurisdiktion

NIS2 schreibt keine EU-exklusive Datenspeicherung vor, aber es verlangt, dass du Risiken managst. Daten außerhalb der EU einzulagern bringt rechtliche und operative Risiken mit sich, die schwer zu kontrollieren sind. US-Cloud-Anbieter unterliegen US-Recht, einschließlich CLOUD Act-Anfragen, die mit EU-Datenschutzpflichten kollidieren können. Das ist keine Hypothese — es ist eine reale Spannung, die die Rechtsabteilungen deiner Kunden ansprechen werden.

Für Organisationen, die EU-Kunden in regulierten Sektoren bedienen, bedeutet NIS2-konformes Hosting zunehmend Hosting, das Daten und Betrieb innerhalb der EU-Jurisdiktion hält, mit Anbietern, die ihre eigenen Sicherheitszertifizierungen nachweisen können — ISO 27001, SOC 2, BSI C5.

Souveränität und Kontrolle

EU-souveräne Infrastruktur — vollständig innerhalb der EU gehostet und betrieben, von EU-ansässigen Unternehmen — reduziert rechtliche und regulatorische Risiken. Du weißt, welche Jurisdiktion deine Daten regelt, welche Gerichte zuständig sind, und welchen Regulierungsbehörden du gegenüber rechenschaftspflichtig bist.

Das ist wichtig, weil deine Kunden in regulierten Branchen diese Fragen stellen werden. “Unsere Infrastruktur ist souverän, in der EU gehostet, von einem österreichischen Unternehmen betrieben” ist eine viel sauberere Antwort als die Datenübertragungsmechanismen und Standardvertragsklauseln (SCCs) zu erklären, die du mit einem US-Hyperscaler verwendest.

Zertifizierungen und Audit-Nachweise

NIS2 verlangt, dass du deine Risikomanagementmaßnahmen dokumentierst. Ein Hosting-Anbieter mit relevanten Zertifizierungen gibt dir Audit-Nachweise, auf die du verweisen kannst. Das ist viel einfacher als zu versuchen, gleichwertige Zusicherungen aus der generischen Compliance-Dokumentation eines großen Cloud-Anbieters herauszuziehen — die zwar umfangreich, aber nicht spezifisch ist.

Praktische NIS2-Checkliste

Verwende das als Ausgangspunkt, nicht als Ersatz für eine Rechtsberatung.

Scoping

  • Größenschwellenwert bestimmen — hat dein Unternehmen 50+ Mitarbeiter oder 10M€+ Jahresumsatz? Wenn ja und du in einem betroffenen Sektor operierst, arbeite den Rest dieser Liste durch.
  • Sektor identifizieren — ist er als wesentlich oder wichtig unter NIS2 gelistet? Prüfe Anhang I und II der Richtlinie für die vollständige Liste.
  • Kundenexposition bewerten — auch wenn du unter dem Schwellenwert liegst: Sind deine Kunden NIS2-betroffene Einrichtungen? Wenn ja, werden ihre Lieferkettenanforderungen vertraglich auf dich abgewälzt.

Risikomanagement

  • Sicherheitsrichtlinien dokumentieren — fang mit einem einfachen Dokument an, das deine Zugriffskontrollen, Verschlüsselungsstandards und Update-Verfahren auflistet. Alle 6 Monate überprüfen. Ein 5-seitiges Dokument, das du tatsächlich befolgst, ist besser als ein 50-seitiges, das niemand liest.
  • Formale Risikoanalyse durchführen — identifiziere deine kritischen Systeme, die Bedrohungen, denen sie ausgesetzt sind, und die Kontrollen, die du hast. Ergebnisse dokumentieren.
  • MFA implementieren — für alle administrativen Zugänge. Authenticator-App verwenden, nicht SMS wenn möglich.
  • Verschlüsselungsstandards definieren — im Ruhezustand und bei der Übertragung. Dokumentieren, welche Algorithmen du verwendest, wo Schlüssel gespeichert sind, und wer Zugang hat.

Incident Response

  • “Erheblichen Vorfall” definieren — schreib auf, was das für deine spezifischen Systeme bedeutet. Beispiele: “jede Verletzung von Kundendaten”, “jeder Ausfall über 4 Stunden”, “jeder unbefugte Zugang zur Produktion”. Konkret genug, dass dein On-Call-Engineer um 2 Uhr nachts die Entscheidung treffen kann.
  • Incident-Response-Runbook erstellen — mit klarer Eigentümerschaft und Eskalationspfaden. Wer erklärt einen Vorfall? Wer erstellt den 24h-Bericht? Wer ist der rechtliche Ansprechpartner?
  • Nationales CSIRT identifizieren — finde das Meldeportal deines Landes im ENISA CSIRT-Verzeichnis und bookmarke es.
  • Incident Response testen — mindestens jährlich einen simulierten Vorfall durchspielen. Rollen zuweisen, einen Mock-Bericht erstellen, die Zeit messen. Gefundene Lücken schließen.

Lieferkette

  • Kritische Lieferanten inventarisieren — Cloud, Hosting, SaaS-Tools mit Datenzugang. Eine einfache Liste mit Anbietername, welche Daten sie berühren, und ihren Zertifizierungen reicht zum Start.
  • Zertifizierungen oder Fragebogen-Antworten einholen — von wichtigen Lieferanten. Nach ISO 27001 oder SOC 2 Zertifikaten fragen. Wenn sie keine liefern können, ist das selbst ein zu dokumentierendes Risiko.
  • Verträge prüfen — auf Sicherheitsklauseln, Auftragsverarbeitungsverträge (AVVs) und Prüfungsrechte. Wenn ein wichtiger Lieferant keine Sicherheitsklauseln in deinem Vertrag hat, bei der Verlängerung hinzufügen.
  • Hosting-Anbieter bewerten — Jurisdiktion, Zertifizierungen, Sicherheitspraktiken. Können sie antworten: Wo liegen deine Daten physisch? Wer kann darauf zugreifen? Welche Zertifizierungen haben sie?

Business Continuity

  • Backup-Strategie dokumentieren — was gesichert wird, wie oft, wo Backups gespeichert sind, und wie lange die Wiederherstellung dauert. Wiederherstellung mindestens vierteljährlich testen.
  • RTO und RPO definieren — RTO ist, wie schnell du nach einem Ausfall wiederherstellen musst. RPO ist, wie viel Datenverlust du dir leisten kannst. Aufschreiben und vierteljährlich testen.
  • Disaster-Recovery-Plan dokumentieren — wer macht was, wenn die Produktion ausfällt? Auch ein einseitiges Runbook ist besser als nichts.

Schulung und Governance

  • Führungsebene informieren — die Managerhaftung ist in der Richtlinie explizit. Dein CEO und Vorstand müssen verstehen, was NIS2 verlangt, und deinen Compliance-Ansatz absegnen.
  • Sicherheitsbewusstseinstraining durchführen — für alle Mitarbeiter, mindestens jährlich. Phishing-Simulationen, Passworthygiene, wie man verdächtige Aktivitäten meldet.
  • Einen namentlichen Verantwortlichen benennen — für NIS2-Compliance. Jemand muss das besitzen, die Checkliste verfolgen und Ansprechpartner für Audits und Vorfälle sein.

Genau dafür haben wir runtiq gebaut

NIS2-Compliance ist eine laufende operative Aufgabe. Für viele Unternehmen ist der Infrastrukturteil am schwierigsten — EU-souveränes Hosting einrichten, Zertifizierungen sammeln, Vorfallsberichte vorbereiten, die Lieferkette dokumentieren.

Genau dafür haben wir runtiq gebaut. Wir übernehmen diese Last, damit du dich auf dein Produkt konzentrieren kannst:

  • EU-souveräne Infrastruktur von Anfang an — deine Workloads laufen in EU-Rechenzentren, betrieben von einem EU-eingetragenen Unternehmen. Keine CLOUD Act-Exposition. Keine komplexen Datenübertragungsmechanismen.
  • Compliance-Nachweise automatisch geliefert — Zertifizierungen, Audit-Berichte und Lieferkettendokumentation bereit für deinen nächsten Lieferantenfragebogen.
  • Incident-Reporting-Unterstützung — vordefinierte Workflows und Berichtsvorlagen, die dir helfen, die 24h/72h/1-Monat NIS2-Meldefristen einzuhalten.
  • Business Continuity eingebaut — automatisierte Backups mit dokumentierten RTO/RPO-Garantien.

Für KMUs ist die Frage nicht ob NIS2 gilt — für die meisten Unternehmen über dem Schwellenwert gilt es. Die Frage ist, wie viel von der Compliance-Arbeit du selbst machen willst versus von deinem Infrastrukturanbieter erledigen lässt.

Wir haben runtiq gebaut, damit die Antwort auf die Compliance-Fragen deiner Kunden einfach und dokumentiert ist. Sieh dir unsere Pläne an.