Datenschutzvorfall melden: Wann Website-Hacks und Malware meldepflichtig sind

Der Anruf kommt meistens am Freitagnachmittag. Die Website leitet auf eine fremde Seite um, im Backend taucht ein Admin-Konto auf, das niemand angelegt hat, und irgendwo im Uploads-Verzeichnis liegen PHP-Dateien mit kryptischen Namen. Die erste Frage lautet fast immer: Wie kriegen wir die Seite schnell wieder sauber? Die zweite Frage stellt in dem Moment kaum jemand, und sie hat eine Uhr, die bereits läuft: Sind dabei personenbezogene Daten in falsche Hände geraten?

Genau an dieser Stelle wird aus einem IT-Sicherheitsvorfall ein Datenschutzvorfall. Ausschlaggebend ist, ob personenbezogene Daten zerstört, verloren, verändert, unbefugt offengelegt oder unbefugt zugänglich wurden. Wenn ja, muss das verantwortliche Unternehmen die Lage bewerten, dokumentieren und unter Umständen innerhalb von 72 Stunden an die Datenschutzaufsicht melden.

Die kurze Antwort: Meldepflichtig ist nicht jeder Hack, sondern ein Vorfall mit voraussichtlichem Risiko für betroffene Personen. Könnten Kunden-, Interessenten- oder Mitarbeiterdaten abgeflossen, eingesehen oder verändert worden sein, gehört eine zügige Prüfung dazu. Bei hohem Risiko kommt die Information der Betroffenen hinzu. Dieser Beitrag ordnet die technische und organisatorische Seite ein; die Bewertung des konkreten Einzelfalls gehört zu Datenschutzbeauftragten oder in die juristische Beratung.

Wann muss ein Datenschutzvorfall gemeldet werden?

Die DSGVO fasst den Begriff weit. Artikel 4 Nummer 12 meint nicht nur das nachweisbare Datenleck, sondern auch unbefugten Zugriff, Verlust, Zerstörung oder Veränderung personenbezogener Daten. Bei einer Website sind das übernommene Nutzerkonten, auslesbare Formulareingänge, offen erreichbare Backups oder manipulierte Datenbanken.

Artikel 33 DSGVO verlangt die Meldung an die zuständige Aufsichtsbehörde, sobald die Verletzung voraussichtlich zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt. Sie soll unverzüglich erfolgen, spätestens aber 72 Stunden nach Bekanntwerden. Und selbst wenn Sie begründet zu dem Schluss kommen, dass kein Risiko besteht und deshalb nicht melden: Der Vorfall bleibt dokumentationspflichtig.

Malware allein beantwortet die Frage noch nicht. Entscheidend ist, was der Angreifer erreichen konnte und welche Daten dort lagen. Diese Einordnung hilft als erste Orientierung:

Situation	Datenschutzrechtliche Einordnung	Nächster Schritt
Website wurde verändert, personenbezogene Daten waren nach belastbarer Prüfung nicht erreichbar.	Nicht automatisch ein meldepflichtiger Datenschutzvorfall.	Technik absichern, Prüfung und Begründung dokumentieren.
Angreifer konnten möglicherweise auf Kontaktformulare, Kundenkonten, Logfiles oder Datenbanken zugreifen.	Ein Risiko für Betroffene ist möglich.	Umfang und Folgen zügig bewerten; Meldung nach Art. 33 DSGVO prüfen.
Zugangsdaten, Zahlungsdaten, Ausweiskopien, Gesundheitsdaten oder große Mengen an Kontaktdaten sind betroffen.	Hohes Risiko ist naheliegend.	Aufsicht melden und die Benachrichtigung der Betroffenen nach Art. 34 DSGVO prüfen.

Für eine belastbare Antwort brauchen Sie technische Fakten: Welche Systeme waren betroffen? Welche Zeitspanne ist relevant? Waren Daten verschlüsselt? Grenzen die Logs die Zugriffe ein? Lagen dort überhaupt Passwörter, Kontaktanfragen oder Dateien mit Personenbezug?

Häufig fehlt genau das. Der Hoster hebt Access-Logs nur 14 Tage auf, das Sicherheits-Plugin wurde erst nach dem Vorfall installiert, und wann der Schadcode tatsächlich hochgeladen wurde, lässt sich nur noch über Dateizeitstempel schätzen, die der Angreifer möglicherweise selbst gesetzt hat. Diese Lücken verschieben die Entscheidung nicht nach hinten. Sie gehören als offene Punkte in die Risikobewertung, und die Untersuchung rückt nach vorn.

72 Stunden: Was Betreiber nach einem Website-Hack tun sollten

Die Frist beginnt mit Ihrer Kenntnis, nicht mit dem Abschluss der Forensik. Das ist der Punkt, an dem die meisten Unternehmen stolpern: Man will erst sauber verstehen, was passiert ist, und merkt am dritten Tag, dass die Uhr schon lief. Artikel 33 erlaubt ausdrücklich, Informationen schrittweise nachzureichen, wenn zum Zeitpunkt der ersten Meldung noch nicht alles geklärt ist. Eine verspätete Meldung braucht dagegen eine Begründung.

Für einen ersten geregelten Ablauf sind diese Schritte sinnvoll:

1. Betroffene Website oder kompromittierte Zugänge eingrenzen, ohne vorschnell Beweise zu löschen.
2. Zeitpunkt der Entdeckung, Warnungen, Screenshots, Logauszüge und erste Maßnahmen festhalten.
3. Zugangsdaten, Administratoren, Plugins, Serverzugriffe und Datenablagen prüfen.
4. Datenschutzbeauftragte, Geschäftsführung und bei Bedarf Hosting- oder IT-Partner einbeziehen.
5. Betroffene Datenkategorien, Personengruppen, möglichen Zugriff und denkbare Folgen bewerten.
6. Entscheidung zur Meldung sowie ihre Begründung dokumentieren und die zuständige Aufsicht fristgerecht einbinden, wenn ein Risiko besteht.
7. Schutzmaßnahmen umsetzen, etwa kompromittierte Zugänge sperren, Sicherheitsupdates einspielen, Schadcode entfernen und Backups prüfen.

Bei größeren Vorfällen planen Sie die technische Bereinigung und die Beweissicherung getrennt. Der Reflex, sofort ein sauberes Backup einzuspielen, ist verständlich und manchmal richtig. Er überschreibt aber unter Umständen genau die Spuren, mit denen sich später klären ließe, ob überhaupt Daten abgeflossen sind. Wer zuerst ein Image des kompromittierten Stands zieht und dann bereinigt, hat beides.

Die organisatorische BSI-Checkliste für IT-Sicherheitsvorfälle verweist ebenfalls darauf, bei einem relevanten Datenschutzvorfall die zuständige Datenschutzaufsicht einzubeziehen. Für die technische und organisatorische Sofortreaktion ist sie eine gute Ergänzung.

Wo muss ein Datenschutzvorfall gemeldet werden?

Für die meisten privatwirtschaftlichen Website-Betreiber ist die Datenschutzaufsicht des Bundeslands zuständig, in dem die Hauptniederlassung sitzt. Die Datenschutzkonferenz führt eine Übersicht der Aufsichtsbehörden des Bundes und der Länder. Viele Landesbehörden stellen eigene Online-Meldeformulare bereit.

Unternehmen mit Sitz in Berlin nutzen beispielsweise das Datenpannenformular der Berliner Beauftragten für Datenschutz und Informationsfreiheit. Für Bundesbehörden und bestimmte Sonderbereiche gelten andere Zuständigkeiten. Wer mehrere Gesellschaften, internationale Standorte oder regulierte Dienstleistungen betreibt, klärt die federführende Behörde besser vorab datenschutzrechtlich, statt im Ernstfall zu suchen.

Das BSI ist für einen gewöhnlichen DSGVO-Websitevorfall übrigens nicht die Meldestelle. Je nach Branche und gesetzlicher Einordnung können zusätzliche Sicherheits- oder Meldepflichten bestehen, die von der DSGVO unabhängig sind. Dieser Artikel behandelt die DSGVO-Meldepflicht.

Was muss in die Meldung an die Datenschutzbehörde?

Die Meldung muss nicht jede technische Frage abschließend beantworten. Die Mindestangaben aus Artikel 33 Absatz 3 DSGVO braucht sie aber:

• Art der Verletzung sowie, soweit möglich, Kategorien und ungefähre Zahl der betroffenen Personen und Datensätze
• Kontaktdaten des Datenschutzbeauftragten oder einer anderen Anlaufstelle
• wahrscheinliche Folgen für die betroffenen Personen
• bereits ergriffene oder geplante Maßnahmen zur Behebung und zur Minderung möglicher Nachteile

Die Berliner Datenschutzbehörde erläutert diese Angaben und stellt ein Onlineformular bereit. Der Aufbau taugt gut als Muster, auch wenn für Sie eine andere Behörde zuständig ist.

Wichtig ist die Rollenverteilung: Der Verantwortliche meldet an die Aufsicht. Ein Hosting-Anbieter, eine Agentur oder ein anderer Dienstleister, der Daten im Auftrag verarbeitet, muss den Verantwortlichen nach Artikel 33 Absatz 2 DSGVO ohne unangemessene Verzögerung informieren. In der Praxis scheitert die 72-Stunden-Frist selten am Formular. Sie scheitert daran, dass am Freitagabend niemand weiß, wer beim Dienstleister anzurufen ist und wer im eigenen Haus die Meldung freigibt. Ein Auftragsverarbeitungsvertrag sollte deshalb nicht nur existieren, sondern konkrete Eskalationswege und erreichbare Ansprechpartner benennen.

Wann müssen betroffene Personen informiert werden?

Zusätzlich zur Behördenmeldung regelt Artikel 34 DSGVO die Benachrichtigung der Betroffenen. Sie wird fällig, wenn der Vorfall voraussichtlich ein hohes Risiko für deren Rechte und Freiheiten verursacht: kompromittierte Zugangsdaten, Finanzdaten, besondere Kategorien personenbezogener Daten oder eine Konstellation, aus der Identitätsdiebstahl und Betrug entstehen können.

Die Information muss klar und verständlich erklären, was passiert ist, welche Folgen möglich sind, wer als Ansprechpartner erreichbar ist und welche Schutzmaßnahmen Sie empfehlen. Entfallen kann sie, wenn geeignete Schutzmaßnahmen wie wirksame Verschlüsselung die Daten für Unbefugte unlesbar machen oder wenn nachträgliche Maßnahmen das hohe Risiko wirksam beseitigen. Auch diese Abwägung gehört in die Dokumentation.

Welche Pflichten Website-Betreiber vor einem Vorfall haben

Die Meldefrage stellt sich meistens erst, wenn die Website bereits kompromittiert ist. Artikel 32 DSGVO verlangt angemessene technische und organisatorische Maßnahmen aber vorher. Für Websites sind das wiederkehrende Betriebsaufgaben:

• WordPress, Themes, Plugins, PHP und serverseitige Komponenten aktuell halten
• nicht benötigte Plugins, Themes, Benutzerkonten und Zugänge entfernen
• individuelle Admin-Zugänge, starke Passwörter und Zwei-Faktor-Authentifizierung nutzen
• Backups erstellen, Wiederherstellungen testen und Zugriffsrechte begrenzen
• Sicherheitsmeldungen, auffällige Änderungen und relevante Logs auswerten
• einen erreichbaren Eskalationsweg für Datenschutz, Hosting und IT festlegen

Der von Kolb Blickhan Partner zusammengefasste Fall zu veralteter Shop-Software zeigt, warum nicht mehr gepflegte Systeme mehr sind als ein Technikproblem: Fehlende Sicherheitsupdates vergrößern die Angriffsfläche und werfen die Frage nach angemessenen Schutzmaßnahmen auf.

Für WordPress-Websites deckt eine regelmäßige WordPress-Wartung genau diesen Betrieb ab: Updates, Backup- und Wiederherstellungslogik, Monitoring und die Prüfung auffälliger Änderungen. Ist die Ursache eines Vorfalls unklar oder ein System bereits kompromittiert, ist eine WordPress-Erste-Hilfe oder eine WordPress-Inspektion der sachgerechte technische Einstieg.

Im Bajorat Media Cockpit steht zudem ein WordPress-Sicherheits-Check bereit. Er erkennt bekannte Schwachstellen, veraltete Komponenten und Wartungslücken einer WordPress-Installation inklusive ihrer Plugins und ordnet sie nach Dringlichkeit. Damit sehen Sie offene Risiken, bevor daraus ein Vorfall wird.

Fazit: Technische Reaktion und Datenschutzprozess müssen zusammenlaufen

Wer einen Website-Hack ausschließlich als Technikproblem behandelt, übersieht die Pflichten gegenüber Aufsicht und Betroffenen. Eine formale Meldung allein hilft aber genauso wenig, solange Zugänge offen bleiben, Updates fehlen oder die Ursache im Dunkeln liegt.

Die Reihenfolge, die sich bewährt hat: Vorfall eindämmen, Fakten sichern, personenbezogene Daten und Risiken bewerten, Entscheidung dokumentieren und bei Meldepflicht fristgerecht die zuständige Aufsicht einschalten. Der Freitagnachmittag wird dadurch nicht angenehmer. Aber er wird beherrschbar, wenn Sie vorher wissen, wen Sie anrufen.