WordPress-Vorfallsreaktion unter NIS2: 24-Stunden-Frühwarnungs-Playbook

#WordPress-Vorfallsreaktion unter NIS2: 24-Stunden-Frühwarnungs-Playbook

Artikel 23 der Richtlinie 2022/2555 presst die Anfangsphase der Vorfallsreaktion in drei Fristen: 24 Stunden, 72 Stunden, ein Monat. Der 24-Stunden-Zähler trifft WordPress-Betreiber unvorbereitet, weil er bei Kenntnisnahme startet, nicht bei der Behebung, und Kenntnisnahme auf einer typischen WordPress-Site eher aus einer Slack-Nachricht als aus einem SOC-Dashboard kommt.

Dies ist ein vertiefender Beitrag im Pillar zu NIS2 und DORA auf WordPress mit Querverweisen auf den Anhang-II-Nachweispfad und das DORA-Artikel-28-Lieferanten-Audit.

#TL;DR

• 24 Stunden ab Kenntnisnahme: Frühwarnung an das CSIRT.
• 72 Stunden ab Kenntnisnahme: Vorfallsmeldung mit Erstbewertung.
• 1 Monat nach der 72-Stunden-Meldung: Abschlussbericht mit Ursache und Gegenmaßnahmen.
• „Kenntnisnahme” ist der Auslöser, nicht ein SIEM-Alert.
• Sechs WordPress-Signale, die für mich „der Zähler läuft jetzt” bedeuten.
• Vorlagen je Sprache stehen in diesem Playbook.

#Was NIS2 Artikel 23 verlangt

Artikel 23 Absatz 1 setzt die Pflicht: Meldung jedes Vorfalls mit erheblichen Auswirkungen auf die Bereitstellung der Dienste an das CSIRT oder die zuständige Behörde. Artikel 23 Absatz 3 definiert „erheblich”: geeignet, schwere Betriebsstörung der Dienste oder finanziellen Schaden für die Einrichtung zu verursachen, oder geeignet, andere natürliche oder juristische Personen durch erhebliche materielle oder immaterielle Schäden zu beeinträchtigen.

Artikel 23 Absatz 4 splittet die Zeitachse:

• (a) Unverzüglich, in jedem Fall innerhalb von 24 Stunden ab Kenntnisnahme des erheblichen Sicherheitsvorfalls: eine Frühwarnung mit Angabe, ob der Vorfall vermutlich auf rechtswidrige oder böswillige Handlungen zurückzuführen ist und ob er grenzüberschreitende Auswirkungen haben könnte.
• (b) Unverzüglich, in jedem Fall innerhalb von 72 Stunden: eine Vorfallsmeldung, die die Frühwarnung aktualisiert und eine Erstbewertung mit Schweregrad, Auswirkung und Indikatoren einer Kompromittierung enthält.
• (c) Auf Anforderung des CSIRT oder der zuständigen Behörde: Zwischenbericht zum Stand.
• (d) Spätestens einen Monat nach der Vorfallsmeldung nach Buchstabe b: Abschlussbericht mit detaillierter Beschreibung, Bedrohungstyp oder Ursache, umgesetzten Gegenmaßnahmen, gegebenenfalls grenzüberschreitenden Auswirkungen.

Der Zähler startet bei der Kenntnisnahme des erheblichen Sicherheitsvorfalls. Die Richtlinie definiert diesen Zeitpunkt nicht, Erwägungsgrund 102 wiederholt nur die Fristen. Dieses Playbook setzt die Kenntnisnahme, sobald eine fachkundige Person in der Einrichtung mit hinreichender Sicherheit einschätzt, dass ein erheblicher Sicherheitsvorfall vorliegt, und hält fest, wer das auf welcher Grundlage festgestellt hat. Für WordPress entscheidend, weil Kenntnisnahme meist aus einer Kunden-E-Mail, einem externen Monitoring-Dienst oder einem Schwachstellen-Scanner kommt, nicht aus einem internen SOC.

#Wann ein Sicherheitsvorfall nach Durchführungsverordnung 2024/2690 erheblich ist

Artikel 23 Absatz 3 der Richtlinie liefert den allgemeinen Maßstab. Für bestimmte Einrichtungsarten hat die Kommission ihn konkretisiert. Die Durchführungsverordnung (EU) 2024/2690 gilt für DNS-Diensteanbieter, TLD-Namenregister, Anbieter von Cloud-Computing-Diensten, Anbieter von Rechenzentrumsdiensten, Betreiber von Inhaltszustellnetzen, Anbieter verwalteter Dienste, Anbieter verwalteter Sicherheitsdienste, Anbieter von Online-Marktplätzen, Online-Suchmaschinen und Plattformen für Dienste sozialer Netzwerke sowie Vertrauensdiensteanbieter (Artikel 1). Eine WordPress-Agentur, die für Kunden Hosting, Wartung und Monitoring betreibt, kann unter die Anbieter verwalteter Dienste fallen. Ob sie es tut, folgt aus der Einordnung nach den Anhängen der Richtlinie und dem nationalen Recht, nicht aus diesem Playbook.

Für diese Einrichtungen gilt ein Sicherheitsvorfall nach Artikel 3 Absatz 1 der Verordnung als erheblich, wenn mindestens eines dieser Kriterien erfüllt ist:

• ein unmittelbarer finanzieller Verlust von mehr als 500 000 EUR oder 5 % des Gesamtjahresumsatzes des vorangegangenen Geschäftsjahres, je nachdem, welcher Betrag niedriger ist;
• die Exfiltration von Geschäftsgeheimnissen im Sinne der Richtlinie (EU) 2016/943;
• der Tod einer natürlichen Person oder eine erhebliche Schädigung ihrer Gesundheit;
• ein erfolgreicher, mutmaßlich böswilliger und unbefugter Zugriff auf Netz- und Informationssysteme, der schwerwiegende Betriebsstörungen verursachen kann;
• die einrichtungsspezifischen Schwellen der Artikel 5 bis 14.

Für Anbieter verwalteter Dienste und verwalteter Sicherheitsdienste legt Artikel 10 diese Schwellen fest: Der Dienst ist länger als 30 Minuten vollständig nicht verfügbar; die Verfügbarkeit ist für mehr als 5 % seiner Nutzer in der Union oder mehr als 1 Million Nutzer, je nachdem, welche Zahl kleiner ist, länger als eine Stunde eingeschränkt; oder Integrität, Vertraulichkeit oder Authentizität der Daten zum Dienst sind infolge einer mutmaßlich böswilligen Handlung beeinträchtigt, oder mit Auswirkung auf mehr als 5 % der Nutzer oder 1 Million Nutzer, je nachdem, welche Zahl kleiner ist.

Zwei Regeln verändern die Triage einer WordPress-Landschaft. Artikel 3 Absatz 2 nimmt geplante Dienstunterbrechungen und die geplanten Folgen planmäßiger Wartung aus, ein angekündigtes Wartungsfenster ist nach diesem Maßstab also kein erheblicher Sicherheitsvorfall. Artikel 4 ergänzt wiederkehrende Vorfälle: Vorfälle, die einzeln nicht erheblich sind, gelten zusammen als ein erheblicher Sicherheitsvorfall, wenn sie mindestens zweimal innerhalb von sechs Monaten aufgetreten sind, dieselbe offensichtliche Ursache haben und zusammen das Kriterium des finanziellen Verlusts erfüllen. Nummer 3.4.2 Buchstabe b des Anhangs verlangt eine vierteljährliche Prüfung auf solche Vorfälle. Bei WordPress ist die erneute Infektion über dasselbe ungepatchte Plugin das Muster, das diese Prüfung finden soll.

Einrichtungen außerhalb der Liste aus Artikel 1 wenden weiterhin den Maßstab aus Artikel 23 Absatz 3 in der Umsetzung ins nationale Recht an.

#Woran man eine gehackte WordPress-Seite erkennt

Diese Befunde verlangen einen Vorfallsdatensatz und eine sofortige Erheblichkeitsprüfung. Sie starten nicht automatisch eine NIS2-Frist. Artikel 23 greift, wenn eine erfasste Einrichtung Kenntnis davon erlangt, dass ein Vorfall nach den anwendbaren Regeln erheblich ist.

1. Defacement auf einer kundenseitigen Seite. Suchmaschinenindexierte Defacements, ersetzte Startseite, ersetzte Produktseiten. Die Sichtbarkeit macht die Schwere-Bewertung leicht: Vertrauensschaden ist gegeben.

2. Kompromittierter Admin mit bestätigter Anmeldung. Ein neuer Admin-Account, ein bestehender Admin-Account mit Anmeldungen aus ungewöhnlichem IP-Bereich oder Land, ein Admin-Account, der andere Konten ändert. Festgestellt von Audit-Log-Plugins (WP Activity Log, Stream, Wordfence-Audit-Log).

3. Böswillige Plugin-Installation oder Theme-Upload. Eine Plugin-Datei in wp-content/plugins/ außerhalb des regulären Updatekanals oder mit PHP, das eval, base64_decode, gzinflate oder assert auf Eingabedaten ausführt. Erkannt durch Datei-Integritätsüberwachung oder Wordfence-Scan.

4. Datenbank-Injection mit bestätigtem Schreibvorgang. SQL-Injection, der Zeilen einfügen oder ändern konnte. Bestätigt durch Audit-Log-Diff oder durch Manipulation an wp_users oder wp_options. Klassisches Signal: die siteurl-Option zeigt plötzlich auf eine fremde Domain.

5. Unberechtigter Personendaten-Export. WordPress-Export, REST-API-Aufruf mit Benutzerlisten, große wp-json/wp/v2/users-Antwort von einer unerwarteten IP. DSGVO-Artikel 33 kann zusätzlich zu NIS2 Artikel 23 greifen.

6. Ransomware oder Dateisystem-Verschlüsselung auf Produktionsserver oder Backups. Dateien mit neuen Endungen, .html-Lösegeldforderungen in Upload-Verzeichnissen, verschlüsselte Backup-Archive. Das ist ein Signal hoher Schwere, Umfang und Wesentlichkeit brauchen dennoch eine dokumentierte Entscheidung.

Für jeden dieser Befunde sagt das Agentur-Runbook: Zeitstempel der Kenntnisnahme im IR-Ticket, benannte verantwortliche Person, 24-Stunden-Zähler starten, CISO oder Pendant der Einrichtung in der ersten Stunde benachrichtigen. Die Agentur reicht nicht beim CSIRT ein; die Einrichtung tut es. Die Agentur liefert den technischen Inhalt.

#Vorlage für die NIS2-Frühwarnung binnen 24 Stunden

Die Frühwarnung ist bewusst kurz. Vorlage, die ich beim Konformitäts-Team der Einrichtung einreiche:

Einrichtung: [rechtlicher Name]
Sektor: [Anhang I oder II Klassifizierung]
Nationale Kennung: [Steuer-ID oder Registernummer]

Vorfallszusammenfassung
Datum und Uhrzeit der Kenntnisnahme: [ISO-8601 mit Zeitzone]
Erkennungsquelle: [Audit-Log / Kundenmeldung / externer Scanner / Hosting-Anbieter]
Betroffener Dienst: [öffentliche WordPress-Site unter https://example.com, Kundenportal etc.]

Erstklassifizierung
Vermutete Ursache: [böswillig / versehentlich / in Untersuchung]
Grenzüberschreitende Auswirkung: [ja / nein / in Untersuchung]
Indikatoren grenzüberschreitender Wirkung: [falls ja, was deutet darauf hin]

Erstauswirkung
Verfügbarkeit: [erreichbar / eingeschränkt / nicht erreichbar]
Bestätigter Datenzugriff: [keiner / vermutet / bestätigt]
Potenziell betroffene Betroffene: [Anzahl falls bekannt, sonst „in Untersuchung"]

Erstmaßnahmen
Eindämmungsmaßnahmen: [Zugangsdaten rotiert, Plugin entfernt, IP gesperrt etc.]
Forensik läuft: [ja / nein, mit Anbieter falls extern]
Nächstes Update: [Zeitpunkt der 72-Stunden-Meldung oder früherer Zwischenbericht]

Kontakt
Name und Rolle: [CISO, IT-Leitung etc.]
Kontakt-E-Mail und Telefon: [Direktnummer]

Das ist die Frühwarnung, nicht die Vorfallsmeldung. Die 72-Stunden-Meldung erweitert sie um Schwere-Bewertung, Indikatoren der Kompromittierung und eine klarere grenzüberschreitende Einschätzung.

#Was in die NIS2-Meldung nach 72 Stunden gehört

Innerhalb von 72 Stunden ab Kenntnisnahme ergänzt die Meldung:

• Schwere-Bewertung. Anzahl betroffener Nutzer, geografische Verteilung, Schätzung des finanziellen Schadens, geschätzte Wiederherstellungszeit.
• Indikatoren der Kompromittierung. IP-Adressen, Datei-Hashes, URLs, böswillige User-Agent-Strings, Angriffssignaturen. Artikel 23 Absatz 4 Buchstabe b verlangt sie, soweit verfügbar.
• Grenzüberschreitende Auswirkungsbewertung. Bestätigt oder ausgeschlossen, mit Begründung.
• Stand der Eindämmung. Was eingedämmt ist, was offen.
• Kooperationsbedarf. Ob die Einrichtung Unterstützung von CSIRT oder anderen Behörden benötigt.

Für WordPress enthält der Indikatoren-Block in der Regel: Angreifer-IPs aus den Access-Logs, böswillige Dateipfade in wp-content/, Hashes böswilliger Dateien, beobachtete User-Agent-Strings und alle vom WAF erhaltenen HTTP-Request-Bodies.

#Was der NIS2-Abschlussbericht enthalten muss

Artikel 23 Absatz 4 Buchstabe d: Abschlussbericht spätestens einen Monat nach der Vorfallsmeldung. Inhalte:

• Detaillierte Beschreibung des Vorfalls.
• Bedrohungstyp oder Ursache.
• Umgesetzte und laufende Gegenmaßnahmen.
• Grenzüberschreitende Auswirkung, sofern zutreffend.

Bei WordPress-Vorfällen landet die Ursachenbeschreibung typischerweise auf einem von: veraltetem Plugin mit bekanntem CVE, schwachem Admin-Passwort ohne MFA, ausgesetzter wp-config.php aus einer Backup-Datei, RCE über eine Theme-Funktion, Lieferketten-Kompromittierung eines Updatekanals, server-seitiger Fehlkonfiguration. Der Maßnahmen-Teil bildet die Ursache auf die Maßnahme aus Artikel 21 Absatz 2 ab, die das verhindert hätte, und aktualisiert das Risikoregister der Einrichtung.

#Welche Pflichten Artikel 23 NIS2 neben den drei Meldungen enthält

Die Fristen von 24 Stunden, 72 Stunden und einem Monat kennt jeder. Derselbe Artikel enthält weitere Pflichten und einen Schutz:

• Laufende Vorfälle. Nach Artikel 23 Absatz 4 Buchstabe e legt die Einrichtung, wenn der Vorfall zum Zeitpunkt des Abschlussberichts noch andauert, zu diesem Zeitpunkt einen Fortschrittsbericht vor und den Abschlussbericht innerhalb eines Monats nach Abschluss der Bearbeitung.
• Antwort des CSIRT. Artikel 23 Absatz 5 verpflichtet CSIRT oder zuständige Behörde, unverzüglich und nach Möglichkeit innerhalb von 24 Stunden nach Eingang der Frühwarnung zu antworten, mit einer ersten Rückmeldung und auf Ersuchen mit Hinweisen zu Abhilfemaßnahmen. Besteht der Verdacht einer Straftat, gibt es auch Hinweise zur Meldung an die Strafverfolgungsbehörden.
• Empfänger der Dienste. Gegebenenfalls unterrichtet die Einrichtung die Empfänger ihrer Dienste unverzüglich über erhebliche Sicherheitsvorfälle, die die Erbringung dieser Dienste beeinträchtigen könnten (Artikel 23 Absatz 1). Nach Artikel 23 Absatz 2 erfahren Empfänger, die von einer erheblichen Cyberbedrohung betroffen sein könnten, welche Maßnahmen oder Abhilfen sie selbst ergreifen können. Für einen WordPress-Shop oder ein Kundenportal ist das die vorab formulierte Kundenmitteilung.
• Vertrauensdiensteanbieter. Abweichend von Buchstabe b meldet ein Vertrauensdiensteanbieter erhebliche Sicherheitsvorfälle, die seine Vertrauensdienste betreffen, innerhalb von 24 Stunden nach Kenntnisnahme, nicht erst nach 72.
• Haftung. Artikel 23 Absatz 1 stellt klar, dass die Meldung als solche keine erhöhte Haftung der meldenden Einrichtung begründet.
• Unterrichtung der Öffentlichkeit. Nach Artikel 23 Absatz 7 können CSIRT oder zuständige Behörde nach Anhörung der Einrichtung die Öffentlichkeit informieren oder die Einrichtung dazu verpflichten, wenn das zur Verhütung oder Bewältigung des Vorfalls nötig ist oder die Offenlegung sonst im öffentlichen Interesse liegt.
• Beinahe-Vorfälle. Artikel 6 Nummer 5 definiert sie als Ereignisse, die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit von Daten oder Diensten hätten beeinträchtigen können, deren Eintritt aber verhindert wurde oder die nicht eingetreten sind. Artikel 30 erlaubt wesentlichen und wichtigen Einrichtungen, Sicherheitsvorfälle, Cyberbedrohungen und Beinahe-Vorfälle freiwillig zu melden. Ein abgewehrter Exploit-Versuch gegen ein WordPress-Plugin ist keine Pflichtmeldung, kann aber über diesen Kanal gehen.

#Wo meldet man einen NIS2-Sicherheitsvorfall

Jeder Mitgliedstaat benennt ein oder mehrere CSIRTs und eine zuständige Behörde. Die aktuelle Liste pflegt das ENISA-Portal. Häufige Anlaufstellen für Einrichtungen, mit denen ich arbeite:

• Deutschland. Bundesamt für Sicherheit in der Informationstechnik (BSI) und CERT-Bund. Die Meldungen nach § 32 BSIG gehen an die gemeinsame Meldestelle von BSI und Bundesamt für Bevölkerungsschutz und Katastrophenhilfe; registriert wird im BSI-Portal.
• Österreich. Seit dem 2026-10-01 nach § 34 NISG 2026 an das sektorspezifische CSIRT oder, falls es keines gibt, an das nationale CSIRT, das die Meldung an das Bundesamt für Cybersicherheit weiterleitet.
• Schweiz. Kein EU-Mitglied, NIS2 gilt dort nicht. Die in Art. 74b ISG genannten Behörden und Betreiber kritischer Infrastrukturen melden Cyberangriffe seit dem 2025-04-01 innert 24 Stunden nach der Entdeckung dem BACS (Art. 74e).
• Spanien. INCIBE-CERT für Privatsektor und Bürger, CCN-CERT für die öffentliche Verwaltung.
• Norwegen. Kein EU-Mitgliedstaat. Die Richtlinie richtet sich an die Mitgliedstaaten (Artikel 46), norwegische Meldepflichten ergeben sich daher aus norwegischem Recht; die aktuellen Regeln nennt die NSM.
• Portugal. CERT.PT unter dem CNCS (Centro Nacional de Cibersegurança).

Für Einrichtungen mit mehreren Jurisdiktionen pflegt ENISA die Single-Point-of-Contact-Liste (SPOC) für die grenzüberschreitende Koordination.

Aktualisierung, 26. Oktober 2026. Wenn ein Angriff über Ihre eigene Website hinausgeht, gibt es eine weitere Meldeadresse. Wordfence hat am 26. Oktober 2026 ein Threat Response Team gestartet, das den Zeitraum vom ersten Signal einer neuen Bedrohung bis zur Stabilisierung verantwortet, in der Regel die ersten 72 Stunden (Ankündigung von Wordfence). Meldungen gehen an [email protected], und zwar in drei Fällen: ein Plugin oder Theme wird aktiv ausgenutzt, ein Lieferkettenangriff wie ein manipuliertes Plugin- oder Theme-Update, oder eine Angriffswelle trifft viele WordPress-Websites gleichzeitig. Wordfence bittet um eine Beschreibung mit Beginn, das betroffene Plugin oder Theme mit Version, Indikatoren (verdächtige Dateien, unbekannte Admin-Konten, IP-Adressen, Logeinträge) und eine Kontaktmöglichkeit. Das sind dieselben Daten, die Sie für die Frühwarnung nach der Vorlage oben sammeln, ein Beweispaket reicht also für beide Meldungen. IP-Adressen in Logs sind personenbezogene Daten nach der DSGVO: Senden Sie die Adressen der Angreifer, nicht die Besuchslogs Ihrer Kunden. Diese Meldung ersetzt weder Artikel 23 NIS2 noch § 32 BSIG: Die Frühwarnung an die zuständige Stelle geht innerhalb von 24 Stunden raus, unabhängig davon, wie der Sicherheitsanbieter reagiert.

#Wie man einen Incident-Response-Plan für WordPress vorbereitet

Die 24-Stunden-Frist ist gnadenlos für Einrichtungen, die mit der Vorbereitung erst bei Kenntnisnahme beginnen. Vor jedem Vorfall:

• Eine benannte On-Call-Rotation. Zwei Personen, primär und sekundär, mit Telefonnummern im IR-Runbook.
• Ein Eskalationsbaum zum CISO der Einrichtung. Die Agentur kann die Frühwarnung nicht einreichen; die Einrichtung muss, also muss der Pfad von „Agentur sieht etwas” zu „Einrichtung entscheidet” unter einer Stunde liegen.
• Vorlagen für die Kommunikation. Kundenbenachrichtigung, interne Benachrichtigung, Behördenmeldung. Alle drei in allen relevanten Sprachen.
• Snapshot-Fähigkeit für die Produktions-WordPress-Instanz. Vor jeder Eindämmungsänderung Dateisystem und Datenbank für die Forensik sichern.
• Eine Beziehung zu einem Forensik-Anbieter, vorab vertraglich geregelt. Forensik nach Artikel 23 binnen 72 Stunden braucht einen Anbieter, der ans Telefon geht, keine Beschaffungsausschreibung.
• Ein Off-Site-immutables Backup. Ohne dieses kann Ransomware den Abschlussbericht verhindern, indem sie Beweise zerstört.

Die Preisgestaltung für die Einrichtung dieser Bereitschaft ist individuell und hängt vom Umfang der WordPress-Landschaft ab; sie ist keine Position auf einer Hosting-Rechnung.

#Anforderungen an die Vorfallsbewältigung in der Durchführungsverordnung 2024/2690

Abschnitt 3 des Anhangs der Durchführungsverordnung 2024/2690 legt für die in ihrem Artikel 1 genannten Einrichtungen die Anforderungen an die Bewältigung von Sicherheitsvorfällen nach Artikel 21 Absatz 2 Buchstabe b der Richtlinie fest. Auf eine WordPress-Landschaft übertragen, ändern diese Punkte den Arbeitsalltag:

• Konzept für die Bewältigung von Sicherheitsvorfällen (3.1). Rollen, Zuständigkeiten und Verfahren zum Erkennen, Analysieren, Eindämmen, Wiederherstellen, Dokumentieren und Melden, mit einem Kategorisierungssystem, Kommunikationsplänen für Eskalation und Meldung und den Dokumenten für die Reaktion: Handbücher, Eskalationsdiagramme, Kontaktlisten und Vorlagen (3.1.2). Die Frühwarnungsvorlage oben ist eines dieser Dokumente. Das Konzept wird in geplanten Abständen und nach erheblichen Sicherheitsvorfällen getestet und überprüft (3.1.3).
• Protokollierung (3.2.3). Gegebenenfalls erfassen Protokolle das Anlegen, Ändern oder Löschen von Nutzern und die Erweiterung von Berechtigungen, Authentifizierungsereignisse, jeden privilegierten Zugriff und die Tätigkeiten administrativer Konten sowie Zugriffe auf kritische Konfigurations- und Sicherungsdateien oder deren Änderung. Für WordPress heißt das: Änderungen an Nutzern und Rollen, Administrator-Anmeldungen, Änderungen an wp-config.php, .htaccess und Backup-Archiven.
• Geschützte Protokolle (3.2.5). Protokolle werden für einen festgelegten Zeitraum aufbewahrt und vor unbefugtem Zugriff oder Änderung geschützt. Ein Protokoll, das nur auf dem kompromittierten WordPress-Server liegt, kann der Angreifer ändern, es ist daher schwer als geschützt zu werten.
• Synchronisierte Zeit (3.2.6). Systeme nutzen synchronisierte Zeitquellen, damit sich Protokolle korrelieren lassen. Ohne sie lässt sich der Zeitstempel der Kenntnisnahme aus der Frühwarnung nicht mit Webserver-, WAF- und Datenbankprotokollen abgleichen.
• Meldung von Ereignissen (3.3). Ein einfacher Mechanismus erlaubt Beschäftigten, Lieferanten und Kunden, verdächtige Ereignisse zu melden, und Lieferanten und Kunden werden gegebenenfalls darüber informiert.
• Reaktion (3.5). Eindämmung, Beseitigung und Wiederherstellung; Kommunikationspläne mit dem CSIRT oder der zuständigen Behörde; Protokollierung der Reaktionsmaßnahmen samt Beweisen; Tests der Verfahren in geplanten Abständen.
• Überprüfung nach dem Vorfall (3.6). Gegebenenfalls ermittelt eine Überprüfung nach der Wiederherstellung die Ursache und endet mit dokumentierten Erkenntnissen. Der Abschlussbericht nach Artikel 23 Absatz 4 Buchstabe d und diese Überprüfung stützen sich auf dieselben Beweise.

#Wie man einen WordPress-Vorfall bewertet und Beweise sichert

Bei einem glaubwürdigen Signal wird ein zentraler Vorfallsdatensatz geöffnet. Darin stehen die unveränderte Erstbeobachtung, Zeit mit Zeitzone, Quelle, Umgebung und Triage-Leitung. Geprüft werden Echtheit, Wirkung auf Vertraulichkeit, Integrität und Verfügbarkeit und erst danach eine mögliche Erheblichkeit. Operative Stufen wie Ereignis, schwerer Vorfall und Krise steuern Ressourcen, ersetzen aber weder Artikel 23 noch nationales Recht. Bestätigte Zugriffe, Konten, Komponenten, Kundenwege, Dauer, geografischer Umfang, Lieferantenbezug und Sicherheitsgrad werden fortlaufend aktualisiert. Unbekanntes bleibt als solches markiert.

Eindämmung und Beweissicherung laufen parallel. Vor Neuinstallation oder Löschung verdächtigen Codes werden, soweit sicher, Snapshot oder Dateikopie, Datenbankzustand, Deployment-Kennung, Sitzungen, Administratorliste und Protokolle gesichert. Originalexporte bleiben erhalten, übertragene Forensikdateien erhalten Hashwerte, Arbeitskopien bleiben getrennt. Jede Zustandsänderung wie Passwortrotation, WAF-Regel, Plugin-Entfernung, Restore und DNS-Änderung kommt in die Zeitleiste. Wenn Beweissicherung laufenden Schaden verlängern würde, hat Sicherheit Vorrang; die Lücke wird begründet.

Neben der technischen Zeitleiste steht ein chronologisches Entscheidungsprotokoll. Jeder Eintrag nennt Entscheidung, Tatsachen, Annahmen, Alternativen, Eigentümer und nächsten Prüfpunkt. Technik, Management, Recht und Datenschutz sowie Kundenkommunikation erhalten getrennte Informationsstränge, die eine Koordination abgleicht. Die Agentur liefert Komponenten, Entdeckungszeit, Beweisreferenzen, Eindämmungsstand, vermuteten Zugriff und Recovery-Schätzung. Die Einrichtung entscheidet und meldet, sofern keine ausdrücklich autorisierte Regelung anderes festlegt.

#Wie man ein Incident-Response-Playbook testet und abnimmt

Eine Übung verbindet Host, Agentur, Vorfallsleitung, Datenschutz und Kommunikation. Sie reicht vom Alert über Beweissicherung und Erheblichkeitsprüfung bis zu Behördenübergabe, Recovery-Freigabe und Kundeninformation. Das Playbook ist abgenommen, wenn Bereitschaft reagiert, der richtige Datensatz öffnet, Beweise ohne improvisierten Zugang erfasst werden, Entscheider die Übergabe erhalten, Vorlagen aktuell sind, ein sauberer Wiederherstellungspunkt freigegeben werden kann und jede Maßnahme Eigentümer und Termin erhält.

Nach der Wiederherstellung bleiben Zeitleiste, Entscheidungsprotokoll, Beweisindex, Meldungskopien, Asset-Liste, Ursachenanalyse, Restore-Nachweis, Kommunikation und Verifikation der Reparaturen erhalten. Vorläufige Eindämmung wird durch eine dauerhafte Kontrolle oder eine ausdrückliche Restrisikoentscheidung ersetzt.

Für Vorbereitung oder Übung senden Sie eine schriftliche Kurzbeschreibung über den NIS2- und DORA-Readiness-Service. Nennen Sie Rechtsträger, Jurisdiktionen, WordPress-Umgebungen, Hosting, wesentliche Kundenwege, Logging, Backups, Vorfallskontakte, frühere Übungen und Prüflücken. Zugangsdaten, personenbezogene Daten und rohe Kompromittierungsbeweise gehören nicht in die erste Nachricht. Die Arbeit verbessert Bereitschaft und Nachweise, ist aber weder Rechtsgutachten noch Garantie oder automatische Feststellung einer Meldepflicht.

#Weitere Artikel zu NIS2 und Compliance

• Pillar: NIS2 und DORA auf WordPress: Konformitäts-Stack 2026
• NIS2 Anhang II für WordPress-Agenturen: Geltungsbereich, Fristen, Nachweispfad
• DORA Artikel 28 IKT-Drittparteirisiko: WordPress-Hosting- und WAF-Lieferanten-Audit
• Cyber Resilience Act + NIS2 + DORA: der Compliance-Stack 2026 für headless WordPress
• NIS2 Incident-Meldepflicht WordPress: 24 Stunden, 72 Stunden, ein Monat
• NIS2 vs DORA Geltungsbereich-Überschneidung für WordPress-Agenturen 2026
• EU-Konformitätsaudit für WordPress