Datenschutz-Folgenabschätzung (Art. 35 DSGVO) – MousePlayer Session Replay

1. Warum diese Folgenabschätzung erforderlich ist

Art. 35 Abs. 1 DSGVO verlangt eine Folgenabschätzung, wenn eine Form der Verarbeitung, insbesondere bei Verwendung neuer Technologien, aufgrund der Art, des Umfangs, der Umstände und der Zwecke der Verarbeitung voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen zur Folge hat. MousePlayer zeichnet das Verhalten von Websitebesuchern fortlaufend und standardmäßig auf: Zeigerbewegung, Klicks, Scrollen, Taps und Tabwechsel, dazu einen vollständigen Abzug der Seite, die der Besucher gesehen hat, und jede spätere Änderung daran, sowie den Text, den der Besucher in Formulare eingibt. Das aufgezeichnete Material wird gespeichert, wiedergegeben, bewertet und kann geteilt werden. Das ist kein Randfall von Art. 35 Abs. 1, das ist dessen Mitte.

Ein Punkt der Einordnung muss genau benannt statt nachgesprochen werden. Art. 35 Abs. 3 zählt drei Fälle auf, in denen eine Folgenabschätzung insbesondere erforderlich ist, und keiner der drei passt sauber. Buchstabe a betrifft die systematische und umfassende Bewertung auf der Grundlage automatisierter Verarbeitung, die als Grundlage für Entscheidungen mit Rechtswirkung oder ähnlich erheblicher Beeinträchtigung dient - die Bewertung gibt es hier (siehe Risiko R8), eine solche Entscheidung gegenüber Besuchern wurde jedoch nicht gefunden. Buchstabe b betrifft die umfangreiche Verarbeitung besonderer Kategorien nach Art. 9 - hier nicht beabsichtigt, wenngleich besondere Kategorien auf einem ungewollten Weg in die Aufzeichnung gelangen (Risiko R1), und die gemessenen Mengen auf diesem System sind nicht umfangreich. Buchstabe c betrifft die systematische Überwachung öffentlich zugänglicher Bereiche in großem Umfang und zielt auf die körperliche Beobachtung, nicht auf eine Website. Buchstabe b als Aufhänger für Session Replay anzuführen, wäre unzutreffend, und eine falsche Fundstelle ist das Erste, was eine Aufsichtsbehörde streicht.

Der richtige Weg ist Art. 35 Abs. 1 selbst, angewendet über die neun Kriterien der WP29-Leitlinien zur Folgenabschätzung (WP248 rev.01, vom EDSA bestätigt). Zwei Kriterien gelten allgemein als Hinweis auf ein hohes Risiko. Diese Verarbeitung erfüllt sechs oder sieben.

• Bewerten oder Einstufen - erfüllt. Jede Sitzung erhält engagement_score (0-255), session_quality und is_bot; bei der Erhebung im August 2026 gab es 4043 Merkmalszeilen und 3203 maschinell geschriebene Sitzungsprotokolle. Seither sind weitere Bewertungen und Ableitungen hinzugekommen (siehe R8).
• Automatisierte Entscheidungsfindung mit Rechtswirkung oder ähnlicher Wirkung - für Besucher nicht belegt. Belegt ist sie gegenüber Kunden und IP-Adressen (Auto-Ban, is_suspicious), und das ist eine andere Gruppe betroffener Personen.
• Systematische Überwachung - erfüllt, und zwar in der stärksten Form. Die Aufzeichnung ist fortlaufend, planmäßig und für die beobachtete Person unsichtbar, sobald das Banner weg ist.
• Sensible Daten oder Daten höchstpersönlicher Art - erfüllt. Formulareingaben, der vollständige Text der Seite so, wie er für diese Person dargestellt wurde, und ein minutengenaür Nachweis dessen, was sie gelesen hat und wo sie gezögert hat.
• Großvolumigkeit - nach den gemessenen Zahlen dieses Entwicklungssystems nicht erfüllt (Erhebung August 2026: 706 Sitzungen, 329 verschiedene Besucherkennungen, 7 Projekte, 4 Konten. Stand 16.10.2026: 8648 Sitzungen von Menschen mit 7363 verschiedenen Besucherkennungen seit dem 21.07.2026, davon 3515 verschiedene Kennungen in den letzten 30 Tagen, in 3 von 75 angelegten Projekten; daneben 186163 als Bot markierte Sitzungen der letzten 14 Tage, die nach Ablauf ihrer Frist gelöscht werden; 24 Konten, davon 19 erkennbare Testkonten). Erfüllt ist sie in der Absicht des Entwurfs, und der Entwurf kennt keine Obergrenze.
• Abgleich oder Zusammenführung von Datensätzen - erfüllt. MousePlayer.setUserId() und der automatische dataLayer-Pfad 'uid' heften die eigene Kennung des Kunden an die Aufzeichnung; der BigQuery-Export bringt visitor_id, custom_user_id und ip_address in das eigene Data Warehouse des Kunden.
• Schutzbedürftige betroffene Personen - mit guten Gründen erfüllt. Der Besucher kann nicht sehen, was aufgezeichnet wurde, kann es nicht überprüfen, und in 92 Fällen der Erhebung vom August 2026 ließ er sich mit seinen eigenen Datensätzen überhaupt nicht verbinden (Stand 16.10.2026: keine solche Sitzung; siehe R9).
• Innovative Nutzung - erfüllt. Vollständige DOM-Wiedergabe zusammen mit maschinell erzeugten Verhaltensprotokollen ist kein etabliertes, gut verstandenes Verfahren.
• Hinderung an der Ausübung eines Rechts oder der Nutzung eines Dienstes - in zwei engen Punkten erfüllt: der automatische IP-Bann beendet den weiteren Zugang, und die Zuordnungslücke (R9) macht Art. 15 und Art. 17 für einen Teil der gespeicherten Daten technisch unerfüllbar.

Art. 35 Abs. 4 verpflichtet jede Aufsichtsbehörde, eine Liste der Verarbeitungsvorgänge zu veröffentlichen, für die eine Folgenabschätzung verpflichtend ist. Zuständig ist hier die polnische UODO. auszufüllen: welche Einträge der aktuellen UODO-Liste nach Art. 35 Abs. 4 auf Session Replay zutreffen, und das Datum der geprüften Fassung der Liste

2. Rollen: Wen die Pflicht trifft, und wofür

MousePlayer nimmt zwei Stellungen zugleich ein, und die Antwort auf fast jede Frage in diesem Dokument hängt davon ab, nach welcher gefragt wird. Die Unterscheidung ist keine Frage der Darstellung, sie steht im Code. class/Server.class.php:416 sagt es im Quelltext selbst: 'REGEL B ... Hier sind wir AUFTRAGSVERARBEITER'.

Daten	Rolle von MousePlayer	Verantwortlicher	Folge
Besucher auf Kundenwebseiten: Aufzeichnungen, Seiteninhalt, Formulareingaben, Kennungen, abgeleitete Bewertungen	Auftragsverarbeiter (Art. 28)	Der MousePlayer-Kunde, der die Website betreibt	Die Pflicht aus Art. 35 trifft förmlich den Kunden. MousePlayer schuldet die Unterstützung nach Art. 28 Abs. 3 lit. f.
Eigene Kunden von MousePlayer: Konten, Abrechnung, Support, Zugriffsprotokolle des Portals, Änderungsprotokoll	Verantwortlicher (Art. 24)	LW IT Solutions Company Lukas Wójcik	MousePlayer schuldet die Abschätzung nach Art. 35 für diese Verarbeitung aus eigenem Recht - dieser Teil allein würde sie allerdings nicht auslösen.

Daraus folgt ein Ergebnis, das man deutlich aussprechen sollte, weil es häufig in beide Richtungen falsch gemacht wird. Die Verarbeitung, die eine Folgenabschätzung erfordert, ist genau die Verarbeitung, für die MousePlayer nicht Verantwortlicher ist. Ein Auftragsverarbeiter kann die Abschätzung des Verantwortlichen nicht an dessen Stelle durchführen, kann die Erforderlichkeitsfrage nicht für ihn entscheiden und kann die Aufsichtsbehörde nicht nach Art. 36 an seiner Stelle konsultieren. Was ein Auftragsverarbeiter kann und muss, ist dem Verantwortlichen alles zu liefern, was dieser braucht - die Beschreibung nach lit. a, die gemessenen Tatsachen nach lit. c und eine ehrliche Statusliste nach lit. d. Genau das ist dieses Dokument: MousePlayers eigene Abschätzung des eigenen Betriebs und die tatsächliche Grundlage, die der Kunde für die seine braucht.

3. Datenschutzbeauftragter: die Prüfung nach Art. 37

Ein Datenschutzbeauftragter ist nicht benannt. Art. 37 Abs. 1 bindet 'den Verantwortlichen und den Auftragsverarbeiter' gleichermaßen, die Frage ist also MousePlayers eigene und keine, die sich an Kunden weiterreichen lässt. Die drei gesetzlichen Fälle:

Art. 37 Abs. 1	Prüfung	Ergebnis nach den gemessenen Tatsachen
lit. a	Verarbeitung durch eine Behörde oder öffentliche Stelle	Nicht einschlägig. Die LW IT Solutions Company ist ein privates Unternehmen.
lit. b	Die Kerntätigkeit erfordert eine umfangreiche regelmäßige und systematische Überwachung betroffener Personen	Kerntätigkeit: ja, ohne Diskussion - die Überwachung ist das Produkt, keine Hilfsfunktion. Regelmäßig und systematisch: ja - fortlaufend, planmäßig, nach einem im Voraus festgelegten System. Umfangreich: nein, nach den gemessenen Zahlen (Erhebung August 2026: 706 Sitzungen, 329 Kennungen, 4 Konten; Stand 16.10.2026: 3515 verschiedene Besucherkennungen von Menschen in 30 Tagen; eine Entwicklungsinstanz).
lit. c	Die Kerntätigkeit besteht in der umfangreichen Verarbeitung von Daten nach Art. 9 oder Art. 10	Nicht der Bauart nach. Besondere Kategorien gelangen gleichwohl auf dem in Risiko R1 beschriebenen Weg in den gespeicherten Seiteninhalt. Das ist beiläufig statt konstitutiv, der Fall ist heute also nicht erfüllt - er wird jedoch vertretbar, sobald ein Kunde aus dem Gesundheits-, Rechts- oder Finanzbereich aufgenommen wird.

WP243 (vom EDSA bestätigt) beurteilt 'umfangreich' nach der Zahl der betroffenen Personen, dem Umfang und der Bandbreite der Daten, der Dauer und der geografischen Reichweite. Drei dieser vier Faktoren stehen hier bereits am Anschlag: die Bandbreite ist die vollständige Rekonstruktion der Sitzung der Person, die Dauer ist fortlaufend, und die geografische Reichweite ist die des Publikums der Kunden. Nur die Kopfzahl ist klein. Damit die Schwelle nicht zu spät bemerkt wird, zählt srv/cron_status.php seit dem 19.08.2026 einmal täglich die verschiedenen Besucherkennungen von Menschen der letzten 30 Tage (ohne 'unknown' und ohne als Bot markierte Sitzungen), hält die Zahl gegen die Schwelle von 100000 Endnutzern je Monat und meldet eine Überschreitung sowie die fällige jährliche Wiedervorlage per E-Mail. Stand 16.10.2026: 3515.

Zweierlei folgt daraus, und beides sind Empfehlungen, keine Rechtsaussagen. Erstens: jetzt eine schriftliche Schwellenbewertung festhalten, mit einer benannten Zahl überwachter Endnutzer, ab der die Benennung von selbst erfolgt, und einem festen Prüfabstand - damit die Entscheidung als getroffen dokumentiert ist und nicht bloß als noch nicht getroffen. Zweitens: Art. 37 Abs. 4 erlaubt es dem Recht der Mitgliedstaaten, die Benennung in weiteren Fällen vorzuschreiben. auszufüllen: rechtliche Bestätigung, ob das polnische Recht nach Art. 37 Abs. 4 über Art. 37 Abs. 1 hinaus eine Benennungspflicht begründet. Schwellenwert und Prüfabstand sind entschieden: mehr als 100000 beobachtete Endnutzer je Monat, mindestens jährlich

Art. 35 Abs. 2 verlangt, dass der Verantwortliche bei der Durchführung einer Folgenabschätzung den Rat des Datenschutzbeauftragten einholt, sofern ein solcher benannt ist. Da keiner benannt ist, entfällt dieser Schritt, und das Unterbleiben ist kein Mangel. Freigegeben von Lukas Wójcik, Inhaber, am 17.08.2026. Externer Datenschutzrat wurde nicht eingeholt. Überprüft wird jährlich und bei jeder Änderung der Verarbeitung; die datierten Fassungen liegen im Versionsverwaltungssystem unter ai/cms/.

4. Vorgehen, Quellen und die Grenzen dieses Entwurfs

Jede Tatsachenaussage in diesem Dokument wurde am laufenden System gemessen - Quelltext, Datenbankschema, Zeilenzahlen, Prozessliste, Konfigurationswerte und Protokolldateien - statt aus Produktbeschreibungen oder aus dem übernommen, was die Software tun soll. Wo eine Messung einer Absicht widerspricht, wird die Messung berichtet. Wo sich eine Tatsache nicht feststellen ließ, steht an ihrer Stelle ein Platzhalter; keine Zahl wurde geschätzt und keine Aufbewahrungsfrist erfunden.

• Gemessen wurde das Entwicklungssystem (APP_ENV=dev). Mehrere Zahlen sind deshalb Artefakte von Testdaten und als solche gekennzeichnet - am wichtigsten die Einwilligungsnachweise, bei denen 671 von 706 Sitzungen consent_source='testdata' mit NULL-Zeitstempel tragen, geschrieben von ai/devdata/001_altsitzungen_markieren.sql (Erhebung August 2026; Stand 16.10.2026: 566 von 8648 Sitzungen von Menschen).
• Einige Messungen liegen Minuten auseinander und weichen deshalb geringfügig voneinander ab (705 gegen 706 Sitzungen; 36409 Protokollzeilen gegen 36542 geprüfte Adressen). Beide Zahlen werden so berichtet, wie sie gemessen wurden, statt nachträglich abgeglichen.
• Ein Zugang mit root-Rechten stand nicht zur Verfügung. Die Jail-Konfiguration von fail2ban, die crontabs von root und www-data und die Ankunft der ausgelagerten Sicherung am Ziel ließen sich deshalb nicht überprüfen. Jedes davon ist als ungeprüft gekennzeichnet statt unterstellt. Nachgetragen: die Umstellung der Sicherung hat der Inhaber seither mit root-Rechten vorgenommen, und die Ankunft der ausgelagerten Sicherung am Ziel ist seit dem 11.08.2026 belegt, weil der tägliche Lauf sie selbst protokolliert und nachprüft - für den 11.08.2026 und den 12.08.2026 liegt sie vor (siehe R5). Nachgeprüft am 16.10.2026: fail2ban führt neun Jails, darunter mp-nginx-429 für Adressen, die wiederholt die Ratenbegrenzung von nginx auslösen. Die geplanten Läufe von MousePlayer stehen in /etc/cron.d/mouseplayer und laufen über srv/cron_run.sh unter dem eigenen Konto mouseplayer-dev; unter diesem Konto laufen auch die Worker-Dienste. Die tägliche Sicherung wird weiterhin aus dem cron von root gestartet, der tägliche Löschlauf weiterhin im db_worker-Prozess.
• Die vendor-Verzeichnisse (Stripe-SDK, Google-Cloud-SDK, PHPMailer, Symfony) wurden nicht nach ausgehenden Endpunkten durchsucht. Der eigene Code wurde erschöpfend nach curl_init, curl_exec, file_get_contents auf http, fsockopen und stream_context_create sowie nach allen https-Literalen durchsucht.
• Eine Zahl dieser Abschätzung - 92 Sitzungen mit visitor_id 'unknown' - wurde bei der Erhebung im August 2026 als belegte Messung übernommen, weil sie sich damals nicht nachmessen ließ. Nachgemessen am 16.10.2026: keine Sitzung trägt mehr die visitor_id 'unknown'. Der Code kann den Wert beim Anlegen einer Sitzung weiterhin schreiben (srv/db_worker.php); R9 bleibt deshalb als Möglichkeit bestehen.

5. (a) Systematische Beschreibung der Verarbeitungsvorgänge und der Zwecke

5.1 Wie die Aufzeichnung funktioniert

Der Kunde bindet eine statische JavaScript-Datei (www/mp.js) auf seiner Website ein. Bevor etwas aufgezeichnet wird, müssen sich zwei Riegel öffnen. Zuerst läuft eine Bot-Prüfung, die bei automatisierten Browsern abbricht. Dahinter steht der Einwilligungs-Zustandsautomat mpEinw, der den Aufbau des Trackers nur bei einem positiven Einwilligungssignal zulässt - aus dem eigenen API-Aufruf des Kunden, aus dem Google Consent Mode, aus einem unterstützten CMP oder aus einem TCF-String. Jeder andere Ausgang, einschließlich gar keines Signals, eines CMP, das nicht lädt, eines Skriptfehlers und einer unbekannten Herkunft, führt zu keiner Aufzeichnung. Der Leitsatz steht in den Arbeitsnotizen des Projekts und trägt durch den gesamten Code: im Zweifel nicht aufzeichnen.

Sobald es erlaubt ist, öffnet das Skript einen verschlüsselten WebSocket (/mp_wss/) zum Aufzeichnungsserver. Die TLS-Verschlüsselung endet in nginx; der WebSocket-Server selbst (srv/server.php) lauscht nur auf der Loopback-Adresse 127.0.0.1:8081 und erhält die Verbindung von dort innerhalb desselben Rechners unverschlüsselt. Der Server wendet den Riegel ein zweites Mal an, unabhängig vom Browser: class/Server.class.php:977-1004 lässt nur GRANTED oder GRANTED_LATE oder eine ausdrückliche Regionsfreigabe durch und schließt die Verbindung bei einem Widerruf, einem unbekannten Land und allem Unklaren mit Code 1008. Davor läuft eine Ausschlussliste für Pfade, die nur auf den Pfad passt und nicht auf die volle Adresse. Kommt der WebSocket dreimal hintereinander nicht zustande (ein Proxy oder eine Firewall blockt den Verbindungsaufbau), schickt das Skript dieselben Nachrichten stattdessen per HTTPS-POST an /mp_wst; dieser Endpunkt entscheidet nichts und reicht sie an denselben Serverprozess weiter, wo sie denselben Riegel durchlaufen (www/api/ws_tunnel.php, class/HttpTunnel.class.php). Ein Seitenabbild, das größer als 1 MB ist, lädt das Skript per HTTPS-POST an /mp_dom hoch (www/api/dom_upload.php); der Endpunkt prüft einen vom Server signierten, zeitlich begrenzten Zugang, legt das Abbild höchstens 120 Sekunden in Redis ab und entscheidet sonst nichts - eingelöst wird es von derselben Verbindung, die die Riegel bereits durchlaufen hat. Daneben zählt /mp_wsfail fehlgeschlagene WebSocket-Verbindungen je Projekt, ohne Besucherkennung; die IP-Adresse wird dort nur als Hashwert zum Entprellen verwendet und verfällt nach einer Stunde. Ereignisse laufen über Redis in eine Warteschlange und werden von einem dauerhaft laufenden Worker (srv/db_worker.php) nach MariaDB geschrieben.

Gespeichert wird kein Video. Gespeichert wird die Seite selbst: eine serialisierte Kopie des DOM im Augenblick des Seitenaufrufs, dazu jede spätere Änderung daran, später in einem iframe wiedergegeben mit den aufgezeichneten Zeigerpositionen darüber. Diese Unterscheidung ist für die Risikobewertung wesentlich, denn sie bedeutet: das gespeicherte Material enthält alles, was die Seite enthielt - auch Text, den der Besucher nie getippt und nie als 'Daten' wahrgenommen hat.

5.2 Verzeichnis der Verarbeitungsvorgänge

Zweck	Rolle	Wesentliche Tabellen	Löschung (Stand 23.09.2026)
Verhaltensaufzeichnung: Bewegung, Klicks, Scrollen, Taps, Tabwechsel	Auftragsverarbeiter	mouse_events (225892 Zeilen, 322,6 MB), session_pageviews, visitor_sessions	Täglicher Löschlauf nach Tarif, überwacht (siehe R7)
Seiteninhalt: DOM-Schnappschuss und laufende Änderungen, um die Seite so wiederzugeben, wie sie gesehen wurde	Auftragsverarbeiter	session_pageviews.payload_blob (1848 Zeilen, 162,9 MB), mouse_events.target_selector für Mutationen (66153 Zeilen)	Derselbe Löschlauf
Formulareingaben, Zeichen für Zeichen, maskiert nach eingestellter Stufe	Auftragsverarbeiter	mouse_events.target_selector bei input-Ereignissen (599 Zeilen)	Derselbe Löschlauf; zu den 173 Altzeilen siehe R2
Wiedererkennung desselben Besuchers über Sitzungen und Seitenaufrufe hinweg	Auftragsverarbeiter	visitor_sessions.visitor_id / custom_user_id, visitor_nicknames (329 Zeilen)	visitor_nicknames: mit der letzten Sitzung des Besuchers
Netz- und Grobstandortbestimmung	Auftragsverarbeiter	visitor_sessions.ip_address, country, city, asn_number, asn_org; ip_lifetime_stats (446 Zeilen)	ip_lifetime_stats: 365 Tage
Nachweis der Einwilligung und ihrer Wechsel (Art. 7 Abs. 1)	Auftragsverarbeiter, gehalten für die Beweislast des Kunden	consent_events (120 Zeilen), visitor_sessions.consent_*	730 Tage ab dem Widerruf; bis dahin absichtlich, denn es ist der Beleg dafür, dass widerrufen wurde
Benutzerdefinierte Ereignisse, Frustrationssignale, JavaScript-Fehler	Auftragsverarbeiter	session_custom_events (823), session_custom_event_params (1264)	Derselbe Löschlauf
Abgeleitete Merkmale und maschinell geschriebene Sitzungsprotokolle	Auftragsverarbeiter	ai_session_features (4043), ai_timelines (3203 Zeilen, 5,5 MB)	Mit der Sitzung, in derselben Löschkette
Betrieb der eigenen Kundenkonten von MousePlayer	Verantwortlicher	users (4), user_ip_history (5), workspace_users, workspace_invites	Mit dem Konto; untätige Konten nach 24 Monaten und einer zugestellten Warnung
Zugriffs-, Sicherheits- und Änderungsprotokolle des Portals	Verantwortlicher	mouseplayer_logs (36409), security_access_logs (1354), audit_logs (666), banned_ips	60 Tage / 72 Stunden / 60 Tage / bei Ablauf
Supportanfragen	Verantwortlicher	support_requests	730 Tage
Zusammenarbeit am Replay: Kommentare und Freigabe-Links	Gemischt - Verantwortlicher für den Verfasser, Auftragsverarbeiter für den aufgezeichneten Inhalt	session_comments (12), session_shares (9)	Kommentare mit der Sitzung; Freigabe-Links 90 Tage nach ihrem Ablauf
Annahme der regionsbezogenen Aufzeichnungsregeln durch den Kunden	Verantwortlicher	consent_region_acceptances (0 Zeilen)	730 Tage

5.3 Rechtsgrundlage

Für alles im Aufzeichnungsweg ist die Grundlage die Einwilligung, und die Begründung steht in der Migration, die die Einwilligungsarchitektur eingeführt hat (ai/migrations/018_consent.sql): die Aufzeichnung ist Verhaltensbeobachtung im Sinne des Erwägungsgrundes 24 und Zugriff auf das Endgerät nach der polnischen Umsetzung der ePrivacy-Regeln, sie ist einwilligungspflichtig, und ein berechtigtes Interesse trägt sie nicht. Alle 7 Projekte stehen auf consent_mode='required'. Der Notaus site_settings.consent_gate_active ist an. Diese Bewertung ist zutreffend und ungewöhnlich gut dokumentiert; sie wird an keiner Stelle des Codes aufgeweicht.

Für vier Verarbeitungen weist der Code überhaupt keine Grundlage aus: den eigenen Kontenbetrieb von MousePlayer, die Zugriffs- und Sicherheitsprotokolle des Portals, Supportanfragen und Kommentare am Replay. Das sind die Verarbeitungen in der Verantwortlichenrolle. Berechtigtes Interesse (Art. 6 Abs. 1 lit. f) und Vertragserfüllung (Art. 6 Abs. 1 lit. b) sind die naheliegenden Kandidaten, aber ein Kandidat ist keine Festlegung, und Art. 6 Abs. 1 lit. f verlangt eine dokumentierte Abwägung. Beantwortet am 17.08.2026: Konto- und Abrechnungsdaten Art. 6 Abs. 1 lit. b, für die Aufbewahrung der Rechnungen lit. c (fünf Jahre ab Ende des Kalenderjahres, in dem die Zahlungsfrist der Steuer ablief). Zugriffs-, Sicherheits- und Änderungsprotokolle sowie reCAPTCHA und die Serverprotokolle: lit. f, Zweck Missbrauchsabwehr und Nachvollziehbarkeit; die Abwägungen stehen im Verzeichnis unter B.2 und B.5. Die Demonstration auf der Startseite: Einwilligung, lit. a. Supportanfragen: lit. b, soweit die anfragende Person Kunde ist und die Anfrage den Vertrag betrifft, sonst lit. f (Verzeichnis, B.3). Kommentare und Freigabe-Links am Replay verarbeitet MousePlayer auf Weisung des Kunden (Verzeichnis, A.9).

5.4 Empfänger und Drittlandtransfers

Innerhalb des Aufzeichnungswegs wurde kein einziger ausgehender Aufruf an einen Dritten gefunden. Die Geo-Auflösung läuft gegen lokale MaxMind-Dateien statt gegen einen Webdienst - eine bewusste, im Code festgehaltene Entwurfsentscheidung, damit vor Vorliegen der Einwilligung kein Dritter kontaktiert wird. Schriften, Flaggen und Skripte werden lokal ausgeliefert. Das ist ein wirklich gutes Ergebnis und sollte auch so benannt werden.

Empfänger	Was übertragen wird	Stand heute
Der Kunde	Alles Aufgezeichnete, über das Dashboard und die drei Player-Endpunkte	Aktiv - das ist der Zweck
Jeder Inhaber eines Freigabe-Links, ohne jede Anmeldung	Die vollständige Wiedergabe einer Sitzung	Aktiv; Stand 16.10.2026: 5 Freigabe-Links angelegt; jeder Abruf wird mit Zeitpunkt, IP-Adresse und Browserkennung protokolliert (share_views)
Google Cloud Storage, Warschau (bis 05.09.2026: Google Drive, USA)	Täglich eine vollständige Kopie jeder Datenbank und des gesamten Webverzeichnisses. Bis 11.08.2026 unverschlüsselt. Seit 11.08.2026 auf dem eigenen Server verschlüsselt, bevor sie übertragen wird	Täglich aktiv. Übertragung im Klartext beendet am 11.08.2026; der unverschlüsselte Altbestand bei Google wurde am 12.08.2026 gelöscht. Seit 05.09.2026 Firmenkonto, Region europe-central2 (Warschau), gedeckt von den Google-Cloud-Datenverarbeitungsbedingungen; die Kopien auf dem früheren Drive-Konto wurden am 06.09.2026 gelöscht - siehe Risiko R5
Stripe (USA / Irland)	E-Mail, Name, Rechnungsanschrift und Zahlungsdaten des Kunden - keine Besucherdaten	Nur Testschlüssel; Produktivschlüssel leer
Namecheap Private Email (E-Mail-Versand über SMTP)	Empfängeradresse, Betreff und Inhalt ausgehender E-Mails an Kunden und an den Betreiber, etwa Kontobestätigung, Passwortzurücksetzung, Einladungen, Anmeldemeldungen für neue Geräte, Warnung vor der Löschung untätiger Konten, Mitteilungen geänderter Vertragsunterlagen, Wochenbericht, Supportantworten, Meldungen zu Markierungen und Auffälligkeiten sowie Systemmeldungen	Aktiv seit 23.09.2026, Absender office@mouseplayer.com; in der Liste der Unterauftragsverarbeiter geführt
Telegram (außerhalb der EU)	Bis 11.08.2026: Supportanfragen vollständig, einschließlich der ungekürzten IP-Adresse und des gesamten Nachrichtentextes. Seit 11.08.2026: ausschließlich der feste Satz "MousePlayer: es liegt eine neue Supportanfrage vor." - keine Variable, keine Vorgangsnummer, kein Link; damit gehen über diesen Kanal keine personenbezogenen Daten mehr hinaus	Kanal weiterhin aktiv (Token in .env gesetzt), seit 11.08.2026 aber kein Empfänger personenbezogener Daten und damit kein Auftragsverarbeiter
Google reCAPTCHA (USA)	Anmelde-, Registrierungs-, Support- und Abrechnungsseiten	Auf diesem System aus (APP_ENV=dev); in Produktion aktiv
Google BigQuery (eigenes Projekt des Kunden)	session_id, visitor_id, custom_user_id, ip_address, country, referrer, User-Agent, Bildschirmmaße, Zeitstempel, Gerätetyp	Inaktiv: bei allen 7 Projekten abgeschaltet, und der Prozess läuft nicht
Vom Kunden bestimmte Webhook-URL (Ziel unbegrenzt)	Ereignisdaten samt einem direkten Player-Link zur Sitzung	Inaktiv: bei allen 7 Projekten abgeschaltet, Dispatcher-Prozess läuft

5.5 Aufbewahrung, gemessen statt beabsichtigt

Es gibt einen automatischen Löschlauf, und er läuft. Er steht im dauerhaft laufenden Worker-Prozess (srv/db_worker.php) und wird beim Prozessstart und danach einmal je Kalendertag ausgeführt; die Fristen für als Bot markierte Sitzungen räumt derselbe Prozess stündlich. Einen eigenen cron-Eintrag hat der Löschlauf nicht. Sein Ausbleiben bleibt aber nicht mehr still: der Worker hinterlegt sein Ergebnis, und srv/cron_status.php - ein anderer Prozess - bewertet es, meldet einen Lauf, der länger als 48 Stunden zurückliegt, per E-Mail und führt die Störung als Eintrag in den Urgent Logs des Administrationsbereichs. Die übrigen geplanten Läufe stehen in /etc/cron.d/mouseplayer; Fehlschläge und zu lange Pausen dieser Läufe meldet derselbe Statusprozess ebenso (Stand 16.10.2026).

Bei der Erhebung im August 2026 hatte der Lauf noch nichts gelöscht: alle Projekte gehörten einem Eigentümer im enterprise-Tarif mit 365 Tagen Aufbewahrung, und die älteste Sitzung war 20 Tage alt. Stand 16.10.2026 löscht er nachweislich: die Fristen für Protokolle und Ableitungen greifen (der älteste Eintrag in audit_logs liegt an der Frist von 60 Tagen), als Bot markierte Sitzungen werden nach 14 Tagen gelöscht und ihre Aufzeichnungen nach der eigenen Frist geleert (Frist in Tagen: 1). Die Tariffrist für Sitzungen von Menschen hat bisher keine Sitzung erreicht, weil die beiden Projekte mit echtem Besucherverkehr weiterhin einem Eigentümer im enterprise-Tarif mit 365 Tagen gehören und ihre ältesten Sitzungen vom 21.07.2026 stammen.

6. (b) Bewertung der Notwendigkeit und der Verhältnismäßigkeit

Notwendigkeit und Verhältnismäßigkeit werden am erklärten Zweck gemessen: einem Websitebetreiber zu ermöglichen zu verstehen, wie Besucher seine Seite nutzen, wo sie hängen bleiben und warum sie abbrechen. Dieser Zweck ist legitim, und das Verfahren ist grundsätzlich geeignet, ihm zu dienen. Die Frage nach Art. 35 Abs. 7 lit. b ist enger und härter: ist diese Verarbeitung in dieser Detailtiefe für diesen Zweck notwendig - und steht der Eingriff im Verhältnis zum Nutzen?

Bestandteil	Für den Zweck notwendig?	In der gebauten Form verhältnismäßig?
Zeigerbewegung, Klicks, Scrollen, Taps	Ja. Das ist das Signal, um das es dem Zweck geht.	Ja.
Struktur und Layout der besuchten Seite	Ja. Koordinaten sind ohne das Layout, auf das sie sich beziehen, bedeutungslos.	Im Grundsatz ja.
Vollständiger Textinhalt der Seite, wörtlich	Nein - jedenfalls nicht allgemein. Um zu verstehen, wo ein Besucher hängen blieb, braucht es die Struktur und die Beschriftungen, nicht den darin dargestellten personenbezogenen Inhalt.	Nein, so wie gebaut. Die Maskierung muss je Element angefordert werden; die Vorgabe ist, alles zu speichern. Siehe R1.
Formulareingaben	Streitig. Zu wissen, dass ein Feld abgebrochen wurde, ist wertvoll; zu wissen, was hineingetippt wurde, ist selten notwendig.	Teilweise. Der Maskierungsboden ist stark und alle Projekte laufen auf der strengsten Stufe - der Entwurf lässt aber weiterhin schwächere Stufen zu, und die Beschriftung dieser Einstellung ist umgekehrt (Stufe 0 ist die strengste, der Dashboard-Tipp behauptet das Gegenteil).
Zustand von Checkbox und Radio	Streitig.	Nein. Diese werden auf keiner Stufe je maskiert - und eine Checkbox kann eine Gesundheitsangabe, eine politische Zugehörigkeit oder eine Einwilligung in einen sensiblen Zweck tragen.
Wiedererkennung über Sitzungen hinweg	Ja für die Auswertung wiederkehrender Besucher; nicht für den Kernzweck.	Bedingt. Die pseudonyme Wiedererkennung ist verhältnismäßig; bei der vom Kunden gesetzten Klarkennung endet die Verhältnismäßigkeit. Siehe R6.
IP-Adresse	Ja für die grobe Standortzuordnung (Land; die Stadt nur aus der bereits gekürzten Adresse) und die Missbrauchsabwehr.	Ja, für die Zukunft: die Adresse wird unmittelbar nach dem Auslesen gekürzt, bevor irgendein Verbraucher sie sieht. Der Altbestand im Aufzeichnungsweg ist am 17.08.2026 bereinigt worden; siehe R3.
Bewertung und Sitzungsprotokolle	Nein. Das sind Bequemlichkeiten für den Sichtungsablauf des Kunden.	Fraglich, und der am wenigsten geprüfte Teil des Systems - nirgends im Code ist dafür eine Rechtsgrundlage ausgewiesen.
Vollständige ausgelagerte Kopie (bis 05.09.2026 zu einem Drittlandanbieter)	Eine ausgelagerte Sicherung ja - sie dient der Verfügbarkeit (Art. 32 Abs. 1 lit. c). Ihr Umfang geht über diesen Dienst hinaus: sie enthält jede Datenbank des Rechners.	Seit 05.09.2026 ja, mit einer Einschränkung beim Umfang. Die Kopie wird vor der Übertragung verschlüsselt und liegt in einer europäischen Region unter einem Vertrag nach Art. 28. Bis 05.09.2026 nein: ohne festgestellten Vertrag, bis 11.08.2026 unverschlüsselt. Siehe R5.

Bei der Datenminimierung (Art. 5 Abs. 1 lit. c) zeigt das System zwei gegensätzliche Gesichter. Bewusste Minimierung ist an mehreren Stellen sichtbar und im Code gut begründet: Feldnamen werden klassifiziert statt übertragen, weil ein roher Feldname in einem Shop oft sprechend genug ist, um auf die Person zu schließen; der TCF-String wird nur als SHA-256 gespeichert; der Replay-Payload ist bewusst von der öffentlichen API ausgenommen. Dem steht die zentrale Entwurfsentscheidung gegenüber, die gesamte Seite standardmäßig wörtlich zu speichern, und die ist das Gegenteil von Minimierung und wird durch nichts von alledem aufgewogen.

Bei der Speicherbegrenzung (Art. 5 Abs. 1 lit. e) war die Bewertung bis zum 17.08.2026 eindeutig und ungünstig. Dreizehn Tabellen mit personenbezogenen Daten hatten überhaupt keine Löschfrist, darunter die beiden mit dem am besten lesbaren Material: ai_timelines, die jede Sitzung als lesbaren Fließtext enthält, und visitor_nicknames. Der Lauf, den es gab, war nie gegen echte Daten gelaufen. Ein Aufbewahrungskonzept, das noch nie einen Datensatz gelöscht hat, ist ein Plan und keine Schutzmaßnahme. Seit dem 17.08.2026 haben alle dreizehn Tabellen eine Frist, der Löschlauf löscht nachweislich, und sein Ausbleiben wird gemeldet (siehe R7).

7. (c) Bewertung der Risiken für die Rechte und Freiheiten der betroffenen Personen

Die Risiken werden für die betroffene Person bewertet, nicht für das Unternehmen. Die Eintrittswahrscheinlichkeit ist mit fern, möglich, wahrscheinlich oder eingetreten bewertet - 'eingetreten' heißt, dass das Ereignis keine Prognose ist, sondern ein gegenwärtiger, gemessener Zustand der Daten. Die Schwere ist mit begrenzt, erheblich, schwer oder sehr schwer bewertet, beurteilt danach, was die betroffene Person zu verlieren hat: nicht Peinlichkeit, sondern die Offenlegung von Gesundheits-, Finanz- oder anderen geschützten Merkmalen, den Verlust der Kontrolle über die Identifizierbarkeit und die Unmöglichkeit, ein Recht auszuüben.

Nr.	Risiko	Wahrscheinlichkeit	Schwere	Stufe
R1	Besondere Kategorien personenbezogener Daten im aufgezeichneten Seiteninhalt	Wahrscheinlich	Sehr schwer	Sehr hoch
R2	Unmaskierte Formulareingaben in Altdaten (173 Zeilen) - Einstufung aus der Erhebung; die Zeilen wurden am 17.08.2026 gelöscht, eine Neubewertung durch den Verantwortlichen steht aus	Eingetreten	Erheblich	Hoch
R3	Ungekürzte IP-Adressen in Altdaten und Portalprotokollen - Einstufung aus der Erhebung; der Altbestand wurde am 17.08.2026 gekürzt, die Portalprotokolle tragen seither Fristen, eine Neubewertung steht aus	Eingetreten	Erheblich	Hoch
R4	Freigabe-Links geben eine vollständige Wiedergabe ohne jede Anmeldung frei	Möglich	Schwer	Hoch
R5	Täglicher ausgelagerter Vollabzug - bis 11.08.2026 unverschlüsselt, seit 11.08.2026 vor der Übertragung auf dem eigenen Server verschlüsselt; der unverschlüsselte Altbestand wurde beim Anbieter am 12.08.2026 gelöscht. Seit 05.09.2026 liegt die Kopie in einem Bucket bei Google Cloud Storage in der Region europe-central2 (Warschau) unter einem Firmenkonto, gedeckt von den Google-Cloud-Datenverarbeitungsbedingungen; die Kopien auf dem früheren Drive-Konto wurden am 06.09.2026 gelöscht. Der Umfang ist unverändert. Gehen beide Schlüsseldateien verloren, ist die Sicherung unwiederbringlich; ausgedruckte Fassungen liegen im Safe	Fern (neu bewertet am 17.09.2026). Bis dahin: Übertragung im Klartext bis 11.08.2026, Übermittlung ohne festgestellte Rechtsgrundlage bis 05.09.2026 - beides eingetreten und beendet	Sehr schwer	Mittel - neu bewertet am 17.09.2026; bis 05.09.2026 sehr hoch. Die Bedingung aus der Bewertung (Entfernung der alten Skripte) ist am 16.10.2026 erfüllt; die Neubewertung von R5 liegt beim Verantwortlichen
R6	Wiedererkennung über Sitzungen hinweg und Zusammenführung mit dem Bestand des Kunden	Wahrscheinlich	Schwer	Hoch
R7	Keine Löschfrist für dreizehn Tabellen; seit 17.08.2026 behoben, der Löschlauf läuft täglich und wird überwacht	Fern (neu bewertet am 23.09.2026). Bis 17.08.2026: eingetreten	Schwer	Gering - neu bewertet am 23.09.2026; bis 17.08.2026 hoch
R8	Automatisierte Bewertung und Einstufung jeder Sitzung	Wahrscheinlich	Erheblich	Mittel
R9	92 Sitzungen über keine Kennung erreichbar; kein Weg von der Person zum Datensatz - Einstufung aus der Erhebung; Stand 16.10.2026 keine solche Sitzung, Selbstauskunft seit 17.08.2026, eine Neubewertung steht aus	Eingetreten	Erheblich	Hoch
R10	Keine Verschlüsselung im Ruhezustand, kein TLS zur Datenbank, Redis ohne Zugriffsschutz (bis 16.08.2026; seither zugangsbeschränkt, Datenbank und Redis zusätzlich im lokalen Netz erreichbar - eine Neubewertung steht aus)	Möglich	Sehr schwer	Mittelhoch
R11	Kein Protokoll darüber, wer welche Aufzeichnung angesehen hat	Eingetreten	Erheblich	Mittelhoch
R12	Qualität der Einwilligungsnachweise; ungeprüft gebliebene CMP-Adapter	Eingetreten (Entwicklungsdaten)	Schwer	Mittel
R13	Supportanfragen an Telegram einschließlich der ungekürzten IP - bis 11.08.2026; seit 11.08.2026 geht nur noch ein fester Hinweistext ohne jede Variable hinaus. Es bleibt die örtliche Speicherung der Anfrage samt E-Mail-Adresse und IP in support_requests; seit dem 17.08.2026 mit einer Frist von 730 Tagen (siehe R7)	Übermittlung: behoben am 11.08.2026. Örtliche Speicherung: eingetreten	Erheblich - bis 11.08.2026 für die Übermittlung, seither nur noch für die örtliche Speicherung	Behoben am 11.08.2026 für die Übermittlung; die verbliebene örtliche Speicherung wird unter R7 geführt (dort: gering seit 23.09.2026)
R14	Ausleitung an Empfänger, die der Verantwortliche selbst wählt — ein Löschverlangen erreicht sie nicht	Möglich (abhängig davon, ob der Verantwortliche eine Brücke einschaltet; im Bestand: keine eingeschaltet)	Erheblich	Mittel

R1 - Besondere Kategorien personenbezogener Daten im aufgezeichneten Seiteninhalt

Das ist das schwerwiegendste Risiko des Systems und das am wenigsten sichtbare, denn nichts daran sieht nach einem Mangel aus. Die Maskierung des Seitenabbilds wirkt nur innerhalb markierter Bereiche (www/mp.js:3934-3970): innerhalb eines Elements mit data-mp-mask oder der Klasse .mp-masked wird jedes Nicht-Leerzeichen ersetzt und jedes Attribut außerhalb einer Positivliste auf [FILTERED] gesetzt. Alles Übrige wird wörtlich gespeichert. Die Maskierung ist damit eine Opt-in-Auszeichnung, die der Kunde Element für Element auf einer Seite anbringen muss, die er womöglich nicht vollständig beherrscht.

Die Folge ist, dass der Schutz das erfasst, was der Besucher eingibt, und nicht das, was die Seite zurückgibt. Eine Bestätigungsseite einer Arztpraxis mit einem Termin bei einer benannten Fachrichtung; ein Apothekenwarenkorb; ein Versicherungsangebot mit Vorerkrankungen; ein Kontoauszug; eine Aufnahmezusammenfassung einer Rechtsberatung - all das ist Seitenausgabe außerhalb jedes Eingabefeldes, und all das landet unverändert in payload_blob. Das ist nicht hypothetisch: 1848 Zeilen sind befüllt, im Mittel 90,3 kB, und eine Stichprobe bestätigt, dass der gespeicherte Wert mit dem vollständigen <html>-Dokument beginnt. Dasselbe gilt für jede spätere Änderung der Seite, serialisiert als HTML-Fragmente in mouse_events.target_selector über 66153 Mutationszeilen.

Wahrscheinlichkeit - wahrscheinlich. Der Schutzmechanismus verlangt eine bewusste Handlung von jemandem, der nicht die gefährdete Person ist, speichert im Vorgabezustand alles und hat keine Erkennung, keine Warnung und keinen Bericht, der einem Kunden sagt, dass unmaskierte personenbezogene Inhalte erfasst werden. Nichts im System zieht Stichproben aus dem gespeicherten Payload auf die Muster, die darauf hinweisen würden. Die Wahrscheinlichkeit, dass wenigstens eine Kundenseite Daten besonderer Kategorien darstellt, liegt über jeden nennenswerten Betriebszeitraum nahe bei eins.

Schwere - sehr schwer. Daten nach Art. 9 Abs. 1 genießen den höchsten Schutz, und keine der Ausnahmen des Art. 9 Abs. 2 steht hier zur Verfügung. Die Einwilligung des Besuchers in die Sitzungsaufzeichnung ist keine ausdrückliche Einwilligung in die Verarbeitung von Gesundheitsdaten, und sie könnte es nicht sein - weder der Besucher noch der Kunde noch MousePlayer weiß zu diesem Zeitpunkt, dass solche Daten erfasst werden. Das Material wird wörtlich gespeichert, ist vollständig wiedergebbar, ist exportierbar, ist Teil des täglichen ausgelagerten Vollabzugs (R5) und kann per Freigabe-Link an einen nicht identifizierten Dritten gegeben werden (R4).

R2 - Unmaskierte Formulareingaben in Altdaten

173 Zeilen in mouse_events enthalten Formulareingabewerte im Klartext. Sie wurden über einen Mustervergleich auf der gespeicherten Struktur gefunden ('"v":"' gefolgt von einem anderen Zeichen als dem Maskierungszeichen), fallen in den Zeitraum vom 21. bis 27. Juli 2026 und enthalten unter anderem den vollen Namen einer Person. Am 10. August 2026 geschriebene Zeilen sind maskiert, das laufende Verhalten ist also inzwischen richtig: alle 7 Projekte laufen mit smart_masking=0, was entgegen der Beschriftung die strengste Einstellung ist und jedes Zeichen jedes Feldes ersetzt, und ein unbedingter Boden ersetzt Kennwörter und Zahlungsdaten auf jeder Stufe.

Wahrscheinlichkeit - eingetreten. Das ist keine Prognose. Die Zeilen existieren jetzt, und weil mouse_events nur über den Tarif-Purge geleert wird - der nichts löscht, bevor ein Datensatz 365 Tage alt ist, und der noch nie ausgeführt wurde - bleiben sie mindestens bis Juli 2027 stehen, sofern sie nicht von Hand entfernt werden. Die Wahrscheinlichkeit einer Wiederholung ist für die Zukunft gering.

Schwere - erheblich. Die bekannten Stichproben sind harmlos, aber der Inhalt der übrigen Zeilen ist nicht klassifiziert, und zu den Feldkategorien, die das System kennt, gehören E-Mail, Telefon, Zahlung, Anschrift und Name. Ob der unbedingte Boden für Kennwörter und Zahlungsdaten in jenem Zeitraum bereits stand, ist nicht festgestellt. Erledigt am 17.08.2026: die Zeilen sind ungesichtet gelöscht worden (Entscheidung des Verantwortlichen). Gemessen waren es 174 Zeilen aus 18 Sitzungen eines einzigen Projekts, vom 21.07. bis 06.08.2026; nach dem Lauf verbleiben 0. Die Lücke selbst war schon vorher geschlossen: seit dem 07.08.2026 trägt kein Wert mehr Klartext. Beim Messen fast ein zweiter Fehler: das Maskierungszeichen ist der Stern, nicht der Aufzählungspunkt - ein Muster auf den Punkt fand 862 Zeilen mit einem jüngsten Treffer von heute und sah damit nach einem laufenden Abfluss aus. Eine Löschung auf diese Zahl hätte 688 sauber maskierte Zeilen mitgenommen.

R3 - Ungekürzte IP-Adressen in Altdaten und Portalprotokollen

Die IP-Kürzung im Aufzeichnungsweg ist richtig und an der richtigen Stelle umgesetzt: class/Server.class.php:432-435 ersetzt das letzte IPv4-Oktett bzw. die letzte IPv6-Gruppe unmittelbar nach dem Auslesen der Adresse, bevor es einen Verbraucher des Wertes gibt. Für neue Daten ist sie als wirksam nachgewiesen - jede seit dem 7. August 2026 aufgezeichnete Sitzung ist gekürzt. Sie wirkt nicht rückwirkend, und einen Nachlauf gibt es nicht; der Altbestand ist stattdessen am 17.08.2026 einmalig von Hand bereinigt worden - siehe die Standnotiz unter der Tabelle.

Tabelle	Ungekürzte Adressen (Stand der Erhebung, vor dem 17.08.2026)	Löschfrist
visitor_sessions	236 von 705, datiert vom 21. Juli bis 7. August 2026, vollständige öffentliche Adressen	Tarif-Purge - nie ausgeführt
ip_lifetime_stats	291 von 446	Nirgends eine
mouseplayer_logs	Keine der 36542 geprüften Adressen war gekürzt	60 Tage
audit_logs	Alle 666 Zeilen	Keine
user_ip_history	Alle 5 Zeilen	Keine
security_access_logs	1004 von 1354	72 Stunden
support_requests	Alle, und zusätzlich weitergeleitet - siehe R13	Keine
Apache-Zugriffsprotokoll	Alle	14 tageweise Rotationen

Wahrscheinlichkeit - eingetreten. Schwere - erheblich. Eine IP-Adresse allein ist eine begrenzte Offenlegung. In visitor_sessions steht sie nicht allein: sie liegt in derselben Zeile wie die Aufzeichnung und verbindet damit eine Netzidentität, und über sie eine Person, mit einer vollständigen Wiedergabe des Verhaltens dieser Person - einschließlich alles dessen, was R1 erfasst. Die Portalprotokolle sind weniger zugespitzt, dafür weit umfangreicher, und sie sind die Verarbeitung in der Verantwortlichenrolle, in der MousePlayer für die Entscheidung unmittelbar einsteht.

Erledigt am 17.08.2026: die Altadressen in audit_logs (681) und user_ip_history (7) sind nachträglich gekürzt worden, in derselben Form, die der Recorder ohnehin schreibt; verbleibend 0. Die künftigen Fristen stehen seit demselben Tag. (Entscheidung des Verantwortlichen, 17.08.2026)

Stand 17.08.2026. Der Altbestand im Aufzeichnungsweg ist erledigt: gemessen waren 267 von 267 Adressen in ip_lifetime_stats gekürzt und 881 von 901 in visitor_sessions; die verbleibenden 20 tragen 0.0.0.0 und stammen aus den Testdaten der Formularauswertung, sind also keine Besucheradressen. In den Portalprotokollen bleibt die volle Adresse stehen - das ist Absicht und trägt seit dem 17.08.2026 eine ausgewiesene Frist: mouseplayer_logs 60 Tage, security_access_logs 72 Stunden, audit_logs 60 Tage, user_ip_history 90 Tage ab dem letzten Auftreten einer Adresse (seit dem 24.09.2026), support_requests 730 Tage. Warum die volle Adresse bei Supportanfragen gebraucht wird, steht im Verzeichnis nach Art. 30 unter B.3.

R4 - Freigabe-Links geben eine vollständige Wiedergabe ohne jede Anmeldung frei

Eine Rewrite-Regel führt /s/<40 Hex-Zeichen> unmittelbar auf den Player. Der Token ist die gesamte Schranke, und der Entwurf steht ehrlich dazu: der Token besteht aus 20 Bytes von random_bytes (160 Bit, nicht erratbar), Kanal- und Sitzungskennung kommen ausschließlich aus dem Token statt aus der Anfrage, der übrige Query-String wird ersetzt statt ignoriert, die Rolle bleibt NULL, sodass Löschen und Weiterteilen serverseitig unmöglich sind, alle drei Player-Endpunkte sind auf die Sitzung des Tokens beschränkt, und erfundene, abgelaufene und zurückgenommene Token liefern dieselbe Antwort, sodass Durchprobieren nichts ergibt. Die Vorgabelaufzeit beträgt 7 Tage, mindestens 1, höchstens 90; ein Widerruf ist vorgesehen. Das ist ein sorgfältig gebauter Mechanismus.

Die verbleibende Aussetzung ist nicht kryptografisch, sondern menschlich, und zwei Umsetzungsdetails vergrößern sie. Erstens trägt die Seite, die die Aufzeichnung über einen Freigabe-Link zeigt (player.php im Freigabemodus), zwar die Kopfzeilen Referrer-Policy: no-referrer und Cache-Control: no-store, aber keine Kopfzeile X-Robots-Tag; noindex steht nur in www/share.php, das nur noch die Fehlerseite ist, und robots.txt erlaubt alles (geprüft am 16.10.2026). Zweitens hält das System seit dem 17.08.2026 jeden Abruf eines Freigabe-Links fest - Zeitpunkt, ungekürzte IP-Adresse und Browserkennung in share_views (siehe auch R11) -, die Person hinter dem Abruf lässt sich daraus aber nicht bestimmen.

Wahrscheinlichkeit - möglich. Der Token wird nicht durch Ausprobieren gefunden. Er wird weitergereicht - in ein Ticket eingefügt, in einen Gruppenchat, in einen E-Mail-Verlauf, der einen Empfänger hinzubekommt - und er kann über eine Referer-Kopfzeile abfließen. Schwere - schwer: ein Link gibt eine ganze Sitzung einem unbegrenzten, nicht identifizierten Publikum frei, einschließlich alles dessen, was R1 und R2 betreffen, und hinterher lässt sich nur feststellen, von welcher Adresse und mit welchem Browser sie abgerufen wurde (share_views), nicht aber, wer sie gesehen hat. Eine verwandte Frage ist in den Projektnotizen als offen vermerkt und bleibt ungeprüft: Gemessen am 17.08.2026: die Beobachtergrenze wird von Freigabe-Links nicht umgangen - sie betrifft sie gar nicht. Gezählt werden Live-Beobachter über das Merkmal IS_LIVE_VIEWER auf der WebSocket-Verbindung (class/Server.class.php, zaehleLiveViewers). www/player.php enthält keine einzige WebSocket-Stelle; der Player spielt nur ab. Der Freigabe-Link führt in den Player, nicht in die Live-Ansicht. Was tatsächlich unbegrenzt ist, ist etwas anderes: wie viele Personen denselben Link gleichzeitig öffnen. Dafür gibt es keine Grenze und, anders als bei der Live-Ansicht, auch keinen Zähler. Seit dem 17.08.2026 wird wenigstens jeder Abruf protokolliert (share_views, Verzeichnis B.6), sodass sich hinterher feststellen lässt, wie oft und von wo ein Link benutzt wurde.

R5 - Täglicher ausgelagerter Vollabzug (bis 05.09.2026 zu Google Drive, seither zu Google Cloud Storage in Warschau; seit 11.08.2026 verschlüsselt übertragen; Altbestand am 12.08.2026 gelöscht)

Dieses Risiko steht nicht in der technischen Faktenbasis; es wurde aus der projekteigenen Datei der offenen Punkte erhoben und ist dort ausführlich dokumentiert. Bis 11.08.2026 lief täglich um 02:00 ein früheres Sicherungsskript aus dem cron von root. Es führte mysqldump über alle Datenbanken aus und packte das gesamte Webverzeichnis in ein tar-Archiv, dann lud es das Ergebnis per rclone nach gdrive:backups/rpi-ls5/daily - ohne jede Verschlüsselung. Lokal sind 653 MB Datenbank und 678 MB Dateien je Tag bestätigt. Seit 11.08.2026 ist die cron-Zeile umgestellt: der tägliche Lauf ist ein neues Sicherungsskript des Projekts, das denselben Umfang sichert, ihn aber vor der Übertragung auf dem eigenen Server verschlüsselt (rclone crypt) und in einen eigenen, getrennten Zielordner überträgt; planmäßig findet er um 03:00 statt. Auch Datei- und Verzeichnisnamen sind verschlüsselt; beim Anbieter liegen damit Blöcke ohne Bedeutung. Der Lauf vom 11.08.2026 wurde von Hand angestoßen und ist angekommen (733 MB Datenbank, 678 MB Dateien); der Lauf vom 12.08.2026 lief planmäßig um 03:00 vollständig durch. Beide sind protokolliert, und die Gegenprobe am Ziel hat den Datenbankauszug beide Male mit derselben Byte-Zahl wiedergefunden.

Was die Maschine verlässt, ist damit keine Sicherung von Sitzungsaufzeichnungen. Es ist eine vollständige Kopie jeder Datenbank und jedes Systems auf dem Rechner - einschließlich der Aufzeichnungen mit ihren Seitenabbildern, der 173 Klartext-Formulareingaben, der 236 ungekürzten Adressen und jeder .env-Datei mit ihren Produktivgeheimnissen. Der Umfang ist unverändert; die Verschlüsselung ändert daran nichts. Geändert hat sich die Lesbarkeit beim Anbieter: bis 11.08.2026 lag vor dem Hochladen keine Verschlüsselungsschicht, der Klartext kam als Klartext an; seit 11.08.2026 wird auf dem eigenen Server verschlüsselt, bevor etwas hinausgeht, und die Schlüssel liegen in zwei Dateien mit Modus 600 auf demselben Server - Google hat sie nicht. Der Altbestand war davon nicht erfasst: das neue Skript räumt nur seinen eigenen Zielordner auf, und der bisherige Ordner hielt Wochenkopien bis zu 364 Tage. Er wurde am 12.08.2026 gelöscht; unverschlüsselte Vollkopien aus der Zeit vor dem 11.08.2026 liegen beim Anbieter damit nicht mehr.

• Die Übermittlung findet statt, und zwar täglich. Bis 11.08.2026 war ungeprüft, ob sie ankommt: der Lauf benutzte die rclone-Konfiguration von root, das Skript protokollierte nichts, und cron verwarf seine Ausgabe. Seit 11.08.2026 schreibt der Lauf ein Protokoll und prüft nach der Übertragung selbst nach, ob der Datenbankauszug mit der erwarteten Byte-Zahl am Ziel steht; für den 11.08.2026 (von Hand) und den 12.08.2026 (planmäßig um 03:00) ist beides belegt, jeweils mit bestandener Gegenprobe. Damit ist nicht nur der erste Versuch belegt, sondern der tägliche Betrieb. Das Verfügbarkeitsrisiko ist deshalb nicht erledigt, sondern verlagert: gehen beide Schlüsseldateien verloren, ist die gesamte ausgelagerte Sicherung unwiederbringlich. Eine Maßnahme, die die Lesbarkeit beim Anbieter beseitigt, schafft damit eine neue Abhängigkeit von der Verwahrung der Schlüssel; außerhalb dieses Rechners liegen sie nach Angabe des Verantwortlichen ausgedruckt in einem Safe (Abschnitt 8.3). Der Inhaber hat die Entschlüsselung geprüft - das ist seine Angabe und keine Messung dieses Dokuments.
• Bis 05.09.2026 war kein Übermittlungsinstrument festgestellt. Die Kopie lag bei Google Drive unter einem privaten Konto (beantwortet am 17.08.2026), ohne buchbare europäische Datenregion und ohne Auftragsverarbeitungsvertrag. Seit dem 05.09.2026 liegt sie in einem Bucket bei Google Cloud Storage in der Region europe-central2 (Warschau) unter einem Firmenkonto und ist von den Google-Cloud-Datenverarbeitungsbedingungen gedeckt; die Kopien auf dem Drive-Konto wurden am 06.09.2026 gelöscht.
• Das alte Skript war eine Rechteausweitung. Bis 11.08.2026 gehörte es root, wurde aus dem cron von root ausgeführt, und seine Dateirechte standen auf 777: wer das SSH-Konto pi hatte, hatte um 02:00 root. Seit 11.08.2026 läuft der tägliche Lauf nicht mehr über dieses Skript; die Übertragung zu Google Drive ist am 09.09.2026 aus ihm entfernt worden. Die alten Sicherungsskripte wurden am 16.10.2026 entfernt. Die Neubewertung von R5 liegt beim Verantwortlichen.
• Bis 05.09.2026 lag die Kopie außerhalb jeder Weisung des Kunden. Art. 28 Abs. 3 lit. a verlangt, dass der Auftragsverarbeiter nur auf dokumentierte Weisung handelt; eine tägliche Kopie der Besucheraufzeichnungen zu einem US-Verbraucherdienst war von keiner aktenkundigen Weisung gedeckt. Seither nennen Abschnitt 9 des Auftragsverarbeitungsvertrags und die Liste der Unterauftragsverarbeiter die Sicherung bei Google Cloud Storage.

Überholt seit dem 05.09.2026 (siehe oben); hier als Verlauf belassen. Beantwortet am 17.08.2026: Privatkonto. Damit ist keine europäische Datenregion buchbar und es gibt keinen Auftragsverarbeitungsvertrag - für ein privates Google-Konto stehen die Datenverarbeitungsbedingungen nicht zur Verfügung. Entscheidung des Verantwortlichen: die Sicherung bleibt vorerst dort. Wiederherstellungstests künftig monatlich. Die beiden Schlüsseldateien liegen ausgedruckt in einem Safe, zu dem ausschließlich der Verantwortliche Zugang hat (Angabe des Verantwortlichen, 17.08.2026); sie überleben damit den Verlust dieses Rechners.

Gemessen am 17.09.2026: die letzte gelungene Sicherung lief am selben Tag um 03:30 und hat die Gegenprobe am Ziel bestanden. Die Wiederherstellungsübung ist monatlich vorgesehen; bestanden hat sie vor der Löschung der Drive-Kopien am 06.09.2026, und kein Wächter erinnert an die nächste. Am 07.10.2026 wurde zusätzlich ein vollständiger Datenrestore aus der Cloud-Sicherung in eine getrennte Umgebung durchgeführt (rund 70 Minuten; Stichproben aus Archiv und Datenbank ohne Fehler). Seit dem 06.10.2026 enthält die tägliche Sicherung auch das Aufzeichnungsarchiv (/mnt/mouseplayer-dev-archive); es liegt auf derselben Platte wie das System. Die Aufzählung oben beschreibt, soweit dort nicht anders vermerkt, den Stand vor dem 05.09.2026.

R6 - Wiedererkennung über Sitzungen hinweg und Zusammenführung mit dem Bestand des Kunden

Eine pseudonyme Kennung wird erzeugt und im localStorage des Besuchers unter mp_visitor_id gehalten. Für sich genommen ist das gewöhnlich und für die Auswertung wiederkehrender Besucher verhältnismäßig. Zwei weitere Mechanismen ändern ihren Charakter. MousePlayer.setUserId() erlaubt es dem Kunden, seine eigene Kennung - einen Anmeldenamen, eine Kundennummer - an die Aufzeichnung zu heften, gespeichert in visitor_sessions.custom_user_id mit eigenem Index; und derselbe Wert wird automatisch aus einem dataLayer-Pfad namens 'uid' übernommen, ohne jedes bewusste Zutun des Kunden. Wo ein Tag Manager bereits eine Nutzerkennung veröffentlicht, werden die Aufzeichnungen als Nebenwirkung der Installation einer namentlich bekannten Person zuordenbar.

Von da an ist die Aufzeichnung in der Hand des Kunden nicht mehr pseudonym. Sie lässt sich mit seinem CRM verbinden, und der BigQuery-Export ist so gebaut, dass er genau die Spalten mitführt, die die Verbindung trivial machen: visitor_id, custom_user_id und ip_address in derselben Zeile. Dieser Export ist derzeit bei allen Projekten abgeschaltet und sein Prozess läuft nicht - die Fähigkeit besteht, die Tätigkeit nicht.

Eine Schwäche des Entwurfs sollte festgehalten werden, ohne sie zu überzeichnen. visitor_nicknames trägt eine UNIQUE-Bedingung allein auf visitor_id, ohne Mandantengrenze - die Tabelle ist strukturell projektübergreifend. In der Praxis lebt die Kennung im localStorage und ist damit an eine Herkunft (Origin) gebunden, sodass daraus für sich genommen keine seitenübergreifende Verfolgung zwischen den Domains verschiedener Kunden entsteht. Es ist eine fehlende Grenze im Schema und kein belegtes Leck, und sie sollte geschlossen werden, bevor es einen Betrieb gibt, in dem zwei Projekte dieselbe Herkunft teilen können.

Wahrscheinlichkeit - wahrscheinlich für die Wiedererkennung über Sitzungen hinweg (es ist das Vorgabeverhalten, und 329 Kennungen sind erfasst); möglich bis wahrscheinlich für die Identifizierung, angesichts des automatischen dataLayer-Pfads. Schwere - schwer: die Identifizierung nimmt den mildernden Umstand weg, der die Verhaltensaufzeichnung erträglich macht, und sie tut das rückwirkend - sobald eine Kennung angeheftet ist, werden auch zuvor pseudonyme Sitzungen dieses Besuchers zuordenbar.

R7 - Keine Löschfrist für dreizehn Tabellen; Fristen gesetzt am 17.08.2026

Der tarifabhängige Purge löscht fünf Tabellen: mouse_events, session_custom_event_params, session_custom_events, session_pageviews und visitor_sessions. Dreizehn Tabellen mit personenbezogenen Daten fehlen in dieser Liste: ai_session_features, ai_timelines, consent_events, session_comments, session_shares, visitor_nicknames, ip_lifetime_stats, audit_logs, user_ip_history, users einschließlich last_ip, support_requests, consent_region_acceptances und heatmap_page_stats.

Die praktische Folge ist schlimmer, als die Liste vermuten lässt, und zwar wegen der Reihenfolge, in der die Dinge geschehen würden. Wenn der Purge irgendwann greift, verschwindet die Sitzung und die Ableitungen bleiben - ai_timelines behielte die Sitzung als lesbaren Fließtext, 3203 Zeilen und 5,5 MB davon, die eine Person beschreiben, deren zugrunde liegender Datensatz gelöscht ist. Heute gibt es keine solchen Waisen, aber nur, weil noch nie etwas gelöscht wurde.

Drei weitere Mängel verschärfen das. Der Lauf wird nicht von cron oder systemd geplant, sondern läuft im Worker-Prozess, sodass die Löschung aufhört, wenn dieser Prozess anhält, und niemand das meldet. Seine Auswahlabfrage verbindet Sitzungen über INNER JOIN mit Projekten, Workspaces, Eigentümern und Nutzern, sodass eine Sitzung, deren Projekt gelöscht wurde, nie ausgewählt und damit nie gelöscht werden kann - eine von 706 Sitzungen ist bereits in diesem Zustand. Und die tatsächlich geltende Aufbewahrung beträgt für jedes Projekt des Systems 365 Tage, bei einem Datenbestand, dessen ältester Datensatz 20 Tage alt ist, was bedeutet, dass die Löschkette nie durchgängig erprobt wurde.

Wahrscheinlichkeit - eingetreten. Schwere - schwer, als ein Verstoß gegen Art. 5 Abs. 1 lit. e, der strukturell und nicht zufällig ist. Umgestellt am 17.08.2026. Der Lauf selbst bleibt im db_worker, aber sein AUSBLEIBEN fällt jetzt auf: der Worker hinterlegt sein Ergebnis (mp_purge_status), und srv/cron_status.php - ein ANDERER Prozess - bewertet es im 60-Sekunden-Takt, schreibt sys_purge für den Administrationsbereich und meldet per E-Mail, wenn der letzte Lauf länger als 48 Stunden zurückliegt. Höchstens eine Meldung am Tag; ein Wächter, der im Minutentakt mailt, wird ignoriert und meldet dann auch den echten Ausfall an niemanden mehr. Der Wächter sitzt bewusst nicht im Worker: ein toter Prozess kann sich nicht selbst melden. Stand 23.09.2026: der E-Mail-Versand steht; die Meldung geht an die im Administrationsbereich hinterlegte Alarmadresse.

Stand 17.08.2026. Behoben. Fünf der dreizehn Tabellen stehen seit dem 12.08.2026 in der gemeinsamen Löschkette, sechs haben eine eigene, im Administrationsbereich einstellbare Frist bekommen (Migration 039), und zwei fehlten in der Aufzählung ganz: ai_visitor_value und ai_insights - also gerade die Bewertung der Person und der über sie erzeugte Text. Die Fristen stehen in site_settings und werden aus derselben Zeile gelesen, aus der sie auch das Verzeichnis nach Art. 30 in seinen Text übernimmt. Der Löschlauf läuft; belegt ist der Lauf vom 17.08.2026 um 17:37:09 im Protokoll des Workers. Die Befürchtung dieses Abschnitts - die Sitzung verschwindet und die Ableitung bleibt als Waise stehen - kann damit nicht mehr eintreten. Der Lauf hängt weiterhin am Worker-Prozess und wird weder von cron noch von systemd geplant; sein Ausbleiben meldet seit dem 17.08.2026 der Wächter im Statusprozess, seit dem 23.09.2026 auch per E-Mail.

Neu bewertet am 23.09.2026. Gemessen am selben Tag: der Löschlauf lief zuletzt vor 21 Stunden, der älteste Eintrag in audit_logs ist 60 Tage alt - genau die eingestellte Frist -, und keine Sitzung steht ohne Projekt. Die Auswahl verbindet weiterhin über INNER JOIN; verwaiste Sitzungen entstehen trotzdem nicht, weil die Löschung eines Projekts oder Kontos dessen Sitzungen über die channelid mitnimmt. Seit dem 24.09.2026 hat auch user_ip_history eine eigene Frist: 90 Tage ab dem letzten Auftreten einer Adresse, spätestens mit dem Konto. Wahrscheinlichkeit - fern. Schwere - schwer. Gesamtrisiko - gering.

R8 - Automatisierte Bewertung und Einstufung jeder Sitzung

Jede Sitzung wird automatisch bewertet. engagement_score (0-255) wird aus Tiefensignalen und Ärgernissignalen berechnet; session_quality trennt Sitzungen ab, in denen wenig geschah; is_bot mit einem Begründungscode stuft den Besucher als nicht menschlich ein, und diese Prüfung läuft vor dem Einwilligungsriegel. Die Bewertungen sind indiziert und steuern die Sortierung der Sichtungsliste des Kunden, was bedeutet, dass sie bestimmen, welche Personen angesehen werden. Bei der Erhebung im August 2026 gab es 4043 Merkmalszeilen und 3203 erzeugte Protokolle.

Das ist Profiling im Sinne des Art. 4 Nr. 11 - automatisierte Bewertung persönlicher Aspekte einer natürlichen Person, namentlich um ihr Verhalten zu analysieren oder vorherzusagen. Nach der Befundlage ist es keine automatisierte Entscheidung im Sinne des Art. 22: eine Kredit-, Preis-, Zugangs- oder Berechtigungsentscheidung gegenüber einem Besucher wurde nicht gefunden. Ein Mechanismus liegt näher an der Grenze als die übrigen und sollte benannt werden: bei der Erkennung eines Wutklicks übergibt www/mp.js ein Verhaltensurteil an fremde Chat-Widgets, die im Browser des Besuchers selbst laufen - Intercom bekommt ein Merkmal, LiveChat eine Sitzungsvariable. Ein über den Besucher gebildetes Urteil verlässt damit in Echtzeit das System und kann verändern, wie diese Person auf der Seite behandelt wird.

Umfang des Profilings, Stand 16.10.2026. Seit der Erhebung sind weitere Bewertungen und Ableitungen hinzugekommen, und alle gehören zu diesem Risiko: maschinell formulierte Sätze und Berichte über einzelne Besucher (ai_insights, ai_besucher_bericht; die Befunde werden gerechnet, ein Sprachmodell auf eigenen Rechnern im selben lokalen Netz formuliert sie); ein Absprungmodell (logistische Regression), das im Browser des Besuchers ein Absprungrisiko schätzt und, wenn der Betreiber es einschaltet, ein Exit-Angebot auslöst, dessen Text erst nach Freigabe durch den Betreiber angezeigt wird; ein regelbasierter Abwanderungsindikator für wiederkehrende Besucher (ai_churn); Verhaltensprofile, die Sitzungen nach ihrem Verlauf gruppieren (k-Means, mp_profile, mp_profil_sitzung), und Sequenzmuster; ein Reibungswert je Sitzung; Umfragen und ein Feedback-Knopf mit Antworten des Besuchers; das Element-Tracking, das Klicks markierten Elementen zuordnet; ein Index der angezeigten Texte für die Suche (mp_text_block, mp_text_pv, 30 Tage); und Konsolenmeldungen sowie fehlgeschlagene oder langsame Anfragen der Kundenseite (ohne Rumpf und Kopfzeilen). Keine davon trifft nach der Befundlage eine Entscheidung im Sinne des Art. 22 gegenüber dem Besucher; das Exit-Angebot verändert aber unmittelbar, was dem Besucher auf der Seite gezeigt wird, und steht deshalb von den genannten am nächsten an der Grenze. Die Einzelheiten stehen im Verzeichnis nach Art. 30.

Getrennt davon haben zwei automatisierte Folgen tatsächlich Wirkung, aber gegenüber Kunden und IP-Adressen statt gegenüber Besuchern: einem Konto, das bei der Registrierung automatisch als is_suspicious gekennzeichnet wird, wird die Aufbewahrung auf 24 Stunden gekürzt, und eine IP, die die Verbindungsschwellen überschreitet, wird gesperrt, wonach jede weitere Anfrage abgebrochen wird - bei der Erhebung im August 2026 waren 24 solcher Sperren verzeichnet. Bei der Erhebung gab es für beide keinen dokumentierten Weg zur menschlichen Nachprüfung und keinen Widerspruchsweg; für die Sperre besteht er seit dem 17.08.2026 (unten), für das Merkmal is_suspicious weiterhin nicht.

Wahrscheinlichkeit - wahrscheinlich (Vorgabeverhalten). Schwere - erheblich: keine Rechtswirkung für Besucher, aber bewertet und sortiert zu werden, ohne davon zu wissen, und diese Bewertung an ein fremdes Widget ausgeliefert zu bekommen, ist genau der Kontrollverlust, den Erwägungsgrund 75 beschreibt. Bewertet am 17.08.2026. Der automatische Bann lief seit demselben Tag nach 7 Tagen von selbst ab; bis dahin lief er nie aus. Stand 16.10.2026 sperrt der WebSocket-Server selbst, und die Sperre läuft nach 24 h ab (einstellbar von 1 bis 168 h); fail2ban sperrt für eine Stunde; banned_ips wird nur noch von Hand befüllt. Ein Widerspruch geht über das Supportformular oder an office@mouseplayer.com und wird von einem Menschen bearbeitet; der Administrationsbereich kann den Bann aufheben. Die Dauer steht in site_settings (autoban_stunden). Damit hat der Vorgang eine begrenzte Wirkung, eine menschliche Überprüfung auf Verlangen und einen benannten Weg dorthin - die Merkmale, an denen Art. 22 hängt. Die Einordnung selbst bleibt eine Rechtsfrage; entschieden ist die Vorkehrung, nicht die Auslegung. (Entscheidung des Verantwortlichen, 17.08.2026)

R9 - 92 Sitzungen über keine Kennung erreichbar; kein Weg von einer Person zu ihrem Datensatz

92 Sitzungen tragen die visitor_id 'unknown'. Für diese Datensätze gibt es keinerlei Schlüssel, der zu ihnen führt: die Daten existieren, sind personenbezogen, enthalten eine Wiedergabe und möglicherweise eine Adresse, und lassen sich mit keiner Abfrage finden, die ein Betroffenenantrag auslösen könnte. Eine Löschung nach Art. 17 kann für sie nicht geleistet, eine Auskunft nach Art. 15 nicht erteilt werden. Nachgemessen am 16.10.2026: keine Sitzung trägt mehr die visitor_id 'unknown'; der Code kann den Wert beim Anlegen einer Sitzung aber weiterhin schreiben.

Das weitergehende Problem ist größer als die 92 Zeilen und in den Projektnotizen bereits als ungelöst vermerkt. Selbst wo eine visitor_id existiert, lebt sie im localStorage des Besuchers, und der Mensch kennt sie nicht. Es gibt keinen Weg von einer realen Person - die einen Namen, eine E-Mail-Adresse, ein Datum und eine Seite nennen kann - zu ihren Datensätzen. Ein Löschknopf, den die dazu berechtigte Person nicht erreichen kann, ist eine Attrappe.

Art. 11 bietet eine teilweise und unbequeme Antwort: kann der Verantwortliche nachweisen, dass er nicht in der Lage ist, die betroffene Person zu identifizieren, gelten die Art. 15 bis 20 nicht - aber Art. 11 Abs. 2 verlangt, dass der Verantwortliche die betroffene Person darüber unterrichtet, und die betroffene Person kann zusätzliche Informationen beibringen, die ihre Identifizierung ermöglichen. Genau diese letzte Bestimmung ist der Punkt: der Besucher kann seine Kennung beibringen, denn sie liegt in seinem eigenen Browser. Eine Selbstauskunftsseite, die einem Besucher seine eigene mp_visitor_id anzeigt, würde aus einem unmöglichen Antrag einen alltäglichen machen - was es schwer verteidigbar macht, sich auf Art. 11 zu berufen, solange es eine solche Seite nicht gibt.

Wahrscheinlichkeit - eingetreten. Schwere - erheblich, in Verbindung mit R1 ansteigend auf schwer: die Person, die ihren Datensatz am wenigsten erreichen kann, ist die Person, die nicht weiß, dass es ihn gibt. Entschieden am 17.08.2026: eine Selbstauskunft für Besucher wird eingerichtet - eine Seite, auf der ein Besucher seine eigene Kennung sieht und die Löschung seiner Aufzeichnungen auslösen kann, verlinkt aus der Datenschutzerklärung. (Entscheidung des Verantwortlichen, 17.08.2026) In Betrieb seit dem 17.08.2026 unter /meine-daten (englisch /my-data, polnisch /moje-dane), verlinkt aus dem Fußbereich jeder Seite. Sie zeigt Zahl der Sitzungen, Zeitraum und betroffene Domains — keine Aufzeichnungen: die Kennung ist ein Trägerausweis, und wer sie kennt, könnte sonst fremdes Verhalten ansehen. Die Löschung wird vorgemerkt und vom Worker mit der bestehenden Kette ausgeführt; die Seite selbst löscht nicht.

Wie weit das R9 entschärft, hängt davon ab, wo der Besucher aufgezeichnet wurde, und diese Grenze ist technisch bedingt: der Browserspeicher ist je Herkunft getrennt. Die Kennung liegt im Speicher derjenigen Website, auf der das Skript lief, nicht in unserem. Eine Seite auf mouseplayer.com kann sie deshalb nicht von allein sehen — an den Daten gegengeprüft, wo keine einzige Kennung auf mehr als einer Domain vorkommt. Daraus folgen drei Wege hinein:

• Besucher von mouseplayer.com selbst erreichen ihre Daten unmittelbar, denn hier ist der Browserspeicher unserer. Für sie ist R9 aufgehoben.
• Besucher einer Kundenwebsite erreichen sie über einen Link, den der Kunde in seine Datenschutzerklärung setzt; MousePlayer.privacyUrl() liefert ihn fertig samt Kennung. Das ist keine Ausflucht, sondern die Zuständigkeitsordnung des Art. 28: für seine Besucher ist der Kunde der Verantwortliche, und der Hinweis nach Art. 13 gehört ohnehin in seine Erklärung. Wir stellen das Werkzeug und sind der Empfänger.
• Wer seine Kennung bereits kennt, trägt sie auf der Seite ein.

Setzt ein Kunde den Link nicht, bleibt R9 für dessen Besucher in voller Höhe bestehen — der Antrag ist dann nicht unmöglich, aber er läuft über den Kunden statt über uns, und dafür steht die Aussage nach Art. 11 in der Datenschutzerklärung. Wer seinen Browserspeicher geleert hat, ist über keinen der drei Wege erreichbar. Die Seite hebt R9 also nicht auf; sie verschiebt es von "technisch unerfüllbar" zu "erfüllbar, sofern der Verantwortliche den Weg dorthin ausschildert".

R10 - Keine Verschlüsselung im Ruhezustand, kein TLS zu Datenbank und Redis im LAN

Drei Lücken in der Infrastruktur sind als nicht umgesetzt dokumentiert, und sie wurden geprüft statt unterstellt. Die Verschlüsselung von InnoDB-Tabellen, -Protokollen und temporären Tabellen ist sämtlich aus, und der Datenträger ist nicht verschlüsselt, sodass der gesamte Bestand - 322,6 MB Ereignisse und 162,9 MB Seitenabbilder - im Klartext ruht. Die Datenbankverbindung läuft ohne TLS: der Server unterstützt es, aber es sind weder Zertifikat noch Schlüssel noch CA konfiguriert; die Verbindung ist lokal, was den Punkt mildert, aber nicht beseitigt. Redis lief bis zum 16.08.2026 ohne Zugriffsschutz bei aktiver Persistenz auf die Platte, und seine Warteschlangen halten die gekürzte IP, die vollständige URL und den DOM-Payload im Durchlauf.

Wahrscheinlichkeit - möglich. Ein Angriff aus der Ferne ist unwahrscheinlich: Redis und die Datenbank lauschten bei der Erhebung nur auf localhost (zum heutigen Stand siehe unten), HTTPS wird erzwungen, und die TLS-Verbindung des WebSocket endet mit einem echten Zertifikat in nginx. Die realistischen Wege sind körperlich - Diebstahl der Maschine, Entsorgung der Platte - und der Sicherungsweg aus R5, der bis 11.08.2026 jede Nacht denselben Klartext von der Maschine trug und seit 11.08.2026 verschlüsselt überträgt; die unverschlüsselten Kopien aus der Zeit davor sind beim Anbieter am 12.08.2026 gelöscht worden. Schwere - sehr schwer, wenn es eintritt, denn offengelegt wird alles auf einmal.

Beantwortet am 17.08.2026: der Server steht in einem abgesperrten, videoüberwachten Raum in Lodz; Zutritt hat ausschließlich der Verantwortliche. Die USB-Sicherungsplatte liegt im selben Raum wie der Server. Beantwortet am 17.08.2026: eine Verschlüsselung im Ruhezustand wird vor dem Produktivstart nicht eingeführt - in der Anfangsphase auf dem Raspberry Pi nicht umsetzbar (Entscheidung des Verantwortlichen). Damit bleibt dieses Risiko in voller Höhe bestehen: der gesamte Bestand liegt im Klartext auf der Platte, und die USB-Sicherungsplatte liegt im selben Raum. Die verbleibende Absicherung ist körperlich - abgesperrter, videoüberwachter Raum, Zutritt nur der Verantwortliche - und trägt gegen Diebstahl oder unsachgemäße Entsorgung eines Datenträgers nur so weit, wie dieser Raum hält. Neu zu bewerten, sobald der Betrieb den Raspberry Pi verlässt.

Stand 17.08.2026. Ein Teil ist behoben, ein anderer hat sich verschoben. Redis ist seit dem 16.08.2026 zugangsbeschränkt; gegengeprüft verweigert der Dienst Anfragen ohne Anmeldung. Die Verschlüsselung im Ruhezustand fehlt unverändert. Die mildernde Annahme dieses Abschnitts gilt dagegen nicht mehr: Redis und die Datenbank lauschen seit dem 16.08.2026 nicht mehr nur auf localhost, sondern zusätzlich auf der LAN-Adresse (bind-address = 127.0.0.1,192.168.20.2), damit ein zweiter Knoten den gemeinsamen Zustand erreichen kann; die ssl-Zeilen der Serverkonfiguration sind weiterhin auskommentiert. Solange ein einziger Knoten läuft, bleibt das theoretisch. Mit dem zweiten wandern Sitzungsinhalte und Datenbankverkehr im Klartext über das Netz, und die Wege sind dann nicht mehr nur körperlich. Die Einstufung dieses Risikos ist vor der Inbetriebnahme eines zweiten Knotens neu zu treffen.

Stand 16.10.2026. Verbindungen aus dem Internet sind TLS-verschlüsselt; die Verschlüsselung endet in nginx, und der WebSocket-Server lauscht nur auf 127.0.0.1:8081, also auf demselben Rechner. MousePlayer nutzt eine eigene Redis-Instanz auf 127.0.0.1:6381 mit Zugangsbeschränkung und Persistenz auf die Platte (Append-only-Datei); damit gelangen auch Warteschlangeninhalte und die für die Dauer der Sperre (24 h) gehaltenen ungekürzten IP-Adressen der automatischen Sperre auf die Platte. Eine ältere, gemeinsam genutzte Redis-Instanz lauscht zugangsbeschränkt zusätzlich auf der LAN-Adresse. MariaDB lauscht auf 127.0.0.1 und auf der LAN-Adresse 192.168.20.2 ohne TLS (kein Zertifikat konfiguriert), und es bestehen Verbindungen aus dem lokalen Netz. Innerhalb des eigenen lokalen Netzes am selben Ort laufen Datenbank- und Redis-Verbindungen damit unverschlüsselt; sie sind zugangsbeschränkt und nur aus dem eigenen lokalen Netz erreichbar (keine Portweiterleitung). Die Verschlüsselung im Ruhezustand fehlt weiterhin.

R11 - Kein Protokoll darüber, wer welche Aufzeichnung angesehen hat

Das Änderungsprotokoll erfasst schreibende Handlungen - Anlegen und Zurücknehmen von Freigaben, Löschen von Kommentaren, Löschen von Sitzungen und Besuchern, automatische Sperren, Superadmin-Handlungen, bei der Erhebung insgesamt 666 Einträge. Es erfasst das Lesen nicht. Ein Aufruf der Player-Seite, des Ereignis-Endpunkts oder des Theatre-Endpunkts hinterlässt keine Spur. Niemand kann hinterher feststellen, welcher Mitarbeiter eines Kunden die Sitzung einer namentlich bekannten Person angesehen hat, wie oft, oder ob ein Administrator von MousePlayer es getan hat. Seit dem 17.08.2026 werden wenigstens die Abrufe von Freigabe-Links protokolliert (share_views); Aufrufe durch angemeldete Nutzer bleiben ohne Spur (Stand 16.10.2026).

Wahrscheinlichkeit - eingetreten als Kontrollücke. Schwere - erheblich, mit einer Folgewirkung, die schwerer wiegt als die unmittelbare: nach einem Vorfall verlangen Art. 33 und Art. 34 vom Verantwortlichen, die Kategorien und die ungefähre Zahl der betroffenen Personen und Datensätze zu beschreiben. Ohne Leseprotokoll lässt sich diese Beschreibung nicht aus Belegen erzeugen, und jede Meldung wird zur Schätzung.

R12 - Qualität der Einwilligungsnachweise und ungeprüft gebliebene CMP-Adapter

Art. 7 Abs. 1 legt die Beweislast für die Einwilligung dem Verantwortlichen auf, und der Code nennt das ausdrücklich als Grund für das Einwilligungsprotokoll. Nach den gemessenen Daten der Erhebung (August 2026) tragen 671 von 706 Sitzungen consent_source='testdata' mit NULL-Zeitstempel, geschrieben von einer Entwicklungsvorlage - das belegt nichts. Echte Nachweise gab es damals 35: 27 aus der API, 5 aus dem Google Consent Mode, 2 späte Erteilungen, 1 Widerruf. Stand 16.10.2026 tragen 566 von 8648 Sitzungen von Menschen consent_source='testdata'; die übrigen tragen einen Nachweis aus der API (7451), aus dem Consented-Adapter (620) oder aus dem Google Consent Mode (9). Die Löschung bei Widerruf besteht als Option und ist bei allen Projekten abgeschaltet (Stand 16.10.2026), ein Widerruf stoppt also die künftige Aufzeichnung, lässt aber die bisherigen Aufzeichnungen stehen.

Von den sechs CMP-Adaptern und den drei Erkennungsebenen sind nur drei Wege gegen die Wirklichkeit erprobt: die unmittelbare API, der Google Consent Mode und Cookiebot. TCF und fünf Adapter - Usercentrics, OneTrust, Consentmanager, Borlabs, Complianz - sind gebaut, liefen aber nie gegen ein echtes CMP. Angesichts des geltenden Leitsatzes, im Zweifel nicht aufzuzeichnen, fällt ein Adapter, der ein Signal falsch liest, in Richtung keine Aufzeichnung, und das ist die sichere Richtung; das Risiko liegt daher vor allem in unbelegten Nachweisen und nicht in unrechtmäßiger Aufzeichnung.

Wahrscheinlichkeit - eingetreten für diesen Datenbestand. Schwere - schwer mit Blick auf den Produktivbetrieb, denn eine Einwilligung, die sich nicht belegen lässt, ist im Streitfall eine Einwilligung, die es nicht gab. Diese Einstufung gilt für die Entwicklungsdaten und muss neu gemessen werden. auszufüllen: gemessener Anteil der Produktivsitzungen mit einem echten Einwilligungsnachweis, und das Datum, an dem jeder CMP-Adapter gegen eine echte Installation geprüft wurde

R13 - Supportanfragen mit der ungekürzten IP an Telegram weitergeleitet (Übermittlung eingestellt am 11.08.2026)

Bis 11.08.2026 wurde beim Abschicken einer Supportanfrage der gesamte Vorgang an Telegram geschoben: Kontostatus, E-Mail-Adresse, Thema, der vollständige Nachrichtentext, die Herkunfts-URL und die IP-Adresse ungekürzt. Die Token waren gesetzt, der Zweig war also scharf. Die anfragende Person ist häufig kein Kunde, und Supporttext ist unbegrenzt - Menschen schildern in Supporttickets Gesundheitslagen, Streitigkeiten und finanzielle Verhältnisse, weil das Feld genau dazu einlädt. Seit dem 11.08.2026 sendet cfg/lib.php genau eine feste Zeichenkette: "MousePlayer: es liegt eine neue Supportanfrage vor." Keine einzige Variable erreicht die Nachricht, es gibt keinen parse_mode, bewusst auch keine Vorgangsnummer - sie wäre ein Merkmal, das sich auf eine Person bezieht - und keinen Link aus dem angefragten Hostnamen, weil dieser Wert aus der Anfrage stammt. Ein Wächter (ai/pruefstand/test_telegram_signal.php) prüft dabei nicht das Ergebnis, sondern die Möglichkeit: welche Variablen können die Nachricht überhaupt erreichen. Vier sind erlaubt, 15 Merkmale sind verboten, und der Text muss eine einfach zitierte Zeichenkette ohne Einsetzung sein; der Wächter ist gegen zwei absichtlich fehlerhafte Fassungen gelaufen und hat beide gefangen. Nicht behoben ist die örtliche Speicherung. Die Anfrage wird unverändert in support_requests abgelegt, einschließlich E-Mail-Adresse und IP-Adresse - das ist gewollt, die Angaben werden für Streitfälle gebraucht -, und support_requests hatte bis zum 17.08.2026 keine Aufbewahrungsfrist; seither wird die Anfrage nach 730 Tagen gelöscht (siehe R7). Der Sinn der Änderung ist, dass die Daten nicht hinausgehen, nicht dass sie verschwinden.

Wahrscheinlichkeit - bis 11.08.2026 eingetreten bei jeder Absendung; seit 11.08.2026 entfällt die Übermittlung vollständig. Schwere - erheblich: bis 11.08.2026, weil Telegram außerhalb der EU liegt und für Bot-Kanäle keine Auftragsverarbeitungsvereinbarung bietet; seither bezieht sich dieselbe Einstufung nur noch auf die örtliche Speicherung, denn was bleibt, ist die Vorhaltung von E-Mail-Adresse, IP und unbegrenztem Freitext in der eigenen Datenbank - seit dem 17.08.2026 befristet auf 730 Tage. Der Drittlandbezug ist weg, die Aufbewahrung ist befristet; sie wird unter R7 geführt. Die Entscheidung ist getroffen und datiert: der Kanal bleibt bestehen, die Nachricht trägt seit dem 11.08.2026 keine Daten mehr. Eine Rechtsgrundlage und eine Übermittlungsgrundlage für die Drittlandübermittlung sind damit nicht mehr erforderlich, weil an Telegram keine personenbezogenen Daten mehr gehen; Telegram ist für diesen Vorgang kein Auftragsverarbeiter. Gesamtrisiko - mittel bis 11.08.2026, seither gering.

R14 - Ausleitung an Empfänger, die der Verantwortliche selbst wählt

MousePlayer bietet Brücken an, über die einzelne Angaben an Systeme des Verantwortlichen weitergehen: an sein Kundenverwaltungs-, Helpdesk-, Marketing-, Werbe-, Speicher- oder Aufgabensystem, oder an eine Adresse, die er selbst benennt. Die Auswahl trifft allein er, den Zugang hinterlegt er selbst, und die Übermittlung ist damit seine Weisung. Die Einzelheiten stehen im Verzeichnis, Abschnitt 4.1.

Worin das Risiko besteht. Nicht in der Menge: übermittelt werden Kennungen und Ereignisnamen, nie der aufgezeichnete Seiteninhalt, kein Mausverlauf und kein Formulartext. Das Risiko liegt in der Unumkehrbarkeit. Erreicht uns ein Löschverlangen nach Art. 17, löschen wir unsere Kopie — die Kopie beim Empfänger erreichen wir nicht. Wie lange er sie aufbewahrt, wohin er sie bringt und an wen er sie weitergibt, entzieht sich unserem Einfluss und ist auch nicht von uns zu überwachen. Dasselbe gilt für eine Übermittlung in ein Drittland: das Ziel bestimmt der Verantwortliche, und damit auch die Garantie nach Kapitel V.

Was dagegen getan ist. Die Datenschutzerklärung sagt beides ausdrücklich — was hinausgeht und dass ein Löschverlangen dort nicht wirkt — und verweist die betroffene Person für die Frage, welche Empfänger eingeschaltet sind, an den Betreiber der Website, der diese Entscheidung getroffen hat. Der AVV stellt klar, dass diese Empfänger keine Unterauftragsverarbeiter von MousePlayer sind. Technisch ist die Menge klein gehalten, und an Werbenetze gehen Name, E-Mail-Adresse, Telefonnummer und IP-Adresse ausdrücklich nicht. Seit dem 20.08.2026 führt jedes Projekt ein Zustellprotokoll (Verzeichnis A.11), aus dem der Verantwortliche ablesen kann, was tatsächlich hinausgegangen ist — vorher war das für ihn nicht erkennbar.

Was bleibt. Ein Restrisiko, das sich technisch nicht ausräumen lässt, solange die Funktion besteht: die Weitergabe ist gewollt, und ihre Folgen liegen außerhalb unserer Sphäre. Es wird getragen vom Verantwortlichen, der die Brücke einschaltet, und ist ihm gegenüber im AVV und in dieser Folgenabschätzung benannt.

8. (d) Zur Bewältigung der Risiken geplante Maßnahmen

Jede Maßnahme unten trägt einen Status, und die Statusangaben sind nicht schmückend. Umgesetzt heißt: heute im laufenden System geprüft. Teilweise heißt: der Mechanismus besteht, erreicht seinen Zweck aber noch nicht. Geplant heißt: er besteht nicht. Eine Folgenabschätzung, die geplante Maßnahmen als umgesetzte darstellt, zieht den üblichen Vorwurf gegen dieses Instrument auf sich, und es ist der Vorwurf, der den Wert des Dokuments genau in der einzigen Lage zerstört, in der das Dokument zählt.

8.1 Heute umgesetzt - geprüft

Maßnahme	Wirkt gegen	Beleg
Einwilligungsriegel im Browser, im Zweifel geschlossen: kein Signal, CMP-Ausfall, Skriptfehler und unbekannte Herkunft führen sämtlich zu 'nicht aufzeichnen'	Rechtmäßigkeit	Zustandsautomat mpEinw in www/mp.js, hinter der Bot-Prüfung
Unabhängige serverseitige Durchsetzung: nur GRANTED oder GRANTED_LATE oder eine ausdrückliche Regionsfreigabe kommen durch; Widerruf, unbekanntes Land und alles Unklare schließen die Verbindung	Rechtmäßigkeit	class/Server.class.php:977-1004; bei der Erhebung 24 geblockte Verbindungen verzeichnet
Ausschlussliste für Pfade vor dem Riegel, nur auf dem Pfad geprüft	Minimierung	class/Server.class.php:963-975; bei der Erhebung 71 geblockte Verbindungen verzeichnet
IP-Kürzung am Ort des Auslesens, vor jedem Verbraucher des Wertes	R3, nur für die Zukunft	class/Server.class.php:432-435; alle Sitzungen seit dem 7. August 2026 gekürzt
Maskierung von Formulareingaben mit unbedingtem Boden für Kennwörter und Zahlungsdaten auf jeder Stufe; alle Projekte auf der strengsten Stufe	R2, nur für die Zukunft	www/mp.js:4818-4853
Feldnamen werden klassifiziert statt übertragen	Minimierung	www/mp.js:4653-4674
DOM-Maskierung innerhalb markierter Bereiche, auch auf laufende Mutationen angewendet	R1, teilweise	www/mp.js:3934-3970 und 4732-4768
TC-String nur als SHA-256 gespeichert	Minimierung	visitor_sessions.tcf_hash
Replay-Payload bewusst von der öffentlichen API ausgenommen	R4	www/api/v1_session_detail.php:25
Freigabe-Links: 160-Bit-Token, 7 Tage Vorgabe und 90 Tage Höchstlaufzeit, Kennungen ausschließlich aus dem Token, Query-String ersetzt statt ignoriert, Rolle NULL, alle drei Endpunkte eingeschränkt, gleiche Antwort für erfundene, abgelaufene und zurückgenommene Token, Widerruf möglich	R4	cfg/lib.php mp_share_erstellen / mp_share_pruefen; www/.htaccess
Geo-Auflösung gegen lokale Datenbankdateien - kein Aufruf eines Dritten irgendwo im Aufzeichnungsweg	Drittlandtransfers	class/IP2CityLite.class.php:37; class/Server.class.php:724
Rollenmodell je Workspace; Löschen auf owner und admin beschränkt und immer auf das Projekt begrenzt	Zugriffssteuerung	www/player.php:267, 275-282
Einwilligungsprotokoll bleibt über die Sitzungslöschung hinaus bewusst erhalten, als Beleg, dass ein Widerruf erfolgt ist	Art. 7 Abs. 1	srv/db_worker.php:257-259
Änderungsprotokoll über schreibende Handlungen	Rechenschaftspflicht	cfg/lib.php:2878-2890; 666 Einträge bei der Erhebung
Transportsicherheit: erzwungenes HTTPS; TLS mit echtem Zertifikat endet in nginx, auch für den WebSocket (/mp_wss/), den HTTP-Tunnel (/mp_wst), den Abbild-Upload (/mp_dom) und den Messpunkt (/mp_wsfail); der WebSocket-Server lauscht nur auf der Loopback-Adresse. Datenbank- und Redis-Verbindungen innerhalb des lokalen Netzes sind nicht verschlüsselt (siehe R10)	Vertraulichkeit	www/.htaccess; nginx-Konfiguration (srv/nginx/); srv/server.php mit Bindung an 127.0.0.1:8081
CSRF-Token aus random_bytes mit laufzeitkonstantem Vergleich; Sitzungscookie httponly, SameSite=Lax, secure; Passwort-Hashing; durchgängig vorbereitete Anweisungen in den geprüften Schreibpfaden; Ratenbegrenzung bei der Anmeldung; automatischer Bann und Verbindungsgrenzen je IP; fail2ban läuft	Vertraulichkeit	cfg/lib.php:110-132; www/login.php; class/Server.class.php:449-455, 660-668
Geheimnisse außerhalb der Versionsverwaltung	Vertraulichkeit	.gitignore erfasst .env; verfolgt wird nur .env.example
Durchgesetzte Aufbewahrung für die Portalprotokolle: 60 Tage bzw. 72 Stunden, dazu Ablauf der Sperren	Speicherbegrenzung	srv/db_worker.php (täglicher Löschlauf)
Täglicher Löschlauf nach Tarif und nach eigenen Fristen für die übrigen Tabellen, dazu stündlich die Fristen für als Bot markierte Sitzungen; sein Ausbleiben meldet ein getrennter Statusprozess per E-Mail und in den Urgent Logs	Speicherbegrenzung, R7	srv/db_worker.php; srv/cron_status.php (sys_purge); ältester Eintrag in audit_logs am 16.10.2026 an der Frist von 60 Tagen
fail2ban mit neun Jails, darunter mp-nginx-429, das Adressen sperrt, die wiederholt die Ratenbegrenzung von nginx auslösen; dazu Ratenbegrenzungen in nginx	Verfügbarkeit, Missbrauchsabwehr	fail2ban-client status, geprüft am 16.10.2026
Archivierung vor dem endgültigen Löschen: das Löschen von Projekten, Workspaces und Konten sowie die Löschung nach IP-Adresse oder Besucher blendet die Daten zuerst aus und beendet die Aufzeichnung; endgültig gelöscht wird nach 30 Tagen oder vorher auf Anforderung, ausgeführt und nachgezählt vom Worker. Die Löschung untätiger Konten archiviert nicht vorher	Integrität, Speicherbegrenzung	Migration 189; cfg/archivierung_lib.php; mp_loesch_archiv
Fristen für als Bot markierte Sitzungen: Aufzeichnung geleert (Frist in Tagen: 1), Sitzungszeile nach 14 Tagen gelöscht	Speicherbegrenzung	site_settings retention_bot_recording_days und retention_bot_session_days; srv/db_worker.php

8.2 Teilweise - vorhanden, erreicht seinen Zweck aber noch nicht

Maßnahme	Warum sie noch nicht wirkt
DOM-Maskierung	Opt-in je Element. Schützt, was der Besucher eingibt, nicht, was die Seite ausgibt - der Kern von R1
Löschung bei Widerruf	Als Option umgesetzt, bei allen Projekten abgeschaltet (Stand 16.10.2026), ein Widerruf entfernt also nicht, was bereits aufgezeichnet wurde
Kopfzeilen noindex und no-referrer	Die Seite, die die Aufzeichnung über einen Freigabe-Link zeigt (player.php im Freigabemodus), trägt Referrer-Policy: no-referrer und Cache-Control: no-store, aber keine Kopfzeile X-Robots-Tag; noindex steht nur in www/share.php, der Fehlerseite, und robots.txt erlaubt alles (geprüft am 16.10.2026)

8.3 Geplant - nicht umgesetzt

Maßnahme	Wirkt gegen	Vorrang
Die ausgelagerte Kopie vor dem Hochladen verschlüsseln - erledigt am 11.08.2026: der tägliche Lauf verschlüsselt auf dem eigenen Server vor der Übertragung (rclone crypt, auch die Namen), die Schlüssel liegen in zwei Dateien mit Modus 600. Den unverschlüsselten Altbestand im bisherigen Zielordner löschen - erledigt am 12.08.2026. Die Schlüsseldateien so hinterlegen, dass sie die Zerstörung des Rechners überleben - erledigt am 17.08.2026: sie liegen ausgedruckt in einem Safe (Angabe des Verantwortlichen). Die Google-Drive-Regelung feststellen oder beenden – erledigt am 05.09.2026: die ausgelagerte Kopie liegt seit diesem Tag in einem Bucket bei Google Cloud Storage in der Region europe-central2 (Warschau) und ist von den Google-Cloud-Datenverarbeitungsbedingungen gedeckt. Der Restbestand auf dem privaten Drive-Konto wurde am 06.09.2026 gelöscht, nachdem die Wiederherstellungsübung aus dem neuen Ziel bestanden war. Die alten Sicherungsskripte entfernen - erledigt am 16.10.2026.	R5	Entfällt - erledigt
Die Vorgabe für Seiteninhalt umkehren: Text maskiert speichern, solange er nicht ausdrücklich freigegeben ist, und vor der wörtlichen Erfassung von Seitentext eine schriftliche Bestätigung des Kunden verlangen	R1	Zuerst
Vertragliche Branchenpolitik: welche Branchen überhaupt zugelassen werden, und unter welchen zusätzlichen Bedingungen	R1	Zuerst
Einmalige Kürzung oder Löschung der 236 + 291 + 666 + 5 Altadressen - erledigt am 17.08.2026: der Altbestand im Aufzeichnungsweg sowie in audit_logs und user_ip_history ist gekürzt (siehe R3)	R3	Entfällt - erledigt am 17.08.2026
Die 173 Klartext-Eingabezeilen sichten und löschen - erledigt am 17.08.2026: ungesichtet gelöscht (Entscheidung des Verantwortlichen, siehe R2)	R2	Entfällt - erledigt am 17.08.2026
Den Purge auf die dreizehn nicht erfassten Tabellen ausdehnen; ihn auf einen überwachten Plan umstellen; die INNER-JOIN-Lücke schließen, damit verwaiste Sitzungen erreichbar werden	R7	Entfällt - erledigt am 17.08.2026 (Fristen und Wächter); die INNER-JOIN-Auswahl besteht, verwaiste Sitzungen entstehen nicht (siehe R7)
Lesezugriffe auf den Player und beide Daten-Endpunkte protokollieren	R11, Art. 33	Hoch
Referrer-Policy und X-Robots-Tag auf der Player-Seite; kürzere Vorgabelaufzeit für Freigaben - Referrer-Policy: no-referrer steht im Freigabemodus (geprüft am 16.10.2026); X-Robots-Tag und eine kürzere Vorgabelaufzeit (weiterhin 7 Tage) stehen aus	R4	Mittel
Selbstauskunft, damit ein Besucher seine eigene Kennung abrufen kann, sodass Anträge nach Art. 15 und Art. 17 beantwortbar werden - erledigt am 17.08.2026: /meine-daten (englisch /my-data, polnisch /moje-dane), siehe R9	R9	Entfällt - erledigt am 17.08.2026
Den Zustand von Checkbox und Radio nie von der Maskierung ausnehmen; die Maskierung darauf ausdehnen	R1, R2	Mittel
Verschlüsselung im Ruhezustand; TLS zur Datenbank; Zugriffsschutz für Redis - Zugriffsschutz für Redis erledigt am 16.08.2026; Verschlüsselung im Ruhezustand und TLS zur Datenbank stehen aus (siehe R10)	R10	Mittel
Die IP aus der Telegram-Benachrichtigung entfernen oder den Kanal ersetzen - erledigt am 11.08.2026: die Benachrichtigung besteht nur noch aus einem festen Hinweistext ohne jede Variable (cfg/lib.php), abgesichert durch ai/pruefstand/test_telegram_signal.php	R13	Entfällt - erledigt am 11.08.2026
Aufbewahrungsfrist für support_requests, audit_logs und user_ip_history	R7	Entfällt - erledigt am 17.08.2026 für support_requests und audit_logs, am 24.09.2026 für user_ip_history
Mandantengrenze auf visitor_nicknames	R6	Gering
Dokumentierter Überprüfungs- und Widerspruchsweg für den automatischen Bann und das Merkmal is_suspicious - für den automatischen Bann erledigt am 17.08.2026 (Ablauf damals nach 7 Tagen, heute nach 24 h, Widerspruch über das Supportformular, Aufhebung im Administrationsbereich, siehe R8); für das Merkmal is_suspicious steht er aus	R8	Gering
Jeden CMP-Adapter gegen eine echte Installation prüfen, bevor er angeboten wird	R12	Gering

8.4 Verfahren und Vorkehrungen, die noch festzulegen sind

Art. 35 Abs. 7 lit. d verlangt Garantien, Sicherheitsvorkehrungen und Verfahren - dazu gehören die organisatorischen Abläufe, nicht nur der Code. Bei der Erhebung fehlten vier; ihr heutiger Stand steht jeweils dabei.

• Festgelegt am 17.08.2026. Erkennen: der Verantwortliche selbst, ein Kunde oder ein Websitebesucher. Meldeweg an uns: privacy@mouseplayer.com. Entscheidung über die Meldung an die Aufsichtsbehörde: Lukas Wójcik, Inhaber, binnen 72 Stunden nach Art. 33 Abs. 1. Unterrichtung des Kunden: per E-Mail, unverzüglich nach Art. 33 Abs. 2, spätestens innerhalb von 48 Stunden (Auftragsverarbeitungsvertrag, Abschnitt 8). Versand: ausgehende E-Mail ist seit dem 23.09.2026 über SMTP bei Namecheap Private Email eingerichtet (Absender office@mouseplayer.com); der zugesagte Weg zum Kunden steht damit. Eine Übung hat bisher nicht stattgefunden.
• Beantwortet am 17.08.2026: bis dahin war kein Wiederherstellungstest durchgeführt worden; vorgesehen war ein monatlicher Test, angestrebte Wiederherstellungszeit höchstens 24 Stunden. Die beiden Schlüsseldateien liegen ausgedruckt in einem Safe, zu dem ausschließlich der Verantwortliche Zugang hat. Seither durchgeführt: eine Wiederherstellungsübung aus dem neuen Ziel in Google Cloud Storage vor der Löschung der Drive-Kopien (05./06.09.2026) und am 07.10.2026 ein vollständiger Datenrestore aus der Cloud-Sicherung in eine getrennte Umgebung - rund 70 Minuten, Stichproben aus Archiv und Datenbank ohne Fehler. Das ist ein Nachweis der Datenwiederherstellung, kein Neuaufbau eines vollständigen Produktivrechners; ein Wächter, der an den nächsten Test erinnert, besteht nicht.
• Beantwortet am 17.08.2026: eine automatische Alarmierung gibt es NICHT, geprüft wird von Hand. Gemessen am selben Tag: im Code existiert kein Melder für Ausfall, Plattenplatz oder Sicherungserfolg - die einzigen Telegram-Fundstellen liegen in einer mitgelieferten Bibliothek, die niemand aufruft, srv/cron_status.php schreibt nur einen Statuswert nach Redis, und system_alerts ist leer. Die TOM sagten bis zum 17.08.2026 das Gegenteil zu ("Bei Systemausfällen erhält der Administrator automatisch eine Meldung"). Das war eine Zusage, die der Code nicht einlöst; sie ist am selben Tag berichtigt worden. Erledigt am 19.08.2026: srv/backup-crypt.sh hält den Ausgang jedes Laufs in einer Statusdatei fest, und srv/cron_status.php prüft neben den bisherigen fünf Bestandteilen den Erfolg der Sicherung, den freien Plattenplatz auf System- und Sicherungsträger sowie – als Rechts- und nicht als Betriebswächter – die Schwelle nach Art. 37. Jede fehlgeschlagene Prüfung wird höchstens einmal am Tag per E-Mail gemeldet. Der Wächter fragt nach der letzten gelungenen Sicherung und nicht nach dem letzten Versuch: Ein Skript, das jede Nacht startet und jede Nacht abbricht, hat einen frischen Zeitstempel und keine Sicherung – genau so blieb der GeoIP-Lauf fünf Tage lang unbemerkt. Eine Grenze bleibt und wird ausdrücklich genannt: Der Wächter läuft auf dem Rechner, den er überwacht, und kann dessen Totalausfall nicht melden; eine externe Erreichbarkeitsprüfung gab es nicht. Seit dem 2. Oktober 2026 prüft ein zweiter Rechner am selben Ort die Anwendung jede Minute (TOM, Abschnitt 5); ein Ausfall der Internetanbindung fällt ihm weiterhin nicht auf. Die TOM sind am selben Tag nachgezogen worden (Fassung 1.2), damit die Berichtigung nicht auf dieses Dokument beschränkt bleibt.
• Der Standpunkt der betroffenen Personen ist nicht eingeholt worden. Begründung: MousePlayer wird gegenüber den beobachteten Endnutzern ausschließlich als Auftragsverarbeiter tätig und hat zu ihnen keinen eigenen Kanal - jede Ansprache liefe über die Websites der Kunden und wäre selbst eine Verarbeitung ihrer Daten zu einem neuen Zweck. Die Interessen der Betroffenen sind stattdessen mittelbar berücksichtigt: über den Einwilligungs-Riegel, der ohne Signal nichts aufzeichnet, über die Maskierung der Eingaben und über die Löschfristen. Eine Einholung bleibt möglich, sobald es einen Kanal gibt, der die Betroffenen erreicht, ohne sie dafür erneut zu erfassen. (Entscheidung des Verantwortlichen, 17.08.2026)

9. Verbleibendes Risiko und vorherige Konsultation nach Art. 36

Art. 36 Abs. 1 verlangt die vorherige Konsultation der Aufsichtsbehörde, wenn aus einer Folgenabschätzung hervorgeht, dass die Verarbeitung ohne Maßnahmen zur Eindämmung des Risikos ein hohes Risiko zur Folge hätte. Die Prüfung fragt also nicht, ob hohe Risiken festgestellt wurden - zwei sehr hohe wurden es -, sondern ob ein hohes Risiko bleibt, sobald die Maßnahmen nach lit. d stehen. Diese Frage ist für die beiden ehrlich zu beantworten.

R5, der tägliche ausgelagerte Vollabzug, war mit gewöhnlichen Mitteln behebbar - und ist behoben. Die Verschlüsselungsschicht vor dem Hochladen steht seit dem 11.08.2026, der unverschlüsselte Altbestand beim Anbieter ist am 12.08.2026 gelöscht worden, und seit dem 05.09.2026 liegt die Kopie in einer europäischen Region unter den Google-Cloud-Datenverarbeitungsbedingungen. Die Frage, worauf die tägliche Übermittlung gestützt wird, ist damit beantwortet. Neu bewertet am 17.09.2026 steht R5 auf mittel. Die Bedingung aus der Bewertung (Entfernung der alten Skripte) ist am 16.10.2026 erfüllt; die Neubewertung von R5 liegt beim Verantwortlichen.

R1, besondere Kategorien im Seiteninhalt, ist nicht vollständig behebbar. Das System kann nicht wissen, was die Seite eines Kunden ausgibt, und keine noch so ausgefeilte Maskierungslogik ändert daran etwas. Was die Maßnahmen erreichen können, ist die Umkehr der Vorgabe, sodass der Fehlerfall eine unbrauchbare Aufzeichnung statt einer rechtswidrigen ist, dazu eine vertragliche Branchenpolitik und eine Bestätigung des Kunden. Das verringert das Risiko erheblich. Es beseitigt es nicht, denn ein Kunde kann den Seitentext weiterhin für eine Seite freigeben, die später etwas Sensibles darstellt.

Zu Art. 36 hat das Ergebnis zwei Teile, und sie dürfen nicht zu einem verschmolzen werden. Förmlich trifft die Konsultationspflicht den Verantwortlichen - den Kunden, der die Website betreibt - und nicht MousePlayer, das für die Besucherdaten mit dem hohen Risiko Auftragsverarbeiter ist. MousePlayer kann nicht an der Stelle eines Kunden konsultieren, und ein Kunde kann die Entscheidung nicht abtreten. Was MousePlayer nach Art. 28 Abs. 3 lit. f schuldet, ist, dem Kunden die Tatsachen zu geben, die ihn zur Entscheidung befähigen, und genau dafür sind die Abschnitte (a) und (c) dieses Dokuments da.

In der Sache: eine vorherige Konsultation ist nicht angezeigt, wenn die Maßnahmen aus 8.3 vor dem Produktivstart umgesetzt werden, denn dann fällt das verbleibende Risiko unter die Schwelle, die Art. 36 anspricht. Angezeigt ist die vorherige Konsultation in einer bestimmten Lage, und sie ist eine Entscheidung und kein Unfall: wenn der Inhaber sich entscheidet, die Vorgabe für den Seiteninhalt nicht umzukehren und zugleich Kunden aus dem Gesundheits-, Rechts-, Finanz- oder öffentlichen Bereich aufzunehmen. Dann bleibt das verbleibende Risiko aus freier Entscheidung hoch, und Art. 36 Abs. 1 greift nach seinem Wortlaut. Eine zweite Lage, die hier bis zum 17.09.2026 stand - der tägliche ausgelagerte Vollabzug ohne festgestellte Übermittlungsgrundlage -, besteht seit dem 05.09.2026 nicht mehr (R5).

Ein weiterer Punkt gehört hierher, weil er leicht verloren geht. Art. 36 ist keine Strafe, und zu konsultieren ist kein Eingeständnis. Es ist der Mechanismus, den die Verordnung genau für die Lage vorsieht, in der dieses System steht - ein wirklich nützliches Verfahren, dessen verbleibendes Risiko an einem Faktor hängt, den der Betreiber nicht vollständig beherrscht. Wo ein Verantwortlicher mit einem hohen verbleibenden Risiko fortfahren will, ist die Konsultation der rechtmäßige Weg dorthin.

10. Überprüfung, Fassung und Freigabe

Art. 35 Abs. 11 verlangt vom Verantwortlichen zu überprüfen, ob die Verarbeitung gemäß dieser Abschätzung durchgeführt wird, zumindest wenn sich das Risiko ändert. Drei Ereignisse ändern das Risiko hier wesentlich und sollten jeweils eine neue Erhebung auslösen statt einer Lektüre: der erste Kunde aus einer regulierten Branche; die erste Aktivierung des BigQuery-Exports oder eines Webhooks; und der Zeitpunkt, an dem die überwachten Endnutzer die in Abschnitt 3 festgehaltene Schwelle überschreiten.

Die Folgenabschätzung beruht im Kern auf Messungen vom 10. und 11. August 2026 am Entwicklungssystem, ist am 17.08.2026 freigegeben und seither fortgeschrieben worden, zuletzt am 16.10.2026 durch einen Abgleich mit dem technischen Stand. Offen sind die Platzhalter in den Abschnitten 1, 3 und 4 sowie in R12, die nur der Verantwortliche füllen kann, und die Neubewertung der Risiken, deren Ursachen seit der Erhebung ganz oder teilweise beseitigt sind (R2, R3, R9, R10); der Schluss zum verbleibenden Risiko in Abschnitt 9 steht unter dem Vorbehalt der in 8.3 noch offenen Maßnahmen.

Punkt	Eintrag
Verantwortlicher und Auftragsverarbeiter	LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82 lok. 301, 90-437 Lodz, Polen - NIP PL7252266190 - office@mouseplayer.com
Datenschutzbeauftragter	Nicht benannt. Siehe Abschnitt 3 für die Prüfung nach Art. 37 und die Empfehlung.
Verwandte Dokumente	Verzeichnis der Verarbeitungstätigkeiten nach Art. 30 Abs. 1 und Art. 30 Abs. 2, die technischen und organisatorischen Maßnahmen, die Liste der Unterauftragsverarbeiter, die Auftragsverarbeitungsvereinbarung und die Datenschutzhinweise
Grundlage der Tatsachen	Quelltext, Datenbankschema, Zeilenzahlen, Prozessliste, Konfigurationswerte und Protokolldateien des Entwicklungssystems, 10. bis 11. August 2026, fortgeschrieben bis 16. Oktober 2026
Fassung und Datum der Freigabe	Freigegeben von Lukas Wójcik, Inhaber, am 17.08.2026. Externer Datenschutzrat wurde nicht eingeholt. Überprüft wird jährlich und bei jeder Änderung der Verarbeitung; die datierten Fassungen liegen im Versionsverwaltungssystem unter ai/cms/. Ergänzt am 17.09.2026 auf Anweisung des Inhabers: R5 neu bewertet (Abschnitte 5.4, 6, 7, 8.3 und 9). Ergänzt am 16.10.2026: Abgleich mit dem technischen Stand (Kopf, Abschnitte 1, 3, 4, 5, 7, 8 und 10); Risikostufen unverändert, Neubewertung von R2, R3, R9 und R10 durch den Verantwortlichen offen. Ergänzt am 16.10.2026 (zweiter Durchgang): Fristen und die Dauer der automatischen Sperre als Einstellungen statt fester Zahlen, Rechtsgrundlagen für Supportanfragen und Kommentare, Verwahrung der Schlüssel und Erreichbarkeit der alten Sicherungsskripte (R5), Frist für die Unterrichtung des Kunden; Risikostufen unverändert, Neubewertung von R5 durch den Verantwortlichen offen. Ergänzt am 16.10.2026 (dritter Durchgang): Entfernung der alten Sicherungsskripte nachgetragen (R5), Angaben zum Zugriffsschutz von Datenbank und Redis vereinheitlicht (R10); Risikostufen unverändert, Neubewertung von R5 durch den Verantwortlichen offen.