Ein praktischer Leitfaden zu Wenn Analyseplattformen Ihre Daten verletzen

Selten mit derselben Dringlichkeit behandelt wie Kartenlecks: Was geschieht, wenn Analyseplattformen Ihre Daten verletzen, betrifft URLs, Suchbegriffe, Referrer, Kampagnen-IDs, Standorte und Produktnutzung.

Verstöße gegen Analytics-Daten werden selten mit der Dringlichkeit von Zahlungskartenlecks oder Anmeldedatendiebstahl behandelt. Das ist ein Fehler. Analyseplattformen können URLs, Suchbegriffe, Referrer, Kampagnen-IDs, IP-abgeleitete Standorte, Kontoereignisse, Produktnutzung und manchmal auch Kennungen auf Benutzerebene speichern. Im falschen Kontext können diese Daten Kunden, Strategie, Gesundheitsinteressen, Akquisitionstrichter oder vertrauliches Produktverhalten offenbaren.

Auch die rechtliche Problematik ist klar: Gemäß GDPR umfasst eine Verletzung des Schutzes personenbezogener Daten die versehentliche oder unrechtmäßige Zerstörung, den Verlust, die Änderung, die unbefugte Offenlegung oder den Zugriff auf personenbezogene Daten. Der Verantwortliche muss das Risiko bewerten und muss möglicherweise die Aufsichtsbehörde innerhalb von 72 Stunden gemäß Artikel 33 und die betroffenen Personen gemäß Artikel 34 benachrichtigen. Die Tatsache, dass ein Anbieter den Vorfall verursacht hat, entbindet den Verantwortlichen nicht von seiner Verantwortung.

Wie Analytics-Verstöße aussehen

Nicht bei jedem Vorfall handelt es sich um einen Hacker, der eine Datenbank ausspioniert. Viele Analytics-Vorfälle sind auf gewöhnliche Betriebsausfälle zurückzuführen:

• Ein Multi-Tenant-Dashboard zeigt die Daten eines Kunden einem anderen Kunden an.
• In der Debug-Protokollierung wird die vollständige URLs mit E-Mails, Reset-Tokens oder Integritätsabfrageparametern gespeichert.
• Ein falsch konfigurierter BigQuery-, S3- oder Data-Warehouse-Export wird öffentlich.
• Supportmitarbeiter können ohne geschäftlichen Grund auf rohe Ereignisströme zugreifen.
• Ein Tag-Manager lädt ein nicht genehmigtes Skript, das Ereignisdaten an einen Dritten kopiert.
• Ein Lieferant verarbeitet Daten in einem Land, das nicht von der Vertrags- oder Transferbewertung abgedeckt wurde.

Diese Vorfälle sind schmerzhaft, da die Analysedaten normalerweise umfangreich sind. Ein Tracking-Skript kann jede Seite und jede User Journey erfassen.

Datensouveränität ist mehr als nur der Serverstandort

Datensouveränität bedeutet, dass Sie verstehen, welche Gesetze, Unternehmen, Personen und Infrastruktur Ihre Daten beeinflussen können. Eine Unterbringung in Frankfurt oder Dublin ist hilfreich, beantwortet aber nicht alle Fragen. Sie müssen weiterhin die Unternehmensgerichtsbarkeit des Anbieters, die Unterauftragsverarbeiter, den Remote-Support-Zugriff, das Verschlüsselungsmodell, den Prozess zur Reaktion auf Vorfälle und die Frage kennen, ob Daten außerhalb des EEA übertragen werden können.

Für EU personenbezogene Daten gelten für internationale Übermittlungen GDPR Kapitel V. Übertragungen können auf einer Angemessenheitsentscheidung, Standardvertragsklauseln, verbindlichen Unternehmensregeln oder einem anderen genehmigten Mechanismus beruhen. Nachdem der Gerichtshof Privacy Shield in Schrems II für ungültig erklärt hatte, mussten Organisationen auch prüfen, ob ergänzende Maßnahmen für Übermittlungen in Länder mit Überwachungsrisiken erforderlich waren. Das EU-US-Datenschutzrahmenwerk existiert mittlerweile, es gilt jedoch nur für zertifizierte US-Organisationen und bleibt ein Risikobereich, der überwacht werden sollte.

Warum eine gemeinsame Infrastruktur das Risikomodell verändert

Die meisten SaaS-Analyseplattformen sind mandantenfähig. Das ist normal, aber es macht die Isolierung der Mieter zu einer entscheidenden Kontrolle. Sie möchten den Nachweis erbringen, dass Kundendaten auf Anwendungs-, Datenbank-, Zugriffskontroll-, Protokollierungs-, Sicherungs- und Supportebene getrennt sind.

Bitten Sie die Anbieter um genaue Antworten:

• Sind Mandanten nach Datenbank, Schema, Berechtigungen auf Zeilenebene oder Anwendungslogik getrennt?
• Können Mitarbeiter rohe Kundenereignisse direkt abfragen?
• Werden Produktionszugriffssitzungen protokolliert und überprüft?
• Werden Exporte im Ruhezustand und während der Übertragung verschlüsselt?
• Wie werden Backups isoliert und gelöscht?
• Was passiert, wenn die Konfiguration eines Mandanten versehentlich auf einen anderen angewendet wird?

Wenn ein Anbieter die Mietertrennung nicht klar erklären kann, handelt es sich um ein Beschaffungsrisiko und nicht um eine Dokumentationssache.

Vorfallbereitschaft für Analysedaten

Ein praktischer Plan für Analysevorfälle sollte festlegen, was als meldepflichtig gilt, wer die Entscheidung trifft und wie schnell Beweise gesammelt werden können. Beziehen Sie Analysen in Ihre Tabletop-Übungen zu Sicherheitsverletzungen ein. Die Untersuchung sollte Folgendes beantworten:

1. Welche Datensätze wurden offengelegt oder verändert?
2. Umfassten die Daten personenbezogene Daten, pseudonyme Identifikatoren oder sensible Daten?
3. Wie viele Personen und Konten waren betroffen?
4. Könnten die Daten mit Personen verknüpft werden?
5. Hat ein anderer Kunde, ein Mitarbeiter eines Lieferanten, die Öffentlichkeit oder ein Angreifer auf die Daten zugegriffen?
6. Sind Benachrichtigungen von Aufsichtsbehörden oder Kunden erforderlich?
7. Welche Protokolle beweisen die Eindämmung?

Die EDPB-Richtlinien zur Meldung von Verstößen sind nützlich, weil sie sich auf Risiken und nicht auf Etiketten konzentrieren.

So reduzieren Sie die Exposition vor einem Vorfall

Die stärkste Kontrolle ist die Minimierung. Senden Sie keine personenbezogenen Daten an Analytics, es sei denn, Sie benötigen sie wirklich. Vermeiden Sie die Erfassung der vollständigen URL, wenn URLs Benutzereingaben enthalten können. Entfernen Sie standardmäßig Abfrageparameter und lassen Sie nur genehmigte Kampagnenparameter zu. Geben Sie niemals E-Mails, Telefonnummern, Namen, Token oder Freitextformularwerte in Ereigniseigenschaften ein.

Als nächstes verkürzen Sie die Retention. Bewahren Sie rohe Ereignisdaten nur so lange auf, wie sie betrieblich nützlich sind, und aggregieren Sie sie dann. Ein 30- oder 90-tägiges Rohereignisfenster kann für das Debugging und die Trichteranalyse ausreichend sein, während monatliche Gesamtberichte länger aufbewahrt werden können.

Bevorzugen Sie schließlich Architekturen, die den Zugriff Dritter einschränken. Für einige Teams bedeutet das ein in der EU gehostetes, datenschutzorientiertes SaaS mit starken Verträgen und ohne standortübergreifende Kennungen. Für regulierte oder öffentliche Teams kann dies eine selbst gehostete oder dedizierte Infrastruktur, vom Kunden verwaltete Verschlüsselungsschlüssel und strenge Support-Zugriffsgenehmigungen bedeuten.

Fragen zur Lieferanten-Due-Diligence

Fragen Sie vor der Auswahl einer Analyseplattform nach:

• Eine Datenverarbeitungsvereinbarung und eine Liste der Unterauftragsverarbeiter.
• Datenresidenz und Übertragungsdokumentation.
• Sicherheitszertifizierungen oder unabhängige Audits, sofern verfügbar.
• Eine Verpflichtung zur Meldung von Verstößen mit Fristen.
• Eine Aufbewahrungs- und Löschrichtlinie.
• Eine Liste der gesammelten Felder und Bezeichner.
• Unterstützung für die Deaktivierung von Cookies, IP-Speicherung, Fingerabdruck und Tracking auf Benutzerebene.
• Export- und Löschworkflows beim Verlassen.

Analytics soll Unsicherheit reduzieren. Wenn die Plattform selbst Rechts-, Sicherheits- und Souveränitätsunsicherheit schafft, wirkt sich das Tool nachteilig auf das Unternehmen aus.

Checkliste für vorfallbereite Analysen

Bereiten Sie sich auf Analysevorfälle vor, bevor sie passieren. Bewahren Sie eine aktuelle Datenzuordnung, Anbieterliste, Unterprozessorliste, Aufbewahrungszeitplan, Zugriffsprotokoll, Exportpfad und Kontaktroute für Sicherheitshinweise auf. Integrieren Sie Analysetools in Tabletop-Übungen zu Sicherheitsverletzungen.

Reduzieren Sie den Explosionsradius, indem Sie weniger Identifikatoren sammeln, sensible URLs und Ereignisse ausschließen, die Rohdatenaufbewahrung verkürzen, den Dashboard-Zugriff einschränken und Anbieter bevorzugen, die Mandantentrennung, Supportzugriff und Datenstandort konkret erklären können.

Häufig gestellte Fragen

Wie schnell muss man einen Analytics-Datenschutzvorfall nach der DSGVO melden?

Nach der DSGVO müssen Verantwortliche die Aufsichtsbehörde gemäß Artikel 33 innerhalb von 72 Stunden nach Bekanntwerden einer Verletzung des Schutzes personenbezogener Daten benachrichtigen. Artikel 34 regelt, wann betroffene Personen direkt informiert werden müssen. Dass der Anbieter den Vorfall verursacht hat, entbindet den Verantwortlichen nicht von dieser Pflicht. Die Frist beginnt, sobald genug Informationen für eine Risikobewertung vorliegen, nicht erst nach Abschluss der Untersuchung.

Zählt ein Fehler des Anbieters trotzdem als Verstoß nach der DSGVO?

Ja. Die DSGVO definiert eine Verletzung des Schutzes personenbezogener Daten als jede unbeabsichtigte oder unrechtmäßige Vernichtung, jeden Verlust, jede Veränderung sowie unbefugte Offenlegung oder unbefugten Zugang zu personenbezogenen Daten, unabhängig davon, wer sie verursacht hat. Eine Fehlkonfiguration des Anbieters, die den Vorfall auslöst, hebt die eigenen Meldepflichten des Verantwortlichen nicht auf.

Was gilt innerhalb einer Analytics-Plattform als personenbezogene Daten?

Analytics-Tools können URLs, Suchbegriffe, Referrer, Kampagnen-IDs, aus der IP abgeleiteten Standort, Kontoereignisse, Produktnutzung und manchmal nutzerbezogene Kennungen erfassen. Jedes davon kann zu personenbezogenen Daten werden, sobald es sich einer Person zuordnen lässt, etwa ein Reset-Token in einer im Debug-Log gespeicherten URL. Deshalb behandelt der Beitrag Analytics-Plattformen mit derselben Ernsthaftigkeit wie Zahlungskartensysteme.

Was unterscheidet Hosting in der EU von echter Datensouveränität?

Der Serverstandort ist nur ein Teil davon. Datensouveränität hängt außerdem von der Unternehmensjurisdiktion des Anbieters ab, von seinen Subunternehmern, dem Fernzugriff des Supports, dem Verschlüsselungsmodell, dem Prozess zur Vorfallreaktion und davon, ob Daten den EWR überhaupt verlassen dürfen. Ein in Frankfurt gehostetes Dashboard kann trotzdem für Mitarbeiter oder Subunternehmer außerhalb der EU erreichbar sein.

Warum war Schrems II für Analytics-Anbieter relevant?

Der Europäische Gerichtshof erklärte das EU-US Privacy Shield im Schrems-II-Urteil für ungültig. Das Urteil zwang Unternehmen, neu zu bewerten, ob zusätzliche Maßnahmen für Übermittlungen in Länder mit Überwachungsrisiken nötig sind. Das EU-US Data Privacy Framework existiert inzwischen, gilt aber nur für zertifizierte US-Unternehmen und bleibt ein Risikobereich, den man weiter beobachten sollte.

Was sollte man einen Anbieter zur Mandantentrennung fragen?

Fragen Sie, ob Mandanten durch Datenbank, Schema, zeilenbasierte Berechtigungen oder Anwendungslogik getrennt sind, ob Mitarbeiter direkt auf Rohdaten von Kundenereignissen zugreifen können und ob Produktionszugriffe protokolliert und überprüft werden. Fragen Sie auch, wie Exporte und Backups verschlüsselt und isoliert sind und was passiert, wenn die Konfiguration eines Mandanten versehentlich auf einen anderen angewendet wird. Ein Anbieter, der das nicht klar beantworten kann, ist ein Beschaffungsrisiko, keine Formalität.

Wie lange sollte man Analytics-Rohdaten aufbewahren?

Nur so lange, wie sie operativ nützlich bleiben, danach zu Aggregaten übergehen. Ein Zeitfenster von 30 oder 90 Tagen für Rohdaten reicht meist für Debugging und Funnel-Analysen aus, während monatliche Aggregatberichte länger aufbewahrt werden können, ohne dieselbe Angriffsfläche zu schaffen.

Was sind Beispiele für gewöhnliche Fehler, die zu Analytics-Verstößen führen?

Häufige Ursachen sind ein Multi-Tenant-Dashboard, das die Daten eines Kunden einem anderen zeigt, und Debug-Logs, die vollständige URLs mit E-Mails oder Reset-Tokens speichern. Dazu kommen ein falsch konfigurierter BigQuery- oder S3-Export, der öffentlich zugänglich wird, Support-Mitarbeiter, die ohne geschäftlichen Grund auf Rohdaten-Streams zugreifen, und ein Tag-Manager, der ein nicht genehmigtes Skript lädt, das Ereignisdaten an Dritte kopiert. Keiner dieser Fälle braucht einen Angreifer. Es sind operative Fehler.

Was sollte eine Untersuchung eines Analytics-Vorfalls klären?

Die Untersuchung sollte klären, welche Datensätze offengelegt oder verändert wurden, ob die Daten personenbezogene Daten, pseudonyme Kennungen oder sensible URLs enthielten, und wie viele Personen und Konten betroffen waren. Sie sollte außerdem klären, ob sich die Daten Personen zuordnen lassen, wer darauf zugegriffen hat, und ob eine Meldung an Behörden oder Kunden erforderlich ist, gestützt auf Protokolle, die die Eindämmung belegen.

Wonach sollte man bei der Due-Diligence-Prüfung eines Anbieters fragen?

Fordern Sie eine Auftragsverarbeitungsvereinbarung und eine Liste der Subunternehmer, Dokumentation zu Datenresidenz und Übermittlungen sowie, sofern verfügbar, Sicherheitszertifizierungen oder unabhängige Audits an. Fragen Sie außerdem nach einer Verpflichtung zur Vorfallmeldung mit Fristen, einer Aufbewahrungs- und Löschrichtlinie, einer Liste der erfassten Felder und Kennungen sowie nach Export- und Löschprozessen für den Fall eines Anbieterwechsels.