GDPR für URL-Shortener: was dein DPO tatsächlich sehen will

Ich habe vier Jahre damit verbracht, SaaS Data Processing Agreements von der Anbieterseite zu prüfen, und ein Jahr damit, sie aus dem Stuhl eines Fintech-Käufers zu prüfen. Die Klauseln, über die sich alle Sorgen machen - Verschlüsselung at-rest, Aufbewahrungsfenster, das Breach-Notification-SLA - sind bei einem ernsthaften Shortener in der Regel in Ordnung. Die Klauseln, die über die Beschaffung tatsächlich entscheiden, sind subtiler. Es sind die, über die der DPO oft genug gelesen hat, um eine Meinung zu haben, und die ein generisches "GDPR compliant"-Abzeichen nicht adressiert.

Dieser Post ist die Lesart eines arbeitenden DPO darüber, was die GDPR von einem URL-Shortener verlangt, der Klickdaten zu EU-Betroffenen verarbeitet, mit Artikelnummern als Belegstellen, damit du die Aussagen zu deinem eigenen Counsel mitnehmen und verifizieren kannst. Ich werde markieren, wo Elidos Haltung konservativ ist, wo sie Industriestandard ist, und wo der vernünftige Käufer trotzdem ein Addendum einfordern sollte.

Die Artikelverweise gehen auf die Regulation (EU) 2016/679 - den konsolidierten GDPR-Text auf EUR-Lex. Wo ich Leitlinien einer Aufsichtsbehörde zitiere, verlinke ich auf die Originalentscheidung. Wo ich Rechtsprechung zitiere, ist die Belegstelle das CJEU-Urteil.

Warum ein URL-Shortener überhaupt im Anwendungsbereich liegt

Ein URL-Shortener ist Auftragsverarbeiter nach Artikel 4(8), wenn er Klickdaten über identifizierbare natürliche Personen im Auftrag des Kunden verarbeitet. Der Kunde ist der Verantwortliche; er entscheidet, warum die Daten erhoben werden (Kampagnen-Attribution) und auf welcher Grundlage (Artikel 6 - typischerweise berechtigtes Interesse nach 6(1)(f) für Klick-Level-Analytics, Einwilligung nach 6(1)(a), wo granulares Tracking betroffen ist). Der Shortener ist der Auftragsverarbeiter; er verarbeitet diese Daten nur auf dokumentierte Weisung des Verantwortlichen, was die Substanz von Artikel 28 ist.

Zwei Datenstücke machen das klar. Jeder Redirect protokolliert eine IP-Adresse; der CJEU hat seit Breyer (C-582/14, 2016) festgestellt, dass dynamische IP-Adressen personenbezogene Daten sein können, wenn sie mit Informationen kombiniert werden, die dem Verantwortlichen zur Verfügung stehen. Jeder Redirect protokolliert außerdem einen User-Agent, der in Kombination mit IP und Zeitstempel in vielen High-Traffic-Mustern ausreicht, um Individuen herauszulösen - der EDPB hat das in Guidelines 04/2020 zur Nutzung von Standortdaten markiert, und das Prinzip generalisiert.

Also: ein URL-Shortener verarbeitet personenbezogene Daten von EU-Betroffenen, auch wenn das Klick-Event selbst auf den ersten Blick anonym aussieht. Die Fragen ergeben sich daraus.

Artikel 3: territorialer Anwendungsbereich

Artikel 3 ist der Artikel, der von US-basierten Anbietern, die in die EU verkaufen, am häufigsten missverstanden wird.

Artikel 3(1) erfasst die Verarbeitung im Rahmen einer EU-Niederlassung. Artikel 3(2) erfasst die Verarbeitung von EU-Betroffenendaten durch einen Nicht-EU-Verantwortlichen oder -Auftragsverarbeiter, wenn die Verarbeitung sich auf (a) das Anbieten von Waren oder Dienstleistungen an EU-Betroffene oder (b) das Beobachten ihres Verhaltens in der EU bezieht. Klick-Tracking auf EU-Nutzern ist Beobachtung; die GDPR gilt, unabhängig davon, wo der Shortener gehostet ist.

Die Konsequenz: "wir sind ein US-Unternehmen, die GDPR gilt nicht" ist falsch. Jeder Shortener, der Klicks von EU-Nutzern verarbeitet, muss compliant sein. Die für die Beschaffung relevante Frage ist nicht, ob die GDPR gilt - sie tut es -, sondern wie der Anbieter Compliance nachweist und welche Residenz-Verpflichtungen vertraglich bindend sind. Für diese Frage, durchgespielt an einem konkret genannten Anbieter, siehe ob Bitly GDPR-konform ist.

Artikel 6: Rechtsgrundlage

Klick-Tracking über einen Shortener stützt sich typischerweise auf eine von drei Rechtsgrundlagen.

6(1)(a) - Einwilligung. Der Verantwortliche hat die Einwilligung der betroffenen Person für die Verarbeitung eingeholt. Für Shortener-Level-Klick-Tracking wird Einwilligung in der Regel in das Cookie-Banner oder den Marketing-Opt-in-Flow auf der Zielseite eingebettet. Die EDPB-Leitlinien zur Einwilligung (Guidelines 05/2020, Version 1.1, 2020) verlangen eine freiwillige, spezifische, informierte und unmissverständliche Einwilligung. Wann diese Einwilligung für einen Kurzlink tatsächlich erforderlich ist und wann eine reine Weiterleitung ganz ohne Banner auskommt, ist eine eigene Frage, die in Cookie-Einwilligung für Kurzlinks durchgespielt wird.

6(1)(b) - erforderlich für die Vertragserfüllung. Der Redirect selbst - den Klick entgegenzunehmen und zum Ziel zu routen - ist erforderlich für den Dienst, den der Nutzer angefragt hat. Die sauberste Trennung ist, dass das Routing Vertragserfüllung ist, während die Analytics-Schicht (ob dieser Klick für eine retrospektive Auswertung erfasst wird) eine separate Verarbeitungsoperation ist, die möglicherweise eine andere Grundlage braucht.

6(1)(f) - berechtigtes Interesse. Die meisten B2B-Kunden gründen kampagnenweite Analytics auf berechtigtem Interesse, nachdem sie eine Legitimate Interest Assessment (LIA) durchgeführt haben. Die LIA wägt das Interesse des Verantwortlichen an der Messung der Marketing-Effektivität gegen die Interessen der betroffenen Person ab; für aggregierte Klickzahlen und Standard-Attribution kippt die Abwägung in der Regel zugunsten des Verantwortlichen. Für hochauflösendes Verhaltensprofiling - Fingerprinting, seitenübergreifendes Tracking, Retargeting auf Personen-Ebene - wird die LIA schwieriger.

Der Shortener ist in allen drei Fällen der Auftragsverarbeiter. Er verarbeitet die Daten auf dokumentierte Weisung des Verantwortlichen. Er wählt die Rechtsgrundlage nicht aus; das tut der Verantwortliche.

Artikel 28: der Auftragsverarbeitungsvertrag

Artikel 28(3) listet die acht Verpflichtungen auf, die jeder Vertrag zwischen einem Verantwortlichen und einem Auftragsverarbeiter enthalten muss. Lies es direkt; die Unterabsätze (a) bis (h) sind kurz und konkret. Ein brauchbares DPA für einen URL-Shortener muss jeden davon adressieren.

Ich gehe durch, wie diese Klauseln in der Praxis aussehen.

(a) Verarbeitung nur auf dokumentierte Weisung. Die Weisungen des Verantwortlichen sind der Vertrag plus die schriftlichen Anweisungen des Kunden pro Feature (z. B. "Klick-Events für diese Workspaces verarbeiten, X Monate aufbewahren"). Der Shortener darf Klickdaten nicht ohne Weisung des Verantwortlichen für eigene Zwecke verwenden. In der Praxis heißt das: keine Verwendung von Kunden-Klickdaten zum Trainieren interner Recommendation-Modelle ohne Opt-in, keine an Dritte weitergegebenen Aggregat-Analytics ohne Ankündigung. Elidos Standard-DPA ist hier explizit; falls dein bestehender Shortener-DPA das nicht ist, frag warum.

(b) Vertraulichkeit. Personen, die die Daten verarbeiten, unterliegen Vertraulichkeitsverpflichtungen. Das ist auf Anbieterseite operativ und selten umstritten.

(c) Sicherheitsmaßnahmen (Artikel 32). Unten in einem eigenen Abschnitt behandelt.

(d) Einbindung von Sub-Processors. Der Auftragsverarbeiter zieht Sub-Processors nur mit Autorisierung des Verantwortlichen hinzu, und der Sub-Processor muss gleichwertige Pflichten unter einem schriftlichen Vertrag akzeptieren. Es gibt zwei Ausprägungen der Autorisierung. Spezifische vorherige Autorisierung verlangt, dass der Verantwortliche jedem neuen Sub-Processor zustimmt. Allgemeine vorherige Autorisierung verlangt nur eine vorherige Ankündigung mit Widerspruchsrecht. Die meisten SaaS-Verträge nutzen allgemeine Autorisierung mit einem 30-Tage-Vorankündigungsfenster. Beides ist nach Artikel 28 in Ordnung; wichtig ist, dass der Vertrag spezifiziert, welches.

(e) Unterstützung bei Betroffenenrechten. Der Auftragsverarbeiter muss dem Verantwortlichen helfen, auf Anfragen nach Betroffenenrechten nach Artikeln 15-22 zu reagieren. Für einen Shortener heißt das: der Verantwortliche kann nach einem Klick-Datensatz-Export verlangen, der nach einem spezifischen Identifier verschlüsselt ist (selten, aber kommt vor), und der Shortener muss in der Lage sein, ihn zu liefern. Die Elido-API enthält GET /v1/clicks?subject_id= für diesen Zweck; falls dein Bestandsanbieter das nicht hat, beantwortest du Auskunftsersuchen manuell.

(f) Unterstützung nach Artikel 32 / 33 / 34 / 35 / 36. Der Auftragsverarbeiter muss dem Verantwortlichen helfen, Sicherheits-, Breach-Notification- und DPIA-Pflichten zu erfüllen. Die "Hilfe" ist operativ - Bereitstellung von Sicherheitsaudit-Berichten, Benachrichtigung von Vorfällen innerhalb eines SLA, Lieferung der für eine DPIA benötigten technischen Details.

(g) Rückgabe oder Löschung am Ende der Dienste. Wenn der Vertrag endet, gibt der Auftragsverarbeiter alle personenbezogenen Daten zurück oder löscht sie, sofern Unions- oder mitgliedstaatliches Recht nicht eine Speicherung verlangt. Elidos Standardklausel sind 30 Tage nach Beendigung, mit einem auf Anfrage dokumentierten Löschzertifikat.

(h) Audit-Rechte. Der Auftragsverarbeiter muss alle Informationen bereitstellen, die zum Nachweis der Compliance erforderlich sind, und Audits unterzogen werden können. SaaS-Verträge engen das auf schriftliche Audit-Fragebogen plus Vor-Ort-Audits mit angemessener Vorlaufzeit ein; volle uneingeschränkte Audit-Rechte sind außerhalb von Enterprise-Verträgen ungewöhnlich.

Wenn das DPA deines Bestandsanbieters bei einem von (a)-(h) fehlt oder vage ist, sollte das Beschaffungsgespräch nicht weitergehen. Ein DPA, das Artikel 28 erfüllt, ist die Untergrenze, nicht die Obergrenze.

Artikel 30: Verzeichnis der Verarbeitungstätigkeiten

Artikel 30 verlangt von Auftragsverarbeitern, ein Verzeichnis der Verarbeitungstätigkeiten (RoPA) zu führen. Das RoPA des Auftragsverarbeiters ist das verantwortlichengewandte Artefakt, das deinem DPO erlaubt zu verstehen, was der Shortener mit den Daten tut.

Elido veröffentlicht eine pro-Kunde-RoPA-Vorlage, die du auf deine eigene mappen kannst. Die Spalten sind Kategorien betroffener Personen, Kategorien personenbezogener Daten, Empfänger, Übermittlungen in Drittländer (standardmäßig keine), Aufbewahrung und Sicherheitsmaßnahmen. Schablonenhaft, aber Beschaffungsteams wollen sie konkret ausgefüllt sehen. Der DPO will keinen Platzhalter. Wenn dein Shortener dir das nicht liefert, fällt die Last auf dich, sie aus seiner Dokumentation zusammenzustellen.

Artikel 32: Sicherheit der Verarbeitung

Artikel 32 verlangt "geeignete technische und organisatorische Maßnahmen", um ein dem Risiko angemessenes Sicherheitsniveau sicherzustellen. Der Artikel ist absichtlich nicht präskriptiv; die Aufsichtsbehörden füllen ihn über Leitlinien aus.

Für einen URL-Shortener: der operative Mindeststandard, auf den die meisten DPOs schauen werden:

• TLS 1.3 im Transit, kein Fallback auf TLS 1.0 oder 1.1.
• Verschlüsselung at-rest für den Klick-Event-Store, mit dokumentierter Schlüsselrotation.
• Netzwerksegmentierung zwischen Redirect-Ebene und Analytics-Ebene.
• Authentifizierung via SSO/SAML oder OIDC für die kundenseitige Oberfläche; Service-to-Service via kurzlebige Credentials.
• Ein Audit-Log administrativer Aktionen auf der Shortener-Seite, mindestens 12 Monate aufbewahrt.
• Dokumentiertes Incident-Response und regelmäßige Tabletop-Übungen.
• ISO 27001-Zertifizierung oder gleichwertige unabhängige Bescheinigung.

Elido ist ISO 27001-zertifiziert und mitten in SOC 2 Type II (Ziel H2 2026). Die technische Kontrollfläche ist auf der Trust-Seite dokumentiert. Für HIPAA-relevanten Traffic sind BAAs im Business-Plan verfügbar.

Der Wortlaut auf Artikelebene zählt hier: "angemessen zum Risiko" ist ein relativer Maßstab. Ein Shortener, der Kampagnen-Klicks auf einer öffentlichen Marketing-Seite verarbeitet, ist risikoärmer als einer, der intern zum Teilen authentifizierter Session-URLs verwendet wird. Dein DPO sollte auf das Risiko dimensionieren, das du tatsächlich fährst.

Artikel 35: DPIA

Artikel 35 verlangt eine Datenschutz-Folgenabschätzung für Verarbeitungen, die "voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen zur Folge haben", mit besonderem Augenmerk auf (a) systematische und umfangreiche Bewertung, (b) besondere Kategorien von Daten und (c) systematische Beobachtung öffentlich zugänglicher Bereiche im großen Maßstab.

Für die meisten Shortener-Anwendungsfälle ist eine DPIA nicht zwingend erforderlich - Kampagnen-Klick-Tracking auf einer Marketing-Seite ist keine "systematische und umfangreiche Bewertung" im Sinne von 35(3)(a). Wo eine DPIA dennoch ratsam wird:

• Cross-Site-Verhaltensprofiling auf Individuumsebene.
• Tracking, das Shortener-Daten mit anderen personenbezogenen Daten kombiniert (CRM-Anreicherung, Drittanbieter-Daten-Broker), um ein Personenprofil zu bauen.
• Verwendung von Klickdaten, um Entscheidungen mit rechtlichen oder ähnlich erheblichen Auswirkungen auf die betroffene Person zu treffen (selten, aber denkbar im Kredit- oder Beschäftigungskontext).
• Hohes Traffic-Volumen aus besonderen Kategorien-Kontexten (Gesundheit, Religion, politische Meinung).

Wenn du eine DPIA für shortener-bezogene Verarbeitung in Auftrag gibst, sind die WP29-Leitlinien (WP248 rev.01) die methodische Referenz; viele Aufsichtsbehörden haben eigene Vorlagen veröffentlicht, einschließlich der PIA-Software der CNIL.

Artikel 28(2): Sub-Processor-Offenlegung

Die einzelne handfesteste GDPR-Frage lautet "wer kommt sonst noch an die Daten?". Artikel 28(2) verlangt, dass der Auftragsverarbeiter jeden Sub-Processor offenlegt, den er einbindet, und eine Autorisierung erhält. In der Praxis veröffentlicht jeder ernsthafte SaaS-Anbieter eine Sub-Processor-Liste und einen Benachrichtigungsprozess für Neuzugänge.

Wie eine gute Liste aussieht:

• Name des Sub-Processors, Verarbeitungsort, Rolle.
• Kategorien geteilter personenbezogener Daten.
• Rechtsgrundlage für die Übermittlung (wo zutreffend).
• Datum, an dem der Sub-Processor hinzugefügt wurde.
• Benachrichtigungsmechanismus für Zugänge (typischerweise E-Mail + RSS/JSON-Feed).
• Widerspruchsrecht: üblich 30 Tage ab Benachrichtigung.

Elidos öffentliche Sub-Processor-Liste nennt fünf Anbieter. Diese Zahl ist absichtlich klein - jeder neue Sub-Processor erweitert die Angriffsfläche deines Privacy-Programms. Vergleiche mit dem Bestandsanbieter: wenn er 30 Sub-Processors hat und du nicht erkennen kannst, welche auf dem Klick-Event-Pfad liegen, ist das eine materielle Offenlegungsfrage.

Schrems II: wenn EU-Residenz vertraglich wird

Schrems II (CJEU C-311/18, 2020) hat den EU-US-Privacy-Shield ungültig gemacht und für internationale Datenübermittlungen unter SCCs eine Transfer Impact Assessment verlangt, die bewertet, ob das Überwachungsregime des Ziellandes EU-Betroffenen wirksamen Rechtsschutz verweigert.

Das Nachfolge-Framework - das EU-US Data Privacy Framework, angenommen via Commission Decision (EU) 2023/1795 - ersetzt für teilnehmende Organisationen den Privacy Shield. Zwei wichtige Vorbehalte:

• Die Teilnahme ist freiwillig; nicht jeder US-SaaS-Anbieter ist zertifiziert. Prüfe die DPF participant list.
• Das Framework selbst ist Gegenstand anhängiger Rechtsstreitigkeiten. NOYB hat eine Anfechtungsabsicht signalisiert und ein drittes Schrems-Urteil ist plausibel. Käufer, die umsichtig genug sind, für dieses Szenario zu planen, verlangen zunehmend vertraglich EU-only-Verarbeitung. Für die marktweite Version dieser Verschiebung siehe EU-Alternativen zu US-SaaS.

Wo das bei der Shortener-Auswahl landet: wenn dein Käufer Datenresidenz markiert hat oder deine Branchenregulierung EU-only-Verarbeitung verlangt (deutsche Gesundheit unter dem Sozialdatenschutz, französische Gesundheitsdaten via HDS-Zertifizierung, Finanzdienstleistungen unter EBA-Leitlinien), vereinfacht ein EU-gehosteter Shortener den Vertrag. Die Residenzklausel ist konkret, die TIA ist unnötig, und der Beschaffungszyklus verkürzt sich.

Elido wird standardmäßig in der EU-Region gehostet. Business+-Kunden können an US East oder Asien-Pazifik pinnen, wo ihr Traffic-Profil es verlangt. Das Pinning ist pro Workspace, vertraglich dokumentiert und operativ erzwungen - keine Marketing-Aussage.

Datenminimierung: was du nicht protokollieren musst

Artikel 5(1)(c) verlangt, dass die Verarbeitung "dem Zweck angemessen und erheblich sowie auf das für die Zwecke der Verarbeitung notwendige Maß beschränkt" ist. Für einen Shortener landet das auf dem Klick-Event-Schema.

Die Signale, die ein Shortener zum Redirect-Zeitpunkt erfassen kann:

• IP-Adresse (voll, /24 gekürzt oder gehasht).
• User-Agent-String (voll oder zu Client/OS geparst ohne die seltenen Tokens, die fingerprinten).
• Referrer.
• Zeitstempel.
• Geo abgeleitet von IP (Land, Stadt).
• Gerät abgeleitet von UA (Mobile/Desktop/Tablet, OS-Familie).
• Klick-ID (die eigene Kennung des Shorteners für das Event).

Davon benötigt der tatsächliche Zweck des Verantwortlichen üblicherweise das geparste Gerät, das Land, den Zeitstempel, die Klick-ID und möglicherweise den Referrer. Die IP-Adresse selbst wird über den Moment des Redirects hinaus selten gebraucht - sobald Geo- und Geräte-Parsing abgeschlossen sind, kann die IP gekürzt oder gehasht werden, bevor sie im Klick-Store landet. Dasselbe gilt für den UA: die geparsten Felder device.type / device.os sind das, was die Attribution tatsächlich verwendet; der volle UA-String ist Fingerprinting-Köder, der verworfen werden sollte.

Elido kürzt IPs auf /24 (IPv4) oder /48 (IPv6), bevor Klick-Events persistiert werden. Der volle UA wird geparst und verworfen. Beide Verhalten sind dokumentiert und pro Workspace konfigurierbar, falls dein spezifischer Anwendungsfall die höher aufgelösten Daten verlangt - aber der Default ist Minimierung, was die Artikel-5(1)(c)-Haltung by design ist, nicht by patch.

Betroffenenrechte auf der Shortener-Ebene

Der Verantwortliche bearbeitet Betroffenenrechtsanfragen; der Auftragsverarbeiter unterstützt. Für einen Shortener kommen zwei Anfragen vor:

Artikel 15 - Auskunftsrecht. Die betroffene Person fragt nach einer Kopie ihrer personenbezogenen Daten. Der Shortener muss Klick-Events abrufen können, die auf eine Subject-ID verschlüsselt sind. In der Praxis ist das schwierig, wenn die einzige ID "alle, die Link X von dieser IP geklickt haben" lautet. Die pragmatische Antwort: der Shortener exportiert die Klick-Events für die IP/den Zeitraum, den der Verantwortliche spezifiziert, und der Verantwortliche filtert auf die relevante Person.

Artikel 17 - Recht auf Löschung. Die betroffene Person fragt nach Löschung. Der Shortener muss Klick-Events auf Anfrage innerhalb des GDPR-Wortlauts "ohne unangemessene Verzögerung" löschen können - das operative SLA liegt standardmäßig bei 30 Tagen. Die Komplikation: Klick-Events werden üblicherweise in einer spaltenorientierten Append-only-Analytics-Datenbank (zum Beispiel BigQuery oder Snowflake) gespeichert. Löschung ist echt, aber es ist ein DELETE gegen die Partition, kein zeilenweiser Edit. Stell sicher, dass das DPA deines Shorteners sich auf ein konkretes Lösch-SLA verpflichtet und dass die zugrundeliegende Architektur es einhalten kann.

Elido unterstützt beides via API: GET /v1/subjects/{id}/clicks und DELETE /v1/subjects/{id}. Die Löschung wird innerhalb von 24 Stunden zum Klick-Event-Store propagiert und über Webhook bestätigt.

Was du im Procurement fragen solltest

Die komprimierte Checkliste für ein Beschaffungsgespräch:

1. Wo wird der Shortener gehostet? (Eine-Satz-Antwort; pin oder nicht.)
2. Ist das DPA vorab unterzeichnet oder pro Kunde verhandelt? (Vorab unterzeichnet ist schneller.)
3. Wie viele Sub-Processors? (Kleiner ist einfacher.)
4. Enthält der Standardvertrag EU-only-Verarbeitung, oder ist das ein separates Addendum?
5. Was ist die Default-IP-Truncation auf Klick-Events?
6. Gibt es einen Artikel-15-/17-Endpoint, oder läuft die Löschung über Support?
7. Was ist das Breach-Notification-SLA? (24 Stunden ab Kenntnis ist Industrie-Norm.)
8. Unabhängige Bescheinigung: ISO 27001? SOC 2 Type II? Wann war das letzte Audit?

Ein Anbieter, der diese acht im Discovery Call schriftlich beantworten kann, ist procurement-ready. Ein Anbieter, der das nicht kann, fügt deinem Sales-Zyklus Wochen hinzu.

Lies die Cornerstone-Serie

Dies ist der Cornerstone des compliance cluster. Geschwister-Posts im Cluster: der kommende EU data residency for marketing analytics (tiefer in den vertraglichen Spezifika), Schrems II and tracking pixels (die praktische Auswirkung auf die Attribution) und Click attribution after Safari ITP (die operative Konsequenz der cookielosen Welt). Für die beschaffungsgewandte Zusammenfassung sind die trust page und solutions/compliance die zwei Artefakte zum Bookmarken. Für das architektonische Detail hinter der Residenz-Behauptung geht the edge-redirect architecture doc durch, wie das regionale Pinning zum Routing-Zeitpunkt erzwungen wird.

Verwandt im Blog

• EU data residency for marketing tools: what your DPO actually asks
• Schrems II and tracking pixels: where the DPF leaves you in 2026
• Click attribution after Safari ITP: what still works in 2026
• SCIM and SSO for marketing tools: what enterprise IT actually asks
• Ist Bitly GDPR-konform? Die ehrliche Antwort eines Datenschutzbeauftragten
• EU-Alternativen zu US-SaaS: Ein Leitfaden zur digitalen Souveränität
• Ist Google Analytics GDPR-konform?
• Cookie-Einwilligung für Kurzlinks: Was die EU vorschreibt
• Digital Product Passport QR-Codes: Die EU-ESPR-Regeln
• QR Codes and GDPR: What a Scan Collects and What You Owe