Haeufige Fehler bei der Meldung von Verletzungen personenbezogener Daten, die SaaS-Teams immer noch machen

Die haeufigsten Fehler bei der Meldung von Verletzungen personenbezogener Daten sind selten exotische Rechtsfehler. Es sind operative Fehler: die Bewertung wird zu spaet geoeffnet, der Personenbezug wird nicht sauber bestaetigt, Controller- und Processor-Rollen werden vermischt, Kundenbenachrichtigung wird mit Aufsichtsbenachrichtigung gleichgesetzt und Nachweise bleiben ueber Tools verstreut.

Nach Artikel 33 DSGVO muss ein Verantwortlicher die zustaendige Aufsichtsbehoerde ohne unangemessene Verzoegerung und moeglichst innerhalb von 72 Stunden nach Kenntnis melden, sofern die Verletzung nicht voraussichtlich ohne Risiko fuer Rechte und Freiheiten bleibt. Artikel 34 betrifft die Kommunikation an betroffene Personen bei voraussichtlich hohem Risiko. Auftragsverarbeiter muessen Verantwortliche ohne unangemessene Verzoegerung informieren.

Warum faehige Teams das trotzdem falsch machen

Viele SaaS-Teams haben Incident Response, Security Owner, Customer Support, Legal Review und Executive Escalation. Das Problem ist, dass diese Teile oft in verschiedenen Systemen leben und verschiedene Uhren verwenden. Security verfolgt Erkennung, Legal braucht den Zeitpunkt der Kenntnis, Customer Teams verfolgen Vertragsfristen, Product und Engineering kennen die betroffenen Systeme, Vendor Management kennt Subprozessoren.

Wenn diese Faeden nicht vorher verbunden sind, baut das Unternehmen in den wichtigsten Stunden erst das Betriebsmodell zusammen.

Fehler 1: Auf Sicherheit warten, bevor ein Breach Record entsteht

Teams warten oft, bis klar ist, ob eine Meldung erforderlich ist. Das ist verkehrt herum. Der Record hilft bei der Entscheidung. Er sollte bekannte Fakten, offene Fragen, Owner und naechste Review-Zeit erfassen. Wenn spaeter kein Personenbezug oder kein Risiko besteht, wird er mit Begruendung geschlossen.

Fehler 2: Die falsche Uhr verfolgen

Die 72-Stunden-Frist wird oft an den falschen Zeitpunkt geknuepft: Beginn des Vorfalls, erster Alert, Root Cause oder erstes Legal-Briefing. Operativ wichtig ist, wann die Organisation Kenntnis von einer Verletzung personenbezogener Daten hatte. Zusaetzlich koennen DPA- oder Vertragsfristen schneller laufen als die regulatorische Frist.

Der Fix ist ein Record mit mehreren Zeiten: Erkennung, moegliche Kenntnis, bestaetigter Personenbezug, Kundenfrist, Behoerdenfrist, Entscheidung zu betroffenen Personen und Follow-up.

Fehler 3: Eine einzige GDPR-Rolle annehmen

Ein SaaS-Unternehmen kann Verantwortlicher fuer Account-, Billing-, Mitarbeiter-, Marketing-, Analytics- oder Logdaten sein und zugleich Auftragsverarbeiter fuer Kundendaten. In einem Vorfall kann beides vorkommen.

Wenn die Rollen nicht je Datensatz getrennt werden, informiert das Team die falsche Partei, verpasst Kundenpflichten oder nimmt eine Entscheidung an, die beim Kunden liegt. Der Fix: Rolle, Prozess, Vertrag, Entscheidung und Benachrichtigung fuer jeden betroffenen Datensatz dokumentieren.

Fehler 4: Risiko und hohes Risiko vermischen

Artikel 33 und Artikel 34 haben verschiedene Schwellen. Die Meldung an die Aufsicht haengt am Risiko fuer Rechte und Freiheiten. Die Kommunikation an Personen haengt am hohen Risiko. Teams muessen beide Fragen getrennt beantworten und beide Schlussfolgerungen dokumentieren.

Fehler 5: Verschluesselung oder Eindämmung ueberbewerten

Schutzmassnahmen sind wichtig, ersetzen aber keine Analyse. Das Team muss pruefen, ob die betroffenen Daten wirklich verschluesselt waren, ob Schluessel sicher blieben, ob Metadaten offengelegt wurden und ob auch Integritaet oder Verfuegbarkeit betroffen waren. Eindämmung reduziert Risiko, loescht aber nicht, was vorher passiert ist.

Fehler 6: Kundenpflichten ausserhalb des Incident Workflows lassen

Enterprise-Vertraege enthalten oft eigene Notice-Pflichten, kuerzere Fristen, Inhalte, Kontakte und Kooperationspflichten. Wenn diese Pflichten nur in PDFs liegen, sieht das Incident Team sie nicht rechtzeitig. Vertragsfristen und Security-Kontakte gehoeren in einen nutzbaren Register fuer kritische Kunden.

Fehler 7: Den Nachweis verstreuen

Viele Teams reagieren gut, koennen es aber spaeter nicht beweisen. Timeline, Scope, Genehmigung, Kundenkommunikation, Vendor-Bestaetigung und Remediation liegen in Chats, Tickets, Docs und E-Mails. Ein gutes Evidence Package enthaelt Timeline, Systeme, Datenumfang, Rollenbewertung, Risikoanalyse, Entscheidungen, Nachrichten, Remediation, Root Cause und Kontrollverbesserungen.

Fehler 8: Nach der Meldung schliessen

Meldung ist nicht das Ende. Der Vorfall bleibt offen, bis die Kontrollschwaeche behoben, akzeptiert oder mit Owner und Review-Datum verfolgt wird. Sonst entstehen Wiederholungen und schwache Antworten auf Kundenfragen.

Beispiel

Ein SaaS-Team entdeckt, dass ein Berechtigungsfehler Support-Anhaenge zwischen zwei Kunden-Workspaces sichtbar gemacht hat. Security deaktiviert die Regel schnell. Trotzdem koennen Fehler passieren: kein Record, keine Rollenpruefung, keine DPA-Fristen, keine getrennte Risikoanalyse, keine gesicherten Logs.

Ein staerkerer Ablauf oeffnet den Record sofort, prueft Anhaenge und Zugriffslogs, bestimmt die Rolle je Datensatz, bewertet Risiko und hohes Risiko getrennt, prueft Kundenpflichten, dokumentiert Entscheidungen und verfolgt die Remediation.

FAQ

Was muessen Teams verstehen?

Die Meldung ist ein zeitkritischer Workflow mit Security-Fakten, Privacy-Analyse, Rollenmodell, rechtlichen Schwellen, Kundenpflichten, Nachweisen und Remediation.

Warum zaehlt das praktisch?

Ein Breach wird schnell zu einem Thema fuer Kundenvertrauen, Audit, Legal, Security und Leadership. Dokumentierte Fakten und Entscheidungen beschleunigen Antworten.

Was ist der groesste Fehler?

Der groesste Fehler ist, Breach Notification als einmalige Rechtsauslegung statt als wiederholbaren Workflow mit Ownern, Triggern, Nachweisen und Eskalation zu behandeln.

Quellen

• European Union, General Data Protection Regulation.
• European Data Protection Board, Guidelines 9/2022 on personal data breach notification under GDPR.
• Information Commissioner's Office, Personal data breaches - a guide.
• Information Commissioner's Office, 72 hours - how to respond to a personal data breach.