DSAR ohne Drama: Auskunfts- und Löschrecht im Tracker

Dies ist datenschutzrechtliche Recherche, keine Rechtsberatung. Den vollständigen Haftungsausschluss finden Sie in der Fußzeile.

TL;DR

Artikel 15 und 17 gelten für Webanalyse – pseudonyme Kennzeichner wie gehashte IPs, Cookie-IDs und BLAKE3-HMAC-Besuchersignaturen bleiben personenbezogene Daten gemäß der Rechtslinie aus Breyer, IAB Europe und dem Urteil des Brussels Court of Appeal vom 14. Mai 2025.
Drei Endpunkte ausgeliefert – POST /api/privacy/opt-out, GET /api/privacy/access, POST /api/privacy/erase – alle CSRF-geschützt, mit Rate Limiting und Audit-Protokollierung.
Rollup-Tabellen überstehen die Löschung, weil sie bereits über den Punkt der Identifizierbarkeit hinaus aggregiert wurden – uniqCombined64-HyperLogLog-Skizzen sind Zählwerte, keine Datensätze, und einzelne Beiträge können nicht rückgängig gemacht werden.
8 Datenschutz-Audit-Ereignisse erzeugen strukturierte Rechenschaftsnachweise gemäß Artikel 28(3)(h) – für Opt-out, Zugriff, Löschung, erteilte/widerrufene Einwilligung und Aufrufe der Rechtsseiten.
Der EDPB-Durchsetzungsschwerpunkt 2025 lag auf dem Recht auf Löschung im Rahmen des koordinierten Rahmens; der EDPB-Schwerpunkt 2026 verlagert sich auf Transparenzpflichten. Beides deckt sich mit der in diesem Beitrag beschriebenen Architektur.

Warum Webanalyse die am häufigsten vergessene DSAR-Oberfläche ist

Die meisten DSGVO-DSAR-Workflows (Datenschutz-Auskunftsersuchen) werden rund um Systeme aufgebaut, in denen personenbezogene Daten offensichtlich vorhanden sind – das CRM, die Helpdesk-Tickets, die Bestellhistorie, die E-Mail-Marketing-Listen. Der Webanalyse-Stack ist meist ein Nachgedanke; und wenn er zur Sprache kommt, lautet die erste Reaktion des Betreibers häufig: „Dort gibt es keine personenbezogenen Daten, wir haben die IPs gehasht.” Diese Einschätzung ist rechtlich falsch und zunehmend auch architektonisch unzutreffend.

Die Entwurfsfassung der EDPB-Leitlinien 01/2025 zur Pseudonymisierung – als Entwurf auf der 101. Plenarsitzung am 16. Januar 2025 verabschiedet, öffentliche Konsultation bis 28. Februar 2025, Stand Mai 2026 noch in Entwicklung – stellen klar, dass pseudonymisierte Daten, einschließlich gehashter IPs, Cookie-IDs, BLAKE3/HMAC-Besuchersignaturen und TC-Strings, personenbezogene Daten bleiben, wenn eine Re-Identifizierung durch dem Verantwortlichen oder einem Dritten verfügbare Mittel vernünftigerweise wahrscheinlich ist. Das EuGH-Urteil IAB Europe (C-604/22, 7. März 2024), bestätigt durch das Urteil des Brussels Court of Appeal vom 14. Mai 2025 (Az. 2022/AR/292), weitet dies über TC-Strings hinaus auf jeden mit einer IP verknüpften Kennzeichner aus. Breyer (C-582/14, 19. Oktober 2016) hatte die Frage zur Betreiber-IP bereits viel früher geklärt.

Praktisch bedeutet das: Webanalyse, die IPs, gehashte Cookies, BLAKE3-HMAC-Besuchersignaturen oder einen pro-Besucher-Kennzeichner verarbeitet, verarbeitet personenbezogene Daten im Sinne der DSGVO. Artikel 15 (Auskunftsrecht) und Artikel 17 (Recht auf Löschung) gelten. Artikel 28(3)(e) verpflichtet den Auftragsverarbeiter – sofern einer vorhanden ist – dazu, den Verantwortlichen bei diesen Anfragen zu unterstützen. Die Meldefrist für eine Verletzung gemäß Artikel 33 umfasst auch Verletzungen, die diese Kennzeichner betreffen.

Im folgenden Beitrag erläutern wir die Anatomie eines DSAR gegen einen Analyse-Stack, die drei Endpunkte, die Statnive Live ausliefert, die erforderliche Prüfspur, wie Rollups die Löschung überstehen, ein entwicklerfreundliches DSAR-Runbook sowie ein funktionsfähiges Code-Beispiel.

Anatomie eines DSAR gegen den Analyse-Stack

Ein DSAR gegen einen Webanalyse-Stack sieht anders aus als ein DSAR gegen ein CRM. Es gibt keine E-Mail-Adresse, keinen Kundennamen, keinen offensichtlichen Primärschlüssel. Die betroffene Person meldet sich und sagt sinngemäß: „Ich besuche Ihre Website gelegentlich. Welche Daten haben Sie von mir, und bitte löschen Sie diese.”

Was hat der Betreiber tatsächlich?

Bei einem cookiefreien First-Party-Analyse-Stack wie Statnive Live im Modus consent-free lautet die Antwort: eine tagesseitig begrenzte pseudonyme Signatur, die aus der IP des Besuchers, dem User-Agent, dem Site-Scope und einem täglich rotierenden Salt abgeleitet wird, der am Ende des Tages vernichtet wird. Die Architektur ist im Detail im EU-Leitfaden für einwilligungsfreie Webanalyse 2026 beschrieben. Die Signatur des jeweiligen Tages verbleibt in der Rohereignistabelle, bis der Salt bei der nächsten 00:00 UTC rotiert; nach der Rotation wird die Signatur faktisch irreversibel, weil der Salt, der sie erzeugt hat, nicht mehr vorhanden ist. Rollups aggregieren diese Signatur noch vor der Salt-Rotation zu Zählwerten, sodass der Pro-Besucher-Kennzeichner in den Rollup-Tabellen überhaupt nicht vorhanden ist – dort finden sich nur Zählwerte eindeutiger Besucher pro Tag, Seite oder Quelle.

Bei einem consent-required- oder hybrid-Statnive-Live-Einsatz mit erteilter Einwilligung wird zusätzlich eine Cookie-ID als rohe UUID an den Browser übermittelt. Der Server speichert SHA-256(master_secret || site_id || cookieID) mit dem Präfix h: als Persistenzschlüssel. Die tagesübergreifende Besucherkontinuität wird durch die gehashte Cookie-ID gewährleistet, nicht durch den täglich rotierenden Salt.

Drei Konsequenzen ergeben sich daraus:

Auskunft nach Artikel 15. Die betroffene Person kann dem Betreiber einen Suchbegriff nennen – typischerweise die Cookie-ID aus dem Browser (falls in der aktuellen Sitzung vorhanden) oder eine Beschreibung des Besuchs (Datum, Seite, ungefähre Uhrzeit, IP aus einem bekannten Netzwerk). Der Betreiber kann die passenden Ereignisse zurückgeben.
Löschung nach Artikel 17. Der Betreiber kann dieselben Ereignisse lokalisieren und löschen. Die Datensätze, die der Betreiber identifizieren kann, sind die Datensätze, die er löschen kann.
Was nicht identifiziert werden kann, kann weder gelöscht noch gespeichert werden. Die tägliche Salt-Vernichtung um 00:00 UTC ist eine zeitgleiche, automatische Löschung der tagesübergreifenden Re-Identifizierungsmöglichkeit. Die Sitzungssignatur von Tag 1 eines Besuchers ist mit der Signatur von Tag 2 dauerhaft nicht mehr verknüpft, sobald der Salt von Tag 1 vernichtet wurde; ein Artikel-17-Ersuchen, das den Betreiber an Tag 2 erreicht, kann keine Löschung der Datensätze von Tag 1 verlangen, weil diese nicht lokalisierbar sind – das ist jedoch auch unproblematisch, da sie nicht mehr re-identifizierbar sind.

Die Architektur ist so konzipiert, dass der Steady-State-Bestand an identifizierbaren Daten gering ist. Die Salt-Rotation erledigt den Großteil der Datensparsamkeit gemäß Artikel 5(1)(c) der DSGVO automatisch. DSAR-Anfragen gegen einen so aufgebauten Analyse-Stack weisen von Natur aus ein geringeres Volumen auf als DSAR-Anfragen gegen ein CRM – die meisten Besucher hinterlassen überhaupt keinen Pro-Besucher-Datensatz, sobald der Salt rotiert.

Die drei Endpunkte

Statnive Live liefert standardmäßig drei Datenschutz-Endpunkte aus. Alle drei sind CSRF-geschützt, mit Rate Limiting versehen und erzeugen strukturierte Audit-Ereignisse.

POST /api/privacy/opt-out

Der Endpunkt für das Widerspruchsrecht nach Artikel 21. Ein Besucher ruft diesen über eine Schaltfläche in der Datenschutzerklärung des Betreibers auf. Der Server registriert den Opt-out als notwendiges Cookie, das die Entscheidung des Nutzers ausdrückt (zulässig gemäß ePrivacy § 25(2)(ii) / TDDDG / entsprechenden nationalen Umsetzungen, da es die ausdrücklich angeforderte Servicepräferenz des Nutzers umsetzt). Nachfolgende Ingest-Anfragen desselben Browsers werden auf der Ingest-Ebene abgewiesen, bevor die Besuchersignatur berechnet wird.

Alternativ kann der Opt-out serverseitig über eine Unterdrückungsliste gespeichert werden, die mit der gehashten Besuchersignatur und einer angemessenen TTL verknüpft ist – die Wahl liegt beim Betreiber und ist konfigurierbar.

Der Endpunkt erzeugt das Audit-Ereignis privacy.opt_out_received mit Zeitstempel, Site-ID und einem Hash der Besuchersignatur zur Querverknüpfung mit dem Audit-Log.

GET /api/privacy/access

Der Endpunkt für das Auskunftsrecht nach Artikel 15. Der Besucher stellt bereit:

Die aktuell im Browser gespeicherte Cookie-ID (falls vorhanden), oder
einen signierten vorab ausgetauschten Kennzeichner (für Betreiber, die ihr eigenes DSAR-Portal integrieren), oder
eine Beschreibung des Besuchs, die präzise genug ist, damit der Betreiber ihn lokalisieren kann (Datum, Seite, ungefähre Uhrzeit, Quellnetzwerk).

Der Endpunkt gibt die vorliegenden Ereignisse zurück. Die Antwort ist ein JSON-Objekt mit den rohen Ereignissen, die dem Suchbegriff entsprechen, sowie den rollup-abgeleiteten Metadaten, die den Besucher betreffen (in welche Rollup-Buckets der Besuch eingeflossen ist, ohne andere Besucher im selben Bucket offenzulegen). Audit-Ereignis: privacy.dsar_access_requested.

POST /api/privacy/erase

Der Endpunkt für das Löschrecht nach Artikel 17. Der Suchbegriff ist derselbe wie bei Artikel 15. Der Endpunkt zählt die Tabellen des Speicher-Backends dynamisch auf – per system.tables-Introspektion bei ClickHouse – und löscht die passenden Zeilen aus jeder Tabelle, die eine Spalte visitor_signature oder cookie_id_hash enthält. Die dynamische Aufzählung ist beabsichtigt: Eine künftig hinzugefügte Tabelle schlägt sicher fehl, wenn sie einen Besucher-Kennzeichner enthält, aber nicht in den Löschpfad aufgenommen wurde, da der Integrationstest, der die dynamische Aufzählung prüft, sicherstellt, dass jede dem Schema bekannte Tabelle abgedeckt wird.

Aggregierte Rollups werden nicht gelöscht. Der Grund – und er ist DSGVO-konform – wird im nächsten Abschnitt erläutert. Audit-Ereignis: privacy.dsar_erase_requested.

Alle drei Endpunkte lehnen unsignierte Cross-Origin-Anfragen ab, verlangen einen CSRF-Token aus der Betreiber-Session und begrenzen Anfragen pro IP sowie pro (IP, site_id)-Tupel, um Missbrauch zu verhindern. Das Audit-Log ist von der Analysedatenbank getrennt und wird gemäß der Audit-Log-Aufbewahrungsrichtlinie des Betreibers vorgehalten – in der Regel länger als das 25-monatige Rollup-Fenster.

Warum Rollups die Löschung überstehen – und warum das korrekt ist

Das konzeptionell schwierigste Element beim DSAR-Design für Webanalyse ist das Überleben der aggregierten Rollup-Tabellen nach einem Löschersuchen gemäß Artikel 17. Die erste Reaktion lautet meist: Wenn der Nutzer gelöscht werden möchte, müssen doch alle Daten über ihn verschwinden, einschließlich der Zählwerte, zu denen er beigetragen hat?

Die Antwort hängt davon ab, was die Rollup-Tabelle tatsächlich enthält. Eine Zeile in hourly_visitors enthält beispielsweise: site_id=X, hour=Y, unique_visitors=4271. Die Zeile enthält weder die Signatur des Besuchers noch seine IP noch einen pro-Besucher-Kennzeichner. Sie enthält eine uniqCombined64-HyperLogLog-Skizze – eine probabilistische Datenstruktur, die genaue Kardinalitätsschätzungen liefert, ohne einzelne Werte zu speichern. Die uniqCombined64-Skizze ist ein Zählwert, kein Datensatz darüber, wer vorhanden war. Der Beitrag des Besuchers zum Zählwert kann nicht aus der Skizze herausgerechnet werden.

Das entspricht der Standardposition des EDPB zu aggregierten Daten: Sobald Daten über den Punkt der Identifizierbarkeit hinaus aggregiert wurden – über den Punkt, an dem ein einzelner Beitrag rekonstruiert werden kann –, handelt es sich nicht mehr um personenbezogene Daten. Die CNIL-Sheet-16-Empfehlung zur Aggregation auf die nächste 10er-Stelle beruht auf demselben Grundsatz. Die Anonymisierungsanalyse des italienischen Garante in seiner Entscheidung zu Caffeina Media dreht sich darum, ob eine Re-Identifizierung vernünftigerweise wahrscheinlich ist; für einen aus einer HyperLogLog-Skizze abgeleiteten Gesamtzählwert ist das nicht der Fall.

Die praktische Konsequenz: Ein Löschersuchen gemäß Artikel 17 löscht die rohen Ereigniszeilen (die die Pro-Besucher-Signatur, die IP-basierte Geolokalisierung, den auf den Host beschränkten Referrer und die Seite enthalten), lässt die Rollup-Tabellen jedoch unberührt. Die Dashboards des Betreibers zeigen weiterhin den historischen Traffic für die Seite, aber keine Zeile im Dashboard ist auf die betroffene Person zurückführbar, die die Löschung beantragt hat.

In der Datenschutzerklärung des Betreibers wird dies beschrieben als: „über den Punkt der Identifizierbarkeit hinaus aggregiert.” Das ist die richtige Formulierung – weder übertrieben als „anonym” noch untertrieben als „weiterhin personenbezogen”. Die Rollups sind der DSGVO-konforme Steady State für die Analyseaufbewahrung.

Die 25-monatige Obergrenze für die Rollup-TTL (750 Tage, per Migration 011_rollup_ttl.sql) gilt unabhängig davon. Auch die aggregierten Zählwerte verfallen automatisch gemäß dem CNIL-Sheet-16-Zeitplan.

Die Prüfspur – 8 Datenschutz-Ereignisse

Statnive Live erzeugt 8 strukturierte Audit-Ereignisse, die die Datenschutz- und Rechtsebene abdecken. Diese Ereignisse sind die Rechenschaftsnachweise gemäß Artikel 28(3)(h) für eine Prüfung durch den Datenschutzbeauftragten des Betreibers, den Prüfer des Verantwortlichen oder eine Datenschutzbehörde:

Ereignis	Auslöser	Zweck
`privacy.opt_out_received`	`POST /api/privacy/opt-out`	Widerspruch nach Artikel 21 registriert
`privacy.dsar_access_requested`	`GET /api/privacy/access`	Anfrage nach Artikel 15 eingeleitet
`privacy.dsar_erase_requested`	`POST /api/privacy/erase`	Anfrage nach Artikel 17 eingeleitet
`privacy.consent_given`	`statnive.acceptConsent()`	Einwilligung im Modus `consent-required` / `hybrid` erteilt
`privacy.consent_withdrawn`	`statnive.withdrawConsent()`	Einwilligung widerrufen
`legal.lia_viewed`	`GET /legal/lia`	LIA-Seite des Betreibers ausgeliefert
`legal.dpa_viewed`	`GET /legal/dpa`	Auftragsverarbeitungsvertrag-Seite nach Artikel 28 ausgeliefert
`legal.privacy_policy_viewed`	`GET /legal/privacy-policy/{lang}`	Datenschutzerklärung ausgeliefert

Jedes Ereignis ist strukturiertes JSON mit Zeitstempel, Site-ID, Request-ID und dem relevanten Fingerprint. Das Audit-Log ist von der Analysedatenbank getrennt – es wird nicht aggregiert, verfällt nicht mit der 25-monatigen Analyse-TTL und wird gemäß der Audit-Log-Richtlinie des Betreibers aufbewahrt (in der Regel länger, häufig unbegrenzt als Compliance-Nachweis).

Die Prüfspur ist das, was ein Betreiber einer Aufsichtsbehörde bei einer Prüfung vorlegt. Die Datenschutzerklärung ist die öffentlich zugängliche Position; die Audit-Ereignisse sind der zeitgleiche Nachweis, dass diese Position tatsächlich umgesetzt wurde. Das CNIL-Prüfungsantwortpaket umfasst in der Regel (a) die LIA, (b) die Datenschutzerklärung, (c) das Audit-Log für das Prüfungsfenster und (d) die Ausgabe des Ereignis-Audit-Endpunkts (die 3-Ereignis-Obergrenze für französische Deployments). Statnive Live liefert alle vier standardmäßig.

DSAR-Runbook für Betreiber

Ein funktionsfähiges Runbook für den Umgang mit einem DSAR gegen ein Statnive-Live-Deployment:

Schritt 1: Anfrage identifizieren. Die betroffene Person meldet sich, in der Regel per E-Mail an die veröffentlichte DSAR-Adresse des Verantwortlichen. Die Anfrage muss spezifisch genug sein, damit der Betreiber die Daten lokalisieren kann – typischerweise bedeutet das die Cookie-ID aus dem Browser des Besuchers (die dieser per DevTools einsehen kann) oder eine Beschreibung des Besuchs, die das Ereignisfenster eingrenzt.

Schritt 2: Identität der anfragenden Person überprüfen. Artikel 12(6) der DSGVO erlaubt es dem Verantwortlichen, bei begründeten Zweifeln zusätzliche Informationen zur Identitätsprüfung anzufordern. Bei Analyseanfragen besteht der Nachweis typischerweise darin: Kontrolle über die Cookie-ID (der Besucher sendet einen Screenshot aus den DevTools, der das Cookie zeigt) oder Kontrolle über die IP, von der aus der Besuch erfolgte (eine authentifizierte Anmeldung von derselben IP oder eine Callback-Challenge). Der Betreiber sollte nicht mehr Identifikationsnachweise verlangen als zur Verifikation der Anfrage erforderlich.

Schritt 3: Auskunftsabfrage ausführen. Der Betreiber ruft GET /api/privacy/access mit dem Suchkennzeichner auf. Die Antwort enthält die passenden Ereignisse. Bei einer Auskunftsanfrage nach Artikel 15 ist dies die Antwort, die an die betroffene Person zu übermitteln ist – als CSV, JSON oder PDF, je nach Präferenz des DSAR-Portals des Betreibers.

Schritt 4: Löschung ausführen (sofern beantragt). Der Betreiber ruft POST /api/privacy/erase mit demselben Suchkennzeichner auf. Der Endpunkt löscht die passenden Zeilen aus jeder Tabelle mit einem Besucher-Kennzeichner; Rollup-Tabellen bleiben unberührt (gemäß dem vorangehenden Abschnitt). Der Endpunkt gibt die Anzahl der gelöschten Zeilen pro Tabelle zurück.

Schritt 5: Betroffene Person bestätigen. Artikel 12(3) der DSGVO gestattet eine Bearbeitungsfrist von bis zu einem Monat, die bei komplexen Anfragen um zwei weitere Monate verlängert werden kann. Die Antwort des Betreibers sollte:

Bestätigen, dass die Daten lokalisiert und (sofern Löschung beantragt) gelöscht wurden.
Beschreiben, was aufbewahrt wird – die Rollup-Aggregate – und warum diese keine personenbezogenen Daten darstellen.
Auf die Aufbewahrung des Audit-Logs hinweisen (die Tatsache, dass die DSAR-Anfrage selbst protokolliert wurde).

Schritt 6: Antwort im Audit-Log dokumentieren. Die Statnive-Live-Audit-Ereignisse wurden automatisch erzeugt, als der Betreiber die API-Endpunkte aufrief. Der Betreiber sollte die an die betroffene Person übermittelte Antwort zusätzlich in seinem übergeordneten DSAR-Bearbeitungssystem protokollieren (in der Regel das Helpdesk oder DPMS).

Das gesamte Runbook passt in eine halbseitige Checkliste. Die meisten Betreiber, die es zum ersten Mal umsetzen, befürchten, dass der DSAR gegen den Analyse-Stack aufwendig sein wird; in der Praxis ist die Architektur so konzipiert, dass die Daten entweder in einem kleinen, klar definierten Fenster vorhanden sind oder überhaupt nicht. Das Volumen ist gering, die Abfragen sind begrenzt und die Antwortstruktur ist standardisiert.

Ein funktionsfähiges Integrationsbeispiel

Für Betreiber, die ihr eigenes DSAR-Portal mit Statnive Live integrieren, funktioniert das folgende Muster vollständig:

// Wird aus einem DSAR-Portal nach Identitätsprüfung aufgerufen
async function handleAccessRequest(verifiedRequest) {
  const response = await fetch(
    `https://app.statnive.live/api/privacy/access?site_id=${SITE_ID}&cookie_id=${verifiedRequest.cookieId}`,
    {
      method: 'GET',
      headers: {
        'X-Statnive-CSRF': await getCsrfToken(),
        'X-Statnive-Operator-Key': OPERATOR_API_KEY,
      },
    }
  );
  if (!response.ok) {
    throw new Error(`DSAR access failed: ${response.status}`);
  }
  const { events, rollup_metadata } = await response.json();
  return { events, rollup_metadata };
}

async function handleErasureRequest(verifiedRequest) {
  const response = await fetch(
    `https://app.statnive.live/api/privacy/erase`,
    {
      method: 'POST',
      headers: {
        'X-Statnive-CSRF': await getCsrfToken(),
        'X-Statnive-Operator-Key': OPERATOR_API_KEY,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        site_id: SITE_ID,
        cookie_id: verifiedRequest.cookieId,
      }),
    }
  );
  if (!response.ok) {
    throw new Error(`DSAR erasure failed: ${response.status}`);
  }
  const { rows_deleted_by_table } = await response.json();
  return { rows_deleted_by_table };
}

Der Operator-Schlüssel wird gemäß der Secret-Rotationsrichtlinie des Betreibers rotiert. Der CSRF-Token wird im Rahmen des standardmäßigen Statnive-Live-Admin-Auth-Flows aus der Betreiber-Session abgeleitet.

Was ein selbst gehostetes Deployment verändert

Bei Betreibern, die Statnive Live als selbst gehostetes Deployment betreiben – die Binärdatei läuft auf der eigenen Infrastruktur des Betreibers –, verändert sich die Analyse von Verantwortlichem und Auftragsverarbeiter. Statnive ist überhaupt kein Auftragsverarbeiter der Analysedaten des Betreibers; der Betreiber ist der alleinige Verantwortliche. Es gibt keinen zwischen Statnive und dem Betreiber zu unterzeichnenden Auftragsverarbeitungsvertrag, weil es nichts gibt, für das Statnive Auftragsverarbeiter sein könnte.

Die DSAR-Endpunkte funktionieren auf einer selbst gehosteten Binärdatei identisch wie bei einem gehosteten Statnive-Live-SaaS-Deployment. Die Audit-Ereignisse werden an das vom Betreiber gewählte Log-Ziel ausgegeben (stdout/stderr in containerisierten Deployments, Syslog auf traditionellen Hosts oder eine dedizierte Audit-Tabelle bei selbst gehosteten Setups). Das oben stehende Integrationsbeispiel funktioniert auf dieselbe Weise gegen den eigenen Endpunkt des Betreibers.

Was sich unterscheidet: Die Antwort des Verantwortlichen auf eine Anfrage nach Artikel 15 einer dritten betroffenen Person ist ausschließlich die Antwort des Verantwortlichen. Es gibt keinen Statnive-Unterauftragsverarbeiter, der unterstützt; das IT-Team des Betreibers ist der DSAR-Bearbeiter des Betreibers.

Dies ist eines der Abwägungsthemen, das im Beitrag zu selbst gehostet vs. privater EU-SaaS behandelt wird. Für Betreiber mit einer strikten Position, dass kein Dritter die Daten berühren darf (regulierte Branchen, Air-Gap-Umgebungen), ist das selbst gehostete Modell die saubere Antwort; für Betreiber mit einer strikten Position zu unterzeichneten Auftragsverarbeitungsverträgen (ISO-27001-Anbieterfragebögen, große Beschaffungsverfahren) ist das SaaS-Modell mit einem Auftragsverarbeitungsvertrag nach Artikel 28 die saubere Antwort. Die DSAR-Architektur funktioniert in beiden Fällen auf dieselbe Weise.

Was der Betreiber damit erhält

Das praktische Ergebnis:

Ein vollständiges DSAR-Antwortpaket, das für jede Anfrage nach Artikel 15 / 17 gegen die Analyseebene bereit ist. Drei Endpunkte, acht Audit-Ereignisse, ein Runbook und ein Integrationsbeispiel.
Eine verteidigbare Antwort zum Fortbestand der Rollups. Die Formulierung „über den Punkt der Identifizierbarkeit hinaus aggregiert” entspricht der EDPB-Position; die 25-monatige Rollup-TTL gilt unabhängig davon.
Eine Rechenschaftsspur, die dem Artikel-28(3)(h)-Audit-Beistand für Auftragsverarbeitungsverhältnisse und dem übergeordneten Rechenschaftsprinzip nach Artikel 5(2) für die eigenen Unterlagen des Verantwortlichen entspricht.
Zukunftssicherheit im Hinblick auf die Betroffenenrechte-Erwartungen des Digital Omnibus Artikel 88a. Der aktuelle Text ändert die materiellen Pflichten aus Artikel 15 und 17 nicht; die DSAR-Endpunkte funktionieren unverändert.

Was es nicht bietet: eine Möglichkeit, rohe Pro-Besucher-Daten über das 25-monatige Rollup-Fenster hinaus aufzubewahren, weil die Salt-Vernichtung das unmöglich macht. Eine Möglichkeit, eine Löschanfrage rückgängig zu machen, weil die Löschungen irreversibel sind. Eine Möglichkeit, das Audit-Log für „interne” Anfragen zu überspringen, weil es keine internen Anfragen gibt – jeder Aufruf der drei Endpunkte erzeugt ein Ereignis.

Was zu tun ist – und was nicht

Tun	Nicht tun
Gehashte Besucher-Kennzeichner als personenbezogene Daten mit niedrigem Risiko behandeln; Artikel 15, 17 und 21 darauf anwenden.	Gehashte Kennzeichner als „anonym” vermarkten – pseudonym ist der rechtlich korrekte Begriff; der Brussels Court vom 14. Mai 2025 hat das bestätigt.
Die drei Datenschutz-Endpunkte (`/api/privacy/opt-out`, `/api/privacy/access`, `/api/privacy/erase`) mit CSRF-Schutz, Rate Limiting und Audit-Protokollierung verknüpfen.	Einen einmaligen DSAR-Handler erstellen, der das Audit-Log umgeht – der Rechenschaftsnachweis nach Artikel 28(3)(h) ist das Nachweis-Paket, das Sie bei einer Prüfung benötigen.
Den Fortbestand von Rollup-Tabellen nach Artikel 17 als „über den Punkt der Identifizierbarkeit hinaus aggregiert” beschreiben – weder als „anonym” übertreiben noch als „personenbezogene Daten” untertreiben.	Rollup-Tabellenzeilen auf eine Anfrage nach Artikel 17 hin löschen – sie sind aggregierte Zählwerte, keine Pro-Besucher-Datensätze, und Sie würden historische Traffic-Übersichten ohne DSGVO-Nutzen verlieren.
Die Identität der anfragenden Person gemäß Artikel 12(6) der DSGVO verifizieren – typischerweise durch Kontrolle der Cookie-ID oder eine Callback-Challenge – bevor die Auskunfts- oder Löschabfrage ausgeführt wird.	Mehr Identifikation verlangen als erforderlich; die EDPB-Leitlinien 01/2022 zum Auskunftsrecht sind eindeutig darin, dass übermäßige Anforderungen das Recht untergraben.
Das Runbook dokumentieren und jedes Datenschutz-Audit-Ereignis protokollieren – der EDPB-CEF-Schwerpunkt 2025 war das Recht auf Löschung, der EDPB-CEF-Schwerpunkt 2026 liegt auf Transparenz.	DSAR-Bearbeitung als einmaligen operativen Aufwand behandeln – die koordinierte DPA-Durchsetzung ist aktiv, und eine zeitgleiche Prüfspur ist die richtige Antwort.

Das Fazit

Das Auskunftsrecht und das Recht auf Löschung gemäß den Artikeln 15 und 17 der DSGVO gelten für Webanalyse. Die EDPB-Leitlinien 01/2025, die EuGH-Urteile Breyer und IAB Europe sowie die einheitliche Position der nationalen Aufsichtsbehörden bestätigen das. Die Architekturentscheidung liegt darin, was man damit macht – und die Antwort lautet: das Pro-Besucher-Datenfenster klein halten (tägliche Salt-Rotation), das Rollup-Fenster begrenzen (25-monatige TTL), drei Endpunkte bereitstellen (Opt-out, Auskunft, Löschung), acht Audit-Ereignisse erzeugen und die Position in der Datenschutzerklärung dokumentieren.

Statnive Live liefert diese Oberfläche standardmäßig. Betreiber integrieren dagegen; das Audit-Log erfasst die zeitgleichen Nachweise; die Rollup-Tabellen überstehen die Löschung, weil sie bereits über den Punkt der Identifizierbarkeit hinaus aggregiert wurden. Das DSAR-Drama, wenn es eintritt, ist verfahrenstechnischer Art – eine Einmonatsfrist, ein Verifikationsschritt, ein API-Aufruf, eine Bestätigungs-E-Mail – kein architektonisches.

Für den übergeordneten Datenschutzrahmen siehe den EU-Leitfaden für einwilligungsfreie Webanalyse 2026. Warum der täglich rotierende Salt die Architektur intrinsisch minimal macht, erläutert die Länder-für-Länder-Karte. Wie dieselben Audit-Ereignisse die GPC- und Hybrid-Modus-Integration steuern, zeigt der verknüpfte Beitrag. Die DSAR-Oberfläche ist das verbindende Element zwischen allen vier.

Dies ist datenschutzrechtliche Recherche, keine Rechtsberatung. Die beschriebenen DSAR-Endpunkte sind technische Verfügbarkeitsmerkmale. Die rechtliche Korrektheit einer Antwort auf eine Anfrage nach Artikel 15 / 17 / 21 liegt in der Verantwortung des Verantwortlichen gemäß Artikel 12 der DSGVO und den einschlägigen nationalen Rechtsvorschriften. Jeder Statnive-Kunde bleibt der Verantwortliche und trägt die Verantwortung für seine eigene Konfiguration und DSFA. Konsultieren Sie vor der Veröffentlichung qualifizierten Rechtsrat in Ihrer Jurisdiktion.

Stand der regulatorischen Verweise vom 13. Mai 2026: DSGVO Artikel 12, 15, 17, 21, 28(3)(e), 28(3)(h) und 33; EDPB-Leitlinien 01/2022 zum Auskunftsrecht (endgültige Fassung März 2023 verabschiedet); EuGH C-582/14 Breyer vom 19. Oktober 2016 (ECLI:EU:C:2016:779); EuGH C-604/22 IAB Europe vom 7. März 2024; Urteil des Brussels Court of Appeal vom 14. Mai 2025 in der Rechtssache 2022/AR/292 (bestätigt die IAB Europe / TC-String-Linie); Entwurf der EDPB-Leitlinien 01/2025 zur Pseudonymisierung (als Entwurf auf der 101. Plenarsitzung am 16. Januar 2025 verabschiedet; öffentliche Konsultation bis 28. Februar 2025; endgültige Fassung Stand Mai 2026 noch nicht veröffentlicht; EDPB-Sprint-Team strebt Fertigstellung Sommer 2026 an); EDPB-Leitlinien 1/2024 zum berechtigten Interesse vom 8. Oktober 2024; EDPB-Koordinierter-Durchsetzungsrahmen-Schwerpunkt 2025: Recht auf Löschung (Artikel 17); EDPB-Koordinierter-Durchsetzungsrahmen-Schwerpunkt 2026: Transparenz- und Informationspflichten (Artikel 13/14); ePrivacy-Richtlinie 2002/58/EG (in Kraft) und ihre nationalen Umsetzungen einschließlich § 25 TDDDG (Deutschland) und Artikel 82 Loi 78-17 (Frankreich).