Umgang mit Datenschutzverstößen, Betroffenenanfragen und Behördenanfragen

# Umgang mit Datenschutzverstößen, Betroffenenanfragen und Behördenanfragen

Die Slack-Nachricht um 3 Uhr morgens

Es ist 3:07 Uhr. Ein Security Engineer bei einer mittelgroßen Neobank schreibt in den Incident-Channel: Ein S3-Bucket (ein Cloud-Speichercontainer bei Amazon Web Services) mit 180.000 Transaktionsdatensätzen war falsch konfiguriert und 11 Tage lang öffentlich lesbar. Namen, Kontonummern, Händlerkategorien, Geolokalisierungs-Tags. Zwei Stunden später landet, ohne Zusammenhang, aber zu einem quälend schlechten Zeitpunkt, das Löschbegehren eines Kunden im Compliance-Postfach, mit der Forderung, seine Transaktionshistorie dauerhaft zu löschen.

Diese Lektion geht beide Ereignisse als eine durchgehende Timeline durch, weil sie in der Praxis ständig aufeinandertreffen. Sie nehmen die konkreten Fristen mit, die Aufsichtsbehörden setzen, die Meldefallen, in die Fintechs im grenzüberschreitenden Betrieb tappen, und die Checks, die Sie durchführen sollten, bevor es überhaupt 3 Uhr morgens wird.

Uhr #1: die Breach-Timeline

Eine „Verletzung des Schutzes personenbezogener Daten“ nach der DSGVO (Datenschutz-Grundverordnung, das zentrale Datenschutzrecht der EU) ist jeder Sicherheitsvorfall, der zur unbeabsichtigten oder unrechtmäßigen Vernichtung, zum Verlust, zur Veränderung oder zur unbefugten Offenlegung personenbezogener Daten führt. Ein falsch konfigurierter S3-Bucket erfüllt das sofort, ein Hacker ist nicht nötig.

Stunde 0 bis 72: Meldung an die Aufsichtsbehörde.

Artikel 33 DSGVO verlangt die Meldung an die zuständige DPA (Data Protection Authority, die nationale Aufsichtsbehörde, z. B. die irische Data Protection Commission) innerhalb von 72 Stunden nach Bekanntwerden des Vorfalls, es sei denn, der Verstoß führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten der Betroffenen. Bei Transaktionsdaten (finanziell, quasi-sensibel) ist „voraussichtlich kein Risiko“ ein schwer zu gewinnendes Argument.

Vergleichbare US-Fristen sind fragmentiert, nicht bundesweit. Es gibt kein einheitliches US-Breach-Gesetz; jeder Bundesstaat setzt seine eigene Frist. Der Civil Code von Kalifornien löst die Meldepflicht „without unreasonable delay“ aus. Der SHIELD Act des Staates New York und die Cybersecurity-Regel seines Department of Financial Services (23 NYCRR 500, anwendbar auf lizenzierte Finanzunternehmen) verlangen eine Meldung an die NY DFS innerhalb von 72 Stunden nach Feststellung eines Cybersecurity-Vorfalls, eine Frist, die mit der DSGVO zufällig zusammenfällt, nicht aufgrund von Koordination. Genau wegen dieses Flickenteppichs bauen Fintechs mit Lizenzen in mehreren Bundesstaaten einen internen 72-Stunden-Standard und wenden ihn überall an.

Wann die Betroffenen selbst informiert werden müssen. Artikel 34 DSGVO verlangt, betroffene Kunden „unverzüglich“ zu informieren, wenn der Verstoß voraussichtlich zu einem *hohen* Risiko führt (Betrug, Identitätsdiebstahl, finanzieller Verlust). Bei 180.000 offengelegten Transaktionsdatensätzen mit Kontonummern ist diese Schwelle erreicht. Schweigen ist hier der Punkt, an dem ein technischer Vorfall zur Schlagzeile wird.

Uhr #2: das Löschbegehren

Artikel 17 DSGVO (das „Recht auf Vergessenwerden“) erlaubt Betroffenen, die Löschung ihrer personenbezogenen Daten zu verlangen. Fintechs haben genau einen Monat Zeit zur Antwort, verlängerbar um zwei weitere Monate bei komplexen Anfragen, wobei die Verlängerung selbst innerhalb des ersten Monats mitgeteilt werden muss.

Hier liegt die Falle: Löschung ist nicht absolut. Artikel 17(3) enthält Ausnahmen, und Finanzdienstleistungen lösen mehrere davon aus:

• Rechtliche Verpflichtung: AML-Vorschriften (Anti-Money Laundering) nach den EU-Geldwäscherichtlinien und in den USA der Bank Secrecy Act verlangen üblicherweise die Aufbewahrung von Transaktionsdaten für 5 Jahre nach Kontoschließung.
• Rechtsansprüche: Daten, die zur Abwehr von Streitigkeiten oder Chargebacks benötigt werden.

Die ehrliche Antwort auf die meisten Löschbegehren zu Transaktionsdaten lautet also: „Wir löschen, was wir löschen kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen, und behalten, was die Regulierung verlangt, abgeschottet und von Marketing- oder Analytics-Nutzung ausgeschlossen.“ Diese dokumentierte Antwort ist das tatsächlich rechtskonforme Ergebnis, nicht eine pauschale Ablehnung oder eine vollständige Löschung.

Fallen bei grenzüberschreitenden Meldungen

Fintechs haben selten einen Verstoß in nur einer Jurisdiktion, und hier verbrennen sich Teams die Finger.

Falle 1: Verwirrung um die „federführende Aufsichtsbehörde“. Nach dem One-Stop-Shop-Mechanismus der DSGVO meldet ein Unternehmen mit seiner EU-Hauptniederlassung in einem Land an die DPA dieses Landes, die sich mit den anderen koordiniert. Wenn Ihr Vorfall aber Betroffene in mehreren Mitgliedstaaten betrifft und Ihre EU-Konzernstruktur unklar ist (üblich nach Fintech-M&A), kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen Sie an die falsche Behörde melden und die Frist beginnt von neuem.

Falle 2: Das UK ist nicht mehr die EU. Seit dem Brexit läuft die UK GDPR, durchgesetzt vom ICO (Information Commissioner's Office), auf einer parallelen, aber separaten 72-Stunden-Uhr. Ein Verstoß, der EU- und UK-Kunden betrifft, erfordert zwei separate Meldungen, nicht eine.

Falle 3: Stapelung über US-Bundesstaaten. Ein Verstoß, der Kunden in Kalifornien, New York und Texas betrifft, löst drei verschiedene Gesetze mit unterschiedlichen Fristen und unterschiedlichen Schwellen für „Schadensrisiko“ aus. Einige Bundesstaaten (etwa Kalifornien unter dem CCPA, California Consumer Privacy Act) gewähren Betroffenen zudem ein privates Klagerecht für bestimmte Verstöße, das heißt Kunden kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen direkt klagen und sich nicht nur bei einer Behörde beschweren.

Falle 4: Regeln der Zahlungssysteme kommen zum Datenschutzrecht hinzu. Sind Kartendaten betroffen, verlangt PCI DSS (Payment Card Industry Data Security Standard) eine Meldung an die Kartennetzwerke (Visa, Mastercard) und an Ihre Acquiring-Bank, auf einer separaten Timeline unabhängig von jeder Datenschutzbehörde. Das zu verpassen ist ein vertraglicher Verstoß, nicht nur ein rechtlicher.

Eine brauchbare Einführung in die EU-Mechanik: EDPB-Leitlinien zur Meldung von Verletzungen des Schutzes personenbezogener Daten (European Data Protection Board, kostenlos).

Die Behördenanfrage, die danach kommt

Breach-Meldungen enden selten mit der Einreichung nach 72 Stunden. Aufsichtsbehörden ererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen →öffnen häufig Wochen später eine Folgeanfrage und verlangen:

• Die Data Flow Map: wo die Daten lagen, wer darauf zugreifen konnte, welche Dritten (Cloud-Anbieter, Analytics-Tools) damit in Berührung kamen.
• Nachweise über ein Data Protection Impact Assessment (DPIA), nach Artikel 35 DSGVO erforderlich bei Verarbeitungen mit hohem Risiko, was Finanzdaten auf Transaktionsebene fast immer sind.
• Logs als Nachweis für Least-Privilege-Zugriff (nur Mitarbeiter, die die Daten brauchen, kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen sie sehen) und Verschlüsselung at rest und in transit.

Wenn Sie das auf Anfrage nicht vorlegen kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen, wird die Anfrage selbst zum größeren Enforcement-Risiko. Deshalb ist „Audit-Readiness“ kein Papiertheater, sondern das eigentliche Produkt, das Aufsichtsbehörden kaufen, wenn sie Nachweise verlangen.

Ein minimaler Breach-Readiness-Check, wie ihn ein Data Team vierteljährlich laufen lassen sollte:

# pseudocode: quarterly access audit
for bucket in cloud_storage.list_buckets():
    if bucket.contains_pii() and bucket.is_public():
        alert("CRITICAL: public PII bucket", bucket.name)
    if bucket.encryption_status != "enabled":
        alert("WARNING: unencrypted PII store", bucket.name)
    log_access_review(bucket, reviewers=compliance_team)

Das ist kein Ersatz für ein echtes Cloud Security Posture Management (CSPM) Tool, deckt aber die zwei Checks ab, die in fast jedem Fintech-Breach-Post-mortem auftauchen: öffentliche Exposition und fehlende Verschlüsselung.

Das Response-Playbook aufbauen

Ein funktionierender Incident-Response-Plan legt fest, bevor irgendetwas passiert:

1. Incident Commander: eine benannte Rolle, nicht „wer gerade online ist“, die den Verstoß feststellt und die Fristen starten lässt.

2. Legal/DPO-Freigabe: der Datenschutzbeauftragte (eine von der DSGVO vorgeschriebene Rolle für Organisationen mit umfangreicher Verarbeitung sensibler Daten) bestätigt die Meldepflichten und entwirft die Einreichungen.

3. Holding Statement der Kommunikation: vorab freigegebene Formulierungen für Kunden und Presse, damit um 4 Uhr morgens nichts Improvisiertes hinausgeht.

4. Triage von Löschbegehren: ein dokumentierter Entscheidungsbaum, der löschbare von rechtlich aufzubewahrenden Daten unterscheidet, damit Antworten auf Artikel-17-Anfragen konsistent sind und nicht von Fall zu Fall improvisiert werden.

🎬 [VIDEO: "GDPR Data Breach Notification Explained" - youtube.com/results?search_query=gdpr+data+breach+notification+explained - ein Durchgang durch die 72-Stunden-Regel und was als meldepflichtiger Verstoß gilt, nützlich zur Auffrischung, bevor Sie Ihr eigenes Playbook bauen]

Wichtigste Erkenntnisse

• Zwei Uhren, beide knapp: Die DSGVO gibt Ihnen 72 Stunden, um Aufsichtsbehörden über einen Verstoß zu informieren, und einen Monat, um auf ein Löschbegehren zu antworten; US-Regeln variieren je Bundesstaat und sind für regulierte Finanzunternehmen in der Praxis oft schneller (z. B. die 72-Stunden-Regel der NY DFS).
• Löschung ist nicht absolut: AML- und finanzielle Aufbewahrungspflichten überlagern Löschbegehren bei Transaktionsdaten; die konforme Antwort ist eine dokumentierte Teillöschung, nicht Schweigen oder vollständige Löschung.
• Grenzüberschreitende Vorfälle vervielfachen Pflichten: EU-, UK- und US-Bundesstaatenregime laufen parallel, nicht synchron; bei Kartendaten-Verstößen kommen PCI-DSS-Meldepflichten zum Datenschutzrecht hinzu.
• Aufsichtsbehörden prüfen Ihre Nachweise, nicht Ihre Absichten: DPIAs, Access-Logs und Verschlüsselungsnachweise sind das, was aus einer Anfrage eine geschlossene Akte macht statt eines Enforcement-Verfahrens.
• Playbooks schlagen Improvisation: vorab verteilte Rollen und vorab freigegebene Formulierungen trennen einen eingegrenzten Vorfall von einem, der sich aufschaukelt.