WordPress-Sicherheitsaudit-Bericht: welche Nachweise zählen
So erstellen Sie einen WordPress-Sicherheitsaudit-Bericht: sechs Nachweise, gute und schwache Belege, Fragen von Kunden und Versicherern – mit Vorlage.
Auch auf: English Français Español Italiano Polski Português Türkçe
Wenn ein Kunde, Prüfer oder Versicherer einen Beleg dafür verlangt, dass Ihre WordPress-Website abgesichert ist, reicht „Wir halten alles aktuell“ nicht aus. Gefragt sind Aufzeichnungen. Ein WordPress-Sicherheitsaudit-Bericht fasst diese Aufzeichnungen in einem Dokument zusammen, das ein Dritter lesen und überprüfen kann. Dieser Artikel zeigt, was Sie aufbewahren sollten, wie ein brauchbarer Eintrag aussieht und wie Sie die Dokumentation aktuell halten, ohne dass daraus ein zweiter Job wird.
Warum ein WordPress-Sicherheitsaudit-Bericht zählt: nachweisen statt behaupten
Nach der DSGVO muss der Verantwortliche die Einhaltung der Grundsätze nachweisen können. Sie nur anzuwenden genügt nicht (Art. 5 Abs. 2). Art. 32 Abs. 1 lit. d verlangt zudem ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung Ihrer Sicherheitsmaßnahmen. Wird dieses Verfahren tatsächlich gelebt, hinterlässt es Spuren auf Papier.
Das gilt auch für alle, die an der Website arbeiten. Hoster und Agenturen mit Admin-Zugang sind in der Regel Auftragsverarbeiter nach Art. 28. Ihre Kunden werden deshalb dieselbe Art von Nachweisen von ihnen verlangen. Welche Maßnahmen selbst sinnvoll sind, beschreibt unser Leitfaden zu Art. 32 DSGVO für WordPress.
Dokumentation hat Grenzen. Sie kann belegen, dass Maßnahmen umgesetzt wurden, beweist aber für sich genommen nicht, dass sie weiterhin wirken. Sie macht keine Website sicher, und Papier allein erfüllt Ihre Pflichten aus der DSGVO nicht. Veraltete Dokumentation kann sogar schlechter sein als gar keine. Ein Backup-Konzept, das ein Plugin beschreibt, das Sie letztes Jahr entfernt haben, zeigt einem Prüfer vor allem eines: Ihre Unterlagen werden nicht gepflegt.
Die sechs Nachweise, die Prüfer und Kunden tatsächlich ansehen
1. Inventar. Es enthält die Core-Version, jedes Plugin und Theme mit Version, den Hoster, die PHP-Version und die eingesetzten Drittdienste. Außerdem steht darin, welche personenbezogenen Daten jeder Bestandteil berührt. Ein brauchbarer Eintrag lautet etwa: „Kontaktformular-Plugin, speichert Einträge in der Datenbank (Name, E-Mail, Nachricht), Einträge werden laut unserer Richtlinie nach 90 Tagen gelöscht.“ Aktualisieren Sie das Inventar bei jeder Änderung und gleichen Sie es vierteljährlich mit dem tatsächlichen Stand ab.
2. Update-Protokoll. Jede Zeile hält Datum, Komponente, alte und neue Version fest, wer das Update eingespielt hat und ob es automatisch lief. Tragen Sie jede Änderung einzeln ein. Auto-Updates zählen mit, aber danach sollte jemand bestätigen, dass die Website noch funktioniert.
3. Scan-Berichte. Bewahren Sie datierte Berichte samt Nachbearbeitung nach einer dokumentierten Aufbewahrungsregel auf, statt den vorigen Bericht einfach zu überschreiben. Halten Sie zu jedem Befund fest, wie er erledigt wurde: behoben, mit Begründung akzeptiert oder Fehlalarm. Ein Bericht mit zehn Befunden ohne jede Nachbearbeitung zeigt, dass Sie gescannt haben. Er zeigt nicht, dass Sie gehandelt haben.
4. Backups und Restore-Tests. Dokumentieren Sie den Zeitplan, den Speicherort, die Aufbewahrungsdauer sowie Datum und Ergebnis der letzten Test-Wiederherstellung. Ein erfolgreich gelaufener Backup-Job beweist nicht, dass die Wiederherstellung klappt. Als praktischer Ausgangspunkt bieten sich Restore-Tests einmal im Quartal und nach größeren Änderungen an; wählen Sie die Häufigkeit passend zu Ihren Risiken und Ihrem Wiederherstellungsbedarf. Wiederhergestellte personenbezogene Daten gehören in eine isolierte Testumgebung.
5. Zugriffsliste. Halten Sie fest, wer welche Rolle hat, ob für jedes Konto die Zwei-Faktor-Authentifizierung aktiv ist, wann die Zugriffe zuletzt überprüft wurden und wann ehemalige Mitarbeitende oder Agenturen entfernt wurden. Aktualisieren Sie die Liste bei jeder Änderung und prüfen Sie sie monatlich.
6. Vorfallprotokoll. Erfassen Sie jeden Sicherheitsvorfall, auch Datenpannen, die Sie bewusst nicht gemeldet haben. Art. 33 Abs. 5 verpflichtet Sie, alle Verletzungen des Schutzes personenbezogener Daten zu dokumentieren: die Fakten, die Auswirkungen und die ergriffenen Abhilfemaßnahmen. Die Meldung selbst behandelt unser Leitfaden zur 72-Stunden-Frist.
Was gute Nachweise ausmacht (und was nicht zählt)
Gute Aufzeichnungen haben vier Merkmale gemeinsam:
- Jeder Eintrag ist datiert.
- Jeder Eintrag nennt die Person, die ihn erstellt hat.
- Alle Einträge liegen an einem einheitlichen Ort.
- Sie entstehen im laufenden Betrieb und werden nicht in der Woche vor dem Audit rekonstruiert.
Ein Prüfer merkt meist, wenn ein Protokoll an einem einzigen Nachmittag geschrieben wurde.
Vergleichen Sie zwei Fassungen derselben Aussage. Schwach: „Wir aktualisieren Plugins regelmäßig.“ Besser als Vorlage: „[Datum], [Plugin], [alte Version] auf [neue Version], Auto-Update, [durchgeführter Test], geprüft von [Name].“ Ersetzen Sie jeden Platzhalter durch die tatsächlichen Angaben. Die zweite Fassung lässt sich überprüfen, und sie zeigt eine Routine.
Exporte schlagen Screenshots. Eine CSV-Datei mit Plugin-Versionen oder ein Scan-Bericht als PDF behält Daten und Datum. Ein zugeschnittener Screenshot des Dashboards beweist wenig und ist nicht durchsuchbar. Nutzen Sie Screenshots nur für Einstellungen ohne Exportfunktion und setzen Sie das Datum in den Dateinamen.
Speichern Sie die Nachweise nicht auf dem WordPress-Server. Wird die Website kompromittiert, darf der Angreifer Ihre Belege nicht verändern können, und während der Bereinigung brauchen Sie die Unterlagen ohnehin. Ein zugriffsbeschränktes gemeinsames Laufwerk kann eine praktikable Lösung sein: Bearbeitungsrechte einschränken, Versionsverlauf aktivieren und mit Zugangsdaten schützen, die von denen der WordPress-Website getrennt sind.
Bleiben Sie verhältnismäßig. Für ein kleines Unternehmen ist eine Tabelle mit einem Reiter pro Nachweis plus ein datierter Ordner mit PDFs ein völlig ausreichendes Nachweispaket. Für eine Website mit zehn Seiten erwartet niemand eine Governance-Plattform.
Lieferanten-Fragebögen von NIS2-Kunden beantworten
Agenturen, Freelancer und Plugin-Anbieter bekommen Sicherheitsfragebögen, auch wenn NIS2 für sie selbst gar nicht gilt. Der Grund ist Art. 21 Abs. 2 lit. d der NIS2-Richtlinie. Die Richtlinie verlangt Maßnahmen zur Sicherheit der Lieferkette, was Kunden dazu bringen kann, Nachweise von ihren Lieferanten einzufordern. Die konkreten Pflichten ergeben sich aus dem nationalen Umsetzungsgesetz: Prüfen Sie das NIS2-Recht Ihres Landes. Ob Ihr Kunde oder Sie selbst als wichtige oder besonders wichtige Einrichtung erfasst sind, ist eine eigene Frage; sie behandeln wir in NIS2 und Ihre WordPress-Website.
Die Fragen unterscheiden sich je nach Kunde und Vertrag, lesen Sie also den tatsächlichen Fragebogen. Die Themen orientieren sich meist an den Maßnahmen aus Art. 21 Abs. 2, und jedes lässt sich einem Nachweis zuordnen, den Sie ohnehin führen:
| Themenbereich | Ihr Nachweis |
|---|---|
| Bewältigung von Sicherheitsvorfällen | Vorfallprotokoll |
| Backups, Betriebskontinuität | Backup- und Restore-Test-Nachweis |
| Umgang mit Schwachstellen | Update-Protokoll, Scan-Berichte |
| Zugriffskontrolle, MFA | Zugriffsliste |
| Verschlüsselung | Inventar (TLS, Hosting) |
| Asset-Management | Inventar |
Beantworten Sie nur, was Sie belegen können. Wo ein Formular nur Ja/Nein vorsieht, ergänzen Sie eine kurze Anmerkung oder bieten das Dokument an, zum Beispiel: „Ja, monatlich. Die letzten drei Scan-Berichte stellen wir auf Anfrage bereit.“ Ist etwas nur teilweise umgesetzt, sagen Sie das. Eine geschönte Antwort in einem Lieferantenvertrag ist selbst ein Risiko.
Fragen der Cyberversicherung: dieselben Nachweise, aber das echte Formular lesen
Versicherer stellen eigene Fragen, und die Formulierungen unterscheiden sich von Anbieter zu Anbieter. Ihre Antworten können später im Schadenfall eine Rolle spielen. Antworten Sie zutreffend, bewahren Sie eine datierte Kopie genau dessen auf, was Sie eingereicht haben, und prüfen Sie die Angaben erneut, wenn sich Ihr Setup ändert. Ein neuer Hoster oder eine weggefallene 2FA-Pflicht sind Beispiele für solche Änderungen.
Typische Themen wie Backups, Multi-Faktor-Authentifizierung und Patching lassen sich denselben sechs Nachweisen zuordnen. Was eine konkrete Police verlangt und wie sich Ihre Antworten auf den Versicherungsschutz auswirken, klären die Versicherungsbedingungen und Ihr Makler.
Die Dokumentation aktuell halten, ohne Mehraufwand
Der folgende Rhythmus ist ein praktischer Ausgangspunkt, keine gesetzliche Mindestanforderung. Passen Sie ihn an Ihre Risiken, die Änderungshäufigkeit und vertragliche Vorgaben an:
| Wann | Was aktualisieren |
|---|---|
| Bei jeder Änderung | Update-Protokoll, Zugriffsliste |
| Monatlich | Scan-Berichte, Zugriffsprüfung |
| Vierteljährlich | Restore-Test, Inventar-Abgleich |
| Jährlich | Gesamtprüfung, Freigabe durch die Leitung |
Die jährliche Prüfung sollte jemand mit Entscheidungsbefugnis abzeichnen. Für Einrichtungen, die unter das nationale NIS2-Recht fallen, verlangt Art. 20, dass die Leitungsorgane die Cybersicherheitsmaßnahmen billigen, ihre Umsetzung überwachen und an Schulungen teilnehmen. Eine jährliche Unterschrift allein belegt keine laufende Überwachung; bewahren Sie Aufzeichnungen über Entscheidungen, Überprüfungen und Folgemaßnahmen auf.
Automatisieren Sie die Exporte. Mit WP-CLI erzeugt ein monatlicher Cronjob auf dem Server oder ein Skript von Ihrem Arbeitsplatzrechner datierte Dateien:
wp core version > core-$(date +%F).txt
wp plugin list --format=csv > plugins-$(date +%F).csv
wp theme list --format=csv > themes-$(date +%F).csv
wp user list --role=administrator --format=csv > admins-$(date +%F).csv
Führen Sie die Befehle in einem Verzeichnis außerhalb des Web-Roots aus und verweisen Sie WP-CLI mit --path=/path/to/wordpress auf die Website, damit die Exporte nie öffentlich erreichbar sind. Kopieren Sie sie anschließend in Ihre Nachweisablage. Der Admin-Export enthält E-Mail-Adressen, behandeln Sie ihn also als personenbezogene Daten.
Scan-Berichte gehören in denselben Ordner. Das Plugin Security Audit & Compliance von secaudit.eu exportiert einen Bericht und eine CSV-Datei, deren Befunde DSGVO Art. 32, NIS2 Art. 21 und den OWASP Top 10:2025 zugeordnet sind; beides können Sie direkt im Nachweisordner ablegen. Ein solcher Bericht zeigt, dass eine Prüfung stattgefunden hat und was sie ergeben hat, mehr nicht. Die Maßnahmen hinter den einzelnen Nachweisen finden Sie in unserer WordPress-Sicherheitscheckliste.
Vorlage: Gliederung für einen WordPress-Sicherheitsaudit-Bericht
Übernehmen Sie diese Struktur und füllen Sie sie aus Ihren sechs Nachweisen:
- Umfang und Datum: welche Website(s), welcher Zeitraum, wer den Bericht verfasst hat.
- Website und Verantwortliche: Inhaber, technischer Ansprechpartner, Auftragsverarbeiter (Hoster, Agentur) und Stand ihrer Auftragsverarbeitungsverträge (Art. 28).
- Zusammenfassung des Inventars: Core, PHP, Anzahl der Plugins und Themes, Drittdienste, verarbeitete personenbezogene Daten.
- Umgesetzte Maßnahmen, zugeordnet zu Art. 32 Abs. 1 lit. a–d: Verschlüsselung; Vertraulichkeit, Integrität und Verfügbarkeit; Wiederherstellbarkeit; regelmäßige Überprüfung.
- Stand von Updates und Schwachstellen: veraltete Komponenten, bekannte Schwachstellen, geplante Korrekturen.
- Scan-Ergebnisse und Behebung: Datum jedes Scans, Befunde, Erledigung.
- Backups und Restore-Tests: Zeitplan, Speicherort, Aufbewahrung, Datum und Ergebnis des letzten Tests.
- Zugriffsprüfung: Konten je Rolle, 2FA-Abdeckung, entfernte Konten, Prüfdatum.
- Dokumentierte Vorfälle und Datenpannen (Art. 33 Abs. 5), einschließlich nicht gemeldeter.
- Offene Risiken und geplante Maßnahmen, jeweils mit Verantwortlichem und Frist.
- Freigabe: Name, Funktion, Datum.
Fangen Sie diesen Monat mit zwei Dingen an: einem Inventar-Export und einer Test-Wiederherstellung auf einer Staging-Website. Zusammen decken sie bereits mehrere Themenbereiche aus der Fragebogen-Tabelle oben ab. Für datierte Scan-Berichte im Nachweisordner führt das Audit-Plugin von secaudit.eu die Prüfungen auf Ihrer Website durch und exportiert die Ergebnisse → secaudit.eu.
Dieser Artikel ist eine allgemeine Information und keine Rechtsberatung.
FAQ
Wie lange sollte ich Sicherheitsnachweise aufbewahren?
Die DSGVO legt für diese Aufzeichnungen keine einheitliche Aufbewahrungsfrist fest. Bewahren Sie sie so lange auf, wie Sie sie zum Nachweis der Einhaltung benötigen, und prüfen Sie, ob Ihre Branche oder Ihre Verträge bestimmte Fristen vorgeben. Legen Sie Fristen je Nachweisart und Zweck fest; speichern Sie personenbezogene Daten nicht unbegrenzt, nur weil das Setup noch in Betrieb ist. Personenbezogene Daten in den Nachweisen, etwa Admin-E-Mail-Adressen, sollten nicht länger als nötig aufbewahrt werden.
Heißt ein sauberer Audit-Bericht, dass wir die DSGVO erfüllen?
Nein. Ein Bericht zeigt, dass bestimmte technische Prüfungen an einem bestimmten Tag bestanden wurden. Die DSGVO umfasst außerdem Rechtsgrundlagen, Einwilligungen, Auftragsverarbeitungsverträge, Betroffenenrechte und mehr. Selbst auf der Sicherheitsseite sagt ein sauberer Scan nichts darüber aus, wie Ihr Team mit Passwörtern oder Phishing umgeht.
Kann unsere Agentur die Dokumentation für uns führen?
Ja, und Agenturen haben oft die besten Daten. Rechenschaftspflichtig bleibt aber der Verantwortliche. Nehmen Sie die Dokumentationspflichten in den Vertrag nach Art. 28 auf: was erfasst wird, wie oft und wie Sie Zugriff erhalten. Behalten Sie eine eigene Kopie, damit die Nachweise nicht mit der Agentur verschwinden.
Prüfen Sie Ihre eigene Website
Security Audit & Compliance ist das WordPress-Plugin von secaudit.eu: Es sucht nach Malware, verstecktem Spam, veränderten Kerndateien und unsicherem Code und ordnet seine Befunde DSGVO Art. 32, NIS2 Art. 21 und den OWASP Top 10 zu.
Sehen, was das Plugin prüft