Eine Datenpanne ist selten ein einzelner technischer Moment. Für Website-Betreiber beginnt sie oft mit einer unscheinbaren Beobachtung: ein ungewöhnlicher Login im WordPress-Backend, ein kompromittiertes Formular-Plugin, ein falsch freigegebener Export, ein offener Backup-Link, eine fehlgeleitete E-Mail oder ein Zugriff auf Kundendaten, der sich nicht sofort erklären lässt. Genau dann entscheidet nicht der perfekte Rechtstext, sondern ein vorbereiteter Prozess.
Der Europäische Datenschutzausschuss hat im Juni 2026 eine gemeinsame Vorlage für Meldungen von Datenschutzverletzungen beschlossen. Sie soll Verantwortlichen und Aufsichtsbehörden helfen, Meldungen strukturierter und vergleichbarer zu bearbeiten. Für deutsche KMU ist das kein Grund, jedes Formular sofort neu zu bauen. Es ist aber ein guter Anlass, Website-Vorfälle praktischer zu denken: Welche Informationen müssen im Ernstfall schnell verfügbar sein, wer entscheidet und welche Systeme müssen geprüft werden?
Warum eine Vorlage Website-Betreibern hilft
Die DSGVO verlangt bei meldepflichtigen Verletzungen des Schutzes personenbezogener Daten eine Benachrichtigung der zuständigen Aufsichtsbehörde grundsätzlich innerhalb von 72 Stunden, nachdem der Verantwortliche Kenntnis erlangt hat. Zusätzlich kann eine Information betroffener Personen nötig werden, wenn ein hohes Risiko für deren Rechte und Freiheiten besteht. Diese Regeln sind nicht neu. Neu relevant ist die praktische Frage, ob ein Unternehmen die nötigen Informationen rechtzeitig zusammentragen kann.
Eine Vorlage macht sichtbar, welche Angaben typischerweise gebraucht werden: Was ist passiert? Welche Datenarten sind betroffen? Wie viele Personen könnten betroffen sein? Welche Systeme und Dienstleister spielen eine Rolle? Welche Risiken entstehen? Welche Maßnahmen wurden bereits gesetzt? Wer ist intern zuständig? Wer kann Rückfragen beantworten? Wer diese Fragen erst im Vorfall zum ersten Mal hört, verliert wertvolle Zeit.
Typische Website-Vorfälle im KMU-Alltag
Bei Websites entstehen Datenpannen häufig an Schnittstellen. Kontaktformulare senden Anfragen an falsche Empfänger. Bewerbungsunterlagen landen in ungeschützten Postfächern. Newsletterlisten werden falsch exportiert. WooCommerce-Daten werden über ein Plugin offengelegt. Backups liegen in öffentlich erreichbaren Ordnern. Ein Agenturzugang bleibt nach Projektende aktiv. Ein kompromittiertes Passwort ermöglicht Adminzugriff. Auch Server-Logfiles, Support-Tools, CRM-Integrationen und Analyseexporte können personenbezogene Daten enthalten.
Nicht jeder technische Fehler ist automatisch eine meldepflichtige Datenschutzverletzung. Entscheidend ist, ob personenbezogene Daten unbeabsichtigt oder unrechtmäßig vernichtet, verloren, verändert, offengelegt oder zugänglich wurden. Trotzdem sollten Website-Teams lieber früh prüfen und dokumentieren, statt Vorfälle informell wegzuwischen. Eine saubere Ersteinschätzung hilft später, wenn die Entscheidung nachvollziehbar erklärt werden muss.
Die 72-Stunden-Frist braucht Vorarbeit
Die 72 Stunden laufen nicht erst, wenn alle Details bekannt sind. Gerade deshalb ist Vorbereitung wichtig. Ein Unternehmen muss nicht sofort jedes technische Detail perfekt kennen, sollte aber schnell feststellen können, ob ein Risiko besteht und welche Sofortmaßnahmen nötig sind. Bei einer Website heißt das: Logs sichern, betroffene Plugins oder Formulare identifizieren, Zugänge prüfen, Dienstleister informieren, Backups kontrollieren und Datenflüsse nachvollziehen.
Wer im Ernstfall erst suchen muss, wer den Hoster kontaktiert, wo Formularübermittlungen gespeichert werden oder welche Agentur noch Zugriff hat, kommt unter Druck. Ein einfacher Vorfallplan sollte deshalb neben Datenschutz auch IT, Marketing, Geschäftsführung und externe Dienstleister einbeziehen. Besonders wichtig ist eine klare Regel: Verdachtsfälle werden nicht nebenbei im Chat abgehandelt, sondern strukturiert erfasst.
Welche Informationen sofort greifbar sein sollten
Website-Betreiber sollten mindestens eine kleine Datenquellen-Matrix pflegen. Darin stehen Kontaktformular, Newsletter, Shop, Kundenkonto, Bewerbungsformular, Logfiles, Backups, CRM, Consent-Tool, Analyse, Hosting und Support-Systeme. Für jede Quelle sollten Verantwortliche, Dienstleister, Datenarten, Speicherorte, Zugriffskreise und Aufbewahrungsfristen bekannt sein. Diese Matrix ist nicht nur für Datenschutzdokumentation nützlich, sondern auch für Datenpannen.
Zusätzlich braucht es eine Kontaktliste: Wer erreicht den Hoster? Wer kann WordPress-Adminzugänge sperren? Wer prüft Logs? Wer kann Newsletter- oder CRM-Exporte stoppen? Wer entscheidet über eine Meldung an die Aufsicht? Wer formuliert die Information an Betroffene? In kleinen Unternehmen können mehrere Rollen bei derselben Person liegen. Entscheidend ist, dass die Zuständigkeit vorab geklärt ist.
Dienstleister müssen in den Ablauf passen
Viele Website-Vorfälle betreffen nicht nur das eigene Unternehmen. Hosting, Wartung, Newsletter, Formularanbieter, Consent-Tool, CRM, Shop-Plugins und Sicherheitsdienste können Teil der Untersuchung sein. Deshalb sollten AV-Verträge und Supportwege nicht nur abgelegt, sondern im Ernstfall nutzbar sein. Wer innerhalb von 72 Stunden eine belastbare Einschätzung braucht, muss wissen, welcher Dienstleister welche Logs liefern kann, wie schnell Rückmeldungen zu erwarten sind und ob weitere Unterauftragsverarbeiter beteiligt sein könnten.
Auch die Protokollierung sollte vorab geprüft werden. Ohne Logs bleibt oft unklar, ob Daten nur theoretisch erreichbar waren oder tatsächlich abgerufen wurden. Gleichzeitig dürfen Logdaten nicht beliebig lange oder unnötig umfangreich gespeichert werden. Website-Betreiber brauchen hier eine Balance: genug Informationen für Sicherheit und Vorfallprüfung, aber keine Datensammlung ohne Zweck.
Ersteinschätzung: Risiko statt Bauchgefühl
Die Frage, ob eine Datenpanne meldepflichtig ist, sollte nicht aus dem Bauch heraus beantwortet werden. Eine strukturierte Prüfung betrachtet Art und Umfang der Daten, Anzahl betroffener Personen, mögliche Folgen, Schutzmaßnahmen und Wahrscheinlichkeit eines Missbrauchs. Ein öffentlich erreichbares Backup mit Kundendaten ist anders zu bewerten als eine intern falsch adressierte Nachricht ohne sensible Inhalte. Zugangsdaten, Gesundheitsdaten, Bewerbungsunterlagen, Zahlungsdaten und Kinder- oder Kundendaten erhöhen die Sensibilität.
Auch technische Schutzmaßnahmen spielen eine Rolle. Waren Daten verschlüsselt? Wurde der Zugriff protokolliert? Konnte der Link tatsächlich von außen erreicht werden? Wurde der kompromittierte Account sofort gesperrt? Solche Fakten müssen belegbar sein. Deshalb sollten Logs und Screenshots nicht unkontrolliert gelöscht werden. Gleichzeitig dürfen bei der Untersuchung nicht unnötig neue Kopien personenbezogener Daten entstehen.
Kommunikation nach außen vorbereiten
Viele Unternehmen konzentrieren sich bei Datenpannen nur auf die Meldung an die Aufsicht. Je nach Risiko kann aber auch eine Information an betroffene Personen nötig sein. Diese Kommunikation muss klar, verständlich und hilfreich sein. Betroffene wollen wissen, was passiert ist, welche Daten betroffen sind, welche Risiken bestehen und was sie selbst tun können. Beschönigende oder unpräzise Formulierungen schaden Vertrauen und können Rückfragen vervielfachen.
Auch die interne Kommunikation zählt. Mitarbeitende sollten wissen, an wen sie Verdachtsfälle melden und welche Informationen sie sammeln sollen. Agenturen und Dienstleister sollten vertraglich und organisatorisch eingebunden sein. Wenn ein Formularanbieter, Hoster oder Newsletterdienst zuerst vom Vorfall erfährt, muss klar sein, wie schnell die Information weitergegeben wird.
WordPress: besonders auf Zugänge und Plugins achten
WordPress-Websites sind nicht per se unsicher, aber sie bestehen oft aus vielen beweglichen Teilen. Themes, Plugins, Benutzerrollen, Agenturzugänge, Formularspeicher, Sicherheitsplugins, Backups und externe Dienste greifen ineinander. Ein Vorfallplan sollte deshalb WordPress-spezifische Punkte enthalten: Admin-Accounts prüfen, 2FA aktivieren, nicht mehr benötigte Benutzer entfernen, Plugin-Updates zeitnah einspielen, Formularspeicherung dokumentieren und Backups vor öffentlichem Zugriff schützen.
Nach einem Vorfall ist nicht nur die Reparatur wichtig, sondern auch die Ursachenanalyse. War ein Plugin veraltet? Wurde ein Passwort mehrfach genutzt? Gab es zu viele Adminrechte? Lag ein Backup im falschen Ordner? Wurde ein Export per E-Mail weitergeleitet? Aus diesen Fragen entstehen Maßnahmen, die eine Wiederholung unwahrscheinlicher machen.
Praktische Checkliste für den Ernstfall
Eine schlanke Checkliste kann viel leisten. Erstens: Verdacht erfassen und Zeitpunkt dokumentieren. Zweitens: Sofortmaßnahmen festlegen, etwa Zugang sperren, Link entfernen, Plugin deaktivieren oder Dienstleister kontaktieren. Drittens: betroffene Datenquellen und Personengruppen prüfen. Viertens: Risiko für betroffene Personen bewerten. Fünftens: Entscheidung zur Meldung dokumentieren. Sechstens: falls nötig Meldung an die zuständige Aufsicht vorbereiten. Siebtens: Kommunikation an Betroffene prüfen. Achtens: Ursachenanalyse und Präventionsmaßnahmen festhalten.
Diese Liste ersetzt keine individuelle rechtliche Bewertung. Sie verhindert aber, dass wichtige Schritte vergessen werden. Gerade kleinere Website-Betreiber profitieren von einem standardisierten Ablauf, weil im Vorfall häufig mehrere Themen gleichzeitig auftreten: Technik, Datenschutz, Kundenkommunikation, Dienstleistersteuerung und Geschäftsführung.
Fazit: Datenpannen sind Prozessfragen
Die neue EDPB-Vorlage ist mehr als ein Formular. Sie zeigt, welche Informationen im Ernstfall relevant werden und wie wichtig ein vorbereiteter Prozess ist. Für Website-Betreiber bedeutet das: Tool-Inventar, Datenquellen, Zugänge, Backups, Dienstleister und Kommunikationswege sollten nicht erst nach einer Panne geklärt werden.
Wer seine Website professionell betreibt, sollte deshalb einen kleinen Datenpannen-Check einführen. Nicht als Panikprojekt, sondern als Teil guter Website-Organisation. Wenn ein Vorfall passiert, zählt jede Stunde. Ein klarer Ablauf schützt nicht nur vor Fristproblemen, sondern auch vor unnötigem Vertrauensverlust.
