Artikel 7 Absatz 1 des GDPR besagt, dass, wenn die Verarbeitung auf einer Einwilligung beruht, ein für die Datenverarbeitung Verantwortlicher in der Lage sein muss, nachzuweisen, dass diese Einwilligung tatsächlich von der betroffenen Person gegeben wurde. Dies klingt einfach, kann aber schwierig sein, wenn die Einwilligung in einem Kontext eingeholt wird, in dem die betroffene Person nicht leicht zu identifizieren ist: Wenn wir zum Beispiel Besucher unserer Website fragen, ob wir ihre persönlichen Daten sammeln und verarbeiten dürfen, wie können wir dann nachweisen, dass sie tatsächlich eingewilligt haben?

Um dies zu beantworten, müssen wir darüber nachdenken, wie wir Besucher auf unserer Website identifizieren könnten. Im Allgemeinen können Personen, die unsere Website zum ersten Mal öffnen, für uns als anonym angesehen werden, da wir keine Möglichkeit haben, sie zu identifizieren oder zu wissen, ob sie unsere Website schon einmal besucht haben (es sei denn, wir greifen auf unethische und illegale Techniken wie das Browser-Fingerprinting zurück, was wir natürlich nicht tun werden). Um zu messen, wie gut unsere Website funktioniert, möchten wir vielleicht eine Kennung in den Browsern unserer Besucher platzieren, so dass wir sie wieder identifizieren können, wenn sie durch unsere Website navigieren oder sie zu einem späteren Zeitpunkt erneut besuchen. Es gibt verschiedene Möglichkeiten, dies zu erreichen, die beliebteste ist das Setzen eines Browser-Cookies: Unser Webserver oder jedes Skript, das auf unserer Website läuft, kann den Browser unserer Besucher anweisen, ein solches Cookie zu speichern, damit wir es beim nächsten Öffnen einer Seite auf unserer Website wieder abrufen können. Drittanbieterdienste wie Google Analytics verwenden solche Cookies z.B., um dauerhafte Benutzer-IDs zu speichern, die sie mit Ereignisdaten unserer Besucher an ihr Backend gesendet haben, wodurch sie Seitenbesuche mit bestimmten Benutzern verknüpfen können.

Nun, auf einer typischen Website können Besucher ihre persönlichen Daten von mehreren Dritten verarbeiten lassen, wobei jeder seine eigenen, auf Cookies basierenden Identifikatoren verwendet. Um nachzuweisen, dass die Einwilligung korrekt eingeholt wurde, verlangt das GDPR, dass wir die Aufzeichnungen über die Einwilligung der Besucher in einem robusten Zusammenhang mit all diesen Verarbeitungsaktivitäten aufbewahren. Lassen Sie uns also analysieren, wie wir das tun könnten!

Zustimmungsaufzeichnungen für die Verarbeitung kurzlebiger Daten

Wenn die einzigen identifizierenden Informationen, die wir oder unsere Datenverarbeiter über unsere Website-Besucher haben, die in den Cookies ihrer Browser gespeicherten Kennungen sind, könnten wir einfach auch Informationen über ihre Zustimmung in einem Cookie (oder einem ähnlichen Speichermechanismus) speichern. Auf diese Weise werden die Einverständniserklärungen zusammen mit den anderen Identifikatoren, die wir und unsere Datenverarbeiter im Browser der Besucher gespeichert haben, robust gespeichert. Damit wird die Anforderung der GDPR erfüllt, dass die Einwilligungsdatensätze mit den von ihnen geregelten Verarbeitungsaktivitäten verknüpft werden müssen. Da wir die Datensätze jedoch auf der Client-Seite speichern, müssen wir auch sicherstellen, dass sie nicht leicht manipuliert werden können. Dies kann z.B. dadurch erreicht werden, dass die Datensätze vor der Speicherung über eine API kryptografisch signiert werden.

Clientseitige Speicherung im Vergleich zu Serviceseitige Speicherung

Die meisten anderen CMPs speichern Einverständniserklärungen immer in einem Backend (was erhebliche Kosten und Anstrengungen verursacht und nicht sehr datenschutzfreundlich ist). Wir glauben nicht, dass dies für die meisten kurzlebigen Datenverarbeitungsaktivitäten notwendig ist, da die Speicherung von Einverständniserklärungen direkt auf der Client-Seite in diesen Fällen die gleiche Sicherheit bietet wie die Speicherung in einem Backend. Und das ist der Grund:

• Bei kurzlebigen Datenverarbeitungsaktivitäten wie Website-Analysen können wir Besucher nur über die Informationen identifizieren, die in ihren Browsern gespeichert sind.
• Wenn wir einen Einverständnisdatensatz für diese Aktivitäten in einem Backend speichern, müssen wir ihn immer noch mit den Besuchern und ihren Identifikatoren, die in ihren Browsern gespeichert sind, verknüpfen. Dies können wir z.B. erreichen, indem wir dem Datensatz eine eindeutige ID zuweisen und diese ID in einem Browser-Cookie speichern.
• Wenn Besucher ihre Browser-Cookies löschen (einschließlich desjenigen, der unsere Einwilligungsdatensatz-ID enthält), haben wir keine Möglichkeit mehr, den Datensatz plausibel mit einem bestimmten Besucher oder einer bestimmten Datenverarbeitungsaktivität in Verbindung zu bringen, was ihn effektiv nutzlos macht.
• Da der Einwilligungsdatensatz nur in Verbindung mit den im Browser gespeicherten Daten nützlich ist, können wir ihn auch direkt dort speichern.
• Wir können die Einwilligungserklärung des Kunden manipulationssicher machen, indem wir sie kryptografisch signieren, was die gleiche Sicherheit bietet wie die Speicherung in einem Backend.
• Weder die clientseitige noch die backendbasierte Speicherung von Einwilligungsaufzeichnungen schützt uns vor Besuchern, die diese Aufzeichnungen absichtlich löschen oder Kennungen aufzeichnen.

Wie Sie sehen, bietet bei kurzlebigen Datenverarbeitungsaktivitäten die Speicherung von kryptografisch signierten Einwilligungsdatensätzen direkt im Browser die gleiche Sicherheit, die wir bei der Speicherung in einem Backend erhalten würden. Das einzige Szenario, in dem die Backend-Speicherung einen Vorteil bieten könnte, ist, wenn wir zusätzliche (Quasi-)Identifikatoren mit den Datensätzen verknüpfen würden. Einige CMPs speichern z.B. die IP-Adressen von Besuchern in den Datensätzen, in der Hoffnung, dass dies eine zusätzliche Möglichkeit bietet, sie mit anderen Verarbeitungsaktivitäten zu verknüpfen. Wir halten dies für eine zweifelhafte Praxis, da die Speicherung von IP-Adressen nicht datenschutzfreundlich ist und die Verknüpfung mit Verarbeitungsaktivitäten Dritter erfordern würde, dass diese Dienste auch die IP-Adressen der Besucher speichern. Dies wäre aus der Sicht des Datenschutzes höchst problematisch, da dadurch dauerhaft identifizierbare Daten entstehen könnten, die nicht wirksam kontrolliert werden können. Darüber hinaus anonymisieren" Dienste wie Google Analytics IP-Adressen, indem sie die letzten 8 (oder mehr) Bits aus ihnen entfernen. Selbst wenn wir also die vollständige IP-Adresse in einem Einwilligungsdatensatz speichern würden, könnten wir sie nicht effektiv mit den meisten Verarbeitungsdaten Dritter in Verbindung bringen. Ebenso wäre die Speicherung "anonymisierter" IP-Adressen in unseren Einwilligungsdatensätzen ebenso nutzlos, da sie uns keine robuste Möglichkeit bietet, unsere Einwilligungsdatensätze mit anderen Verarbeitungsaktivitäten zu verknüpfen. Die einzige Möglichkeit, im Backend gespeicherte Einwilligungsdatensätze mit Verarbeitungsdaten Dritter zu verknüpfen, wäre die Speicherung der Identifikatoren Dritter (wie z.B. der Google Analytics-Benutzer-ID) ebenfalls in den Datensätzen. Sie könnten dies in Erwägung ziehen, aber wir raten auch davon ab, wenn es sich um eine kurzlebige Datenverarbeitung handelt, da unserer Meinung nach die Risiken für den Datenschutz, die eine solche zentralisierte Speicherung von Identifikatoren mit sich bringt, die Vorteile bei weitem überwiegen. Deshalb empfehlen wir, Einverständniserklärungen für kurzlebige Verarbeitungsaktivitäten als kryptographisch signierte Daten direkt auf der Client-Seite zu speichern: Es ist datenschutzfreundlich, hält die Aufzeichnungen in enger Verbindung mit den Verarbeitungsaktivitäten, die sie regeln, und bietet die gleichen Garantien wie eine Backend-basierte Speicherlösung. Wenn Sie unbedingt eine zusätzliche Kopie Ihrer Aufzeichnungen in einem Backend speichern müssen, können Sie dies natürlich tun, denken Sie jedoch daran, dass diese Aufzeichnungen nur dann nützlich sind, wenn sie mit den Verarbeitungsaktivitäten, die sie regeln, verknüpft werden können.

Zustimmungsaufzeichnungen für die Verarbeitung langlebiger Daten

Wenn wir andererseits Besucher mit langlebigen Identifizierungsmerkmalen - wie einer dauerhaften Benutzer-ID oder E-Mail-Adresse - identifizieren und diese auch Dritten zur Verfügung stellen, müssen wir sicherstellen, dass unsere Einverständniserklärungen ebenfalls ordnungsgemäß mit diesen Identifizierungsmerkmalen verknüpft werden. Nehmen wir zum Beispiel an, wir möchten das Verhalten eingeloggter Benutzer unserer Webanwendung analysieren: Zu diesem Zweck ermöglichen uns Tools wie Segment oder Google Analytics, ihre internen Identifikatoren mit unseren eigenen zu verknüpfen: Wir könnten z.B. die Google Analytics-Daten von eingeloggten Nutzern mit eindeutigen IDs verknüpfen, die wir in unserem Backend für diese Nutzer speichern. Wenn wir das tun, werden die Analysedaten dieser Nutzer, die zuvor pseudonymisiert waren, dauerhaft mit diesen IDs verknüpft. Um die Einwilligung in diesem Szenario ordnungsgemäß zu dokumentieren, müssen wir daher auch die Einwilligungsdatensätze dauerhaft mit unseren internen Benutzer-IDs verknüpfen und sie mindestens so lange aufbewahren, wie wir oder unsere Datenverarbeiter die mit den Benutzern verbundenen Daten aufbewahren. Die Speicherung der Einwilligungsdatensätze auf der Client-Seite reicht in diesem Fall nicht mehr aus, da die Benutzer dort Datensätze löschen könnten, während ihre Daten noch verarbeitet werden, so dass wir nicht mehr nachweisen können, dass sie in diese Datenverarbeitung eingewilligt haben. Daher sollten Aufzeichnungen, die mit langlebigen Identifikatoren verbunden sind, immer in einer Backend-Infrastruktur aufbewahrt und ordnungsgemäß mit allen langlebigen Identifikatoren verknüpft werden. Die meisten Zustimmungsverwaltungsplattformen (CMP) setzen dies nicht korrekt um, da sie es oft nicht erlauben, Zustimmungsdatensätze mit Benutzer-Identifikatoren so zu verknüpfen, dass die Datensätze korrekt mit Verarbeitungsaktivitäten verknüpft werden.

Unser Ansatz

Bei der Entwicklung der Einverständniserklärungsfunktionalität für Klaro! achteten wir darauf, alle GDPR-Anforderungen zu berücksichtigen und über das hinauszugehen, was die meisten anderen CMPs bieten. Unser Ansatz funktioniert wie folgt:

• Für kurzlebige Datenverarbeitungsaktivitäten, die auf pseudonymen Identifikatoren beruhen, die auf dem Client erzeugt werden (z.B. zufällige Benutzer-IDs, die in Browser-Cookies gespeichert werden), und die Daten erzeugen, die nach dem Löschen dieser Pseudonyme effektiv anonym werden, speichern wir Einwilligungsdatensätze zusammen mit diesen Identifikatoren beim Client. Um sicherzustellen, dass es nicht zu Manipulationen kommen kann, signieren wir sie kryptografisch mit einem Zeitstempel und einem authentifizierten Hash über unsere API. Für Kunden, die diese Aufzeichnungen wirklich in einem Backend aufbewahren möchten (was unserer Meinung nach nicht notwendig ist), bieten wir diese Option ebenfalls an.
• Für langlebige Datenverarbeitungsaktivitäten, die sich auf permanente Identifikatoren stützen, wie z.B. Benutzer-IDs, die in Ihrem eigenen Backend gespeichert sind, E-Mail-Adressen oder jede andere Art von permanenten persönlichen Informationen, ermöglichen wir Ihnen, Zustimmungsdatensätze über einen Token-Mechanismus robust mit diesen Identifikatoren zu verknüpfen: Wenn sich ein Benutzer in Ihre Webanwendung oder Website einloggt, erstellen Sie zunächst über unsere API einen Benutzerdatensatz, in dem Sie Informationen speichern, die Sie benötigen, um diesen Benutzer mit allen relevanten Identifikatoren zu verknüpfen (dies könnte z.B. eine interne, undurchsichtige ID sein, die einen Einwilligungsdatensatz mit einem Benutzereintrag in Ihrer eigenen Backend-Datenbank verknüpft). Unsere API stellt Ihnen dann ein kryptografisches Token zur Verfügung, das mit den erstellten Benutzerdaten verknüpft ist und das Sie sicher an Ihr Frontend weiterleiten können. Wenn Ihre Benutzer ihre Zustimmung über Klaro! im Frontend erteilen oder verweigern, wird dieses Token an das Klaro! API weitergeleitet, die es verwendet, um den neu erstellten Einverständnisdatensatz mit den Benutzerdaten zu verknüpfen, die Sie zuvor erstellt haben. Sie können dann den Einwilligungsdatensatz unter Verwendung der sicher bereitgestellten Benutzerdaten nachschlagen und sicherstellen, dass er robust mit allen von Ihnen verwendeten internen Kennungen verknüpft ist, ohne dass Sie uns sensible Benutzerdaten zur Verfügung stellen müssen.

Zusammenfassung

Zusammenfassend lässt sich sagen, dass wir bei der Speicherung von Einwilligungsdatensätzen sicherstellen müssen, dass sie in einem robusten Zusammenhang mit den betroffenen Personen und den von uns durchgeführten Verarbeitungsaktivitäten stehen. Wie wir gesehen haben, bedeutet dies nicht automatisch die Speicherung dieser Aufzeichnungen in einer Backend-Infrastruktur: Wenn wir kurzlebige Daten sammeln, die nur an pseudonyme Identifikatoren gebunden sind, die in Client-Geräten, wie z.B. Browsern, gespeichert sind, und wenn wir über keine anderen Mittel verfügen, um Personen in diesen Daten zu identifizieren, als diese gleichen Identifikatoren zu verwenden, ist es datenschutzfreundlicher, die Einwilligungsdatensätze ebenfalls direkt in den Client-Geräten zu speichern. Wenn wir jedoch dauerhaftere Identifikatoren in unserer Datenverarbeitung verwenden, müssen wir sicherstellen, dass die Einwilligungsdatensätze auch langlebig und robust mit diesen Identifikatoren verknüpft sind, was es oft notwendig macht, sie in einer Backend-Infrastruktur zu speichern. Klaro! unterstützt diese beiden Anforderungen mit einem Einverständnisprotokoll-Mechanismus, der die Einhaltung der Vorschriften gewährleistet und standardmäßig auf den Datenschutz ausgerichtet ist.