NIS2 Incident-Meldepflicht WordPress: 24 Stunden, 72 Stunden, ein Monat
Artikel 23 der Richtlinie 2022/2555 bestimmt, wie Incident Response in der Praxis aussieht. Artikel 21 deckt das laufende Risikomanagement ab; Artikel 23 deckt ab, was passiert, wenn etwas bricht. Drei Milestones, drei Lieferungen, eine Uhr, die bei der Detektion startet.
Dies ist ein vertiefender Artikel innerhalb der NIS2 und DORA WordPress Säule, mit Querverweisen zur Anhang II Nachweispfad-Anleitung und zum DORA Artikel 28 Drittparteienregister.
TL;DR
- Die Uhr läuft ab Detektion eines erheblichen Vorfalls, nicht ab Ursachenbestätigung.
- 24 Stunden: Frühwarnung, vermutete bösartige Ursache, grenzüberschreitender Indikator.
- 72 Stunden: Vollmeldung mit Erstbewertung und Indikatoren.
- Ein Monat: Abschlussbericht mit Bedrohungsart, Mitigation, grenzüberschreitender Auswirkung.
- Der Abschlussbericht wird auch eingereicht, wenn die Ursache harmlos war.
Was “Detektion” bedeutet
Artikel 23 schweigt zur Detektionsdefinition, aber ENISA-Leitlinien und Erwägungsgrund 101 lesen ihn als den Moment, ab dem die Einrichtung erkennt, dass ein Vorfall erheblich sein könnte. Praktisch: der Moment, in dem der Alert beim Runbook-Owner ankommt, nicht der Moment, in dem das Tool den Alert auslöst.
Für eine WordPress-Site bedeutet das typisch:
- Ein Monitoring-Tool (Wordfence, Sucuri, Hosting-IDS, Cloudflare-Alert, Sentry-Error-Spike) markiert eine Anomalie.
- Ein On-Call-Engineer triagiert den Alert und beurteilt den Umfang.
- Wenn die Bewertung die Erheblichkeitsschwelle in Artikel 23(3) überschreitet, hat die Detektion stattgefunden. Die Uhr startet.
Der zu vermeidende Fehler ist, einen Junior um 23:50 einen Credential-Stuffing-Burst triagieren zu lassen, der “wirkt wie Rauschen” abwinkt und morgens neu beurteilt. War der Burst tatsächlich ein Credential-Breach mit bestätigtem Account-Zugriff, läuft die 24-Stunden-Uhr seit 23:50 - der Regulator rekonstruiert das aus Logs.
Die 24-Stunden-Frühwarnung
Inhalt nach Artikel 23(4)(a):
- Ob der Vorfall vermutlich durch rechtswidrige oder bösartige Handlung verursacht wurde.
- Ob der Vorfall grenzüberschreitende Auswirkungen haben kann.
Das ist kurz. Die Frühwarnung ist keine Ursachenanalyse, sondern eine Flagge. CSIRT oder zuständige Behörde muss wissen, dass etwas Erhebliches passiert; Details folgen in der 72-Stunden-Meldung.
Rolle der WordPress-Agentur innerhalb 24 Stunden:
- Vorfallsumfang über Logs, Alerts und Admin-Forensik bestätigen.
- Dem Compliance-Team des Kunden eine einseitige Frühwarnungs-Vorlage liefern, die betroffenen Service, vermutete Kategorie (bösartig oder operativ) und grenzüberschreitendes Element (mehrsprachige Site, EU-weite Kundschaft) benennt.
- Evidenz sichern: Server-Logs, Plugin-Update-Zeitleiste, Admin-Login-Historie, Hosting-Audit-Trail. Datenbankzustand sichern, wenn praktikabel.
- Blutung stoppen: Credentials rotieren, IPs blockieren, kompromittierte Plugins isolieren, Site lesegeschützt setzen, wenn Checkout oder Zahlung betroffen.
Frühwarnung soll keine Spekulation über Attribution enthalten. “Vermutet bösartig” reicht; einen Bedrohungsakteur zu nennen ist Sache forensischer Spezialisten.
Die 72-Stunden-Vollmeldung
Inhalt nach Artikel 23(4)(b):
- Erstbewertung des Vorfalls, einschließlich Schweregrad und Auswirkungen.
- Sofern verfügbar, Kompromittierungsindikatoren.
Schweregrad-Sprache zählt. ENISA arbeitet mit drei Stufen: niedrig, mittel, hoch. Ein WordPress-Vorfall, der die Site unter einer Stunde offline genommen hat ohne Datenabfluss, ist höchstens mittel. Ein bestätigter Credential-Breach mit Kundendaten-Zugriff ist hoch. Ein Defacement einer Marketing-Seite ohne weiteren Zugriff ist niedrig bis mittel.
Lieferung der Agentur innerhalb 72 Stunden:
- Schriftliche Vorfalls-Zeitleiste mit Log-Zeitstempeln.
- Bewertung, ob Kunden-, Zahlungs- oder Sitzungsdaten zugegriffen wurden.
- Kompromittierungsindikatoren: Quell-IPs, User-Agents, Datei-Hashes bei Malware, modifizierte Plugin- oder Theme-Dateien, neu erstellte verdächtige Admin-Konten.
- Erste Liste bereits ergriffener Mitigation: rotierte Credentials, entferntes oder gepatchtes Plugin, hinzugefügte WAF-Regel, Admin-Konten geprüft.
Hier bekommen die meisten WordPress-Vorfälle einen Namen in den Regulator-Akten. Die 72-Stunden-Meldung wird später mit dem Abschlussbericht verglichen.
Der Ein-Monats-Abschlussbericht
Inhalt nach Artikel 23(4)(c):
- Detaillierte Beschreibung des Vorfalls, Schweregrad und Auswirkungen.
- Art der Bedrohung oder Ursache.
- Ergriffene und laufende Mitigationsmaßnahmen.
- Soweit zutreffend, grenzüberschreitende Auswirkungen.
Bis Monatsende sollte die WordPress-Agentur haben:
- Vollständige Ursachenanalyse. Verwundbares Plugin? Geleaktes Credential? Fehlkonfigurierter Server? Phishing-vermittelter Admin-Compromise?
- Evidenz, dass die Sofortmaßnahme wirkt und stabil ist. WAF-Regel ausgespielt, Plugin produktiv gepatcht, Credentials rotiert und MFA durchgesetzt, Monitoring nachjustiert.
- Liste langfristiger Maßnahmen. Plugin-Policy aktualisiert, ungewartete Abhängigkeiten entfernt, periodischer Credential-Audit, Training für Editoren als möglichen Phishing-Vektor.
- Bestätigungsabsatz für den Kunden zur Weiterleitung an den Regulator.
War die Ursache harmlos (verpfuschtes Plugin-Update als Breach fehlklassifiziert), wird der Abschlussbericht trotzdem eingereicht. Artikel 23(7) regelt das mit einer “Keine-Maßnahme”-Variante explizit. Die Uhr stoppt nicht, weil die Bewertung sich ändert.
Was die Agentur in der Toolbox hält
Sechs Artefakte, die jede regulierte WordPress-Beauftragung vor dem ersten Vorfall bereit haben sollte:
- Incident-Response-Runbook mit benanntem Owner, Eskalationspfad und 24/72/30-Tage-Vorlagen.
- CSIRT- und Behördenkontaktliste für Kundenjurisdiktion und relevante grenzüberschreitende.
- Kommunikationsvorlage für betroffene Kunden bei bestätigtem Datenzugriff.
- Evidenzsicherungspolicy: Log-Aufbewahrung, Backup-Integrität, Chain-of-Custody-Notizen.
- Meldesprache-Bibliothek: vorabgenehmigte Phrasen für “vermutet bösartig”, “keine Kundendaten betroffen”, “Schwachstelle gepatcht”, “Monitoring nachjustiert”. Spart 30 Minuten in einem 24-Stunden-Fenster.
- Drill-Kalender: mindestens eine Tabletop-Übung pro Quartal mit 24/72/30-Lauf ohne echten Vorfall.
Die Toolbox ist der Unterschied zwischen einem 24-Stunden-Fenster, das eine ruhige einseitige Frühwarnung produziert, und einem 24-Stunden-Fenster, das einen Panikanruf an die Rechtsabteilung um 03:00 produziert.
