Der Europäische Datenschutzausschuss hat am 10. Juni 2026 ein gemeinsames Template für Meldungen von Datenschutzverletzungen angenommen und zugleich eine öffentliche Konsultation bis 5. August 2026 gestartet. Für österreichische Website-Betreiber, Webshops und KMU ist das kein neuer Panikknopf, aber ein sehr deutlicher Hinweis: Data-Breach-Meldungen sollen in Europa einheitlicher, strukturierter und schneller bearbeitbar werden. Wer im Ernstfall erst sucht, wo Logs, Dienstleisterkontakte, betroffene Systeme und Verantwortlichkeiten liegen, verliert genau die Zeit, die bei Datenschutzvorfällen knapp ist.
Der praktische Nutzen liegt deshalb nicht nur im Formular selbst. Das Template zeigt, welche Informationen Organisationen griffbereit haben sollten, wenn personenbezogene Daten verloren gehen, unbefugt offengelegt werden, verändert werden oder für Unbefugte zugänglich werden. Genau diese Vorbereitung passt gut zu Website-Compliance: Kontaktformulare, Newsletter-Tools, Shops, CRM-Anbindungen, Consent-Logs, Serverlogs und Cloud-Dienste hängen oft enger zusammen, als es im Alltag sichtbar ist.
Warum das EDPB-Template jetzt wichtig ist
Der EDPB begründet das gemeinsame Template damit, Meldungen nach Art. 33 DSGVO zu strukturieren, zu harmonisieren und für Datenschutzbehörden leichter prüfbar zu machen. Für kleinere Organisationen ist daran besonders interessant, dass vordefinierte Felder und Ausfüllhinweise Zeit und Kosten sparen sollen. Noch ist die praktische Umsetzung durch alle Datenschutzbehörden nicht abgeschlossen; nach der Konsultation entscheidet der EDPB über die weitere Implementierung.
Für Österreich bleibt die Datenschutzbehörde die relevante Anlaufstelle. Die Behörde stellt bereits ein Onlineformular und ein PDF-Formular für Data-Breach-Meldungen bereit. Gleichzeitig bestätigt die neue EDPB-Initiative, dass die Meldepraxis europaweit stärker in Richtung standardisierter Informationen geht. Wer heute seine internen Abläufe an den erwarteten Informationsfeldern ausrichtet, ist später nicht vom Formular überrascht.
Die 72 Stunden beginnen nicht erst mit dem Formular
Die österreichische Datenschutzbehörde erklärt die Grundregel klar: Eine Verletzung des Schutzes personenbezogener Daten ist unverzüglich und möglichst binnen 72 Stunden ab Bekanntwerden zu melden, wenn voraussichtlich ein Risiko für die Rechte und Freiheiten natürlicher Personen besteht. Die WKO beschreibt denselben Kern: Erfolgt die Meldung nach Ablauf der 72 Stunden, muss die Verzögerung begründet werden.
Das klingt nach einer juristischen Frist, ist in der Praxis aber ein Organisationsproblem. In den ersten Stunden muss geklärt werden, was passiert ist, welche Systeme betroffen sind, ob personenbezogene Daten im Spiel sind, wie viele Personen ungefähr betroffen sein könnten, welche Datensätze betroffen sind, welche Maßnahmen bereits gesetzt wurden und ob betroffene Personen informiert werden müssen. Ohne vorbereitete Zuständigkeiten wird aus jeder Frage ein Meeting.
Was Website-Betreiber vorab griffbereit haben sollten
Ein guter Incident-Plan muss nicht lang sein. Er muss im richtigen Moment funktionieren. Für Websites und Webshops reicht oft schon eine kleine, gepflegte Übersicht, die regelmäßig aktualisiert wird. Entscheidend ist, dass technische, rechtliche und organisatorische Informationen zusammenfinden.
- Systemliste: Website, Shop, Hosting, CMS, Plugins, Formulare, Newsletter, CRM, Zahlungsanbieter, Analyse- und Marketingdienste.
- Datenarten: Kontaktanfragen, Kundenkonten, Bestellungen, Zahlungsdaten, Consent-Logs, IP-Adressen, Newsletterdaten und Supportverläufe.
- Dienstleisterkontakte: Hosting, Agentur, IT-Support, Plugin-Anbieter, Newsletter-Tool, Zahlungsdienstleister und Datenschutzkontakt.
- Nachweise: Serverlogs, Änderungsprotokolle, Plugin-Updates, Backup-Informationen, Zugriffsrechte und Kommunikationsnotizen.
- Entscheidungsweg: Wer beurteilt Risiko, wer kontaktiert die Datenschutzbehörde, wer informiert Kundinnen und Kunden, wer dokumentiert Maßnahmen?
Diese Liste ist bewusst operativ. Sie ersetzt keine rechtliche Einzelfallprüfung, aber sie verhindert, dass ein Unternehmen bei einem kompromittierten Formular, einem fehlkonfigurierten Shop-Export oder einem kompromittierten Admin-Konto bei null beginnt.
Website-Stacks machen Datenpannen unübersichtlich
Viele Datenschutzvorfälle entstehen nicht durch einen dramatischen Angriff, sondern durch eine Kombination aus Alltagstechnik: ein altes Plugin, ein falscher Rollenwechsel, ein öffentlich erreichbarer Export, ein falsch konfiguriertes Formular oder ein Drittanbieter, der selbst einen Vorfall meldet. Der Beitrag zum NISG und Website-Stack passt hier gut dazu, weil klare Zuständigkeiten auch außerhalb klassischer IT-Abteilungen wichtiger werden.
Für Website-Betreiber ist besonders heikel, dass Verantwortlichkeiten oft verteilt sind. Die Agentur betreut WordPress, der Hoster liefert Logs, das Newsletter-Tool verarbeitet Kontakte, der Zahlungsanbieter verarbeitet Transaktionen, und der Shop speichert Kundenkonten. Wenn ein Vorfall passiert, muss trotzdem ein Verantwortlicher wissen, welche Stellen Informationen liefern können. Auftragsverarbeiter müssen Verletzungen unverzüglich an den Verantwortlichen melden; diese Prozesskette sollte nicht erst im Ernstfall gesucht werden.
Datenschutzerklärung und Dienstedokumentation gehören zum Notfallplan
Ein Data-Breach-Prozess ist leichter, wenn die eingesetzten Dienste bereits sauber dokumentiert sind. Wer nicht weiß, welche Tools personenbezogene Daten verarbeiten, kann weder Risiko noch Umfang schnell einschätzen. Der AdSimple Datenschutz Generator hilft dabei, Dienste und Datenverarbeitungen nachvollziehbar abzubilden. Gerade nach Relaunches, Tool-Wechseln oder neuen Formularen sollte die Dokumentation mit dem tatsächlichen Website-Setup übereinstimmen.
Auch Consent-Daten können relevant werden. Wenn ein Consent-Management-System protokolliert, welche Entscheidungen Nutzer getroffen haben, sind diese Informationen selbst Teil des Datenschutz-Setups. Nach Änderungen am Tracking, an Cookie-Kategorien oder an externen Medien sollte geprüft werden, ob Banner, technische Ladezeitpunkte und Datenschutzhinweise zusammenpassen. Der Beitrag zu technisch notwendigen Cookies zeigt, warum diese technische Wahrheit nicht nur im Bannertext stehen darf. Für die laufende Steuerung von Einwilligungen bleibt der AdSimple Consent Manager der passende Baustein.
Was in den ersten 24 Stunden passieren sollte
Der wichtigste Schritt ist die Triage. Nicht jeder technische Fehler ist eine meldepflichtige Datenschutzverletzung. Aber jeder ernsthafte Verdacht sollte dokumentiert werden. Ein pragmatischer Ablauf beginnt mit vier Fragen: Welche personenbezogenen Daten könnten betroffen sein? Ist Vertraulichkeit, Integrität oder Verfügbarkeit betroffen? Wie viele Personen und Datensätze sind ungefähr berührt? Welche Sofortmaßnahmen wurden bereits gesetzt?
Danach folgt die Beweissicherung. Logs sollten gesichert werden, bevor sie überschrieben werden. Admin-Zugänge müssen überprüft, betroffene Komponenten isoliert und Dienstleister informiert werden. Parallel braucht es eine Kommunikationsspur: Wer wurde wann informiert, welche Entscheidungen wurden getroffen, welche offenen Punkte bleiben? Wenn innerhalb der ersten 72 Stunden noch nicht alle Informationen vorliegen, beschreibt die österreichische Datenschutzbehörde die Möglichkeit schrittweiser Meldungen; unnötige Verzögerungen sollten dadurch aber nicht entstehen.
Betroffene informieren: nicht jede Meldung ist gleich Kundenkommunikation
Art. 34 DSGVO kann zusätzlich zur Behördenmeldung eine Benachrichtigung betroffener Personen auslösen, wenn voraussichtlich ein hohes Risiko für persönliche Rechte und Freiheiten besteht. Das ist eine andere Schwelle als die Meldung an die Aufsichtsbehörde. Unternehmen sollten deshalb nicht automatisch massenhaft informieren, aber auch nicht aus Kommunikationsangst zögern, wenn ein hohes Risiko naheliegt.
Hier hilft vorbereitete Sprache. Vorlagen für interne Lageupdates, Behördeninformationen und Kundenkommunikation sollten klar, sachlich und ohne falsche Sicherheit formuliert sein. Für Website-Basics bleibt außerdem wichtig, dass Verantwortlicher, Kontaktwege und rechtliche Angaben leicht auffindbar sind. Der AdSimple Impressum Generator deckt diese Vertrauensebene ab; das AdSimple Business Paket ist sinnvoll, wenn Datenschutzhinweise, Impressum und laufende Compliance gemeinsam gepflegt werden sollen.
Ein kleiner Monatscheck reicht oft als Start
Viele KMU brauchen keinen großen Incident-Response-Apparat, aber sie brauchen eine realistische Erstversion. Einmal im Monat kann geprüft werden: Sind Admin-Konten aktuell? Stimmen Dienstleisterkontakte? Sind neue Formulare, Plugins oder Trackingdienste dokumentiert? Gibt es einen Export personenbezogener Daten, der besser geschützt werden muss? Wurden alte Zugänge deaktiviert? Diese kleine Routine macht die 72-Stunden-Frist deutlich weniger bedrohlich.
Die EDPB-Prüfaktion zu Datenschutzhinweisen erinnert daran, dass Transparenz nicht erst nach einem Vorfall zählt. Sie beginnt mit aktuellen Informationen, klaren Zuständigkeiten und einer Website, deren technische Realität bekannt ist. Das neue EDPB-Template fügt diesem Bild einen praktischen Notfallrahmen hinzu.
Fazit: Das Formular kommt später, die Vorbereitung beginnt jetzt
Das gemeinsame EDPB-Template ist noch nicht der fertige neue österreichische Meldeweg. Aber es zeigt sehr klar, wohin sich Data-Breach-Meldungen bewegen: weniger Improvisation, mehr strukturierte Informationen, besser vergleichbare Prozesse. Für österreichische Website-Betreiber ist das eine gute Gelegenheit, nicht erst beim nächsten Vorfall zu lernen, welche Daten gebraucht werden.
Der beste nächste Schritt ist klein und wirksam: eine einseitige Incident-Liste für Website, Shop, Dienstleister, Datenarten, Kontakte und Sofortmaßnahmen. Wenn diese Liste aktuell ist, gewinnt ein Unternehmen im Ernstfall Zeit, Ruhe und Nachvollziehbarkeit. Genau diese drei Dinge entscheiden oft darüber, ob aus einem technischen Problem ein beherrschbarer Datenschutzvorfall oder ein langes Compliance-Nachspiel wird.
