NIS2 und Infrastruktur: Was im Runbook stehen muss

Regulierungsdiskussionen enden oft bei Governance-Charts. Für Infrastruktur- und Security-Teams bedeutet NIS2 zeitgebundene Aktionen bei Störungen: klassifizieren, eindämmen, melden, Beweise sichern, recoveren. Leben diese nur in einem einmal von Legal gelesenen PDF, erfindet der erste Incident um 02:00 einen neuen Prozess — und Counsel fragt nach Timestamps, die fehlen. NIS2 interessiert sich nicht für Ordnerdicke, sondern dafür, ob On-Call ein Runbook öffnet, Schritte an echten Systemen ausführt und Meldungen innerhalb gesetzlicher Fristen belegt.

Wir begleiten Essential- und Important-Entities in Fertigung, Logistik und IT-Services bei NIS2-Readiness. Die Lücke sind selten fehlende Policies, sondern fehlende Operability: Severity-Definitionen, die fünf Personen fünfmal interpretieren, Backup-Reports auf Shares nur für den Backup-Admin, Lieferantennummern mit Voicemail während eines Ausfalls. Runbooks schließen diese Lücke — nicht durch mehr Seiten, sondern durch Benennung von Wer-Was-Wo, bevor Adrenalin im Spiel ist.

Pflichtsektionen im Runbook ab Tag eins

Schweregrad-Matrix mit NIS2-Triggern ist nicht verhandelbar. Definieren Sie, was einen signifikanten Incident für Ihre Services bedeutet: Ausfalldauer, betroffene Datenkategorien, grenzüberschreitende Wirkung, Ransom-Forderungen gegen kritische Systeme. Mappen Sie Schweregrade auf Krisenstab, Frühwarnungs-Entwurf, Kundenkommunikation und Regulator-Meldung. Mehrdeutigkeit kostet Tage. Ein MSP debattierte achtzehn Stunden über „betroffene” PII bei Verschlüsselung ohne Exfil — während die 24-Stunden-Uhr lief.

Kontaktbaum mit Stellvertretern für CISO, DPO, Legal, Comms, Cloud-TAM, ISP und MSSP. After-Hours-Nummern und vertragliche Eskalationsklauseln — nicht „Ticket eröffnen” als einziger Weg. Bei DDoS gegen einen polnischen E-Commerce-Anbieter fehlte ein sekundärer ISP-Kontakt; vier Stunden Verzögerung, Sales erfuhr den Ausfall via Twitter.

Technische Preserve-and-Contain-Schritte pro Tier machen aus generischen IR-Plänen ausführbare Checklisten. Für Crown Jewels: Segment isolieren, kompromittierte Credentials deaktivieren, Logs in immutable Storage, Chain of Custody für Disk-Images. „Vom Netz trennen” reicht nicht ohne Switch-Port, VLAN oder Security-Group-Regel. Operatoren sollten Containment unter rechtlicher Beobachtung nicht improvisieren.

Backup, Restore und Lieferantenmaps

Backup- und Restore-Nachweis gehört in den Runbook-Body, nicht in einen ungelesenen Anhang. RPO/RTO pro Tier, Datum des letzten erfolgreichen Restore-Tests, Unterzeichner, Ablageort der Reports. NIS2 betont Resilienz — ungetestetes Backup ist Finding und Fiktion. Ein Industriekunde entdeckte im Tabletop, dass „Nacht-Backup” eines Fileservers sechs Wochen still fehlschlug nach Credential-Rotation. Das Runbook verlinkt jetzt das Backup-Dashboard und benennt täglichen Status-Owner.

Lieferanten- und Sub-Processor-Maps dokumentieren, welcher Incident welchen Vendor innerhalb welcher SLA benachrichtigt. Cloud Shared Responsibility bedeutet: Statuspages, Support-Tiers und Evidence-Export im Runbook. Bei Identity-Kompromittierung über Microsoft 365 und On-Prem-AD muss feststehen, wer den Microsoft-Case öffnet, wer Entra-Sign-in-Logs sichert und wer mit DC-Logs korreliert — nicht um 03:00 entdecken.

Frühwarnung und Meldemechanik

24-Stunden-Frühwarnung und 72-Stunden-Meldung bestrafen Improvisation. Vorlagen mit Platzhaltern für betroffene Services, Datenkategorien, geschätzte Nutzerwirkung und Containment-Status. Vorab vereinbarte Schwellen für Legal-Review — nicht „wir rufen Legal, wenn es schlimm wirkt”. Legal braucht Zeit für Formulierungen; Operatoren brauchen Zeit für Beweissicherung. Parallele Workstreams brauchen ein stündlich aktualisiertes Timeline-Dokument.

Vorlagen in Regulator-Sprache und in einfacher Sprache für Kunden — oft zwei Dokumente, gleiche Fakten. Ablage dort, wo On-Call ohne E-Mail-Jagd zugreift. Ein Logistiker hält Draft-Packs im Incident-Channel-Wiki mit Last-Reviewed-Dates; Legal signiert quartalsweise nach M&A, dass Platzhalter noch zur Entity-Struktur passen.

Tabletop schlägt die nächste Policy-Version

Führen Sie eine 90-Minuten-Übung durch: Ransomware auf Hybrid-File-Service oder IAM-Kompromittierung mit Mail-Regeln. Stoppen Sie jede Entscheidung — klassifizieren, eindämmen, intern melden, Frühwarnungs-Entwurf, Backup-Restore anfordern. Lücken werden dieselbe Woche Runbook-Edits, nicht erst nach Audit-Finding. Tabletops zeigen auch Tooling-Lücken: sagt das Runbook „Logs in immutable Storage exportieren”, aber niemand testete den Export seit sechs Monaten — Tool oder Runbook fixen.

Wiederholen Sie quartalsweise mit rotierenden Rollen — der CISO spielt nicht immer Commander. NIS2 erwartet organisatorische Fähigkeit, nicht Heldentum einer Person aus dem Incident 2019. Lessons mit Ticket-IDs dokumentieren; Prüfer fragen zunehmend nach Übungsgeschichte, nicht nur Policy-Existenz.

Szenario: Cloud-SaaS vs Hybrid-Hersteller

Ein Cloud-first-SaaS-Anbieter betont Tenant-Isolation, Kundenbenachrichtigungslisten aus CRM und koordinierte Statuspage-Updates mit Sub-Processor-Klauseln in Verträgen. Belege in Ticketing, Chat-Exports und Cloud-Audit-Logs mit gesperrter Retention.

Ein Hybrid-Hersteller ergänzt OT-Segmente, On-Prem-Historian und physische Safety-Interlocks. Gleiche NIS2-Fristen, aber Containment verweist auf VLANs an PLCs und einen Process-Safety-Officer vor Netz-Isolation, die eine Linie stoppen könnte. Ein Runbook braucht tier-spezifische Kapitel — Fehler ist identisches IR-PDF in beiden Umgebungen ohne Anpassung.

Nächster Schritt

Öffnen Sie heute Abend Ihr Incident-Runbook. Ersetzen Sie „relevantes Team” und „nach Ermessen” durch Namen, Systeme und Links. Planen Sie ein 90-Minuten-Tabletop vor der nächsten Policy-Review. Sichere Infrastruktur ohne ausführbare Incident-Mechanik scheitert an NIS2 in der Praxis. Wir verbinden Technik und Runbooks in Sichere Public-Cloud-Infrastruktur und Audit — ausführbar unter Druck, nicht Ordner nur für Procurement.

Mehr zu diesem Thema

Identity Security in der Praxis: Was Prüfer zuerst kontrollieren

Vor Pentest-Funden prüfen Auditoren Identity: MFA-Abdeckung, privilegierten Zugriff, Joiner-Mover-Leaver und Belege, dass Zugriff zur Rolle passt — nicht…