Ich habe vier Jahre damit verbracht, SaaS Data Processing Agreements von der Anbieterseite zu pruefen, und ein Jahr damit, sie aus dem Stuhl eines Fintech-Kaeufers zu pruefen. Die Klauseln, ueber die sich alle Sorgen machen — Verschluesselung at-rest, Aufbewahrungsfenster, das Breach-Notification-SLA — sind bei einem ernsthaften Shortener in der Regel in Ordnung. Die Klauseln, die ueber die Beschaffung tatsaechlich entscheiden, sind subtiler. Es sind die, ueber 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 darueber, 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 vernuenftige Kaeufer 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 Aufsichtsbehoerde zitiere, verlinke ich auf die Originalentscheidung. Wo ich Rechtsprechung zitiere, ist die Belegstelle das CJEU-Urteil.
Warum ein URL-Shortener ueberhaupt im Anwendungsbereich liegt#
Ein URL-Shortener ist Auftragsverarbeiter nach Artikel 4(8), wenn er Klickdaten ueber identifizierbare natuerliche 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) fuer 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 Datenstuecke 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 koennen, wenn sie mit Informationen kombiniert werden, die dem Verantwortlichen zur Verfuegung stehen. Jeder Redirect protokolliert ausserdem einen User-Agent, der in Kombination mit IP und Zeitstempel in vielen High-Traffic-Mustern ausreicht, um Individuen herauszuloesen — 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 haeufigsten 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, unabhaengig 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 fuer 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.
Artikel 6: Rechtsgrundlage#
Klick-Tracking ueber einen Shortener stuetzt sich typischerweise auf eine von drei Rechtsgrundlagen.
6(1)(a) — Einwilligung. Der Verantwortliche hat die Einwilligung der betroffenen Person fuer die Verarbeitung eingeholt. Fuer 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 unmissverstaendliche Einwilligung.
6(1)(b) — erforderlich fuer die Vertragserfuellung. Der Redirect selbst — den Klick entgegenzunehmen und zum Ziel zu routen — ist erforderlich fuer den Dienst, den der Nutzer angefragt hat. Die sauberste Trennung ist, dass das Routing Vertragserfuellung ist, waehrend die Analytics-Schicht (ob dieser Klick fuer eine retrospektive Auswertung erfasst wird) eine separate Verarbeitungsoperation ist, die moeglicherweise eine andere Grundlage braucht.
6(1)(f) — berechtigtes Interesse. Die meisten B2B-Kunden gruenden kampagnenweite Analytics auf berechtigtem Interesse, nachdem sie eine Legitimate Interest Assessment (LIA) durchgefuehrt haben. Die LIA waegt das Interesse des Verantwortlichen an der Messung der Marketing-Effektivitaet gegen die Interessen der betroffenen Person ab; fuer aggregierte Klickzahlen und Standard-Attribution kippt die Abwaegung in der Regel zugunsten des Verantwortlichen. Fuer hochaufloesendes Verhaltensprofiling — Fingerprinting, seitenuebergreifendes Tracking, Retargeting auf Personen-Ebene — wird die LIA schwieriger.
Der Shortener ist in allen drei Faellen der Auftragsverarbeiter. Er verarbeitet die Daten auf dokumentierte Weisung des Verantwortlichen. Er waehlt 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 Unterabsaetze (a) bis (h) sind kurz und konkret. Ein brauchbares DPA fuer 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 fuer diese Workspaces verarbeiten, X Monate aufbewahren"). Der Shortener darf Klickdaten nicht ohne Weisung des Verantwortlichen fuer eigene Zwecke verwenden. In der Praxis heisst das: keine Verwendung von Kunden-Klickdaten zum Trainieren interner Recommendation-Modelle ohne Opt-in, keine an Dritte weitergegebenen Aggregat-Analytics ohne Ankuendigung. 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) Sicherheitsmassnahmen (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 Auspraegungen der Autorisierung. Spezifische vorherige Autorisierung verlangt, dass der Verantwortliche jedem neuen Sub-Processor zustimmt. Allgemeine vorherige Autorisierung verlangt nur eine vorherige Ankuendigung mit Widerspruchsrecht. Die meisten SaaS-Vertraege nutzen allgemeine Autorisierung mit einem 30-Tage-Vorankuendigungsfenster. Beides ist nach Artikel 28 in Ordnung; wichtig ist, dass der Vertrag spezifiziert, welches.
(e) Unterstuetzung bei Betroffenenrechten. Der Auftragsverarbeiter muss dem Verantwortlichen helfen, auf Anfragen nach Betroffenenrechten nach Artikeln 15-22 zu reagieren. Fuer einen Shortener heisst das: der Verantwortliche kann nach einem Klick-Datensatz-Export verlangen, der nach einem spezifischen Identifier verschluesselt ist (selten, aber kommt vor), und der Shortener muss in der Lage sein, ihn zu liefern. Die Elido-API enthaelt GET /v1/clicks?subject_id= fuer diesen Zweck; falls dein Bestandsanbieter das nicht hat, beantwortest du Auskunftsersuchen manuell.
(f) Unterstuetzung nach Artikel 32 / 33 / 34 / 35 / 36. Der Auftragsverarbeiter muss dem Verantwortlichen helfen, Sicherheits-, Breach-Notification- und DPIA-Pflichten zu erfuellen. Die "Hilfe" ist operativ — Bereitstellung von Sicherheitsaudit-Berichten, Benachrichtigung von Vorfaellen innerhalb eines SLA, Lieferung der fuer eine DPIA benoetigten technischen Details.
(g) Rueckgabe oder Loeschung am Ende der Dienste. Wenn der Vertrag endet, gibt der Auftragsverarbeiter alle personenbezogenen Daten zurueck oder loescht sie, sofern Unions- oder mitgliedstaatliches Recht nicht eine Speicherung verlangt. Elidos Standardklausel sind 30 Tage nach Beendigung, mit einem auf Anfrage dokumentierten Loeschzertifikat.
(h) Audit-Rechte. Der Auftragsverarbeiter muss alle Informationen bereitstellen, die zum Nachweis der Compliance erforderlich sind, und Audits unterzogen werden koennen. SaaS-Vertraege engen das auf schriftliche Audit-Fragebogen plus Vor-Ort-Audits mit angemessener Vorlaufzeit ein; volle uneingeschraenkte Audit-Rechte sind ausserhalb von Enterprise-Vertraegen ungewoehnlich.
Wenn das DPA deines Bestandsanbieters bei einem von (a)-(h) fehlt oder vage ist, sollte das Beschaffungsgespraech nicht weitergehen. Ein DPA, das Artikel 28 erfuellt, ist die Untergrenze, nicht die Obergrenze.
Artikel 30: Verzeichnis der Verarbeitungstaetigkeiten#
Artikel 30 verlangt von Auftragsverarbeitern, ein Verzeichnis der Verarbeitungstaetigkeiten (RoPA) zu fuehren. Das RoPA des Auftragsverarbeiters ist das verantwortlichengewandte Artefakt, das deinem DPO erlaubt zu verstehen, was der Shortener mit den Daten tut.
Elido veroeffentlicht eine pro-Kunde-RoPA-Vorlage, die du auf deine eigene mappen kannst. Die Spalten sind Kategorien betroffener Personen, Kategorien personenbezogener Daten, Empfaenger, Uebermittlungen in Drittlaender (standardmaessig keine), Aufbewahrung und Sicherheitsmassnahmen. Schablonenhaft, aber Beschaffungsteams wollen sie konkret ausgefuellt sehen. Der DPO will keinen Platzhalter. Wenn dein Shortener dir das nicht liefert, faellt die Last auf dich, sie aus seiner Dokumentation zusammenzustellen.
Artikel 32: Sicherheit der Verarbeitung#
Artikel 32 verlangt "geeignete technische und organisatorische Massnahmen", um ein dem Risiko angemessenes Sicherheitsniveau sicherzustellen. Der Artikel ist absichtlich nicht praeskriptiv; die Aufsichtsbehoerden fuellen ihn ueber Leitlinien aus.
Fuer 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.
- Verschluesselung at-rest fuer den Klick-Event-Store, mit dokumentierter Schluesselrotation.
- Netzwerksegmentierung zwischen Redirect-Ebene und Analytics-Ebene.
- Authentifizierung via SSO/SAML oder OIDC fuer die kundenseitige Oberflaeche; Service-to-Service via kurzlebige Credentials.
- Ein Audit-Log administrativer Aktionen auf der Shortener-Seite, mindestens 12 Monate aufbewahrt.
- Dokumentiertes Incident-Response und regelmaessige Tabletop-Uebungen.
- ISO 27001-Zertifizierung oder gleichwertige unabhaengige Bescheinigung.
Elido ist ISO 27001-zertifiziert und mitten in SOC 2 Type II (Ziel H2 2026). Die technische Kontrollflaeche ist auf der Trust-Seite dokumentiert. Fuer HIPAA-relevanten Traffic sind BAAs im Business-Plan verfuegbar.
Der Wortlaut auf Artikelebene zaehlt hier: "angemessen zum Risiko" ist ein relativer Massstab. Ein Shortener, der Kampagnen-Klicks auf einer oeffentlichen Marketing-Seite verarbeitet, ist risikoaermer als einer, der intern zum Teilen authentifizierter Session-URLs verwendet wird. Dein DPO sollte auf das Risiko dimensionieren, das du tatsaechlich faehrst.
Artikel 35: DPIA#
Artikel 35 verlangt eine Datenschutz-Folgenabschaetzung fuer Verarbeitungen, die "voraussichtlich ein hohes Risiko fuer die Rechte und Freiheiten natuerlicher Personen zur Folge haben", mit besonderem Augenmerk auf (a) systematische und umfangreiche Bewertung, (b) besondere Kategorien von Daten und (c) systematische Beobachtung oeffentlich zugaenglicher Bereiche im grossen Massstab.
Fuer die meisten Shortener-Anwendungsfaelle 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 aehnlich erheblichen Auswirkungen auf die betroffene Person zu treffen (selten, aber denkbar im Kredit- oder Beschaeftigungskontext).
- Hohes Traffic-Volumen aus besonderen Kategorien-Kontexten (Gesundheit, Religion, politische Meinung).
Wenn du eine DPIA fuer shortener-bezogene Verarbeitung in Auftrag gibst, sind die WP29-Leitlinien (WP248 rev.01) die methodische Referenz; viele Aufsichtsbehoerden haben eigene Vorlagen veroeffentlicht, einschliesslich 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 erhaelt. In der Praxis veroeffentlicht jeder ernsthafte SaaS-Anbieter eine Sub-Processor-Liste und einen Benachrichtigungsprozess fuer Neuzugaenge.
Wie eine gute Liste aussieht:
- Name des Sub-Processors, Verarbeitungsort, Rolle.
- Kategorien geteilter personenbezogener Daten.
- Rechtsgrundlage fuer die Uebermittlung (wo zutreffend).
- Datum, an dem der Sub-Processor hinzugefuegt wurde.
- Benachrichtigungsmechanismus fuer Zugaenge (typischerweise E-Mail + RSS/JSON-Feed).
- Widerspruchsrecht: ueblich 30 Tage ab Benachrichtigung.
Elidos oeffentliche Sub-Processor-Liste nennt fuenf Anbieter. Diese Zahl ist absichtlich klein — jeder neue Sub-Processor erweitert die Angriffsflaeche 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 ungueltig gemacht und fuer internationale Datenuebermittlungen unter SCCs eine Transfer Impact Assessment verlangt, die bewertet, ob das Ueberwachungsregime des Ziellandes EU-Betroffenen wirksamen Rechtsschutz verweigert.
Das Nachfolge-Framework — das EU-US Data Privacy Framework, angenommen via Commission Decision (EU) 2023/1795 — ersetzt fuer teilnehmende Organisationen den Privacy Shield. Zwei wichtige Vorbehalte:
- Die Teilnahme ist freiwillig; nicht jeder US-SaaS-Anbieter ist zertifiziert. Pruefe die DPF participant list.
- Das Framework selbst ist Gegenstand anhaengiger Rechtsstreitigkeiten. NOYB hat eine Anfechtungsabsicht signalisiert und ein drittes Schrems-Urteil ist plausibel. Kaeufer, die umsichtig genug sind, fuer dieses Szenario zu planen, verlangen zunehmend vertraglich EU-only-Verarbeitung.
Wo das bei der Shortener-Auswahl landet: wenn dein Kaeufer Datenresidenz markiert hat oder deine Branchenregulierung EU-only-Verarbeitung verlangt (deutsche Gesundheit unter dem Sozialdatenschutz, franzoesische Gesundheitsdaten via HDS-Zertifizierung, Finanzdienstleistungen unter EBA-Leitlinien), vereinfacht ein EU-gehosteter Shortener den Vertrag. Die Residenzklausel ist konkret, die TIA ist unnoetig, und der Beschaffungszyklus verkuerzt sich.
Elido wird standardmaessig in Frankfurt gehostet. Business+-Kunden koennen an Ashburn oder Singapore 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 fuer die Zwecke der Verarbeitung notwendige Mass beschraenkt" ist. Fuer einen Shortener landet das auf dem Klick-Event-Schema.
Die Signale, die ein Shortener zum Redirect-Zeitpunkt erfassen kann:
- IP-Adresse (voll, /24 gekuerzt 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).
- Geraet abgeleitet von UA (Mobile/Desktop/Tablet, OS-Familie).
- Klick-ID (die eigene Kennung des Shorteners fuer das Event).
Davon benoetigt der tatsaechliche Zweck des Verantwortlichen ueblicherweise das geparste Geraet, das Land, den Zeitstempel, die Klick-ID und moeglicherweise den Referrer. Die IP-Adresse selbst wird ueber den Moment des Redirects hinaus selten gebraucht — sobald Geo- und Geraete-Parsing abgeschlossen sind, kann die IP gekuerzt oder gehasht werden, bevor sie im Klick-Store landet. Dasselbe gilt fuer den UA: die geparsten Felder device.type / device.os sind das, was die Attribution tatsaechlich verwendet; der volle UA-String ist Fingerprinting-Koeder, der verworfen werden sollte.
Elido kuerzt 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 hoeher aufgeloesten 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 unterstuetzt. Fuer 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 koennen, die auf eine Subject-ID verschluesselt 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 fuer die IP/den Zeitraum, den der Verantwortliche spezifiziert, und der Verantwortliche filtert auf die relevante Person.
Artikel 17 — Recht auf Loeschung. Die betroffene Person fragt nach Loeschung. Der Shortener muss Klick-Events auf Anfrage innerhalb des GDPR-Wortlauts "ohne unangemessene Verzoegerung" loeschen koennen — das operative SLA liegt standardmaessig bei 30 Tagen. Die Komplikation: Klick-Events werden ueblicherweise in einer Append-only-Analytics-Datenbank (ClickHouse, BigQuery, Snowflake) gespeichert. Loeschung ist echt, aber es ist ein DELETE gegen die Partition, kein zeilenweiser Edit. Stell sicher, dass das DPA deines Shorteners sich auf ein konkretes Loesch-SLA verpflichtet und dass die zugrundeliegende Architektur es einhalten kann.
Elido unterstuetzt beides via API: GET /v1/subjects/{id}/clicks und DELETE /v1/subjects/{id}. Die Loeschung wird innerhalb von 24 Stunden zum Klick-Event-Store propagiert und ueber Webhook bestaetigt.
Was du im Procurement fragen solltest#
Die komprimierte Checkliste fuer ein Beschaffungsgespraech:
- Wo wird der Shortener gehostet? (Eine-Satz-Antwort; pin oder nicht.)
- Ist das DPA vorab unterzeichnet oder pro Kunde verhandelt? (Vorab unterzeichnet ist schneller.)
- Wie viele Sub-Processors? (Kleiner ist einfacher.)
- Enthaelt der Standardvertrag EU-only-Verarbeitung, oder ist das ein separates Addendum?
- Was ist die Default-IP-Truncation auf Klick-Events?
- Gibt es einen Artikel-15-/17-Endpoint, oder laeuft die Loeschung ueber Support?
- Was ist das Breach-Notification-SLA? (24 Stunden ab Kenntnis ist Industrie-Norm.)
- Unabhaengige 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, fuegt 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). Fuer die beschaffungsgewandte Zusammenfassung sind die trust page und solutions/compliance die zwei Artefakte zum Bookmarken. Fuer das architektonische Detail hinter der Residenz-Behauptung geht the edge-redirect architecture doc durch, wie das regionale Pinning zum Routing-Zeitpunkt erzwungen wird.