NIS2 Incident-Meldepflicht WordPress: 24 Stunden, 72 Stunden, ein Monat
Artikel 23 der Richtlinie 2022/2555 bestimmt, wie Vorfallsmeldungen in der Praxis aussehen. Artikel 21 deckt das laufende Risikomanagement ab; Artikel 23 die Meldung erheblicher Sicherheitsvorfälle. Die drei Stufen folgen, nachdem die Einrichtung von einem erheblichen Vorfall Kenntnis erlangt hat. Nicht jeder technische Alarm ist meldepflichtig.
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 Kenntnis eines erheblichen Vorfalls, nicht erst nach abgeschlossener Ursachenanalyse.
- 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.
- Nicht jeder Alarm oder WordPress-Vorfall ist meldepflichtig; die Erheblichkeit wird bewertet und die Entscheidung dokumentiert.
Was Kenntnis bedeutet
Entscheidend ist, wann die Einrichtung von einem erheblichen Vorfall Kenntnis erlangt. Ein technischer Alarm beantwortet diese Frage nicht automatisch. Die Einrichtung kann Kenntnis jedoch nicht durch eine unbeaufsichtigte Warteschlange oder einen undefinierten Eskalationsweg beliebig hinauszögern.
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.
- Überschreitet die Bewertung die Erheblichkeitsschwelle in Artikel 23 Absatz 3, wird der Zeitpunkt der Kenntnis dokumentiert und die Frist von dort berechnet.
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 Konformitäts-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.
Ist der Vorfall zum Fälligkeitszeitpunkt des Abschlussberichts noch nicht abgeschlossen, sieht Artikel 23 Absatz 4 Buchstabe d einen Fortschrittsbericht und anschließend den Abschlussbericht binnen eines Monats nach Behandlung des Vorfalls vor. Ändert sich die Bewertung aufgrund neuer Erkenntnisse, dokumentiert der Meldeverantwortliche die Änderung und stimmt das weitere Vorgehen mit der zuständigen Behörde ab; eine besondere „Keine-Maßnahme“-Meldung nennt die Richtlinie nicht.
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.
Entscheidungstor: Ereignis, Vorfall, erheblicher Vorfall
Drei Ebenen sollten getrennt protokolliert werden. Ein Ereignis ist eine beobachtbare Erscheinung, etwa wiederholte fehlgeschlagene Anmeldungen, eine ausgelöste WAF-Regel oder ein Deployment-Fehler. Ein Sicherheitsvorfall beeinträchtigt oder kann Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit gespeicherter, übermittelter oder verarbeiteter Daten beziehungsweise angebotener Dienste beeinträchtigen. Für die Erheblichkeit nennt Artikel 23 Absatz 3 insbesondere schwere Betriebsstörungen oder finanzielle Verluste der Einrichtung sowie beträchtliche materielle oder immaterielle Schäden anderer Personen.
Das WordPress-Team liefert Tatsachen. Die von der Einrichtung benannte Stelle trifft die rechtliche und aufsichtsrechtliche Meldeentscheidung. Das Entscheidungsprotokoll enthält ersten belastbaren Alarm, Zeitpunkt der Kenntnisnahme durch eine verantwortliche Person, bekannte Service- und Kundenauswirkungen, verfügbare Nachweise, Erheblichkeitsbewertung, Freigabe und nächsten Prüfzeitpunkt. Auch die Entscheidung gegen eine Meldung wird begründet festgehalten.
Mehrsprachigkeit, EU-weite Nutzer oder ein vermuteter Angriff beweisen allein keine Erheblichkeit. Umgekehrt kann die Kompromittierung eines kleinen Plugins erheblich sein, wenn sie eine wesentliche Dienstleistung unterbricht oder zahlreiche Kundenkonten betrifft. Nationale Umsetzung, Behördenhinweise und Sektorkontext können den Maßstab konkretisieren. Rechts- oder Compliance-Funktion des Kunden muss daher den anwendbaren Meldeweg bestätigen.
Nachweise für 24 Stunden, 72 Stunden und Abschluss
Die Frühwarnung braucht eine stabile Vorfallskennung, betroffene Einrichtung und Leistung, Zeitpunkt der Kenntnis, aktuelle Grundlage der Erheblichkeit, vermuteten rechtswidrigen oder bösartigen Ursprung sowie mögliche grenzüberschreitende Auswirkungen. Unsicherheit wird sichtbar gekennzeichnet. „Wird untersucht“ ist belastbarer als eine unbelegte Zuschreibung.
Für die 72-Stunden-Meldung werden eine Zeitlinie, betroffene Umgebungen und Funktionen, beobachtete Dauer, Kunden- und Betriebsauswirkungen, möglicherweise betroffene Datenarten, Kompromittierungsindikatoren, abgeschlossene Eindämmung und verbleibende Exposition zusammengeführt. Jede Aussage wird als bestätigt, abgeleitet oder unbekannt markiert. Die zentrale Zeitlinie nutzt UTC, während ursprüngliche Zeitzonen der Quellsysteme erhalten bleiben.
Der Abschlussbericht ergänzt ausgearbeitete Ursachenanalyse, Schwere und Auswirkungen, Art der Bedrohung soweit bekannt, abgeschlossene und geplante Maßnahmen sowie gegebenenfalls grenzüberschreitende Folgen. Aussagen werden mit Log, Ticket, Change Record, forensischer Notiz oder benannter Entscheidung verknüpft. Originale bleiben soweit praktikabel schreibgeschützt; Sammlung, Export und Übergabe werden protokolliert. Das schafft Nachvollziehbarkeit, behauptet aber nicht, dass eine Agentur bei jedem Mandat formale digitale Forensik erbringt.
Rollen und Übergaben unter Zeitdruck
Monitoring- oder Hosting-Anbieter meldet den technischen Alarm und sichert verfügbare Rohdaten. Der WordPress-Responder begrenzt die Anwendungsauswirkung und erstellt die faktische Zeitlinie. Incident Commander koordiniert, damit Abhilfe keine Nachweise zerstört. Service Owner bewertet Betriebsfolgen. Informationssicherheit oder Forensik führt die technische Untersuchung. Recht, Compliance oder Regulatory Liaison entscheidet über den Kanal und reicht die Meldung ein. Kommunikation verantwortet Kundenhinweise und öffentliche Aussagen, soweit erforderlich.
Für jede Rolle werden eine verantwortliche Person und eine Vertretung benannt. Lieferantenverträge legen Kontakte, Eskalation außerhalb der Geschäftszeiten und Fristen für Logbereitstellung fest. Eine Übergabe gilt erst als erfolgt, wenn der Empfänger sie bestätigt, Tatsachen und Unsicherheiten angehängt sind und die nächste Frist sichtbar ist. Eine Agentur sollte nur dann im Namen des Kunden an Behörden melden, wenn Vollmacht und Verfahren ausdrücklich geregelt sind.
Zeitlinie üben, nicht nur Angriffstechnik
Eine belastbare Tabletop-Übung beginnt mit einem mehrdeutigen Alarm statt einem bereits bestätigten Einbruch. Das Team protokolliert Kenntnis, entscheidet über Erheblichkeit, fordert fehlende Lieferantennachweise an, entwirft die Frühwarnung und aktualisiert sie für die 72-Stunden-Stufe. Später kommt eine neue Information hinzu, etwa betroffene Kundenkonten oder ein Unterauftragnehmer in einem anderen Mitgliedstaat. Auch der Fortschrittsbericht für einen nach einem Monat noch laufenden Vorfall wird geprüft.
Nach der Übung werden Zeiten für Triage, Entscheidung, Beweissicherung, rechtliche Übergabe und Entwurf gemessen. Fehlende Logs, veraltete Kontakte, unzugängliche Meldeportale und widersprüchliche Zeitangaben werden als Maßnahmen mit Verantwortlichem und Termin erfasst. Die fehlgeschlagene Übergabe wird erneut getestet. Die Übungsfrequenz folgt der Risikobewertung der Einrichtung; ein universeller Quartalsrhythmus ist keine Vorgabe der Richtlinie.
Qualitätskontrolle vor dem Absenden
Jeder Entwurf braucht eine kurze Vier-Augen-Prüfung, die den Fristablauf nicht blockiert. Der technische Prüfer kontrolliert Zeitlinie, Systembezeichnungen, Indikatoren und Status der Eindämmung. Der fachliche Service Owner prüft Betriebs- und Kundenauswirkungen. Die Meldeverantwortung bestätigt Empfänger, Rechtsgrundlage, Erheblichkeitsentscheidung und Freigabe. Aussagen zur Attribution, zu betroffenen Daten und zum geografischen Umfang werden nur als bestätigt dargestellt, wenn dafür ein Nachweis vorliegt.
Versionsnummer, Freigabezeit und tatsächlich übermittelter Inhalt gehören in die Vorfallsakte. Anhänge werden auf sensible Daten und unnötige Geheimnisse geprüft. Die Eingangsbestätigung des Portals oder der Behörde wird zusammen mit der versandten Fassung gespeichert. Rückfragen erhalten denselben Vorfallsbezug und fließen in die gemeinsame Zeitlinie ein. So bleibt nachvollziehbar, welche Information zu welchem Zeitpunkt bekannt und gemeldet war.
Eine spätere Korrektur ist kein Grund, die Frühwarnung aufzuschieben. Frühere Aussagen werden jedoch nicht still überschrieben. Der Datensatz zeigt, was geändert wurde, warum und auf welchem neuen Beleg die Änderung beruht. Genau diese Änderbarkeit unter kontrollierter Versionierung macht eine stufenweise Meldung belastbar.
Durchgespielte Entscheidung: verdächtiger Administratorzugang
Um 09:10 meldet der Hoster eine erfolgreiche WordPress-Administratoranmeldung aus einem unbekannten Netz. Kurz danach wird ein Plugin installiert. Das Team hat damit ein Ereignis und einen begründeten Sicherheitsverdacht, aber noch keine ausreichende Grundlage für die Einstufung als erheblich. Der Bereitschaftsdienst eröffnet einen einzigen Vorfallsdatensatz, sichert Hosting- und Identitätslogs, sperrt das Konto über den freigegebenen Weg und fragt beim Service Owner nach Veränderungen an kundenbezogenen Funktionen.
Um 09:35 steht fest, dass das Konto einem ehemaligen Auftragnehmer gehört und das Plugin einen nicht genehmigten Export-Endpunkt angelegt hat. Das Exportprotokoll ist unvollständig. Der Incident Commander hält neue Tatsachen, den frühesten belegbaren Kenntniszeitpunkt und offene Fragen fest: Wurde der Endpunkt aufgerufen? Welche Datensätze waren erreichbar? Wie lange bestand der Zugang? Wurden dieselben Zugangsdaten in weiteren Umgebungen verwendet? Compliance bewertet die Kriterien aus Artikel 23 Absatz 3 anhand von Betriebswirkung und möglichem Schaden. Die bloße Existenz des Plugins wird nicht automatisch mit Erheblichkeit gleichgesetzt.
Zeigen WAF- und Anwendungslogs anschließend keine Aufrufe, keine Betriebsunterbrechung und keinen Zugriff außerhalb einer Testumgebung, kann die zuständige Stelle mit dokumentierter Begründung entscheiden, dass der anwendbare Erheblichkeitsmaßstab nicht erreicht ist. Monitoring und gegebenenfalls Datenschutzprüfung laufen weiter. Werden später Produktionszugriffe oder betroffene Konten entdeckt, wird die Bewertung wieder geöffnet, ohne die frühere Entscheidungsgrundlage zu überschreiben.
Im zweiten Verlauf belegen die Logs Abfragen gegen die Produktion und eine Unterbrechung des Kundenservice während der Eindämmung. Das Meldeteam dokumentiert, wann die Einrichtung genügend Tatsachen hatte, um den erheblichen Vorfall zu erkennen. Es erstellt die Frühwarnung ohne vollständige Attribution abzuwarten und verwendet dasselbe Nachweisregister für die 72-Stunden-Aktualisierung. Kenntnis ist damit eine gesteuerte, belegte Entscheidung und nicht derjenige Zeitstempel, der die bequemste Frist erzeugt.
Protokoll für Nachweisübergaben
Jede Übergabe enthält Vorfallskennung, Quellsystem, abgedeckten Zeitraum, erhebende Person, Erhebungszeit, ursprüngliche Zeitzone, gegebenenfalls Integritätswert, Speicherort, Zugriffsbeschränkung und Empfangsbestätigung. Der Empfänger vermerkt außerdem, ob das Material für die angeforderte Entscheidung vollständig genug ist. Ein Screenshot kann einen Alarm illustrieren. Für Reihenfolge und Umfang werden in der Regel exportierte Logs oder Aufzeichnungen des Anbieters benötigt.
Kann ein Lieferant einen Nachweis vor der Meldestufe nicht bereitstellen, nennt der Entwurf die Anfrage, Zeitpunkt, Ansprechpartner und Auswirkung der Unsicherheit auf die Bewertung. So wird aus einem fehlenden Log keine verdeckte Annahme. Die Anfrage bleibt nach dem Versand offen; ein wesentliches Ergebnis geht an den Meldeverantwortlichen, der über eine Aktualisierung entscheidet.
Abnahme und Grenzen
Meldereife liegt vor, wenn eine genehmigte Erheblichkeitsmatrix, benannte Entscheider und Vertretungen, aktuelle Behördenkontakte, zeitlich abgestimmte Nachweisquellen, getestete Vorlagen, ein bestätigter Lieferanten-Eskalationsweg und ein datiertes Übungsergebnis vorhanden sind. Alle Meldestufen verwenden dieselbe Kennung und Zeitlinie, damit keine konkurrierenden Wahrheiten entstehen.
Der Ablauf macht nicht jeden Sicherheitsvorfall meldepflichtig, entscheidet die rechtliche Erheblichkeit nicht stellvertretend für die Einrichtung und garantiert keine Zustimmung der Behörde zur Erstbewertung. Parallele Pflichten, beispielsweise die Prüfung einer Verletzung des Schutzes personenbezogener Daten nach DSGVO oder sektorspezifische Meldungen, benötigen eigene, miteinander abgestimmte Entscheidungswege.
Für eine abgrenzbare Readiness-Prüfung senden Sie einen schriftlichen Brief mit Einrichtung und Sektor, Jurisdiktionen, WordPress-Funktion, Monitoring-Quellen, Lieferanten, vorhandenen Vorfallsrollen, Meldekanälen und Übungshistorie. Die NIS2- und DORA-Readiness-Prüfung kann daraus Entscheidungstor, Nachweisquellen, Übergaben, Vorlagen und Übungsplan ableiten, ohne das Ergebnis als Rechtszertifikat darzustellen.
Querverweise
- NIS2 Anhang II für WordPress-Agenturen: Artikel 21 Nachweispfad
- DORA Artikel 28 IKT-Drittparteirisiko für WordPress
- NIS2 und DORA auf WordPress Säule
- NIS2 vs DORA Geltungsbereich-Überschneidung für WordPress-Agenturen 2026
- WordPress-Vorfallsreaktion unter NIS2: 24-Stunden-Frühwarnungs-Playbook
- EU-Konformitätsaudit für WordPress
