IT-Risikoanalyse für WordPress-Websites: eine einfache Methode

Eine IT-Risikoanalyse für eine WordPress-Website passt auf eine Seite. Sie hält fest, was Sie haben, was realistischerweise schiefgehen kann, wie schlimm das wäre und wer bis wann was behebt. Mit der folgenden Methode in fünf Schritten haben Sie heute Nachmittag einen ersten Entwurf. Damit haben Sie etwas Konkretes in der Hand, wenn ein Kunde per Fragebogen, Ihre Versicherung oder eine Aufsichtsbehörde wissen will, wie Sie Ihre Sicherheitsmaßnahmen ausgewählt haben.

Warum die IT-Risikoanalyse unter DSGVO und NIS2 am Anfang steht

Art. 32 Abs. 1 DSGVO verlangt geeignete technische und organisatorische Maßnahmen, die ein dem Risiko angemessenes Schutzniveau gewährleisten, und zwar unter Berücksichtigung des Stands der Technik und der Implementierungskosten. Ob eine Maßnahme angemessen ist, können Sie nur begründen, wenn Sie vorher das Risiko benannt haben. Art. 5 Abs. 2 ergänzt die Rechenschaftspflicht: Sie müssen die Einhaltung nachweisen können. Die Risikoanalyse gehört also schriftlich festgehalten. Um die Maßnahmen selbst geht es in unserem Beitrag zu Art. 32 DSGVO für WordPress.

Fällt Ihr Unternehmen als wichtige oder besonders wichtige Einrichtung unter NIS2, beginnt die Liste der Mindestmaßnahmen in Art. 21 Abs. 2 mit Buchstabe a: Konzepte für die Risikoanalyse und die Sicherheit von Informationssystemen. Verbindlich werden die Pflichten erst durch nationales Recht, maßgeblich ist also die deutsche Umsetzung. Ob NIS2 für Sie überhaupt gilt, können Sie vorab prüfen.

Diese Methode ist ein pragmatischer Einstieg. Sie ersetzt weder eine ISO-27001-Einführung noch ein formales externes Audit.

Schritt 1: Assets erfassen (Websites, Daten, Zugänge, Dienstleister)

Ein Asset ist alles, dessen Verlust oder Missbrauch Ihnen schaden würde. Für ein typisches kleines Unternehmen decken vier Gruppen fast alles ab. Beginnen Sie mit den personenbezogenen Daten: Dort greift die DSGVO, und dort wiegen die Folgen am schwersten.

Werden Sie konkret. „Website“ ist zu vage. „shop.example.de, WooCommerce mit rund 40 Plugins, Bestellungen seit 2021“ hilft weiter. Stoßen Sie beim Erstellen der Liste auf eine vergessene Staging-Kopie oder das Admin-Konto eines ehemaligen Freelancers, notieren Sie es. Allein dieser Fund rechtfertigt die Übung.

Schritt 2: Realistische Bedrohungen je Asset benennen

Einen Katalog aller denkbaren Angriffe brauchen Sie nicht. Bei WordPress-Websites decken vier Gruppen von Bedrohungen die meisten echten Vorfälle ab:

• Verwundbare oder verwaiste Plugins und Themes. Jemand nutzt eine bekannte Lücke aus, bevor Sie aktualisieren, oder eine Lücke, die nie geschlossen wird.
• Gestohlene oder geteilte Zugangsdaten. Ein wiederverwendetes Passwort, ein gemeinsam genutztes „admin“-Konto oder ein Agentur-Login, den niemand gelöscht hat.
• Ausfall von Hoster oder Server. Eine Störung, Datenverlust beim Hoster oder eine Lücke in der Serversoftware selbst. Die PHP2Shell-Schwachstellen sind ein Beispiel: Sie steckten in der PHP-Laufzeitumgebung, sodass auch ein vollständig aktualisiertes WordPress angreifbar war.
• Menschliche Fehler. Ein missglücktes Update, das den Checkout lahmlegt, eine gelöschte Seite oder ein Redakteur, der „nur kurz“ die Administrator-Rolle bekommt.

Die Plugin-Bedrohung verdient eine ehrliche Bewertung. Der Anbieter Patchstack zählt in seinem Bericht State of WordPress Security in 2026 für 2025 insgesamt 11.334 neue Schwachstellen im WordPress-Ökosystem. 91 % davon betrafen Plugins, und für 46 % gab es zum Zeitpunkt der Veröffentlichung keinen Fix des Entwicklers. Bei stark ausgenutzten Schwachstellen lag die gewichtete Medianzeit bis zur massenhaften Ausnutzung bei 5 Stunden. Das sind Zahlen eines Herstellers, aber sie erklären, warum „verwundbares Plugin“ in einem WordPress-Register meist ganz oben landet.

Schritt 3: Wahrscheinlichkeit und Auswirkung auf einer Skala von 1–3 bewerten

Arbeiten Sie mit drei Stufen und beschreiben Sie diese in einfachen Worten. Dann kommen zwei Personen, die dasselbe Risiko bewerten, zum selben Ergebnis.

Wahrscheinlichkeit

1. Innerhalb eines Jahres unwahrscheinlich
2. Innerhalb eines Jahres möglich
3. Zu erwarten, oder es ist Ihnen oder einer vergleichbaren Website schon passiert

Auswirkung

1. Ärgernis: Die Behebung dauert eine Stunde, Daten sind nicht betroffen
2. Ausfallzeit oder eine begrenzte Menge nicht sensibler Daten betroffen
3. Personenbezogene Daten offengelegt, Zahlungen betroffen oder Stillstand im Betrieb

Multiplizieren Sie beide Werte. Ein Wert von 1–2 heißt akzeptieren, 3–4 heißt Maßnahme planen, 6–9 heißt sofort handeln. Die Werte 5, 7 und 8 kommen auf dieser Skala nicht vor, dadurch bleiben die Bereiche klar getrennt.

Bewerten Sie das Risiko so, wie es heute ist. Nur eine Schutzmaßnahme, die existiert und funktioniert, senkt die Wahrscheinlichkeit. „Wir haben Backups“ zählt erst, wenn jemand tatsächlich eines zurückgespielt hat. Verzichten Sie auf Nachkommastellen und Gewichtungsfaktoren. Die Skala von 1–3 ist bewusst grob. Scheinpräzision lässt das Register wissenschaftlicher aussehen, als es das Wissen dahinter hergibt.

Schritt 4: Maßnahmen, Verantwortliche und Prüftermine festlegen

Für jedes Risiko ab einem Wert von 3 wählen Sie ein oder zwei konkrete Maßnahmen. „Sicherheit verbessern“ ist keine Maßnahme. „Zwei-Faktor-Anmeldung für alle vier Admins bis 17. November aktivieren“ schon. Benennen Sie eine Person als verantwortlich, nicht „die IT“ oder „die Agentur“, und setzen Sie ein Datum.

Die Maßnahmen selbst behandeln unsere ausführlichen Beiträge, etwa zum Umgang mit verwundbaren Plugins und zu WordPress-Backups, die sich wirklich wiederherstellen lassen. Ihr Risikoregister muss nur die Entscheidung festhalten und auf den Nachweis verweisen.

Zwei Dinge gehören zusätzlich in jede Zeile. Erstens ist „akzeptieren“ bei niedrigen Werten eine legitime Entscheidung, solange Sie die Begründung notieren. Zweitens das Restrisiko, also der Wert, den Sie nach Umsetzung der Maßnahme erwarten. Senkt eine Maßnahme den Wert nicht, ist es wahrscheinlich die falsche.

Praxisbeispiel: Risikoregister für einen kleinen WooCommerce-Shop

Das folgende Beispiel beschreibt einen fiktiven Shop mit einer WooCommerce-Website, einer Staging-Kopie, zwei Beschäftigten, einer externen Agentur und Shared Hosting. „W“ steht für Wahrscheinlichkeit, „A“ für Auswirkung, „Danach“ für den erwarteten Restwert.

Lesen Sie die Tabelle von oben. Diese Woche löscht der Shop das Agentur-Konto und fragt beim Hoster wegen PHP nach. Beides kostet wenig und dauert keine Stunde. Das Aufräumen der Plugins folgt bis nächste Woche, weil es den höchsten Wert hat. 2FA und der Wiederherstellungstest sind innerhalb des Monats eingeplant.

Die Zeilen zu Bedienfehlern und Kontaktformularen haben Zeit bis Dezember. Ihre Werte sind niedriger, und bei Fehlern der Mitarbeitenden bietet die Backup-Arbeit aus Zeile vier bereits eine Rückfallebene. Der Ausfall des Newsletter-Dienstes wird akzeptiert, mit Begründung und Prüftermin. Jede Zeile endet bei 3 oder darunter. Das heißt nicht, dass nichts passieren kann. Es ist ein dokumentiertes, begründetes Risikoniveau.

Die Risikoanalyse aktuell halten

Eine IT-Risikoanalyse, die nie wieder geöffnet wird, belegt vor allem eines: dass Sie irgendwann aufgehört haben hinzuschauen. Überprüfen Sie sie, sobald einer dieser Anlässe eintritt:

• Nach jedem Vorfall oder Beinahe-Vorfall, auch nach einer Welle fehlgeschlagener Logins oder einem Plugin, das Sie zurückrollen mussten
• Nach größeren Änderungen, etwa einem neuen Plugin, das personenbezogene Daten verarbeitet, einem neuen Hoster, einer neuen Agentur oder dem Start eines Shops
• Wenn ein Dienstleister oder ein NIS2-regulierter Kunde einen Sicherheitsfragebogen schickt
• In einem festen Rhythmus Ihrer Wahl, zum Beispiel vierteljährlich oder jährlich. Das entscheiden Sie selbst, eine gesetzliche Vorgabe ist es nicht

Versehen Sie das Dokument mit Versionsnummer und Datum, und bewahren Sie alte Fassungen auf. Eine Historie, die zeigt, wie ein Wert von 9 nach einer Maßnahme auf 3 gesunken ist, ist ein guter Nachweis im Sinne der Rechenschaftspflicht. Wie das Register zu Ihren übrigen Unterlagen passt, zeigt unser Leitfaden zur Dokumentation von Sicherheitsaudits.

Das Audit-Plugin „Security Audit & Compliance“ von secaudit.eu kann Sie bei Schritt 2 und bei jeder Überprüfung unterstützen. Es ordnet seine Befunde Art. 32 DSGVO und Art. 21 NIS2 zu und exportiert sie als Bericht oder CSV, die Sie mit Ihrem Register abgleichen können. Die Entscheidungen im Register bleiben Ihre; das Plugin liefert aktuelle Grundlagen dafür. → secaudit.eu

Ihr nächster Schritt: Kopieren Sie die Beispieltabelle, ersetzen Sie die Zeilen durch Ihre eigenen Assets und tragen Sie den ersten Prüftermin ein, bevor Sie die Datei schließen.

FAQ

Brauche ich dafür ISO 27001?

Nein. Diese Methode ist ein praktischer Einstieg, den Sie mit Ihrem eigenen Team umsetzen können. ISO 27001 ist eine vollständige Norm für Managementsysteme. Ob Sie sie später einführen, ist eine eigene unternehmerische Entscheidung, oft angestoßen durch große Kunden.

Wie lange dauert das für eine Website?

Bei einer einzelnen Website mit bekanntem Aufbau schaffen Sie einen ersten Entwurf in einer Arbeitssitzung. Die meiste Zeit kostet Schritt 1, also das Zusammentragen von Zugängen und Dienstleistern. Spätere Überprüfungen gehen deutlich schneller, weil Sie nur noch Änderungen nachtragen.

Macht eine Agentur das einmal oder für jeden Kunden?

Jeder Kunde ist Verantwortlicher für seine eigene Website, und ihm gehört auch die Risikoanalyse. Die Agentur kann einen Entwurf vorbereiten, den der Kunde freigibt. Für die eigenen Systeme sollte sie ein separates Register führen, etwa für Laptops, Passwort-Tresor und Zugänge zum Hosting der Kunden. Wer was übernimmt, gehört in Ihren Auftragsverarbeitungsvertrag.

Dieser Artikel ist eine allgemeine Information und keine Rechtsberatung.