NIS2 und IT-Infrastruktur: Business Continuity, RTO/RPO und technische Maßnahmen
Stand: Juni 2026 · Fokus: technische Resilienz, keine Rechtsberatung
NIS2 ist kein reines Firewall-Thema. Die Richtlinie nennt unter anderem Risikomanagement, Incident Handling, Business Continuity, Backup, Disaster Recovery und Lieferkettensicherheit. Damit wird technische Resilienz zu einem prüfbaren Infrastrukturthema.
Für die Infrastruktur heißt das: kritische Systeme identifizieren, RTO/RPO definieren, Server und Internet redundant auslegen, Monitoring betreiben und Wiederanlaufprozesse dokumentieren und testen.
Seit wann?
Das NIS2-Umsetzungsgesetz ist seit dem 6. Dezember 2025 in Kraft.
Was prüft Diventus?
Nicht die Rechtslage, sondern die technische Widerstandsfähigkeit Ihrer Infrastruktur.
Was ist der Hebel?
Business Continuity, Incident Response, Redundanz, Monitoring und Recovery-Ziele.
Viele NIS2-Maßnahmen betreffen IT-Sicherheit im engeren Sinne: Zugriffsschutz, Verschlüsselung, Schwachstellenmanagement und Incident Response. In der Praxis entscheidet aber oft ein weniger sichtbarer Bereich über die Betriebsfähigkeit: die Verfügbarkeit der IT-Infrastruktur.
Wenn ERP, DMS, Produktionssteuerung, VPN oder E-Mail ausfallen, ist ein Sicherheitsvorfall schnell auch ein Betriebsstillstand. NIS2-nahe Infrastrukturarbeit beginnt deshalb mit einer nüchternen Frage: Welche Systeme dürfen wie lange ausfallen, wie viele Daten dürfen verloren gehen, und wer merkt es, bevor daraus ein Schaden wird?
Welche technischen Maßnahmen NIS2 in der Infrastruktur auslöst
NIS2 verlangt keine einzelne Standardlösung, sondern angemessene Maßnahmen auf Basis des Risikos. Genau deshalb sollte die technische Prüfung nicht mit Produkten beginnen, sondern mit Geschäftsprozessen: Was darf nicht ausfallen, wie schnell muss es wieder verfügbar sein, und welche Abhängigkeit kann den Betrieb blockieren?
| Maßnahmenbereich | Praktische Bedeutung | Infrastruktur-Output |
|---|---|---|
| Risikomanagement | Kritische Anwendungen, Abhängigkeiten und Ausfallauswirkungen müssen bekannt sein. | Systemliste, Business-Impact-Bewertung, RTO/RPO pro Anwendung. |
| Incident Response | Vorfälle müssen erkannt, bewertet, eskaliert und nachvollziehbar dokumentiert werden. | 24/7-Monitoring, Alarmwege, Zuständigkeiten, Eskalationsmatrix. |
| Business Continuity | Der Betrieb muss bei Störungen kontrolliert weiterlaufen oder schnell wieder anlaufen. | Redundante Server, redundantes Internet, Wiederanlaufplan, Tests. |
| Backup und Disaster Recovery | Datenverlust und Wiederherstellungsdauer müssen zur Kritikalität des Systems passen. | Backup-Strategie, Restore-Tests, RPO-Ziele, Disaster-Recovery-Konzept. |
| Lieferkette | Dienstleister, Provider und technische Abhängigkeiten werden Teil der Risikobetrachtung. | ISP-Redundanz, Provider-Risiko, klare Support- und Meldewege. |
Risikomanagement
Kritische Anwendungen, Abhängigkeiten und Ausfallauswirkungen müssen bekannt sein.
Systemliste, Business-Impact-Bewertung, RTO/RPO pro Anwendung.
Incident Response
Vorfälle müssen erkannt, bewertet, eskaliert und nachvollziehbar dokumentiert werden.
24/7-Monitoring, Alarmwege, Zuständigkeiten, Eskalationsmatrix.
Business Continuity
Der Betrieb muss bei Störungen kontrolliert weiterlaufen oder schnell wieder anlaufen.
Redundante Server, redundantes Internet, Wiederanlaufplan, Tests.
Backup und Disaster Recovery
Datenverlust und Wiederherstellungsdauer müssen zur Kritikalität des Systems passen.
Backup-Strategie, Restore-Tests, RPO-Ziele, Disaster-Recovery-Konzept.
Lieferkette
Dienstleister, Provider und technische Abhängigkeiten werden Teil der Risikobetrachtung.
ISP-Redundanz, Provider-Risiko, klare Support- und Meldewege.
NIS2 im Überblick
Wer ist betroffen?
NIS2 betrifft deutlich mehr Unternehmen als die bisherige KRITIS-Regulierung. Entscheidend sind Branche, Unternehmensgröße und die konkrete Rolle in der digitalen oder physischen Versorgungskette. Typische Prüffelder sind Energie, Verkehr, Gesundheit, Wasser, digitale Infrastruktur, IT-Dienstleister, bestimmte Fertigungsbereiche und weitere regulierte Sektoren.
Die genaue rechtliche Einordnung sollte mit juristischer oder Compliance-Unterstützung erfolgen. Diventus betrachtet die technische Seite: Welche Systeme sind kritisch, wie resilient sind sie, und wie schnell kann der Betrieb nach einem Vorfall stabil weiterlaufen?
Zeitlicher Stand
| Punkt | Datum | Einordnung |
|---|---|---|
| Inkrafttreten NIS2UmsuCG | 6. Dezember 2025 | Registrierungs- und Meldepflichten gelten seit Inkrafttreten. |
| BSI-Portal | seit Inkrafttreten | Registrierung und Meldung erfolgen laut BSI über das vorgesehene BSI-Portal. |
| Infrastruktur-Readiness | laufend | RTO/RPO, Redundanz, Monitoring und Wiederanlauf sollten dokumentiert und getestet sein. |
Was die Infrastruktur leisten muss
- •Geschäftskritische Dienste identifizieren: ERP, DMS, VPN, E-Mail, Produktionssteuerung, Datenbanken und Kommunikation nach Ausfallauswirkung sortieren.
- •Recovery-Ziele festlegen: RTO und RPO pro Anwendung definieren und gegen echte Wiederherstellungstests prüfen.
- •Einzelne Ausfallpunkte entfernen: Server, Internetanbindung, Monitoring und Backup-Ziele auf Single Points of Failure prüfen.
- •Vorfälle früh erkennen: 24/7-Monitoring, klare Meldeketten und dokumentierte Eskalation für technische Störungen etablieren.
So priorisieren Sie NIS2-nahe Infrastrukturmaßnahmen
Der größte Fehler ist eine rein technische Einkaufsliste. Sinnvoller ist eine Reihenfolge, die Ausfallwirkung, Datenverlust, Wiederanlaufzeit und Nachweisbarkeit zusammenführt. Daraus entsteht ein Maßnahmenplan, den Geschäftsführung, IT und externe Prüfer nachvollziehen können.
Welche Systeme stoppen den Betrieb, wenn sie ausfallen?
ERP, DMS, Produktionssteuerung, VPN, E-Mail, Datenbanken priorisieren.
Wie lange darf jedes System ausfallen, wie viele Daten dürfen verloren gehen?
RTO und RPO je Anwendung festlegen und dokumentieren.
Wo hängt der Betrieb an einem Server, einer Leitung oder einem Provider?
Redundanzbedarf für Server, Internet, Storage, Monitoring und Backup ableiten.
Kann das Unternehmen zeigen, dass Maßnahmen funktionieren?
Monitoring, Tests, Verantwortlichkeiten und Wiederanlaufprotokolle sammeln.
Als Brücke zwischen Management und Technik eignen sich RTO und RPO: Das Recovery Time Objective beschreibt, wie schnell ein System wieder laufen muss. Das Recovery Point Objective beschreibt, wie viele Daten maximal verloren gehen dürfen. RTO/RPO genauer erklären
Drei Säulen für NIS2-nahe Infrastruktur
| NIS2-Anforderung | Risiko | Technische Maßnahme |
|---|---|---|
| Business Continuity | Serverausfall → Produktionsstopp | Fehlertolerante Server (Stratus everRun: 0 Sek. Unterbrechung) |
| Business Continuity | Internetausfall → Cloud/Mail/VPN weg | Redundantes Internet (becom.one: gebündelte Leitungen) |
| Incident Response | Fehler unbemerkt → Eskalation | 24/7-Monitoring (DCM: auf separater Hardware) |
| Lieferkette | Abhängigkeit von einem ISP | Multi-Provider-Anbindung (becom.one) |
| Disaster Recovery | Standortausfall → Totalverlust | Geo-Redundanz (SplitSite) + DCW |
Checkliste — NIS2-Infrastruktur-Readiness
- Geschäftskritische Systeme identifiziert
- Ausfallkosten pro Stunde berechnet
- Recovery Time Objective (RTO) definiert
- Recovery Point Objective (RPO) definiert
- Server-Redundanz implementiert (HA oder FT)
- Internetanbindung redundant ausgelegt
- 24/7-Monitoring aktiv
- Disaster-Recovery-Plan dokumentiert
- Verantwortlichkeiten für Incident Response zugewiesen
- BSI-Registrierung und Meldewege geprüft
- Risikoanalyse dokumentiert und aktuell
- Lieferketten-Risiken (IT-Dienstleister, ISP) bewertet
10 Fragen, 2 Minuten, sofortiges Ergebnis
Häufige Fragen zu NIS2 und Infrastruktur
Was bedeutet NIS2 für die IT-Infrastruktur?
NIS2 macht IT-Infrastruktur nicht automatisch zu einer bestimmten Produktpflicht. Praktisch müssen betroffene Unternehmen aber Risiken bewerten, Vorfälle behandeln, Business Continuity sicherstellen und Wiederherstellung planen. Für Server, Internet, Monitoring und Backup bedeutet das: Kritikalität, RTO, RPO, Redundanz und Eskalation müssen nachvollziehbar geregelt sein.
Schreibt NIS2 hochverfügbare Server vor?
NIS2 schreibt in der Regel keine konkrete Servertechnologie vor. Hochverfügbare oder fehlertolerante Systeme können aber eine passende technische Maßnahme sein, wenn eine Anwendung nur sehr kurz ausfallen darf oder wenn ein Ausfall hohe operative Risiken erzeugt.
Welche Systeme sollten zuerst auf NIS2-Readiness geprüft werden?
Zuerst sollten Systeme geprüft werden, die direkt Umsätze, Produktion, Versorgung, Kommunikation oder Nachweispflichten beeinflussen: ERP, DMS, Produktionssteuerung, Datenbanken, VPN, E-Mail, Leitstellen- oder Branchensysteme.
Ist der NIS2-Check von Diventus Rechtsberatung?
Nein. Diventus bewertet technische Infrastruktur-Risiken: Verfügbarkeit, Redundanz, Monitoring, Wiederanlauf und Abhängigkeiten. Die rechtliche Betroffenheit, Fristen und Haftungsfragen sollten separat juristisch geprüft werden.
Quellen und fachliche Einordnung
Diese Seite übersetzt NIS2-Anforderungen in technische Infrastrukturmaßnahmen. Sie ersetzt keine rechtliche Einordnung zur Betroffenheit oder zu Meldepflichten.
NIS2-Readiness Ihrer Infrastruktur prüfen
Wo ist Ihre Infrastruktur schon resilient, und wo entstehen noch Single Points of Failure? In einer kostenlosen Analyse identifizieren wir technische Lücken bei Business Continuity, Monitoring und Wiederherstellung.
+49 30 802020990