Datenschutz-Governance für Session Replay nach GDPR und ISO 27701

Die Demo, die Produkt-Erkenntnisse in Datenschutznachweise verwandelte

Der Demo-Bildschirm wirkte wie ein Durchbruch. Sarah, CISO eines schnell wachsenden SaaS-Unternehmens, sah zu, wie das Produktteam eine reale Onboarding-Sitzung aus der neuen Analyseplattform abspielte. Der Cursor bewegte sich über die Oberfläche, ein Nutzer zögerte bei Schritt drei, klickte zweimal zurück, öffnete einen Hilfe-Tooltip und brach den Ablauf anschließend ab.

Der Produktmanager war begeistert. Session Replay würde genau zeigen, an welchen Stellen Kunden scheitern. Heatmaps würden sichtbar machen, welche Felder Reibung verursachen. Crash-Diagnosen würden der Entwicklung zeigen, welche Browser ausfallen. Mobile Telemetrie würde helfen, Fehlerbehebungen nach Geräteversion zu priorisieren. Es sah nach einer Goldgrube für die User Experience aus.

Dann sah Sarah, was das Tool tatsächlich erfasst hatte.

Ein Nutzer hatte versehentlich ein Passwort in das Feld für den Benutzernamen eingegeben. Ein anderer hatte eine nationale Identifikationsnummer in ein Freitextfeld eingefügt. Ein Support-Mitarbeiter öffnete während einer Fehlersuche ein Kundenkonto, wodurch Finanzdaten auf dem Bildschirm sichtbar wurden. Crash-Protokolle enthielten E-Mail-Adressen, IP-Adressen, Routennamen, Authentifizierungsstatus, Gerätekennungen und Feature Flags, die den internen Workflow des Kunden offenlegten.

Der Analyseanbieter bezeichnete sich als Auftragsverarbeiter. Der Kundenvertrag sah vor, dass produktive PII ohne Genehmigung nicht für Analysen verwendet werden dürfen. Der Datenschutzhinweis sagte lediglich, dass das Unternehmen Analysen zur Verbesserung des Dienstes einsetzt. Session Replay, Verhaltensüberwachung, Gerätekennungen, Maskierung, Aufbewahrung, Empfänger oder internationale Übermittlungen wurden nicht erwähnt.

Das Produktteam sah harmlose Betriebsdaten. Sarah sah unstrukturierte, unmaskierte und ungesteuerte personenbezogene Daten (PII) in einer Cloud-Plattform mit breitem internem Zugriff und unklarer Rechtsgrundlage.

Das ist das eigentliche Problem bei der Datenschutz-Governance für Produkttelemetrie und Session Replay. Das Risiko besteht nicht darin, dass Telemetrie existiert. Das Risiko besteht darin, dass sie als risikoarmer technischer Nebenstrom behandelt wird, statt als gesteuerte Verarbeitungstätigkeit mit Bezug zu Rechtsgrundlage, Datenschutzhinweis, DSFA-Screening, Lieferantenverträgen, Maskierung, Zugriffskontrolle, Aufbewahrung, Incident Response und Auditnachweisen.

Unter ISO/IEC 27701:2025 benötigen Organisationen ein Datenschutz-Informationsmanagementsystem (PIMS), das Datenschutz als Betriebsmodell behandelt. Unter GDPR müssen Verantwortliche die Einhaltung von Grundsätzen wie Rechtmäßigkeit, Verarbeitung nach Treu und Glauben, Transparenz, Zweckbindung, Datenminimierung, Speicherbegrenzung, Integrität, Vertraulichkeit und Rechenschaftspflicht nachweisen. Session Replay und Produkttelemetrie liegen unmittelbar in dieser Rechenschaftszone, weil sie häufig überwachen, wie identifizierbare Personen sich innerhalb eines digitalen Dienstes verhalten.

Der Ansatz von Clarysec besteht darin, Telemetrie aus dem Schatten zu holen und in eine nachvollziehbare Governance-Kette einzubetten: Inventarisierung, Rollenklassifizierung, Rechtsgrundlage, DSFA-Screening, Datenschutzhinweis, Lieferantenbewertung, Maskierung, Aufbewahrung, Zugriffskontrolle, Nachweise und kontinuierliche Überprüfung. Unterstützt wird diese Kette durch den Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, die PIMS-Richtlinien von Clarysec und Zenith Controls: The Cross-Compliance Guide Zenith Controls.

Warum Produkttelemetrie nach GDPR nicht nur Analyse ist

GDPR definiert personenbezogene Daten weit und umfasst Online-Kennungen sowie Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen. Auch Verarbeitung wird weit definiert und umfasst Erhebung, Speicherung, Nutzung, Offenlegung, Löschung und Vernichtung. Produkttelemetrie kann daher zur Verarbeitung personenbezogener Daten werden, wenn sie Nutzer, Mandanten, Administratoren, Beschäftigte oder Endnutzer von Kunden umfasst, mit ihnen verknüpft ist oder ihnen vernünftigerweise zugeordnet werden kann.

Typische Telemetriedatenpunkte sind:

• Benutzerkennungen, E-Mail-Adressen, Mandantenkennungen und Kontokennungen
• IP-Adressen, Gerätekennungen, Browser-Fingerprints und mobile Werbekennungen
• Feature-Nutzung, Klickpfade, Scrolltiefe, Formularinteraktionen und Fehlerverhalten
• Crash-Dumps, Routennamen, Fragmente von API-Payloads und Diagnoseprotokolle
• Session-Replay-Aufzeichnungen, DOM-Snapshots, Tastatureingabeereignisse und Heatmaps
• Support-Metadaten, Screenshots, Bildschirmaufzeichnungen und Nutzerfeedback
• Performance-Ereignisse mit Bezug zu Konto, Rolle, Geografie oder Kundensegment

Das Datenschutzproblem verschärft sich, wenn Telemetrie Verhalten offenlegt. GDPR Article 3 kann auch für Nicht-EU-SaaS-Anbieter gelten, wenn sie Personen in der Union Waren oder Dienstleistungen anbieten oder deren Verhalten innerhalb der Union beobachten. Session Replay, Heatmaps und Produktanalysen sind im allgemeinen Sprachgebrauch häufig Verhaltensüberwachung, selbst wenn der geschäftliche Zweck Produktverbesserung und nicht Werbung ist.

GDPR Article 6 verlangt für jeden Verarbeitungszweck eine Rechtsgrundlage. Einwilligung kann angemessen sein, wenn Tracking optional, eingriffsintensiv oder durch lokale ePrivacy-Vorgaben geregelt ist. Berechtigte Interessen können für begrenzte Telemetrie möglich sein, jedoch nur nach Bewertung von Erforderlichkeit, Verhältnismäßigkeit sowie der Rechte und Freiheiten betroffener Personen. Vertragserfüllung kann Telemetrie stützen, die für die Bereitstellung des Dienstes strikt erforderlich ist; nicht jeder Optimierungs- oder Replay-Anwendungsfall lässt sich jedoch belastbar auf Vertragserfüllung stützen.

Auch Risiken im Zusammenhang mit besonderen Kategorien personenbezogener Daten sind relevant. GDPR Article 9 beschränkt die Verarbeitung von Daten, aus denen Gesundheit, biometrische Merkmale, politische oder religiöse Überzeugungen oder andere sensitive Kategorien hervorgehen. Viele SaaS-Anbieter gehen davon aus, solche Daten nicht zu erheben, und stellen dann fest, dass Kunden sie in Support-Formulare, Workflow-Felder, Notizen, HR-Datensätze, Beschreibungen juristischer Vorgänge, medizinische Leistungsansprüche oder durch Replay-Tools erfasste Screenshots einfügen.

Clarysecs Enterprise-Data Protection and Privacy Policy Data Protection and Privacy Policy macht Rechtsgrundlage und Datenminimierung ausdrücklich verbindlich:

Jede Verarbeitung MUSS auf einer gültigen Rechtsgrundlage beruhen (z. B. Einwilligung, Vertrag, rechtliche Verpflichtung).

Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.1.1.

Es dürfen nur Daten erhoben und verarbeitet werden, die für einen spezifischen, legitimen Geschäftszweck erforderlich sind.

Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.2.1.

Für kleinere Teams verlangt die Data Protection and Privacy Policy-sme Data Protection and Privacy Policy - SME Disziplin bei der Inventarisierung:

Der Datenschutzkoordinator MUSS ein Register aller Verarbeitungstätigkeiten für personenbezogene Daten führen, einschließlich Datenkategorien, Zweck, Rechtsgrundlage und Aufbewahrungsfristen.

Aus Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.2.1.

Sie gibt Produkt- und Entwicklungsteams außerdem eine klare Privacy-by-Design-Basislinie:

Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen MUSS in allen neuen Systemen und Diensten durchgesetzt werden.

Aus Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.3.1.

Die Governance-Korrektur ist einfach: Fragen Sie nicht, ob Telemetrie „Analyse“ ist. Fragen Sie, ob es sich um eine Verarbeitungstätigkeit handelt, die PII, Verhaltensüberwachung, Profiling, Lieferantenzugriff, Aufbewahrung und Sicherheitskontrollen umfasst.

Mit Rollenklarheit nach ISO 27701:2025 beginnen

Datenschutz-Governance nach ISO/IEC 27701:2025 funktioniert am besten, wenn Organisationen zuerst ihre Rolle bestimmen. Handeln Sie als Verantwortlicher für PII und entscheiden, warum Session Replay eingesetzt wird und welche Daten erfasst werden? Sind Sie Auftragsverarbeiter und erfassen Telemetrie im Auftrag eines Kunden nach dokumentierten Weisungen? Oder sind Sie je nach Funktion und Kundenkonfiguration beides?

Der PIMS-Richtliniensatz von Clarysec nutzt Rollenkennzeichnungen, um dies operativ umzusetzen. „Beide“ gilt unabhängig davon, ob die Organisation als Verantwortlicher oder Auftragsverarbeiter handelt. „Verantwortlicher“ gilt, wenn die Organisation Zwecke und Mittel festlegt. „Auftragsverarbeiter“ gilt, wenn die Verarbeitung nach dokumentierten Weisungen erfolgt.

Ein SaaS-Anbieter kann Verantwortlicher für Telemetrie sein, die zur Verbesserung des eigenen Produkts, zur Erkennung von UX-Reibung oder zur Priorisierung von Roadmap-Entscheidungen verwendet wird. Derselbe Anbieter kann Auftragsverarbeiter für Telemetrie sein, die innerhalb eines vom Kunden kontrollierten Arbeitsbereichs erfasst wird, wenn der Kunde den Zweck bestimmt. In seltenen Fällen kann eine gemeinsame Verantwortlichkeit entstehen, wenn beide Parteien Zwecke und Mittel gemeinsam festlegen. In anderen Verarbeitungsketten kann der Anbieter als Unterauftragsverarbeiter Telemetrie für einen anderen Auftragsverarbeiter verarbeiten.

Die Enterprise-PII Processing Inventory and Lawful Basis Policy PII Processing Inventory and Lawful Basis Policy konkretisiert das erste Gate:

[Beide] Der/Die Prozessverantwortliche bzw. fachlich Verantwortliche MUSS einen REG02-Datensatz im Verarbeitungsinventar erstellen, bevor eine neue Verarbeitungstätigkeit für PII beginnt.

Aus Abschnitt „Basislinie für das Verarbeitungsinventar“, Richtlinienklausel 4.1.1.

Für Produkttelemetrie sollte REG02 keine vage Zeile „Analyse“ enthalten. Zwecke und Datenflüsse sind zu trennen.

ISO/IEC 27001:2022 unterstützt diese PIMS-Arbeit, indem sie der Organisation Struktur für Kontext, Anforderungen interessierter Parteien, Geltungsbereich, Führung, Rollen, Risikobeurteilung, Behandlungsplanung, operative Steuerung und extern bereitgestellte Dienste gibt. Das ISMS fragt nach Assets, Risiken, Verantwortlichen, Kontrollen und Nachweisen. Das PIMS fragt, welche PII verarbeitet werden, warum, in welcher Rolle, mit welchen Rechten, Schutzmaßnahmen und Hinweisen.

Zusammen verhindern sie die klassische Datenschutzlücke, bei der Produktteams Tracking schneller aktivieren, als Governance es klassifizieren kann.

DSFA-Auslöser: wenn Produkt-Erkenntnisse zur Hochrisikoverarbeitung werden

Nicht jedes Telemetrieereignis erfordert eine vollständige DSFA. Session Replay und Verhaltensanalysen erfordern jedoch häufig ein DSFA-Screening, weil sie systematische Überwachung, Profiling, umfangreiche Verarbeitung, sensitive Inhalte, schutzbedürftige Nutzer, innovative Technologie oder wesentlich geänderte Verarbeitung umfassen können.

Die Privacy Risk Assessment and DPIA Policy Privacy Risk Assessment and DPIA Policy ist für Verantwortliche eindeutig:

[Verantwortlicher] Der/Die Prozessverantwortliche bzw. fachlich Verantwortliche MUSS Verarbeitungen, die umfangreiche systematische Überwachung, Profiling, automatisierte Entscheidungen, besondere Kategorien von PII, Daten zu strafrechtlichen Verurteilungen oder Straftaten, schutzbedürftige betroffene Personen, innovative Technologie oder wesentlich geänderte Verarbeitung betreffen, vor Beginn der Verarbeitung in REG04 an die Datenschutzleitung / den PIMS-Manager verweisen.

Aus Abschnitt „DSFA-Auslöser und Anforderungsbestimmung“, Richtlinienklausel 4.2.2.

Ein DSFA-Screening für Session Replay sollte praktische Fragen stellen:

• Erfasst Replay Formulareingaben, Seiteninhalte, Chat-Texte, hochgeladene Dokumente oder Fehler-Payloads?
• Erfolgt die Maskierung, bevor Daten den Browser verlassen, oder erst nach der Aufnahme in die Plattform?
• Kann das Tool Passwörter, Token, Secrets, Einmalcodes oder Zahlungsfelder erfassen?
• Sind Sitzungen mit benannten Nutzern, Konten, IP-Adressen oder Gerätekennungen verknüpft?
• Können Beschäftigte Replays nach Nutzer, Kunde, Segment, Fehler, URL oder Verhalten durchsuchen?
• Verwendet der Anbieter die Daten für Analysen, KI-Training, Benchmarking oder Produktverbesserung?
• Sind internationale Übermittlungen beteiligt?
• Welche Aufbewahrungsfrist ist konfiguriert, und kann Löschung nach Mandant oder Nutzer durchgesetzt werden?
• Können Kunden Replay deaktivieren, Maskierung konfigurieren oder Löschung verlangen?
• Sind Beschäftigte, Administratoren und Endnutzer von Kunden durch Hinweise abgedeckt?
• Besteht das Risiko, Daten von Kindern, Gesundheitsdaten, Finanzdaten oder HR-Daten zu erfassen?

Die Enterprise-Data Protection and Privacy Policy bekräftigt die Hochrisikoschwelle:

Bedrohungsmodellierung und Datenschutz-Folgenabschätzungen (DSFA) sind für Verarbeitungssysteme mit hohem Risiko verpflichtend.

Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.3.4.

Eine wichtige Clarysec-Erkenntnis aus Audits ist, dass Session-Replay-Risiko nicht nur ein Datenschutzthema ist. Es ist auch ein Thema der Sicherheitsarchitektur. Wenn DOM-Snapshots Bearer-Token, interne Kennungen, versteckte Felder oder sensitive Kunden-Workflows erfassen, hat die Organisation einen neuen hochwertigen Datenbestand außerhalb ihres normalen Perimeters für Protokollierung, DLP und Berechtigungsüberprüfung geschaffen.

Das Replay-Tool zu einem auditierbaren Asset machen

Der schnellste Weg zur Reduzierung von Telemetrierisiken besteht darin, Tools nicht länger als unsichtbare Produktinfrastruktur zu behandeln. Im Zenith Blueprint, Phase Risikomanagement, Schritt 9, „Identifying Assets, Threats, and Vulnerabilities“, weist Clarysec Organisationen an, Assets zu inventarisieren und Verantwortliche, Standort und Klassifizierung zu erfassen. Dabei wird ausdrücklich darauf hingewiesen, dass Assets mit personenbezogenen Daten hinsichtlich GDPR-Relevanz zu kennzeichnen und kritische Service-Assets für eine mögliche NIS2-Anwendbarkeit zu vermerken sind.

Der Blueprint beschreibt ein Informations-Asset als alles von Wert, das durch einen Sicherheitsvorfall beeinträchtigt werden könnte, einschließlich Informationen, Software, Cloud-Services, Dienste/Prozesse und Drittdienstleistungen. Für Telemetrie-Governance wird jede Analyseplattform, jeder Replay-Anbieter, jedes SDK, jede Ereignispipeline, jeder Data Lake, jedes Dashboard, jeder Export und jeder Speicher für Support-Aufzeichnungen zu einem auditierbaren Asset.

Dies verbindet Datenschutz-Governance mit ISMS-Nachweisen. Produkt-, Datenschutz-, Entwicklungs- und Audit-Teams können auf denselben Datensatz verweisen, statt getrennte Darstellungen zu pflegen.

Zenith Controls als bereichsübergreifendes Compliance-Rückgrat nutzen

Clarysec verwendet Zenith Controls als Cross-Compliance-Leitfaden, nicht als Ersatz für offizielle Rahmenwerke. Für Telemetrie und Session Replay sind die zentralen Themen aus ISO/IEC 27002:2022 Datenschutz und Schutz von PII, Governance von Cloud-Services, Lieferantenbeziehungen, Datenmaskierung, Asset-Inventar, Klassifizierung, Zugriffskontrolle und Änderungsmanagement.

In Zenith Controls ist ISO/IEC 27002:2022 Maßnahme 5.34, Datenschutz und Schutz von PII, der Anker. Die praktische Grundlage ist Datenbewusstsein:

Grundlage dieser Maßnahme ist Datenbewusstsein. Die Organisation MUSS wissen, welche PII sie erhebt, wo diese liegen, warum sie verarbeitet werden und wer darauf zugreifen kann.

Aus Zenith Blueprint, Phase „Controls in Action“, Schritt 23, Maßnahme 5.34, Datenschutz und Schutz personenbezogener Informationen.

Zenith Controls ordnet 5.34 unterstützenden ISO/IEC 27002:2022-Maßnahmen zu, etwa 5.9 Inventar von Informationen und anderen zugehörigen Assets, 8.11 Datenmaskierung, 5.23 Informationssicherheit bei Nutzung von Cloud-Services, 5.12 Klassifizierung von Informationen, 5.14 Informationsübertragung, 5.15 Zugriffskontrolle, 5.16 Identitätsmanagement, 5.19 Informationssicherheit in Lieferantenbeziehungen, 5.8 Informationssicherheit im Projektmanagement und 8.32 Änderungsmanagement.

Für Datenmaskierung identifiziert Zenith Controls ISO/IEC 27002:2022 Maßnahme 8.11 als präventiv und auf Vertraulichkeit ausgerichtet. Zudem wird Maskierung mit 8.3 Beschränkung des Informationszugriffs, 8.10 Löschung von Informationen, 8.12 Verhinderung von Datenabfluss, 8.24 Nutzung von Kryptografie und 8.33 Testinformationen verbunden. Das ist relevant, weil Session-Replay-Maskierung nicht kosmetisch sein darf. Sie MUSS konzipiert, getestet und nachgewiesen werden.

Die Data Masking and Pseudonymization Policy-sme Data Masking and Pseudonymization Policy - SME gibt eine einfache Regel vor, die auch für Produktanalysen gilt:

Produktive personenbezogene Daten dürfen in Tests, externen Tools oder Analysen nur mit formeller Genehmigung verwendet werden.

Aus Abschnitt „Rollen und Verantwortlichkeiten“, Richtlinienklausel 4.4.1.

Ein praktischer Clarysec-Workflow zur Freigabe von Session Replay

Angenommen, das Produktteam möchte Replay für alle fehlgeschlagenen Checkout-Sitzungen in einer Fintech-App aktivieren. Der Business Case ist real: Abgebrochene Checkouts wirken sich auf Umsatz und Kundenzufriedenheit aus. Die Governance-Frage lautet, ob diese Erkenntnisse rechtmäßig, verhältnismäßig und sicher erhoben werden können.

Schritt 1: REG02 erstellen, bevor das SDK produktiv gesetzt wird

Verwenden Sie REG02 gemäß der PII Processing Inventory and Lawful Basis Policy. Erfassen Sie Zweck, Datenkategorien, Nutzerkategorien, Quelle, Empfänger, Aufbewahrung, Übermittlungen, Systemverantwortlichen, Rechtsgrundlage und Rolle.

Schreiben Sie nicht „Analyse“. Schreiben Sie „Session Replay zur Fehlersuche bei fehlgeschlagenen Checkouts und zur Conversion-Verbesserung“. Listen Sie konkrete Felder auf, einschließlich Benutzerkennung, Mandantenkennung, IP-Adresse, Gerätekennung, Klickereignisse, Seitenrouten, DOM-Snapshots, maskierte Formularfelder, Fehlercodes und Status des Zahlungsflusses.

Schritt 2: Rechtsgrundlage bestimmen

Für grundlegende Crash-Diagnosen und aggregierte Performance-Kennzahlen können berechtigte Interessen vertretbar sein, wenn die Organisation Erforderlichkeit, Verhältnismäßigkeit, Schutzmaßnahmen und Nutzererwartungen dokumentiert. Für vollständiges Session Replay, insbesondere auf authentifizierten Seiten, kann Einwilligung klarer sein, wenn lokale Regeln oder die Eingriffsintensität dies erfordern.

Ein hybrider Ansatz ist häufig praktikabler: berechtigte Interessen für begrenzte, nicht eingriffsintensive, maskierte Telemetrie und ausdrückliches Opt-in oder mandantenbezogene Aktivierung für Session Replay. Unabhängig vom Ergebnis MUSS es dokumentiert und in Hinweisen, Verträgen und Konfigurationen abgebildet werden.

Schritt 3: In REG04 auf DSFA-Auslöser prüfen

Replay fehlgeschlagener Checkouts kann Finanzverhalten, Authentifizierung, Zahlungsseiten und systematische Überwachung betreffen. Der/Die Prozessverantwortliche verweist die Aktivität an die Datenschutzleitung. Das Screening bewertet Erforderlichkeit, Verhältnismäßigkeit, Erwartungen betroffener Personen, Maskierung, Zugriffskontrollen, Anbieternutzung, Aufbewahrung und Alternativen wie aggregierte Funnel-Kennzahlen.

Die Privacy by Design and Default Policy Privacy by Design and Default Policy verlangt eine spezifische Minimierungsanalyse:

[Beide] Der/Die Prozessverantwortliche bzw. fachlich Verantwortliche MUSS in REG04 die Machbarkeit von De-Identifizierung, Pseudonymisierung, Aggregation oder nicht identifizierbarer Verarbeitung dokumentieren, bevor identifizierbare PII für Tests, Analysen, Berichterstattung oder sekundäre betriebliche Nutzung genehmigt werden.

Aus Abschnitt „Datenminimierung und datenschutzfreundliche Voreinstellungen“, Richtlinienklausel 4.2.5.

Schritt 4: Datenschutzfreundliche Voreinstellungen vor produktiver Erfassung konfigurieren

Engineering sollte das SDK so konfigurieren, dass:

• Tastatureingabeerfassung standardmäßig deaktiviert ist
• alle Eingabefelder maskiert sind, sofern nicht ausdrücklich genehmigt
• Replay-Erfassung auf Zahlungs-, Passwort-, MFA-, Gesundheits-, HR- oder sensitiven Freitextseiten blockiert ist
• Token, Autorisierungsheader und versteckte Felder entfernt werden
• die Benutzerkennung soweit möglich durch eine pseudonyme Analysekennung ersetzt wird
• IP-Adressen gekürzt oder getrennt mit eingeschränktem Zugriff gespeichert werden
• für Rohaufzeichnungen von Session Replays kurze Aufbewahrungsfristen gelten
• mandantenbezogener Opt-out aktiviert wird, wenn vertraglich erforderlich
• Zugriff über SSO, MFA und rollenbasierte Genehmigung läuft
• Audit-Protokolle für Replay-Anzeige, Export und Löschung aktiviert sind

Schritt 5: Datenschutzhinweis und Kundendokumentation aktualisieren

Die Privacy Notice and Transparency Policy Privacy Notice and Transparency Policy verlangt, dass Inhalte des Datenschutzhinweises aus REG02 abgeleitet werden:

[Verantwortlicher] Der/Die Prozessverantwortliche bzw. fachlich Verantwortliche MUSS PII-Kategorien, Kategorien betroffener Personen, Quellenkategorie bei indirekter Erhebung, Empfängerkategorien, Aufbewahrungsreferenz und Übermittlungsreferenz aus REG02 in REG07 aufnehmen, bevor ein Datenschutzhinweis zur Freigabe eingereicht wird.

Aus Abschnitt „Hinweisinhalte und Transparenzinformationen“, Richtlinienklausel 4.2.3.

Der Hinweis sollte Produktanalysen und Replay in klarer Sprache erklären: was erfasst wird, warum es erfasst wird, ob es optional ist, wer es erhält, wie lange es aufbewahrt wird, wohin es übermittelt wird und wie Nutzer ihre Rechte ausüben können.

Schritt 6: Anbieter bewerten und weiterzugebende Verpflichtungen vertraglich absichern

Vor Beschaffung, Onboarding, Verlängerung oder einer wesentlichen Funktionsänderung ist REG08 gemäß der Processor, Subprocessor and Third-Party Privacy Management Policy Processor, Subprocessor and Third-Party Privacy Management Policy zu verwenden:

[Alle] Der/Die Prozessverantwortliche bzw. fachlich Verantwortliche MUSS jede vorgeschlagene Drittparteienbeziehung, die PII verarbeitet, darauf zugreift, diese empfängt, speichert, überträgt, unterstützt oder anderweitig beeinflusst, vor Beschaffung, Onboarding, Verlängerung oder wesentlicher datenschutzbezogener Änderung bei Drittparteien in REG08 identifizieren.

Aus Abschnitt „Identifizierung und Klassifizierung von Beziehungen“, Richtlinienklausel 4.1.2.

Die Anbieterprüfung sollte Datenstandort, Unterauftragsverarbeiter, Verschlüsselung, Zugriffskontrollen, Meldung von Datenschutzverletzungen, Löschung, Auditrechte, Nutzung von Kundendaten, Ausschlüsse für KI-Training, Support-Zugriff, Aufbewahrung, Exportkontrollen und Zusammenarbeit bei Vorfällen abdecken.

Die Enterprise-Data Protection and Privacy Policy erinnert Teams außerdem:

Verträge mit Auftragsverarbeitern müssen enthalten:

Aus Abschnitt „Durchsetzung und Einhaltung“, Richtlinienklausel 8.5.1.

Die SME-Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME bekräftigt:

Verträge müssen verbindliche Klauseln enthalten zu:

Aus Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.3.

Die Auditfrage ist eindeutig: Können Sie nachweisen, dass der Replay-Anbieter an Ihre Datenschutz-, Sicherheits-, Aufbewahrungs-, Lösch-, Unterstützungs- und Vorfallpflichten gebunden ist?

Schritt 7: Technische Kontrollen nachweisen

Im Zenith Blueprint, Phase „Controls in Action“, Schritt 19, „Technological Controls I“, weist Clarysec Teams an, automatisierte Löschung und Aufbewahrung zu verifizieren, Maskierung und Pseudonymisierung in Tests und Analysen zu überprüfen und DLP-Kontrollen zu bewerten.

Für Replay sind unter anderem folgende Nachweise aufzubewahren:

• Screenshots der SDK-Konfiguration
• Definitionen der Maskierungsregeln
• Testaufzeichnungen, die blockierte sensitive Felder zeigen
• Aufbewahrungskonfiguration
• Löschprotokolle
• Aufzeichnungen der Berechtigungsüberprüfung
• Anbieter-DPA und Liste der Unterauftragsverarbeiter
• Audit-Protokolle zur Replay-Anzeige
• DSFA-Freigabe oder dokumentiertes Screening-Ergebnis
• Freigabe des Datenschutzhinweises

So wird Datenschutz durch Technikgestaltung von einem Slogan zu auditbereiten Nachweisen.

Cross-Compliance-Zuordnung für Telemetrie-Governance

Telemetrie-Governance beginnt häufig als GDPR-Thema, bleibt aber selten darauf beschränkt.

GDPR Article 5 verlangt Rechtmäßigkeit, Verarbeitung nach Treu und Glauben, Transparenz, Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung, Sicherheit und Rechenschaftspflicht. Article 6 verlangt eine Rechtsgrundlage. Article 4 klärt die Rollen von Verantwortlichem und Auftragsverarbeiter sowie Datenschutzverletzungen. Article 9 erhöht die Anforderungen, wenn besondere Kategorien personenbezogener Daten in erfassten Inhalten erscheinen. Für Session Replay übersetzen sich diese Grundsätze in klare Hinweise, minimierte Erfassung, maskierte Felder, begrenzte Aufbewahrung, Zugriffskontrollen, Lieferantenverträge und DSFA-Nachweise.

NIS2 kann für SaaS, Cloud, digitale Infrastruktur, MSP, MSSP und bestimmte digitale Anbieter relevant werden, abhängig von Größe, Sektor und Kritikalität des Dienstes. Article 20 macht Cybersicherheits-Governance zu einer Verantwortung des Leitungsorgans. Article 21 verlangt Risikomanagementmaßnahmen einschließlich Richtlinien, Umgang mit Informationssicherheitsvorfällen, Kontinuität, Lieferkettensicherheit, sichere Entwicklung, Kontrollwirksamkeit, Cyberhygiene, Kryptografie, Personalsicherheit, Zugriffskontrolle und Asset-Management.

DORA gilt für viele Finanzunternehmen und schafft ab dem 17. Januar 2025 ein sektorspezifisches Regelwerk für digitale operationale Resilienz. Die Erwartungen an das IKT-Risikomanagement umfassen Governance, Asset- und Abhängigkeitsabbildung, Schutz, Erkennung, Kontinuität, Wiederherstellung, Schulung und Drittparteienaufsicht. Für Fintech-Telemetrie fragt DORA-orientiertes Denken, ob Replay-Tools kritische oder wichtige Funktionen unterstützen oder beeinflussen, ob der Anbieter ein IKT-Drittanbieter ist und ob Verträge Audit- und Vorfallunterstützung enthalten.

NIST CSF 2.0 ergänzt eine praktische Integrationsschicht. Die Funktion GOVERN verlangt ein Verständnis von Stakeholdern, Abhängigkeiten sowie rechtlichen, regulatorischen, vertraglichen und Datenschutzverpflichtungen. Ergebnisse aus IDENTIFY, PROTECT, DETECT, RESPOND und RECOVER lassen sich natürlich auf Telemetrie-Assets, Datenflüsse, Zugriffskontrolle, Protokollierung, Sicherheitsvorfall-Triage, Eindämmung und Wiederherstellung abbilden.

COBIT 19-Auditoren oder ISACA-geschulte Bewerter, die Governance-Grundsätze anwenden, fragen in der Regel, ob Telemetrie Unternehmensziele unterstützt, ob Risikoverantwortung klar ist, ob Nutzen und Risiko ausgewogen sind, ob Richtlinien durchgesetzt werden und ob Überwachung die Kontrollwirksamkeit belegt.

Wie Auditoren denselben Replay-Workflow prüfen

Ein Datenschutzauditor beginnt mit REG02, REG04 und REG07. Er wählt eine Replay-Aktivität aus und fordert Zweck, Rechtsgrundlage, Kategorien von PII, Kategorien betroffener Personen, Empfänger, Aufbewahrung, Übermittlungen, DSFA-Screening, Hinweistexte und Auftragsverarbeitervereinbarungen an. Er prüft, ob die tatsächliche SDK-Konfiguration dem freigegebenen Verarbeitungsdatensatz entspricht. Wenn der Datensatz besagt, dass Eingabefelder maskiert sind, verlangt er Nachweise.

Ein ISO/IEC 27001:2022-Auditor beginnt mit Geltungsbereich, Risikobeurteilung, Anwendbarkeitserklärung (SoA), Lieferantenkontrollen und operativen Nachweisen. Er kann Telemetrie mit Asset-Inventar, Zugriffskontrolle, Cloud-Services, Management von Lieferantenbeziehungen, sicherer Entwicklung und Vorfallsbereitschaft verknüpfen. Wenn Replay über eine Produktänderung eingeführt wurde, fragt er, ob die Risikobeurteilung aktualisiert wurde und ob extern bereitgestellte Dienste gesteuert wurden.

Ein DORA-Auditor im Fintech-Kontext fragt, ob der Telemetrieanbieter im IKT-Drittparteienregister aufgeführt ist, ob der Dienst eine kritische oder wichtige Funktion unterstützt, ob Verträge Standorte, Datenverarbeitungsregionen, Vorfallunterstützung, Auditrechte, Kündigungsrechte, Anforderungen an Geschäftskontinuität und Unterstützung beim Übergang enthalten.

Ein NIST CSF-Bewerter beginnt mit dem Ist-Profil. Ist Session Replay als Technologieabhängigkeit und Datenverarbeitungstätigkeit dokumentiert? Gibt es einen Zielzustand? Werden Lücken in einem Risikoregister oder Maßnahmenplan verfolgt? Sind Lieferantenanforderungen in Verträgen ausgedrückt? Sind Erkennungs- und Reaktionsrollen definiert, falls Replay-Daten offengelegt werden?

Ein COBIT 19- oder ISACA-orientierter Auditor fragt, ob Governance wirksam ist. Hat das Managementsystem Verantwortlichkeiten definiert? Wurden Stakeholder einbezogen? Wird Risiko auf der richtigen Ebene akzeptiert? Werden Kontrollkennzahlen überprüft? Sind Ausnahmen für das Management sichtbar? Ist die Produkt-Erkenntnis das Datenschutz- und Lieferantenrisiko wert?

Der Wert von Zenith Controls besteht darin, dass ein einzelner Replay-Workflow über Datenschutz- und Sicherheitskontrollen hinweg abgebildet werden kann, ohne getrennte Nachweispakete zu erzeugen. Dieselben Maskierungsnachweise unterstützen PII-Schutz, Verhinderung von Datenabfluss, Zugriffsbeschränkung und Datenschutz durch Technikgestaltung. Dieselbe Lieferantenprüfung unterstützt Cloud-Governance, Auftragsverarbeitermanagement, NIS2-Lieferkettensicherheit und DORA-IKT-Drittparteienrisiko. Dasselbe Inventar unterstützt GDPR-Rechenschaftspflicht, ISO 27701:2025-PIMS-Datensätze, ISO/IEC 27001:2022-Asset-Management und NIST CSF-Asset-Ergebnisse.

Häufige Feststellungen in Telemetrieprüfungen

Telemetrieaudits zeigen regelmäßig wiederkehrende Muster.

Erstens sagt das Verarbeitungsinventar „Analyse“, unterscheidet aber nicht zwischen Crash-Reporting, Heatmaps, Replay, Support-Aufzeichnungen und KI-basierten Produkt-Erkenntnissen. Damit lassen sich Rechtsgrundlage, Hinweis und Aufbewahrung nicht validieren.

Zweitens existiert Maskierung, wird aber nicht getestet. Teams gehen davon aus, dass der Anbieter Passwörter maskiert; Freitextfelder, versteckte Felder, Autocomplete, kundenspezifische Komponenten oder mobile Bildschirme umgehen die Regeln jedoch.

Drittens ist Replay-Zugriff zu breit. Produkt, Engineering, Support und Customer Success haben alle Dashboard-Zugriff, aber es gibt keine geschäftliche Begründung, keine regelmäßige Überprüfung und keine Auswertung der Audit-Protokolle.

Viertens sind Standardwerte für die Aufbewahrung übermäßig lang. Rohaufzeichnungen von Sitzungen werden monatelang aufbewahrt, weil die Anbietervoreinstellung nie geändert wurde, obwohl der Wert für die Fehlersuche schnell abnimmt.

Fünftens hinken Lieferantenverträge der Nutzung hinterher. Der Anbieter wurde als Tool für Produktanalysen onboarded, später wurden jedoch Replay, KI-Zusammenfassungen, Support-Integrationen oder Datenexporte ohne aktualisierte Datenschutzprüfung aktiviert.

Sechstens sind Datenschutzhinweise generisch. Sie erwähnen Analysen, aber nicht Verhaltens-Replay, Gerätekennungen, Empfänger, Aufbewahrung oder Wahlmöglichkeiten der Nutzer.

Siebtens umgehen Produktänderungen das DSFA-Screening. Neue SDK-Funktionen werden über Konfigurationsschalter aktiviert, nicht über Beschaffung, sodass Datenschutz- und Sicherheitsteams die Änderung nie sehen.

Die Clarysec-Lösung besteht nicht darin, Telemetrie zu verbieten. Sie besteht darin, ein schlankes, aber verbindliches Kontrollgate für Telemetrieänderungen aufzubauen.

Praktische Checkliste für Telemetrie-Governance

Verwenden Sie diese Checkliste vor Aktivierung, Erweiterung oder Verlängerung von Produkttelemetrie, mobilen Analysen, Crash-Reporting, Heatmaps oder Session Replay.

Verknüpfen Sie die Checkliste mit den Schritten des Zenith Blueprint: Schritt 9 für Asset-Identifizierung, Schritt 19 für Nachweise zu Löschung, Maskierung und DLP sowie Schritt 23 für PII-Schutz in der Praxis. Nutzen Sie anschließend Zenith Controls, um ISO/IEC 27002:2022-Maßnahmen 5.34, 5.23, 5.19, 8.11, 5.15, 5.16, 5.8 und 8.32 abzubilden, sodass dieselben Nachweise Gespräche zu GDPR, ISO 27701:2025 PIMS, ISO/IEC 27001:2022 ISMS, NIST CSF, NIS2 und DORA unterstützen.

Die Botschaft an das Leitungsorgan: Telemetrie ist eine Vertrauenskontrolle

Produkttelemetrie schafft für Organisationen echten Wert. Sie hilft Teams, defekte Workflows zu beheben, Barrierefreiheit zu verbessern, Supportaufwand zu reduzieren, Abstürze zu erkennen, Entwicklungsarbeit zu priorisieren und Kundenergebnisse zu verstehen. Session Replay kann jedoch auch zu einer Überwachungsschicht werden, wenn es unsichtbar, übermäßig oder schlecht abgesichert ist.

Für CISOs und Compliance-Verantwortliche ist die Botschaft an das Leitungsorgan einfach: Telemetrie ist nicht nur eine Fähigkeit zur Produktoptimierung. Sie ist eine Vertrauenskontrolle. Gut gesteuert verbessert sie die Servicequalität und respektiert zugleich die Privatsphäre. Schlecht gesteuert erzeugt sie undokumentierte Überwachung, unkontrolliertes Lieferantenrisiko und vermeidbare Exponierung bei Datenschutzverletzungen.

NIS2 bekräftigt die Rechenschaftspflicht des Managements für Cybersicherheitsrisikomanagement. DORA stellt IKT-Drittparteien- und Resilienz-Governance für Finanzunternehmen in den Mittelpunkt. GDPR legt Rechenschaftspflicht auf den Verantwortlichen. ISO 27701:2025 hilft, Datenschutzrollen, Datensätze, Hinweise, DSFA und Governance für Auftragsverarbeiter zu operationalisieren. ISO/IEC 27001:2022 stellt den ISMS-Rahmen für Risiko, Verantwortlichkeit, Kontrollen und Nachweise bereit.

Clarysec führt diese Elemente durch Richtlinien, Register, den Zenith Blueprint und Zenith Controls zusammen.

Telemetrie vor dem nächsten Release auditbereit machen

Wenn Ihre Organisation Produktanalysen, Session Replay, Crash-Reporting, Heatmaps, mobile Telemetrie oder Support-Bildschirmaufzeichnungen nutzt, beginnen Sie mit einer Frage: Können Sie nachweisen, was erfasst wird, warum, auf welcher Rechtsgrundlage, wie lange, durch wen, über welchen Lieferanten und mit welcher Maskierung?

Nutzen Sie den Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, um Telemetrie-Assets zu inventarisieren, Maskierungs- und Löschkontrollen zu prüfen und Lieferanten-Governance zu bewerten. Nutzen Sie Zenith Controls: The Cross-Compliance Guide Zenith Controls, um Datenschutz-, Cloud-, Maskierungs-, Zugriffs- und Lieferantenkontrollen über Rahmenwerke hinweg abzubilden. Verwenden Sie die PIMS-Richtlinien von Clarysec, einschließlich der PII Processing Inventory and Lawful Basis Policy, Privacy Risk Assessment and DPIA Policy, Privacy by Design and Default Policy, Privacy Notice and Transparency Policy und Processor, Subprocessor and Third-Party Privacy Management Policy, um jeden Telemetrie-Workflow nachvollziehbar zu machen.

Führen Sie vor dem nächsten produktiven SDK-Schalter eine Prüfung der Datenschutz-Governance für Telemetrie durch. Ihr Produktteam erhält weiterhin Erkenntnisse, aber Ihre Auditoren, Kunden und Nutzer erhalten etwas Wertvolleres: Nachweise für Vertrauen.