01 Wissen · NIS2
NIS2: wer betroffen ist und was technisch zu tun ist
Das NIS2-Umsetzungsgesetz gilt seit dem 6. Dezember 2025, ohne Übergangsfrist und für rund 29.500 Unternehmen in Deutschland. Diese Seite ordnet ein, wer erfasst ist, welche Pflichten daraus folgen und was davon die Infrastruktur betrifft. Sie ersetzt keine Rechtsberatung.
02 Kurzfassung
Das Wichtigste in Kürze
- Das NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) ist seit dem 6. Dezember 2025 in Kraft und hat das BSI-Gesetz neu gefasst. Eine Übergangsfrist gibt es nicht.
- Der Kreis der beaufsichtigten Unternehmen wächst von etwa 4.500 auf rund 29.500. Wer dazugehört, steht in § 28 BSIG und ergibt sich aus Sektor, Einrichtungsart und Größe.
- Es gibt zwei Klassen: besonders wichtige und wichtige Einrichtungen. Die Pflichten sind weitgehend gleich, der Bußgeldrahmen und die Aufsicht unterscheiden sich.
- Die Registrierungsfrist lief am 6. März 2026 ab, die Nachfrist des BSI endete am 31. Juli 2026. Eine noch offene Registrierung ist unverzüglich nachzuholen.
- Betroffene Unternehmen identifizieren sich selbst. Es gibt keinen Bescheid, der die Betroffenheit feststellt, und keine Anmeldung, auf die eine Behörde vorher reagiert.
- Technisch verlangt § 30 Abs. 2 Nr. 3 BSIG die Aufrechterhaltung des Betriebs: Backup-Management, Wiederherstellung nach einem Notfall und Krisenmanagement. Der Nachweis entscheidet, nicht die Absicht.
Was NIS2 ist und wie daraus deutsches Recht wurde
NIS2 ist die zweite europäische Richtlinie zur Netz- und Informationssicherheit. Sie löst die erste NIS-Richtlinie ab, erweitert den Kreis der erfassten Sektoren deutlich und verschiebt den Schwerpunkt: weg von der Meldung einzelner Vorfälle, hin zu einem Risikomanagement, das im laufenden Betrieb funktioniert und belegbar ist.
Eine Richtlinie gilt nicht unmittelbar. Sie verpflichtet die Mitgliedstaaten, eigenes Recht zu schaffen. In Deutschland ist das über das NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz geschehen, kurz NIS2UmsuCG. Es hat das BSI-Gesetz neu gefasst. Wenn im Alltag von NIS2-Pflichten gesprochen wird, sind deshalb in der Sache die Paragrafen des BSIG gemeint: § 28 für die Frage, wer erfasst ist, § 30 für die Maßnahmen.
Das Gesetz ist am 6. Dezember 2025 in Kraft getreten, ohne Übergangsfrist. Der Kreis der Unternehmen unter Aufsicht des Bundesamts für Sicherheit in der Informationstechnik wächst damit von etwa 4.500 auf rund 29.500. Für die meisten dieser Unternehmen ist es das erste Mal, dass IT-Sicherheit für sie eine unmittelbare gesetzliche Pflicht ist und nicht eine interne Richtlinie.
Drei Dinge, die in der Praxis überraschen
- Selbst-Identifizierung. Niemand schreibt Ihnen, dass Sie betroffen sind. Die Einordnung ist Ihre Aufgabe, und sie ist auch dann verbindlich, wenn sie unterbleibt.
- Kein Stufenplan. Die Pflichten gelten seit dem ersten Tag vollständig, nicht nach und nach.
- Die Lieferkette zählt mit. Wer selbst nicht erfasst ist, bekommt die Anforderungen über Kunden und Ausschreibungen trotzdem auf den Tisch.
Wer betroffen ist: Sektor, Einrichtungsart, Größe
§ 28 BSIG unterscheidet besonders wichtige und wichtige Einrichtungen. Die Zuordnung läuft über drei Prüfungen, die in dieser Reihenfolge abgearbeitet gehören.
1. Sonderfälle, für die keine Größe gilt
Betreiber kritischer Anlagen, qualifizierte Vertrauensdiensteanbieter, Top Level Domain Name Registries und DNS-Diensteanbieter sind unabhängig von ihrer Größe besonders wichtige Einrichtungen. Anbieter öffentlich zugänglicher Telekommunikationsdienste und Betreiber öffentlicher Telekommunikationsnetze sind mindestens wichtige Einrichtungen, ab mittlerer Größe besonders wichtige. Für Einrichtungen der Bundesverwaltung gilt nicht § 28, sondern § 29 BSIG.
2. Sektor und Einrichtungsart
Anlage 1 des BSIG nennt sieben Sektoren: Energie, Transport und Verkehr, Finanzwesen, Gesundheit, Wasser, digitale Infrastruktur und IT-Dienste sowie Weltraum. Anlage 2 nennt sieben weitere: Post- und Kurierdienste, Abfallbewirtschaftung, chemische Stoffe, Lebensmittel, verarbeitendes Gewerbe, Anbieter digitaler Dienste und Forschung. Entscheidend ist nicht die Branche im Alltagssinn, sondern ob eine der dort bestimmten Einrichtungsarten auf das Unternehmen zutrifft. Im Sektor digitale Infrastruktur sind das etwa Anbieter von Cloud-Computing-Diensten, Anbieter von Rechenzentrumsdiensten, Managed Services Provider und Managed Security Services Provider.
3. Größe
| Klasse | Anlage | Schwelle |
|---|---|---|
| Besonders wichtige Einrichtung | 1 | ab 250 Mitarbeitende oder über 50 Mio. € Umsatz und über 43 Mio. € Bilanzsumme |
| Wichtige Einrichtung | 1 oder 2 | ab 50 Mitarbeitende oder über 10 Mio. € Umsatz und über 10 Mio. € Bilanzsumme |
Zwei Regeln verschieben das Ergebnis regelmäßig. Nach § 28 Abs. 3 BSIG darf eine Tätigkeit unberücksichtigt bleiben, die gemessen an der gesamten Geschäftstätigkeit vernachlässigbar ist. Und nach § 28 Abs. 4 BSIG zählen Mitarbeitende, Umsatz und Bilanzsumme von Partner- und verbundenen Unternehmen mit, es sei denn, das Unternehmen betreibt seine IT-Systeme, Komponenten und Prozesse unabhängig von der Gruppe. Beide Einschätzungen sollten dokumentiert sein, sie werden im Zweifel geprüft.
Selbst einordnen. Der NIS2-Betroffenheits-Check geht diese Kriterien in bis zu neun Fragen mit Ihnen durch und nennt zum Ergebnis die Norm und eine Begründung. Das BSI bietet unter betroffenheitspruefung-nis-2.bsi.de eine eigene, anonyme Prüfung an. Beide sind Ersteinschätzungen, keine der beiden ist rechtsverbindlich.
Fristen und Registrierung: der Stand ist verstrichen
Die Terminlage ist unangenehm eindeutig. Das Gesetz gilt seit dem 6. Dezember 2025. Die Registrierungsfrist lief am 6. März 2026 ab, die Nachfrist des BSI endete am 31. Juli 2026. Beide Termine sind vorbei. Wer bis heute nicht registriert ist, holt das unverzüglich nach und befindet sich bis dahin in einem sanktionsfähigen Zustand.
Die Registrierung erfolgt beim BSI und ist kein Antrag, über den entschieden wird. Sie ist eine Meldung: Das Unternehmen teilt mit, dass es sich als wichtige oder besonders wichtige Einrichtung einordnet, und benennt Kontaktdaten und Sektorzuordnung. Genau deshalb ist die Einordnung nach § 28 BSIG der eigentliche erste Schritt, nicht das Formular.
Was bei verspäteter Registrierung sinnvoll ist
- Die eigene Einordnung sauber herleiten und schriftlich festhalten, mit Sektor, Einrichtungsart, Größenklasse und der Gruppenfrage aus § 28 Abs. 4 BSIG.
- Registrieren, ohne auf einen fertigen Maßnahmenstand zu warten. Die Registrierung ist nicht die Bestätigung, dass alles umgesetzt ist.
- Parallel den technischen Stand erheben und die Lücken mit Datum, Verantwortlichem und geplanter Umsetzung dokumentieren. Ein belegter Plan ist im Aufsichtsfall etwas anderes als gar nichts.
Eine Beobachtung aus Erstgesprächen: Häufig ist die Registrierung erledigt und der technische Teil nicht begonnen, weil die Registrierung wie ein Abschluss wirkt. Sie ist der Anfang. Die Pflichten aus § 30 BSIG hängen nicht an ihr, sie gelten ohnehin.
Kostenloses Whitepaper · 8 Seiten
Digitale Souveränität
Von Andreas Hankel, CTO onehundred. Download gegen E-Mail-Adresse, ohne Vertriebsanruf.
Die Pflichten: Risikomanagement, Meldung, Registrierung, Haftung
Für beide Klassen gelten weitgehend dieselben Pflichten. Sie lassen sich in vier Blöcke fassen.
Risikomanagement
§ 30 BSIG verlangt geeignete, verhältnismäßige technische und organisatorische Maßnahmen, um Risiken für die genutzten IT-Systeme zu beherrschen und Auswirkungen von Sicherheitsvorfällen gering zu halten. Das Gesetz zählt dafür Bereiche auf, unter anderem in § 30 Abs. 2 Nr. 3 BSIG die Aufrechterhaltung des Betriebs mit Backup-Management, Wiederherstellung nach einem Notfall und Krisenmanagement. Verhältnismäßig heißt: Das Risiko bestimmt die Tiefe der Maßnahme, und diese Abwägung müssen Sie begründen können.
Meldepflichten
Erhebliche Sicherheitsvorfälle sind dem BSI zu melden, gestuft von einer ersten kurzen Meldung bis zu einem Abschlussbericht. Praktisch heißt das: Es braucht vorher einen definierten Prozess, eine benannte Rolle und eine Entscheidungshilfe dafür, was als erheblich gilt. Wer diese Fragen erst im Vorfall klärt, verliert die Zeit, die das Verfahren gerade nicht vorsieht.
Registrierung und Nachweise
Dazu kommen die Registrierung beim BSI und die Pflicht, Auskunft über den Stand der Umsetzung geben zu können. Besonders wichtige Einrichtungen unterliegen der laufenden Aufsicht des BSI. Betreiber kritischer Anlagen müssen die Umsetzung zusätzlich alle drei Jahre nachweisen.
Verantwortung der Geschäftsleitung und Bußgelder
Die Geschäftsleitung ist für die Umsetzung verantwortlich, sie kann das nicht vollständig in die IT delegieren. Der Bußgeldrahmen unterscheidet die beiden Klassen: bis 10 Mio. € oder 2 Prozent des weltweiten Jahresumsatzes für besonders wichtige Einrichtungen, bis 7 Mio. € oder 1,4 Prozent für wichtige Einrichtungen. Maßgeblich ist jeweils der höhere Betrag.
Was das für die Infrastruktur heißt: Backup, Wiederanlauf, RPO und RTO
Von allen Pflichten ist die aus § 30 Abs. 2 Nr. 3 BSIG diejenige, die am direktesten auf die Plattform durchschlägt. Aufrechterhaltung des Betriebs bedeutet nicht, dass gesichert wird. Es bedeutet, dass ein definierter Zustand innerhalb einer definierten Zeit wieder erreichbar ist und dass das geprüft wurde.
Zielwerte zuerst
Am Anfang stehen zwei Größen je Anwendung. Das RPO (Recovery Point Objective) beschreibt, wie viel Datenverlust hinnehmbar ist, also wie weit der Wiederanlaufpunkt zurückliegen darf. Das RTO (Recovery Time Objective) beschreibt, wie lange die Wiederherstellung dauern darf. Das Gesetz nennt für beides keine Zahlen. Sie leiten die Werte aus der Kritikalität her, und diese Werte bestimmen anschließend die Architektur, nicht umgekehrt.
Die Architektur folgt daraus
- Räumliche Trennung. Kopien in einem zweiten Rechenzentrum, mit eigenen Zugängen. Ein Backup-Server neben der Produktion teilt deren Ausfall und deren Angreifer.
- Unveränderbarkeit. Ein Immutable Backup lässt sich für einen festgelegten Zeitraum nicht ändern oder löschen, auch nicht mit administrativen Rechten. Ergänzend eine Kopie ohne ständige Netzverbindung.
- Geprobter Wiederanlauf. Disaster Recovery ist ein Verfahren, kein Produkt. Es zählt erst, wenn es einmal vollständig durchgelaufen ist, mit gemessener Dauer gegen das vereinbarte RTO.
- Reproduzierbarkeit. Konfiguration als Code, Dokumentation im Repository. Wer den Zustand nicht reproduzieren kann, kann ihn auch nicht wiederherstellen.
Business Continuity Management ist der größere Rahmen
Disaster Recovery beantwortet die technische Frage: Wie kommt das System zurück? Business Continuity Management beantwortet die betriebliche: Wie läuft das Geschäft weiter, solange es nicht zurück ist? Dazu gehören Ausweichprozesse, Zuständigkeiten, Kommunikation und die Frage, welcher Prozess welche Anwendung wirklich braucht. NIS2 verlangt beides, und die Reihenfolge ist BCM vor Technik: Erst die Kritikalität der Prozesse, dann die Zielwerte, dann die Plattform.
Wie das konkret gebaut und betrieben wird, steht auf unserer Seite zur NIS2-Beratung für Backup und Disaster Recovery.
Abgrenzung zu DORA: für Finanzunternehmen gilt die Spezialregel
Für den Finanzsektor gibt es ein eigenes europäisches Regelwerk: die DORA-Verordnung (EU) 2022/2554 über die digitale operationale Resilienz. Sie regelt dieselben Themenfelder, IKT-Risikomanagement, Vorfallmeldung, Tests und das Management von Drittanbieterrisiken, für Banken, Versicherungen, Wertpapierfirmen und weitere Finanzunternehmen.
Das Verhältnis der beiden Regelwerke ist geklärt. Nach § 28 Abs. 6 BSIG gelten die zentralen Pflichten des BSIG nicht für Finanzunternehmen, die unter DORA fallen. Die Einordnung als wichtige oder besonders wichtige Einrichtung bleibt bestehen, die Aufsicht über die IT-Sicherheitsanforderungen läuft aber über DORA und die zuständige Finanzaufsicht.
Drei praktische Unterschiede
- Verordnung statt Richtlinie. DORA gilt unmittelbar in allen Mitgliedstaaten, es gibt kein nationales Umsetzungsgesetz dazwischen.
- Drittanbieter im Fokus. DORA reguliert die Verträge mit IKT-Dienstleistern deutlich detaillierter, inklusive Ausstiegsstrategien.
- Testpflichten. DORA verlangt ein Testprogramm für die digitale Resilienz, für bestimmte Unternehmen bis hin zu bedrohungsgeleiteten Penetrationstests.
Für IT-Dienstleister mit Kunden aus der Finanzbranche heißt das: Die Anforderungen kommen über den Vertrag, auch wenn das eigene Unternehmen gar nicht unter DORA fällt. Technisch laufen NIS2 und DORA in dieselbe Richtung. Wer dokumentierte Verfahren, getestete Wiederherstellung und nachvollziehbare Zuständigkeiten hat, bedient beide Regelwerke mit derselben Substanz.
Fünf Fehler, die uns in Erstgesprächen regelmäßig begegnen
Die Muster wiederholen sich, quer durch Branchen und Unternehmensgrößen.
1. Die Betroffenheit wird geschätzt statt hergeleitet
„Wir sind zu klein" stimmt oft, ist aber selten geprüft. Die Größenschwellen aus § 28 BSIG hängen an Mitarbeitenden, Umsatz und Bilanzsumme, und bei Konzernstrukturen zählen Partner- und verbundene Unternehmen mit, wenn die IT nicht unabhängig betrieben wird. Ohne die Gruppenfrage ist die Einschätzung nicht belastbar.
2. Registrierung erledigt, Technik unberührt
Die Registrierung ist die formal sichtbare Pflicht und deshalb die, die zuerst abgehakt wird. Sie sagt nichts über den Stand der Maßnahmen aus.
3. Das Backup gilt als erledigt, weil es grün meldet
Eine fehlerfreie Sicherung ist keine geprüfte Wiederherstellung. In der Mehrzahl der Fälle liegt der letzte vollständige Restore weiter zurück, als die Beteiligten annehmen, oder hat nie stattgefunden.
4. Compliance wird als Projekt geführt, nicht als Betriebseigenschaft
Ein Nachweis, der eigens für einen Termin zusammengestellt wird, altert ab dem Tag danach. Belastbar sind Artefakte, die im Betrieb ohnehin entstehen: Testprotokolle, Änderungshistorien, dokumentierte Verfahren.
5. Die Lieferkette bleibt unbetrachtet
Ein erheblicher Teil der eigenen Verfügbarkeit hängt an Dienstleistern. Wer deren Wiederanlaufzeiten nicht kennt und vertraglich nicht geregelt hat, kann die eigenen Zielwerte nicht zusagen. Umgekehrt gilt: Auch nicht erfasste Dienstleister bekommen die Anforderungen über ihre Kunden.
Ein Vorgehen, das in überschaubarer Zeit trägt
Die Umsetzung lässt sich in eine Reihenfolge bringen, die auch dann funktioniert, wenn die Fristen bereits verstrichen sind. Entscheidend ist, dass jeder Schritt ein Artefakt hinterlässt, das später den Nachweis trägt.
- Einordnung herleiten und festhalten. Sektor, Einrichtungsart, Größenklasse, Gruppenfrage, jeweils mit Begründung. Ergebnis ist ein Dokument, keine Meinung.
- Registrieren, falls noch offen. Ohne auf den Umsetzungsstand zu warten.
- Kritikalität der Prozesse bestimmen. Welcher Geschäftsprozess braucht welche Anwendung, und wie lange geht es ohne? Daraus folgen die Zielwerte für RPO und RTO.
- Technischen Stand gegen die Zielwerte prüfen. Sicherungsreichweite, räumliche Trennung, Unveränderbarkeit, Wiederanlaufverfahren, Dokumentationslage. Ergebnis ist eine nach Risiko sortierte Lückenliste mit Aufwand je Punkt.
- Lücken schließen, in der Reihenfolge des Risikos. Die teuerste Lücke ist selten die gefährlichste.
- Einmal vollständig proben. Ein kompletter Wiederanlauf mit gemessener Dauer, protokolliert. Was dabei nicht hält, wird korrigiert.
- In den Betrieb überführen. Turnusmäßige Restore-Tests, Überwachung, Protokolle. Ab hier entsteht der Nachweis von selbst.
Zwei Hinweise zur Erwartung. Erstens: Die Schritte 3 und 4 dauern Wochen, nicht Monate, wenn die Beteiligten aus Fachbereich und IT gemeinsam am Tisch sitzen. Zweitens: Wer ohnehin die Plattform wechselt, etwa weg von einer proprietären Virtualisierung oder zurück aus der Public Cloud, legt die Wiederanlaufstrecke im selben Zug richtig an. Ein Nachbau im laufenden Bestand kostet erkennbar mehr.
Wo die Grenze unserer Leistung verläuft, sagen wir vorab: Die rechtliche Betroffenheitsprüfung, der Aufbau eines ISMS sowie Governance- und Meldeprozesse gehören nicht dazu. Das ist Rechts- und Managementberatung, dafür arbeiten wir mit spezialisierten Partnern.
04 Lösung · NIS2 und digitale Souveränität
Die technische Seite von NIS2, gebaut und betrieben
Backup-Architektur mit Georedundanz und unveränderbaren Kopien, Zielwerte für RPO und RTO je Anwendung, dokumentierte Wiederherstellungsverfahren, ein vollständiger Testlauf und danach der 24/7-Betrieb mit turnusmäßigen Restore-Tests. Consulting, Transition und Operation aus einer Hand, mit einer Go/No-Go-Entscheidung an jedem Übergang.
05 Weiterlesen
Weiterführend
In Vorbereitung
- NIS2: wer ist betroffen? Sektoren, Einrichtungsarten und Schwellen im Detail
- NIS2-Umsetzung: die Anforderungen Schritt für Schritt
- NIS2-Registrierung beim BSI: Ablauf, Angaben und verspätete Nachholung
- Backup und Disaster Recovery unter NIS2: 3-2-1-Regel, Immutability, Restore-Tests
- DORA und NIS2: welches Regelwerk für welches Unternehmen gilt
- Business Continuity Management: vom Notfallplan zum geprobten Wiederanlauf
06 Häufige Fragen
