Valutazione d’impatto sulla protezione dei dati (art. 35 GDPR) – MousePlayer Session Replay

1. Perché questa valutazione è necessaria

L’art. 35(1) GDPR richiede una valutazione d’impatto quando un tipo di trattamento, in particolare mediante nuove tecnologie e tenuto conto della natura, dell’ambito, del contesto e delle finalità, può presentare un rischio elevato per i diritti e le libertà delle persone fisiche. MousePlayer registra il comportamento dei visitatori dei siti web in modo continuativo e per impostazione predefinita: movimenti del puntatore, clic, scorrimento, tocchi e cambi di scheda, insieme a un’istantanea completa della pagina vista dal visitatore e a ogni sua modifica successiva, nonché il testo che il visitatore digita nei moduli. Il materiale registrato viene conservato, riprodotto, valutato e può essere condiviso. Non si tratta di un caso marginale dell’art. 35(1), ma del suo nucleo centrale.

Un aspetto della classificazione deve essere dichiarato con precisione anziché ripetuto. L’art. 35(3) elenca tre casi in cui è richiesta una DPIA in particolare, e nessuno dei tre corrisponde pienamente. La lettera (a) riguarda la valutazione sistematica e globale basata su un trattamento automatizzato sulla quale si fondano decisioni con effetti giuridici o analogamente significativi — qui la valutazione esiste (si veda il rischio R8), ma non è stata riscontrata alcuna decisione di questo tipo nei confronti di un visitatore. La lettera (b) riguarda il trattamento su larga scala di categorie particolari ai sensi dell’art. 9 — qui non è previsto, sebbene categorie particolari raggiungano la registrazione tramite un percorso non intenzionale (rischio R1), e i volumi misurati su questo sistema non sono su larga scala. La lettera (c) riguarda la sorveglianza sistematica su larga scala di una zona accessibile al pubblico, che è rivolta all’osservazione fisica, non a un sito web. Citare la lettera (b) come fondamento per il session replay sarebbe errato e una citazione errata è la prima cosa che un’autorità elimina.

Il percorso corretto è l’art. 35(1) stesso, applicato attraverso i nove criteri delle linee guida del WP29 sulla DPIA (WP248 rev.01, fatte proprie dall’EDPB). Due criteri sono generalmente considerati indice di un rischio elevato. Questo trattamento ne soddisfa sei o sette.

• Valutazione o attribuzione di punteggi — soddisfatto. Ogni sessione riceve engagement_score (0-255), session_quality e is_bot; alla rilevazione di agosto 2026 esistevano 4.043 righe di caratteristiche e 3.203 descrizioni delle sessioni scritte da una macchina. Da allora sono stati aggiunti ulteriori punteggi e derivazioni (si veda R8).
• Processo decisionale automatizzato con effetti giuridici o analoghi — non accertato per i visitatori. È accertato nei confronti dei clienti e degli indirizzi IP (auto-ban, is_suspicious), che costituiscono un diverso gruppo di interessati.
• Monitoraggio sistematico — soddisfatto nella forma più intensa. La registrazione è continuativa, metodica e invisibile alla persona osservata dopo la scomparsa del banner.
• Dati sensibili o di natura altamente personale — soddisfatto. Dati inseriti nei moduli, testo completo della pagina così come visualizzata per quella persona e una registrazione minuto per minuto di ciò che ha letto e su cui ha esitato.
• Larga scala — non soddisfatto in base ai dati misurati di questo sistema di sviluppo (rilevazione di agosto 2026: 706 sessioni, 329 identificativi visitatore distinti, 7 progetti, 4 account. Stato al 16/10/2026: 8.648 sessioni umane con 7.363 identificativi visitatore distinti dal 21/07/2026, di cui 3.515 identificativi distinti negli ultimi 30 giorni, in 3 dei 75 progetti creati; inoltre 186.163 sessioni contrassegnate come bot degli ultimi 14 giorni, eliminate alla scadenza del relativo periodo; 24 account, di cui 19 riconoscibili come account di prova). È soddisfatto nell’intento progettuale e il progetto non contiene alcun limite superiore.
• Raffronto o combinazione di insiemi di dati — soddisfatto. MousePlayer.setUserId() e il percorso automatico dataLayer 'uid' associano alla registrazione l’identificativo del cliente stesso; l’esportazione BigQuery invia visitor_id, custom_user_id e ip_address al data warehouse del cliente.
• Interessati vulnerabili — probabilmente soddisfatto. Il visitatore non può vedere ciò che è stato registrato, non può verificarlo e in 92 casi, alla rilevazione di agosto 2026, non poteva essere collegato affatto alle proprie registrazioni (stato al 16/10/2026: nessuna sessione del genere; si veda R9).
• Uso innovativo — soddisfatto. La riproduzione completa del DOM combinata con descrizioni comportamentali generate da una macchina non è una tecnica consolidata e ben compresa.
• Impedimento all’esercizio di un diritto o all’utilizzo di un servizio — soddisfatto in due modi circoscritti: il blocco automatico dell’IP termina gli accessi successivi e la lacuna di identificazione (R9) rende tecnicamente impossibile soddisfare l’art. 15 e l’art. 17 per una parte dei dati conservati.

L’art. 35(4) impone a ogni autorità di controllo di pubblicare un elenco delle operazioni di trattamento per cui una DPIA è obbligatoria. L’autorità competente qui è l’UODO polacco. da completare: quali voci dell’elenco UODO attuale ai sensi dell’art. 35(4) si applicano al session replay e la data della versione dell’elenco verificata

2. Ruoli: a chi spetta questo obbligo e per che cosa

MousePlayer occupa due posizioni contemporaneamente e la risposta a quasi ogni domanda in questo documento dipende da quale sia in discussione. La distinzione non è una scelta espositiva; è scritta nel codice. class/Server.class.php:416 lo dichiara nel sorgente stesso: "REGEL B ... Hier sind wir AUFTRAGSVERARBEITER" — qui siamo il responsabile del trattamento.

Dati	Ruolo di MousePlayer	Titolare del trattamento	Conseguenza
Visitatori sui siti web dei clienti: registrazioni, contenuti delle pagine, dati inseriti nei moduli, identificativi, punteggi derivati	Responsabile del trattamento (art. 28)	Il cliente MousePlayer che gestisce il sito web	L’obbligo ai sensi dell’art. 35 spetta formalmente al cliente. Il dovere di MousePlayer è prestare assistenza ai sensi dell’art. 28(3)(f).
I clienti di MousePlayer: account, fatturazione, assistenza, log degli accessi al portale, traccia di audit	Titolare del trattamento (art. 24)	LW IT Solutions Company Lukas Wójcik	MousePlayer è tenuto in proprio alla valutazione ai sensi dell’art. 35 per questo trattamento, sebbene questa parte da sola non la renderebbe necessaria.

Ne deriva un risultato che vale la pena dichiarare chiaramente, perché spesso viene frainteso in entrambe le direzioni. Il trattamento che richiede una DPIA è quello per cui MousePlayer non è il titolare del trattamento. Un responsabile del trattamento non può svolgere la valutazione del titolare al suo posto, non può decidere per suo conto sulla necessità e non può consultare l’autorità di controllo al suo posto ai sensi dell’art. 36. Ciò che un responsabile può e deve fare è fornire al titolare tutto ciò di cui ha bisogno — la descrizione ai sensi della lettera (a), i fatti misurati ai sensi della lettera (c) e un elenco onesto dello stato ai sensi della lettera (d). Questo documento è proprio questo: la valutazione di MousePlayer sulle proprie operazioni e la base fattuale necessaria al cliente per la propria valutazione.

3. Responsabile della protezione dei dati: il criterio dell’art. 37

Non è designato alcun responsabile della protezione dei dati. L’art. 37(1) vincola allo stesso modo "il titolare del trattamento e il responsabile del trattamento", quindi la questione riguarda MousePlayer stesso e non può essere trasferita ai clienti. I tre casi previsti dalla legge:

Art. 37(1)	Criterio	Risultato in base ai fatti misurati
(a)	Trattamento da parte di un’autorità pubblica o di un organismo pubblico	Non applicabile. LW IT Solutions Company è un’impresa privata.
(b)	Le attività principali richiedono il monitoraggio regolare e sistematico degli interessati su larga scala	Attività principale: sì, indiscutibilmente — il monitoraggio è il prodotto, non una funzione di supporto. Regolare e sistematico: sì — continuativo, metodico, secondo un sistema predisposto. Larga scala: no, in base ai dati misurati (rilevazione di agosto 2026: 706 sessioni, 329 identificativi, 4 account; stato al 16/10/2026: 3.515 identificativi distinti di visitatori umani in 30 giorni; un’istanza di sviluppo).
(c)	Le attività principali consistono nel trattamento su larga scala di dati ai sensi dell’art. 9 o dell’art. 10	Non per progettazione. Categorie particolari entrano comunque nei contenuti di pagina conservati tramite il percorso descritto nel rischio R1. Ciò è incidentale, non costitutivo, per cui il caso non sussiste oggi — ma diventa sostenibile nel momento in cui viene acquisito un cliente nel settore sanitario, legale o finanziario.

WP243 (fatto proprio dall’EDPB) valuta la "larga scala" in base al numero di interessati, al volume e alla gamma dei dati, alla durata e all’estensione geografica. Tre di questi quattro fattori sono già al massimo qui: la gamma è una ricostruzione completa della sessione dell’individuo, la durata è continuativa e l’estensione geografica corrisponde al pubblico dei clienti. Soltanto il numero di persone è ridotto. Per evitare di accorgersi della soglia troppo tardi, srv/cron_status.php conteggia, una volta al giorno dal 19/08/2026, gli identificativi distinti dei visitatori umani degli ultimi 30 giorni (escludendo 'unknown' e le sessioni contrassegnate come bot), confronta la cifra con la soglia di 100000 utenti finali al mese e segnala via e-mail il superamento e la scadenza del riesame annuale. Stato al 16/10/2026: 3.515.

Ne conseguono due indicazioni, entrambe raccomandazioni e non affermazioni di legge. In primo luogo, registrare ora una valutazione scritta della soglia, con un numero dichiarato di utenti finali monitorati al cui raggiungimento la designazione avviene automaticamente e un intervallo di riesame fisso — in modo che la decisione sia documentata come presa, non semplicemente come non ancora presa. In secondo luogo, tenere presente che l’art. 37(4) consente al diritto degli Stati membri di richiedere la designazione in ulteriori casi. da completare: conferma giuridica se il diritto polacco, ai sensi dell’art. 37(4), imponga la designazione oltre l’art. 37(1). La soglia e l’intervallo di riesame sono decisi: più di 100000 utenti finali osservati al mese, almeno annualmente

L’art. 35(2) impone al titolare del trattamento di chiedere il parere del responsabile della protezione dei dati, ove designato, durante lo svolgimento di una DPIA. In assenza di un responsabile designato, tale passaggio non è applicabile e l’omissione non costituisce un difetto. Approvata da Lukas Wójcik, titolare, il 17/08/2026. Non è stata ottenuta alcuna consulenza esterna sulla protezione dei dati. Riesaminata annualmente e a ogni modifica del trattamento; le versioni datate sono conservate nel controllo di versione sotto ai/cms/.

4. Metodo, fonti e limiti di questa bozza

Ogni affermazione fattuale di questo documento è stata verificata sul sistema in esecuzione — codice sorgente, schema del database, conteggi delle righe, elenco dei processi, valori di configurazione e file di log — anziché tratta da descrizioni del prodotto o da ciò che il software dovrebbe fare. Se una misurazione contraddice un’intenzione, viene riportata la misurazione. Se non è stato possibile accertare un fatto, al suo posto compare un segnaposto; nessuna cifra è stata stimata e nessun periodo di conservazione è stato inventato.

• Il sistema misurato è l’istanza di sviluppo (APP_ENV=dev). Diverse cifre sono quindi artefatti dei dati di prova e sono indicate come tali — soprattutto le registrazioni del consenso, in cui 671 sessioni su 706 hanno consent_source='testdata' con una marca temporale NULL, scritta da ai/devdata/001_altsitzungen_markieren.sql (rilevazione di agosto 2026; stato al 16/10/2026: 566 su 8.648 sessioni umane).
• Alcune misurazioni sono state effettuate a distanza di pochi minuti e differiscono leggermente di conseguenza (705 contro 706 sessioni; 36.409 righe di log contro 36.542 indirizzi verificati). Entrambe le cifre sono riportate come misurate anziché conciliate a posteriori.
• Non era disponibile l’accesso a livello root. Non è stato quindi possibile verificare la configurazione delle jail fail2ban, i crontab di root e www-data e l’arrivo del backup esterno a destinazione. Ciascun aspetto è contrassegnato come non verificato anziché presunto. Aggiunto successivamente: nel frattempo il gestore ha effettuato il passaggio del backup con diritti root e l’arrivo del backup esterno a destinazione è documentato dall’11/08/2026, perché l’esecuzione giornaliera lo registra e lo verifica autonomamente — è documentato per l’11/08/2026 e il 12/08/2026 (si veda R5). Ricontrollato il 16/10/2026: fail2ban esegue nove jail, tra cui mp-nginx-429 per gli indirizzi che attivano ripetutamente il limite di frequenza nginx. Le esecuzioni programmate di MousePlayer sono elencate in /etc/cron.d/mouseplayer e passano da srv/cron_run.sh con l’account dedicato mouseplayer-dev; anche i servizi worker vengono eseguiti con tale account. Il backup giornaliero è ancora avviato dal cron di root e l’esecuzione giornaliera delle eliminazioni avviene ancora all’interno del processo db_worker.
• Le cartelle dei fornitori (Stripe SDK, Google Cloud SDK, PHPMailer, Symfony) non sono state esaminate alla ricerca di endpoint in uscita. Il codice proprietario è stato esaminato esaustivamente per curl_init, curl_exec, file_get_contents su http, fsockopen e stream_context_create e per tutti i valori letterali https.
• Una cifra in questa valutazione — 92 sessioni con visitor_id 'unknown' — è stata adottata come misurazione accertata alla rilevazione di agosto 2026, perché non poteva essere misurata nuovamente in quel momento. Misurata nuovamente il 16/10/2026: nessuna sessione ha più visitor_id 'unknown'. Il codice può ancora scrivere tale valore alla creazione di una sessione (srv/db_worker.php); R9 rimane quindi possibile.

5. (a) Descrizione sistematica delle operazioni di trattamento e delle finalità

5.1 Come funziona la registrazione

Il cliente incorpora nel proprio sito web un file JavaScript statico (www/mp.js). Prima che venga registrato qualcosa devono essere superati due controlli. Un controllo dei bot viene eseguito per primo e termina per i browser automatizzati. Dietro di esso si trova la macchina a stati del consenso mpEinw, che consente la creazione del tracker soltanto in presenza di un segnale di consenso positivo — proveniente da una chiamata API del cliente stesso, da Google Consent Mode, da una CMP supportata o da una stringa TCF. Ogni altro esito, compresi la completa assenza di segnale, una CMP che non si carica, un errore dello script e un’origine sconosciuta, non produce alcuna registrazione. Il principio guida è registrato nelle note di lavoro del progetto e vale in tutto il codice: in caso di dubbio, non registrare.

Una volta autorizzato, lo script apre un WebSocket cifrato (/mp_wss/) verso il server di registrazione. La cifratura TLS termina in nginx; il server WebSocket stesso (srv/server.php) ascolta soltanto sull’indirizzo di loopback 127.0.0.1:8081 e riceve da lì la connessione non cifrata all’interno della stessa macchina. Il server applica il controllo una seconda volta, indipendentemente dal browser: class/Server.class.php:977-1004 ammette soltanto GRANTED o GRANTED_LATE oppure un’esenzione regionale esplicita e chiude la connessione con codice 1008 in caso di revoca, paese sconosciuto o qualsiasi situazione non chiara. Prima viene eseguito un elenco di esclusione dei percorsi, che confronta soltanto il percorso e non l’URL completo. Se il WebSocket non può essere stabilito per tre volte consecutive (un proxy o firewall blocca l’handshake), lo script invia invece gli stessi messaggi tramite HTTPS POST a /mp_wst; tale endpoint non decide nulla e li passa allo stesso processo server, dove attraversano lo stesso controllo (www/api/ws_tunnel.php, class/HttpTunnel.class.php). Un’istantanea di pagina più grande di 1 MB viene caricata dallo script tramite HTTPS POST a /mp_dom (www/api/dom_upload.php); tale endpoint verifica un token di accesso a validità limitata firmato dal server, mantiene l’istantanea in Redis per un massimo di 120 secondi e non decide altro — viene recuperata dalla stessa connessione che ha già superato i controlli. Inoltre, /mp_wsfail conteggia le connessioni WebSocket fallite per progetto, senza un identificativo visitatore; l’indirizzo IP vi è utilizzato soltanto come hash per la deduplicazione e scade dopo un’ora. Gli eventi passano in coda attraverso Redis e vengono scritti da un worker a lunga esecuzione (srv/db_worker.php) in MariaDB.

Ciò che viene conservato non è un video. È la pagina stessa: una copia serializzata del DOM al momento della visualizzazione di pagina, più ogni sua modifica successiva, riprodotta poi in un iframe su cui sono disegnate le posizioni registrate del puntatore. Questa distinzione è rilevante per la valutazione del rischio, perché significa che il materiale conservato contiene tutto ciò che conteneva la pagina — compreso il testo che il visitatore non ha mai digitato e non ha mai considerato "dati".

5.2 Registro delle operazioni di trattamento

Finalità	Ruolo	Tabelle principali	Cancellazione (stato al 23/09/2026)
Registrazione del comportamento: movimento, clic, scorrimento, tocchi, cambi di scheda	Responsabile del trattamento	mouse_events (225.892 righe, 322,6 MB), session_pageviews, visitor_sessions	Eliminazione giornaliera in base al piano, monitorata (si veda R7)
Contenuto della pagina: istantanea DOM e mutazioni dal vivo, per riprodurre la pagina così come vista	Responsabile del trattamento	session_pageviews.payload_blob (1.848 righe, 162,9 MB), mouse_events.target_selector per le mutazioni (66.153 righe)	Stessa eliminazione
Dati inseriti nei moduli, carattere per carattere, mascherati secondo il livello configurato	Responsabile del trattamento	mouse_events.target_selector per gli eventi di inserimento (599 righe)	Stessa eliminazione; per le 173 righe pregresse si veda R2
Riconoscimento dello stesso visitatore tra sessioni e visualizzazioni di pagina	Responsabile del trattamento	visitor_sessions.visitor_id / custom_user_id, visitor_nicknames (329 righe)	visitor_nicknames: con l’ultima sessione del visitatore
Determinazione della rete e della posizione approssimativa	Responsabile del trattamento	visitor_sessions.ip_address, country, city, asn_number, asn_org; ip_lifetime_stats (446 righe)	ip_lifetime_stats: 365 giorni
Prova del consenso e delle sue modifiche (art. 7(1))	Responsabile del trattamento, conservata per l’onere della prova del cliente	consent_events (120 righe), visitor_sessions.consent_*	730 giorni da the withdrawal; conservata deliberatamente fino ad allora perché costituisce la prova che il consenso è stato revocato
Eventi personalizzati, segnali di frustrazione, errori JavaScript	Responsabile del trattamento	session_custom_events (823), session_custom_event_params (1.264)	Stessa eliminazione
Caratteristiche derivate e descrizioni delle sessioni scritte da una macchina	Responsabile del trattamento	ai_session_features (4.043), ai_timelines (3.203 righe, 5,5 MB)	Con la sessione, nella stessa catena di eliminazione
Gestione degli account dei clienti di MousePlayer	Titolare del trattamento	users (4), user_ip_history (5), workspace_users, workspace_invites	Con l’account; account inattivi dopo 24 mesi e un avviso recapitato
Registrazione degli accessi, della sicurezza e delle modifiche del portale	Titolare del trattamento	mouseplayer_logs (36.409), security_access_logs (1.354), audit_logs (666), banned_ips	60 giorni / 72 ore / 60 giorni / alla scadenza
Richieste di assistenza	Titolare del trattamento	support_requests	730 giorni
Collaborazione su una riproduzione: commenti e link di condivisione	Misto — titolare del trattamento per l’autore, responsabile del trattamento per il contenuto registrato	session_comments (12), session_shares (9)	Commenti con la sessione; link di condivisione 90 giorni dopo la loro scadenza
Accettazione da parte del cliente delle regole regionali di registrazione	Titolare del trattamento	consent_region_acceptances (0 righe)	730 giorni

5.3 Base giuridica

Per tutto ciò che si trova nel percorso di registrazione, la base è il consenso, e il ragionamento è documentato nella migrazione che ha introdotto l’architettura del consenso (ai/migrations/018_consent.sql): la registrazione è osservazione del comportamento ai sensi del considerando 24 e accesso all’apparecchiatura terminale secondo l’attuazione polacca delle norme ePrivacy, richiede il consenso e non può basarsi sul legittimo interesse. Tutti i 7 progetti sono impostati su consent_mode='required'. L’interruttore di disattivazione site_settings.consent_gate_active è attivo. Tale analisi è corretta e insolitamente ben documentata; non viene attenuata in alcun punto del codice.

Per quattro operazioni il codice non indica alcuna base: la gestione degli account di MousePlayer, i log degli accessi e della sicurezza del portale, le richieste di assistenza e i commenti sulle riproduzioni. Sono le operazioni svolte nel ruolo di titolare del trattamento. Il legittimo interesse (art. 6(1)(f)) e l’esecuzione del contratto (art. 6(1)(b)) sono i candidati evidenti, ma un candidato non è una determinazione e l’art. 6(1)(f) richiede una valutazione di bilanciamento documentata. Risposta del 17/08/2026: dati di account e fatturazione art. 6(1)(b), per la conservazione delle fatture (c) (cinque anni dalla fine dell’anno civile in cui cadeva il termine di pagamento dell’imposta). Log degli accessi, della sicurezza e delle modifiche, nonché reCAPTCHA e log del server: (f), finalità difesa dagli abusi e responsabilizzazione; le valutazioni di bilanciamento sono riportate nel registro sotto B.2 e B.5. Dimostrazione nella pagina iniziale: consenso, (a). Richieste di assistenza: (b) se chi chiede è un Cliente e la richiesta riguarda il contratto, altrimenti (f) (registro, B.3). I commenti sulle riproduzioni e i link di condivisione sono trattati da MousePlayer su istruzione del Cliente (registro, A.9).

5.4 Destinatari e trasferimenti verso paesi terzi

Nel percorso di registrazione non è stata trovata alcuna chiamata in uscita verso terzi. La geolocalizzazione utilizza file locali del database MaxMind anziché un servizio web — una scelta progettuale deliberata registrata nel codice, così che nessun terzo venga contattato prima che esista il consenso. Caratteri, bandiere e script vengono serviti localmente. È un risultato effettivamente positivo e dovrebbe essere dichiarato come tale.

Destinatario	Che cosa viene trasferito	Stato attuale
Il cliente	Tutto ciò che viene registrato, tramite la dashboard e i tre endpoint del lettore	Attivo — questa è la finalità
Chiunque possieda un link di condivisione, senza effettuare alcun accesso	Una riproduzione completa di una sessione	Attivo; stato al 16/10/2026: 5 link di condivisione creati; ogni accesso è registrato con ora, indirizzo IP e identificativo del browser (share_views)
Google Cloud Storage, Varsavia (fino al 05/09/2026: Google Drive, USA)	Una copia completa giornaliera di ogni database e dell’intero albero web. Fino all’11/08/2026 non cifrata. Dall’11/08/2026 cifrata sul nostro server prima di essere trasferita	Attivo ogni giorno. Il trasferimento in chiaro è terminato l’11/08/2026; i dati pregressi non cifrati presso Google sono stati eliminati il 12/08/2026. Dal 05/09/2026 account aziendale, regione europe-central2 (Varsavia), coperto dal Google Cloud Data Processing Addendum; le copie nel precedente account Drive sono state eliminate il 06/09/2026 — si veda il rischio R5
Stripe (USA / Irlanda)	E-mail del cliente, nome, indirizzo di fatturazione, dati di pagamento — nessun dato dei visitatori	Soltanto chiavi di prova; chiavi di produzione vuote
Namecheap Private Email (invio di e-mail tramite SMTP)	Indirizzo del destinatario, oggetto e contenuto delle e-mail in uscita ai clienti e al gestore, come conferma dell’account, reimpostazione della password, inviti, avvisi di accesso da nuovi dispositivi, avvisi prima dell’eliminazione di account inattivi, comunicazioni di modifica dei documenti contrattuali, report settimanale, risposte dell’assistenza, avvisi su contrassegni e anomalie e allarmi di sistema	Attivo dal 23/09/2026, mittente office@mouseplayer.com; incluso tra i sub-responsabili
Telegram (al di fuori dell’UE)	Fino all’11/08/2026: richieste di assistenza complete, compresi l’indirizzo IP non abbreviato e il testo completo del messaggio. Dall’11/08/2026: soltanto una frase fissa — "MousePlayer: es liegt eine neue Supportanfrage vor." — nessuna variabile, nessun numero del caso, nessun link; nessun dato personale lascia più il sistema tramite questo canale	Canale ancora attivo (token impostati in .env), ma dall’11/08/2026 non è un destinatario di dati personali e quindi non è un responsabile del trattamento
Google reCAPTCHA (USA)	Pagine di accesso, registrazione, assistenza e fatturazione	Disattivato su questo sistema (APP_ENV=dev); attivo in produzione
Google BigQuery (progetto del cliente)	session_id, visitor_id, custom_user_id, ip_address, country, referrer, user agent, dimensioni dello schermo, marche temporali, tipo di dispositivo	Inattivo: disattivato su tutti i 7 progetti e il processo non è in esecuzione
URL webhook definito dal cliente (destinazione senza restrizioni)	Dati dell’evento più un link diretto al lettore della sessione	Inattivo: disattivato su tutti i 7 progetti, processo dispatcher in esecuzione

5.5 Conservazione, come misurata e non come prevista

Esiste una procedura di eliminazione automatica ed è in esecuzione. Risiede nel processo worker permanentemente attivo (srv/db_worker.php), viene eseguita all’avvio del processo e poi una volta per giorno civile; lo stesso processo elimina ogni ora i dati scaduti delle sessioni contrassegnate come bot. L’esecuzione delle eliminazioni non ha una propria voce cron. La sua assenza, tuttavia, non passa più inosservata: il worker ne registra l’esito e srv/cron_status.php — un processo diverso — lo valuta, segnala via e-mail un’esecuzione risalente a più di 48 ore prima e registra il guasto come voce nei Log urgenti dell’area di amministrazione. Le altre esecuzioni programmate sono elencate in /etc/cron.d/mouseplayer; anche i loro errori e le pause eccessivamente lunghe vengono segnalati dallo stesso processo di stato (stato al 16/10/2026).

Alla rilevazione di agosto 2026 la procedura non aveva ancora eliminato nulla: tutti i progetti appartenevano a un proprietario con livello Enterprise e 365 giorni di conservazione e la sessione più vecchia aveva 20 giorni. Al 16/10/2026 elimina in modo dimostrabile: i periodi dei log e dei dati derivati producono effetti (la voce più vecchia in audit_logs si colloca al limite di 60 giorni), le sessioni contrassegnate come bot vengono eliminate dopo 14 giorni e le relative registrazioni svuotate dopo il proprio periodo (periodo in giorni: 1). Il periodo del livello per le sessioni umane non ha ancora raggiunto alcuna sessione, perché i due progetti con autentico traffico di visitatori appartengono ancora a un proprietario con livello Enterprise e 365 giorni e le loro sessioni più vecchie risalgono al 21/07/2026.

6. (b) Valutazione della necessità e della proporzionalità

Necessità e proporzionalità vengono valutate rispetto alla finalità dichiarata: consentire a un gestore di siti web di comprendere come i visitatori utilizzano il sito, dove incontrano difficoltà e perché lo abbandonano. Tale finalità è legittima e la tecnica generale è in grado di servirla. La domanda posta dall’art. 35(7)(b) è più circoscritta e più difficile: è questo trattamento, a questo livello di dettaglio, necessario per tale finalità — e l’intrusione è proporzionata al beneficio?

Componente	Necessario per la finalità?	Proporzionato così come realizzato?
Movimento del puntatore, clic, scorrimento, tocchi	Sì. È il segnale a cui si riferisce la finalità.	Sì.
Struttura e disposizione della pagina visitata	Sì. Le coordinate non hanno significato senza la disposizione a cui si riferiscono.	Sì, in linea di principio.
Contenuto testuale dell’intera pagina, parola per parola	No — non in generale. Comprendere dove un visitatore ha incontrato difficoltà richiede la struttura e le etichette, non i contenuti personali visualizzati al loro interno.	No, così come attualmente realizzato. Il mascheramento deve essere richiesto per ogni elemento; l’impostazione predefinita è conservare tutto. Si veda R1.
Dati inseriti nei moduli	Discutibile. Sapere che un campo è stato abbandonato è utile; sapere che cosa vi è stato digitato è raramente necessario.	In parte. Il livello minimo di mascheramento è solido e tutti i progetti utilizzano il livello più rigoroso — ma il progetto consente comunque livelli più deboli e l’etichetta di tale impostazione è invertita (il livello 0 è il più rigoroso, il suggerimento della dashboard dice il contrario).
Stato delle caselle di controllo e dei pulsanti di opzione	Discutibile.	No. Non vengono mai mascherati a nessun livello — e una casella di controllo può contenere una dichiarazione sanitaria, un’affiliazione politica o un consenso a una finalità sensibile.
Riconoscimento tra sessioni	Sì per l’analisi dei visitatori di ritorno; non per la finalità principale.	A determinate condizioni. Il riconoscimento pseudonimo è proporzionato; l’identificativo fornito dal cliente è il punto in cui finisce la proporzionalità. Si veda R6.
Indirizzo IP	Sì per l’attribuzione approssimativa della posizione (paese; la città soltanto dall’indirizzo già troncato) e per la difesa dagli abusi.	Sì, per il futuro: l’indirizzo viene troncato immediatamente dopo la lettura, prima che qualsiasi componente che lo utilizza lo veda. I dati pregressi nel percorso di registrazione sono stati rimossi il 17/08/2026; si veda R3.
Attribuzione di punteggi e descrizioni delle sessioni	No. Sono facilitazioni per il flusso di revisione del cliente.	Dubbio e costituisce la parte meno esaminata del sistema — non viene indicata alcuna base giuridica in nessun punto del codice.
Copia esterna completa (presso un fornitore di un paese terzo fino al 05/09/2026)	Un backup esterno sì — serve alla disponibilità (art. 32(1)(c)). La sua portata va oltre questo servizio: contiene ogni database della macchina.	Dal 05/09/2026 sì, con una riserva sulla portata. La copia viene cifrata prima del trasferimento e conservata in una regione europea nell’ambito di un accordo ai sensi dell’art. 28. Fino al 05/09/2026 no: nessun contratto accertato e non cifrata fino all’11/08/2026. Si veda R5.

Quanto alla minimizzazione dei dati (art. 5(1)(c)), il sistema mostra due facce opposte. Una minimizzazione deliberata è visibile in diversi punti ed è ben motivata nel codice: i nomi dei campi vengono classificati anziché trasmessi, perché il nome grezzo di un campo in un negozio è spesso abbastanza descrittivo da identificare la persona; la stringa TCF è conservata soltanto come hash SHA-256; il contenuto della riproduzione è deliberatamente escluso dall’API pubblica. A ciò si contrappone la decisione progettuale centrale di conservare per impostazione predefinita l’intera pagina parola per parola, che è l’opposto della minimizzazione e non è compensata da nessuna delle misure precedenti.

Quanto alla limitazione della conservazione (art. 5(1)(e)), la valutazione era inequivocabile e sfavorevole fino al 17/08/2026. Tredici tabelle contenenti dati personali non avevano alcun periodo di cancellazione, comprese le due che contengono il materiale più leggibile: ai_timelines, che presenta ogni sessione come prosa leggibile, e visitor_nicknames. La procedura esistente non era mai stata eseguita su dati reali. Un piano di conservazione che non ha mai eliminato una registrazione è un progetto, non una misura di protezione. Dal 17/08/2026 tutte e tredici le tabelle hanno un periodo, l’eliminazione cancella in modo dimostrabile e la sua assenza viene segnalata (si veda R7).

7. (c) Valutazione dei rischi per i diritti e le libertà degli interessati

I rischi sono valutati per l’interessato, non per l’impresa. La probabilità è valutata come Remota, Possibile, Probabile o Concretizzato — l’ultima voce significa che l’evento non è una previsione, ma uno stato attuale e misurato dei dati. La gravità è valutata come Limitata, Significativa, Grave o Molto grave, in base a ciò che la persona interessata rischia di perdere: non imbarazzo, ma esposizione di caratteristiche sanitarie, finanziarie o altrimenti protette, perdita di controllo sull’identificazione e impossibilità di esercitare un diritto.

ID	Rischio	Probabilità	Gravità	Livello
R1	Categorie particolari di dati nei contenuti delle pagine registrati	Probabile	Molto grave	Molto alto
R2	Dati inseriti nei moduli non mascherati nei dati pregressi (173 righe) — valutazione della rilevazione; le righe sono state eliminate il 17/08/2026, è in attesa una rivalutazione da parte del titolare del trattamento	Concretizzato	Significativa	Alto
R3	Indirizzi IP non abbreviati nei dati pregressi e nei log del portale — valutazione della rilevazione; i dati pregressi sono stati abbreviati il 17/08/2026 e da allora i log del portale prevedono periodi, è in attesa una rivalutazione	Concretizzato	Significativa	Alto
R4	I link di condivisione espongono una riproduzione completa senza effettuare alcun accesso	Possibile	Grave	Alto
R5	Copia esterna completa giornaliera — non cifrata fino all’11/08/2026, cifrata sul nostro server prima del trasferimento dall’11/08/2026; i dati pregressi non cifrati sono stati eliminati presso il fornitore il 12/08/2026. Dal 05/09/2026 la copia è conservata in un bucket Google Cloud Storage nella regione europe-central2 (Varsavia) con un account aziendale, coperto dal Google Cloud Data Processing Addendum; le copie nel precedente account Drive sono state eliminate il 06/09/2026. La portata è invariata. Se entrambi i file delle chiavi vanno persi, il backup è irrecuperabile; copie stampate sono conservate in una cassaforte	Remota (rivalutato il 17/09/2026). In precedenza: trasferimento in chiaro fino all’11/08/2026, trasferimento senza una base giuridica accertata fino al 05/09/2026 — entrambi concretizzati e terminati	Molto grave	Medio — rivalutato il 17/09/2026; molto alto fino al 05/09/2026. La condizione posta dalla valutazione (rimozione dei vecchi script) è stata soddisfatta il 16/10/2026; la rivalutazione di R5 spetta al titolare del trattamento
R6	Riconoscimento tra sessioni e unione con le registrazioni del cliente	Probabile	Grave	Alto
R7	Nessun periodo di cancellazione per tredici tabelle; risolto dal 17/08/2026, l’eliminazione viene eseguita ogni giorno ed è monitorata	Remota (rivalutata il 23/09/2026). Fino al 17/08/2026: concretizzato	Grave	Basso — rivalutato il 23/09/2026; alto fino al 17/08/2026
R8	Attribuzione automatizzata di punteggi e classificazione di ogni sessione	Probabile	Significativa	Medio
R9	92 sessioni irraggiungibili tramite qualsiasi identificativo; nessun percorso dalla persona alla registrazione — valutazione della rilevazione; stato al 16/10/2026 nessuna sessione del genere, ricerca autonoma dal 17/08/2026, è in attesa una rivalutazione	Concretizzato	Significativa	Alto
R10	Nessuna cifratura a riposo, nessun TLS verso il database, Redis senza protezione degli accessi (fino al 16/08/2026; da allora accesso limitato, database e Redis inoltre raggiungibili nella rete locale — è in attesa una rivalutazione)	Possibile	Molto grave	Medio-alto
R11	Nessuna registrazione di chi abbia visualizzato quale registrazione di sessione	Concretizzato	Significativa	Medio-alto
R12	Qualità della prova del consenso; adattatori CMP non testati	Concretizzato (dati di sviluppo)	Grave	Medio
R13	Richieste di assistenza a Telegram compreso l’IP non abbreviato — fino all’11/08/2026; dall’11/08/2026 viene inviato soltanto un testo di avviso fisso senza alcuna variabile. Rimane la conservazione locale della richiesta con indirizzo e-mail e IP in support_requests; dal 17/08/2026 con un periodo di 730 giorni (si veda R7)	Trasferimento: risolto l’11/08/2026. Conservazione locale: concretizzato	Significativa — fino all’11/08/2026 per il trasferimento, da allora soltanto per la conservazione locale	Risolto l’11/08/2026 per quanto riguarda il trasferimento; la conservazione locale residua è trattata in R7 (ivi valutato basso dal 23/09/2026)
R14	Uscita verso destinatari scelti dal titolare del trattamento — una richiesta di cancellazione non li raggiunge	Possibile (dipende dall’attivazione di un connettore da parte del titolare; nei dati attuali: nessuno attivato)	Sostanziale	Medio

R1 — Categorie particolari di dati nei contenuti delle pagine registrati

Questo è il rischio più grave del sistema e il meno visibile, perché nulla lo fa apparire come un difetto. Il mascheramento dell’istantanea della pagina opera soltanto all’interno delle aree contrassegnate (www/mp.js:3934-3970): all’interno di un elemento con data-mp-mask o la classe .mp-masked, ogni carattere diverso dagli spazi bianchi viene sostituito e gli attributi al di fuori di un elenco di elementi da mantenere vengono impostati su [FILTERED]. Tutto il resto viene conservato parola per parola. Il mascheramento è quindi un’annotazione su adesione esplicita che il cliente deve applicare, elemento per elemento, a una pagina che potrebbe non controllare completamente.

La conseguenza è che la protezione copre ciò che il visitatore digita e non ciò che la pagina mostra in risposta. Una pagina di conferma di uno studio medico che mostra un appuntamento con una specializzazione nominata; un carrello di farmacia; un preventivo assicurativo che elenca condizioni preesistenti; un estratto conto bancario; un riepilogo di ammissione al patrocinio legale — sono tutti contenuti prodotti dalla pagina, al di fuori di qualsiasi campo di inserimento, e finiscono tutti in payload_blob senza modifiche. Non è ipotetico: 1.848 righe sono popolate, in media 90,3 kB, e un campione conferma che il valore conservato inizia con il documento <html> completo. Lo stesso vale per ogni modifica successiva della pagina, serializzata come frammenti HTML in mouse_events.target_selector su 66.153 righe di mutazioni.

Probabilità — Probabile. Il meccanismo di protezione richiede un’azione deliberata da parte di qualcuno diverso dalla persona a rischio, per impostazione predefinita conserva tutto e non prevede rilevamento, avvisi o report che informino il cliente che vengono acquisiti contenuti personali non mascherati. Nulla nel sistema campiona il contenuto conservato alla ricerca degli schemi che lo indicherebbero. La probabilità che almeno una pagina di un cliente visualizzi dati di categorie particolari è prossima a uno su qualsiasi periodo significativo di esercizio.

Gravità — Molto grave. I dati ai sensi dell’art. 9(1) godono della protezione più elevata e nessuna delle eccezioni dell’art. 9(2) è disponibile qui. Il consenso del visitatore alla registrazione delle sessioni non è un consenso esplicito al trattamento di dati sanitari e non potrebbe esserlo — né il visitatore, né il cliente, né MousePlayer sanno in quel momento che tali dati vengono acquisiti. Il materiale è conservato parola per parola, è interamente riproducibile, è esportabile, è incluso nella copia esterna giornaliera (R5) e può essere consegnato a un terzo non identificato tramite un link di condivisione (R4).

R2 — Dati inseriti nei moduli non mascherati nei dati pregressi

173 righe in mouse_events contengono valori inseriti nei moduli in chiaro. Sono state individuate mediante un confronto di schemi sulla struttura conservata ('"v":"' seguito da un carattere diverso da quello di mascheramento), rientrano nel periodo dal 21/07/2026 al 27/07/2026 e comprendono dati come il nome completo di una persona. Le righe scritte il 10/08/2026 sono mascherate, quindi il comportamento in esercizio è ora corretto: tutti i 7 progetti utilizzano smart_masking=0, che nonostante l’etichetta è l’impostazione più rigorosa e sostituisce ogni carattere di ogni campo, mentre un limite minimo incondizionato sostituisce password e dati di pagamento con qualsiasi impostazione.

Probabilità — Concretizzato. Questa non è una previsione. Le righe esistono ora e, poiché mouse_events viene svuotata soltanto dall’eliminazione in base al livello — che non elimina nulla prima che una registrazione abbia 365 giorni e non è mai stata eseguita — rimarranno almeno fino a luglio 2027, salvo rimozione manuale. La probabilità futura di ricorrenza è bassa.

Gravità — Significativa. I campioni noti sono innocui, ma il contenuto delle righe restanti non è stato classificato e le categorie di campo riconosciute dal sistema comprendono email, phone, payment, address e name. Non è stato accertato se il limite minimo incondizionato per password e pagamenti fosse già presente in quel periodo. Completato il 17/08/2026: le righe sono state eliminate senza essere esaminate (decisione del titolare del trattamento). In base alla misurazione erano 174 righe di 18 sessioni di un singolo progetto, dal 21/07/2026 al 06/08/2026; dopo l’esecuzione ne rimangono 0. La lacuna stessa era già stata colmata: dal 07/08/2026 nessun valore contiene testo in chiaro. Quasi un secondo errore nella misurazione: il carattere di mascheramento è l’asterisco, non il punto elenco — un confronto basato sul punto elenco ha trovato 862 righe con l’occorrenza più recente di oggi ed è quindi apparso come una fuga di dati in corso. Un’eliminazione basata su quel numero avrebbe rimosso anche 688 righe correttamente mascherate.

R3 — Indirizzi IP non abbreviati nei dati pregressi e nei log del portale

Il troncamento degli IP nel percorso di registrazione è implementato correttamente e nel punto giusto: class/Server.class.php:432-435 sostituisce l’ultimo ottetto IPv4 o l’ultimo gruppo IPv6 immediatamente dopo la lettura dell’indirizzo, prima che esista qualsiasi componente che utilizza il valore. È verificato come efficace per i nuovi dati — ogni sessione registrata dal 07/08/2026 è troncata. Non è retroattivo e non esiste alcuna procedura di aggiornamento dei dati pregressi; questi sono stati invece rimossi una sola volta, manualmente, il 17/08/2026 — si veda la nota di stato sotto la tabella.

Tabella	Indirizzi non abbreviati (stato al momento della valutazione, prima del 17/08/2026)	Periodo di cancellazione
visitor_sessions	236 su 705, dal 21/07/2026 al 07/08/2026, indirizzi pubblici completi	Eliminazione in base al livello — mai eseguita
ip_lifetime_stats	291 su 446	Nessuno in alcun punto
mouseplayer_logs	Nessuno dei 36.542 indirizzi verificati era abbreviato	60 giorni
audit_logs	Tutte le 666 righe	Nessuno
user_ip_history	Tutte le 5 righe	Nessuno
security_access_logs	1.004 su 1.354	72 ore
support_requests	Tutti e inoltrati ulteriormente — si veda R13	Nessuno
Log degli accessi Apache	Tutti	14 rotazioni giornaliere

Probabilità — Concretizzato. Gravità — Significativa. Un indirizzo IP da solo costituisce un’esposizione limitata. In visitor_sessions non è solo: si trova nella stessa riga della registrazione, quindi collega un’identità di rete e, attraverso essa, una persona a una riproduzione completa del suo comportamento — compreso tutto ciò che rientra in R1. I log del portale sono meno critici ma molto più ampi e costituiscono il trattamento nel ruolo di titolare per cui MousePlayer risponde direttamente della scelta.

Completato il 17/08/2026: gli indirizzi pregressi in audit_logs (681) e user_ip_history (7) sono stati troncati retroattivamente, nella stessa forma già scritta dal registratore; ne rimangono 0. I periodi futuri sono in vigore dallo stesso giorno. (decisione del titolare del trattamento, 17/08/2026)

Stato al 17/08/2026. I dati pregressi nel percorso di registrazione sono sistemati: in base alla misurazione, 267 su 267 indirizzi in ip_lifetime_stats sono stati troncati e 881 su 901 in visitor_sessions; i restanti 20 contengono 0.0.0.0 e provengono dai dati di prova dell’analisi dei moduli, quindi non sono indirizzi di visitatori. Nei log del portale l’indirizzo completo rimane — deliberatamente e dal 17/08/2026 con un periodo dichiarato: mouseplayer_logs 60 giorni, security_access_logs 72 ore, audit_logs 60 giorni, user_ip_history 90 giorni dall’ultima volta in cui è stato visto un indirizzo (dal 24/09/2026), support_requests 730 giorni. La ragione per cui l’indirizzo completo è necessario per le richieste di assistenza è esposta nel registro ai sensi dell’art. 30 sotto B.3.

R4 — I link di condivisione espongono una riproduzione completa senza effettuare alcun accesso

Una regola di riscrittura indirizza /s/<40 hex characters> direttamente al lettore. Il token costituisce l’intera barriera e il progetto lo riconosce onestamente: il token consiste in 20 byte da random_bytes (160 bit, non indovinabile), gli identificativi di canale e sessione provengono esclusivamente dal token e non dalla richiesta e la stringa di query restante viene sostituita anziché ignorata, il ruolo rimane NULL così che eliminazione e nuova condivisione siano impossibili lato server, tutti e tre gli endpoint del lettore sono vincolati alla sessione del token e i token inventati, scaduti e revocati producono una risposta identica così che sondarli non dia risultati. La durata predefinita è di 7 giorni, minimo 1, massimo 90; esiste la revoca. È un meccanismo costruito con attenzione.

L’esposizione residua è umana, non crittografica, e due dettagli di implementazione la ampliano. In primo luogo, la pagina che mostra la registrazione tramite un link di condivisione (player.php in modalità condivisione) contiene le intestazioni Referrer-Policy: no-referrer e Cache-Control: no-store, ma non un’intestazione X-Robots-Tag; noindex compare soltanto in www/share.php, che ora è soltanto la pagina di errore, e robots.txt consente tutto (verificato il 16/10/2026). In secondo luogo, dal 17/08/2026 il sistema registra ogni accesso a un link di condivisione — ora, indirizzo IP non abbreviato e identificativo del browser in share_views (si veda anche R11) — ma da ciò non si può determinare la persona dietro l’accesso.

Probabilità — Possibile. Il token non verrà forzato con tentativi esaustivi. Verrà inoltrato — incollato in un ticket, una chat di gruppo, una conversazione e-mail a cui si aggiunge un destinatario — e può trapelare tramite un’intestazione Referer. Gravità — Grave: un link espone un’intera sessione a un pubblico illimitato e non identificato, compreso tutto ciò che rientra in R1 e R2, e in seguito possono essere accertati soltanto l’indirizzo e il browser da cui è avvenuto l’accesso (share_views), non chi l’abbia vista. Una questione collegata è registrata come aperta nelle note del progetto e rimane non verificata: misurato il 17/08/2026: il limite dei visualizzatori non viene aggirato dai link di condivisione — non si applica affatto a essi. I visualizzatori dal vivo vengono conteggiati tramite il flag IS_LIVE_VIEWER sulla connessione WebSocket (class/Server.class.php, zaehleLiveViewers). www/player.php non contiene alcun codice WebSocket; il lettore si limita alla riproduzione. Un link di condivisione conduce al lettore, non alla vista dal vivo. Ciò che è effettivamente illimitato è altro: quante persone aprono lo stesso link contemporaneamente. Non esiste un limite né, a differenza della vista dal vivo, un contatore. Dal 17/08/2026 almeno ogni accesso viene registrato (share_views, registro B.6), così che in seguito sia possibile accertare quante volte e da dove è stato utilizzato un link.

R5 — Copia esterna completa giornaliera (a Google Drive fino al 05/09/2026, da allora a Google Cloud Storage a Varsavia; trasferita cifrata dall’11/08/2026; dati pregressi eliminati il 12/08/2026)

Questo rischio non è presente nella base fattuale tecnica; è stato accertato dal file dei punti aperti del progetto ed è ivi documentato in dettaglio. Fino all’11/08/2026 un precedente script di backup veniva eseguito dal cron di root ogni giorno alle 02:00. Eseguiva mysqldump su tutti i database e creava un archivio tar dell’intero albero web, quindi caricava il risultato tramite rclone su gdrive:backups/rpi-ls5/daily — senza cifratura in alcun punto. Localmente l’output è confermato in 653 MB di database e 678 MB di file al giorno. Dall’11/08/2026 la riga cron è stata cambiata: l’esecuzione giornaliera utilizza un nuovo script di backup conservato nel progetto, che acquisisce la stessa portata ma la cifra sul nostro server prima del trasferimento (rclone crypt) e scrive in una propria cartella di destinazione separata; è programmato alle 03:00. Anche i nomi di file e cartelle sono cifrati, così che presso il fornitore si trovino blocchi privi di significato. L’esecuzione del 11/08/2026 è stata avviata manualmente ed è arrivata (733 MB di database, 678 MB di file); l’esecuzione del 12/08/2026 si è completata secondo programma alle 03:00. Entrambe sono registrate nei log e il controllo a destinazione ha trovato il dump del database con lo stesso numero di byte in entrambe le occasioni.

Ciò che lascia la macchina non è quindi un backup delle registrazioni delle sessioni. È una copia completa di ogni database e ogni sistema sull’host — comprese le registrazioni con le istantanee DOM, i 173 dati inseriti nei moduli in chiaro, i 236 indirizzi non abbreviati e ogni file .env con i segreti di produzione. La portata è invariata; la cifratura non cambia nulla al riguardo. Ciò che è cambiato è la leggibilità presso il fornitore: fino all’11/08/2026 non vi era alcuno strato di cifratura prima del caricamento e il testo in chiaro arrivava come testo in chiaro; dall’11/08/2026 la cifratura avviene sul nostro server prima che qualcosa esca e le chiavi risiedono in due file con modalità 600 sullo stesso server — Google non le possiede. I dati pregressi non erano coperti da ciò: il nuovo script ripulisce soltanto la propria cartella di destinazione e la cartella precedente conservava copie settimanali fino a 364 giorni. È stata eliminata il 12/08/2026; pertanto presso il fornitore non si trovano più copie complete non cifrate precedenti all’11/08/2026.

• Il trasferimento è reale e giornaliero. Fino all’11/08/2026 non era verificato se arrivasse: l’esecuzione utilizzava la configurazione rclone di root, lo script non registrava nulla nei log e cron scartava l’output. Dall’11/08/2026 l’esecuzione scrive un log e verifica autonomamente dopo il trasferimento se il dump del database si trova a destinazione con il numero di byte previsto; per l’11/08/2026 (manuale) e il 12/08/2026 (programmata, alle 03:00) entrambi sono documentati, ciascuno con un controllo superato. Il funzionamento giornaliero è quindi comprovato, non soltanto il primo tentativo. Il rischio per la disponibilità non è risolto, ma spostato: se entrambi i file delle chiavi vanno persi, l’intero backup esterno è irrecuperabile. Una misura che elimina la leggibilità presso il fornitore crea così una nuova dipendenza dalla custodia delle chiavi; al di fuori di questa macchina sono conservate, secondo il titolare del trattamento, in forma stampata in una cassaforte (sezione 8.3). Il gestore ha testato la decifratura — è una sua dichiarazione, non una misurazione effettuata da questo documento.
• Fino al 05/09/2026 non era accertato alcuno strumento di trasferimento. La copia era conservata su Google Drive con un account privato (risposta del 17/08/2026), senza una regione dati europea prenotabile e senza accordo con un responsabile del trattamento. Dal 05/09/2026 è conservata in un bucket Google Cloud Storage nella regione europe-central2 (Varsavia) con un account aziendale ed è coperta dal Google Cloud Data Processing Addendum; le copie nell’account Drive sono state eliminate il 06/09/2026.
• Il vecchio script costituiva un’escalation di privilegi. Fino all’11/08/2026 era di proprietà di root, veniva eseguito dal cron di root e aveva modalità file 777: chiunque disponesse dell’account SSH pi aveva privilegi root alle 02:00. Dall’11/08/2026 l’esecuzione giornaliera non passa più da tale script; il trasferimento a Google Drive è stato rimosso da esso il 09/09/2026. I vecchi script di backup sono stati rimossi il 16/10/2026. La rivalutazione di R5 spetta al titolare del trattamento.
• Fino al 05/09/2026 la copia era al di fuori di qualsiasi istruzione del cliente. L’art. 28(3)(a) impone al responsabile del trattamento di agire soltanto su istruzioni documentate; una copia giornaliera delle registrazioni dei visitatori del cliente verso un servizio cloud statunitense per consumatori non era coperta da alcuna istruzione registrata. Da allora la sezione 9 dell’accordo sul trattamento dei dati e l’elenco dei sub-responsabili indicano il backup presso Google Cloud Storage.

Superato dal 05/09/2026 (si veda sopra); conservato qui come cronologia. Risposta del 17/08/2026: account privato. Non può quindi essere prenotata una regione dati europea e non esiste alcun accordo sul trattamento dei dati — per un account Google privato non sono disponibili le condizioni sul trattamento dei dati. Decisione del titolare del trattamento: il backup rimane lì per ora. Test di ripristino mensili d’ora in avanti. I due file delle chiavi sono conservati in forma stampata in una cassaforte accessibile soltanto al titolare del trattamento (dichiarazione del titolare del trattamento, 17/08/2026); sopravvivono quindi alla perdita di questa macchina.

Misurato il 17/09/2026: l’ultimo backup riuscito è stato eseguito alle 03:30 di quel giorno e ha superato il controllo a destinazione. Il test di ripristino è previsto mensilmente; è riuscito prima dell’eliminazione delle copie Drive il 06/09/2026 e nessun controllo automatico ricorda il successivo. Il 07/10/2026 è stato inoltre effettuato un ripristino completo dei dati dal backup cloud in un ambiente separato (circa 70 minuti; campioni dall’archivio e dal database senza errori). Dal 06/10/2026 il backup giornaliero contiene anche l’archivio delle registrazioni (/mnt/mouseplayer-dev-archive); si trova sullo stesso disco del sistema. Salvo diversa indicazione, l’elenco sopra descrive lo stato precedente al 05/09/2026.

R6 — Riconoscimento tra sessioni e unione con le registrazioni del cliente

Un identificativo pseudonimo viene creato e conservato nel localStorage del visitatore come mp_visitor_id. Da solo è ordinario e proporzionato per l’analisi dei visitatori di ritorno. Due ulteriori meccanismi ne cambiano la natura. MousePlayer.setUserId() consente al cliente di associare alla registrazione un proprio identificativo — un nome di accesso, un numero cliente — conservato in visitor_sessions.custom_user_id con un indice dedicato; e lo stesso valore viene acquisito automaticamente da un percorso dataLayer denominato 'uid', senza alcun atto deliberato del cliente. Se un gestore di tag pubblica già un ID utente, le registrazioni diventano attribuibili a una persona identificata come effetto collaterale dell’installazione.

Da quel momento la registrazione non è più pseudonima nelle mani del cliente. Può essere collegata al suo CRM e l’esportazione BigQuery è costruita per trasportare esattamente le colonne che rendono banale il collegamento: visitor_id, custom_user_id e ip_address nella stessa riga. Tale esportazione è attualmente disattivata su tutti i progetti e il relativo processo non è in esecuzione — la capacità esiste, l’attività no.

Una debolezza progettuale dovrebbe essere registrata senza sovrastimarla. visitor_nicknames ha un vincolo UNIQUE soltanto su visitor_id, senza confine tra clienti — la tabella è strutturalmente trasversale ai progetti. In pratica l’identificativo risiede in localStorage ed è quindi limitato a un’origine, perciò questo non crea di per sé tracciamento tra siti di domini di clienti diversi. Si tratta di un confine mancante nello schema, non di una fuga di dati dimostrata, e dovrebbe essere chiuso prima di qualsiasi implementazione in cui due progetti possano condividere un’origine.

Probabilità — Probabile per il riconoscimento tra sessioni (è il comportamento predefinito e sono registrati 329 identificativi); Da Possibile a Probabile per l’identificazione, dato il percorso automatico dataLayer. Gravità — Grave: l’identificazione elimina il fattore attenuante che rende tollerabile la registrazione del comportamento e lo fa retroattivamente — una volta associato un identificativo, anche le sessioni prima pseudonime di quel visitatore diventano attribuibili.

R7 — Nessun periodo di cancellazione per tredici tabelle; periodi stabiliti il 17/08/2026

L’eliminazione in base al livello cancella cinque tabelle: mouse_events, session_custom_event_params, session_custom_events, session_pageviews e visitor_sessions. Tredici tabelle contenenti dati personali sono assenti da tale elenco: ai_session_features, ai_timelines, consent_events, session_comments, session_shares, visitor_nicknames, ip_lifetime_stats, audit_logs, user_ip_history, users compreso last_ip, support_requests, consent_region_acceptances e heatmap_page_stats.

La conseguenza pratica è peggiore di quanto suggerisca l’elenco, per l’ordine in cui le cose avverrebbero. Quando l’eliminazione verrà infine eseguita, la sessione scomparirà e i dati derivati rimarranno — ai_timelines conserverebbe la sessione come prosa leggibile, 3.203 righe e 5,5 MB, che descrivono una persona la cui registrazione sottostante è stata eliminata. Oggi non esistono tali dati orfani, ma soltanto perché non è mai stato eliminato nulla.

Tre ulteriori difetti aggravano il problema. La procedura non è programmata da cron o systemd, ma viene eseguita all’interno del processo worker; se tale processo si arresta, la cancellazione si arresta e nulla lo segnala. La query di selezione collega le sessioni a progetti, aree di lavoro, proprietari e utenti tramite inner join, perciò una sessione il cui progetto è stato eliminato non può mai essere selezionata e non verrà mai cancellata — una sessione su 706 si trova già in tale stato. Inoltre la conservazione effettivamente applicata è di 365 giorni per ogni progetto del sistema, a fronte di un insieme di dati la cui registrazione più vecchia ha 20 giorni; ciò significa che la catena di eliminazione non è mai stata esercitata dall’inizio alla fine.

Probabilità — Concretizzato. Gravità — Grave, in quanto violazione dell’art. 5(1)(e) strutturale, non accidentale. Modificato il 17/08/2026. L’esecuzione stessa rimane nel db_worker, ma la sua ASSENZA viene ora notata: il worker registra l’esito (mp_purge_status) e srv/cron_status.php — un processo DIVERSO — lo valuta ogni 60 secondi, scrive sys_purge per l’area amministrativa e segnala via e-mail quando l’ultima esecuzione risale a più di 48 ore prima. Al massimo un messaggio al giorno; un controllo automatico che invia e-mail ogni minuto viene ignorato e poi non segnala a nessuno neppure il guasto reale. Il controllo automatico deliberatamente non risiede nel worker: un processo morto non può segnalare sé stesso. Stato al 23/09/2026: l’invio di e-mail è operativo; il messaggio raggiunge l’indirizzo di allarme impostato nell’area amministrativa.

Stato al 17/08/2026. Risolto. Cinque delle tredici tabelle fanno parte della catena condivisa di eliminazione dal 12/08/2026, sei hanno ricevuto un proprio periodo configurabile nell’area amministrativa (migrazione 039) e due mancavano del tutto dall’elenco: ai_visitor_value e ai_insights — proprio l’attribuzione di punteggi alla persona e il testo generato su di essa. I periodi risiedono in site_settings e vengono letti dalla stessa riga da cui il registro ai sensi dell’art. 30 li legge per il proprio testo. L’eliminazione viene effettivamente eseguita; l’esecuzione del 17/08/2026 alle 17:37:09 è documentata nel log del worker. Il problema di questa sezione — la sessione scompare e il dato derivato rimane orfano — non può quindi più verificarsi. L’esecuzione dipende ancora dal processo worker e non è programmata né da cron né da systemd; dal 17/08/2026 la sua assenza viene segnalata dal controllo automatico nel processo di stato e dal 23/09/2026 anche via e-mail.

Rivalutato il 23/09/2026. Misurato lo stesso giorno: l’ultima eliminazione era stata eseguita 21 ore prima, la riga più vecchia in audit_logs ha 60 giorni — esattamente il periodo configurato — e nessuna sessione è priva di progetto. La selezione utilizza ancora inner join; tuttavia non si creano sessioni orfane perché l’eliminazione di un progetto o di un account rimuove anche le relative sessioni tramite channelid. Dal 24/09/2026 anche user_ip_history ha un proprio periodo: 90 giorni dall’ultima volta in cui è stato visto un indirizzo, al più tardi insieme all’account. Probabilità — Remota. Gravità — Grave. Livello complessivo — basso.

R8 — Attribuzione automatizzata di punteggi e classificazione di ogni sessione

Ogni sessione viene valutata automaticamente. engagement_score (0-255) è calcolato da segnali di profondità e di irritazione; session_quality separa le sessioni in cui è accaduto poco; is_bot con un codice motivo classifica il visitatore come non umano e tale controllo viene eseguito prima del controllo del consenso. I punteggi sono indicizzati e determinano l’ordine dell’elenco di revisione del cliente, il che significa che determinano quali persone vengono osservate. Alla rilevazione di agosto 2026 esistevano 4.043 righe di caratteristiche e 3.203 descrizioni generate.

Questa è profilazione ai sensi dell’art. 4(11) — valutazione automatizzata di aspetti personali riguardanti una persona fisica, specificamente per analizzarne o prevederne il comportamento. In base alle evidenze, non si tratta di un processo decisionale automatizzato ai sensi dell’art. 22: non è stata riscontrata alcuna decisione su credito, prezzi, accesso o idoneità nei confronti di un visitatore. Un meccanismo è più vicino al limite rispetto agli altri e dovrebbe essere indicato: quando rileva un clic di rabbia, www/mp.js invia un giudizio comportamentale a widget di chat di terzi eseguiti nel browser del visitatore stesso — Intercom riceve un flag, LiveChat una variabile di sessione. Un giudizio formulato sul visitatore lascia così il sistema in tempo reale e può cambiare il modo in cui tale persona viene trattata sul sito.

Portata della profilazione, stato al 16/10/2026. Dalla rilevazione sono stati aggiunti ulteriori punteggi e derivazioni, tutti appartenenti a questo rischio: frasi e report formulati automaticamente su singoli visitatori (ai_insights, ai_besucher_bericht; i risultati sono calcolati, un modello linguistico sulle nostre macchine nella stessa rete locale li formula); un modello di uscita (regressione logistica) che stima un rischio di uscita nel browser del visitatore e, se il gestore lo attiva, genera un’offerta di uscita il cui testo è mostrato soltanto dopo l’approvazione del gestore; un indicatore di abbandono basato su regole per i visitatori di ritorno (ai_churn); profili comportamentali che raggruppano le sessioni in base al loro svolgimento (k-means, mp_profile, mp_profil_sitzung) e schemi di sequenza; un punteggio di attrito per sessione; sondaggi e un pulsante di feedback con le risposte del visitatore; tracciamento degli elementi, che assegna i clic agli elementi contrassegnati; un indice dei testi visualizzati per la ricerca (mp_text_block, mp_text_pv, 30 giorni); messaggi della console e richieste fallite o lente della pagina del cliente (senza corpo e intestazioni). In base alle evidenze nessuno di questi prende una decisione ai sensi dell’art. 22 nei confronti del visitatore; l’offerta di uscita, tuttavia, modifica direttamente ciò che il visitatore vede sulla pagina ed è quindi, tra quelli elencati, il più vicino al limite. I dettagli sono esposti nel registro ai sensi dell’art. 30.

Separatamente, due conseguenze automatizzate hanno effetti reali, ma sui clienti e sugli indirizzi IP anziché sui visitatori: un account contrassegnato automaticamente come is_suspicious alla registrazione vede la conservazione dei propri dati ridotta a 24 ore e un IP che supera le soglie di connessione viene bloccato, dopodiché ogni ulteriore richiesta viene terminata — alla rilevazione di agosto 2026 erano registrati 24 blocchi del genere. Alla rilevazione nessuno dei due aveva un percorso documentato di riesame umano o un canale di opposizione; per il blocco ne esiste uno dal 17/08/2026 (di seguito), per il flag is_suspicious non ne esiste ancora alcuno.

Probabilità — Probabile (comportamento predefinito). Gravità — Significativa: nessun effetto giuridico per i visitatori, ma ricevere punteggi ed essere classificati senza saperlo e vedere il punteggio esportato verso un widget di terzi costituisce esattamente la perdita di controllo descritta dal considerando 75. Valutato il 17/08/2026. Da quel giorno il blocco automatico scadeva autonomamente dopo 7 giorni; prima non scadeva mai. Al 16/10/2026 il server WebSocket blocca autonomamente e il blocco scade dopo 24 h (configurabile da 1 a 168 h); fail2ban blocca per un’ora; banned_ips viene compilata soltanto manualmente. Un’opposizione passa dal modulo di assistenza o dall’indirizzo office@mouseplayer.com ed è gestita da una persona; l’area amministrativa può rimuovere il blocco. La durata risiede in site_settings (autoban_stunden). La misura ha quindi un effetto limitato, un riesame umano su richiesta e un percorso indicato per ottenerlo — le caratteristiche da cui dipende l’art. 22. La classificazione stessa rimane una questione giuridica; ciò che è deciso è la salvaguardia, non l’interpretazione. (decisione del titolare del trattamento, 17/08/2026)

R9 — 92 sessioni irraggiungibili tramite qualsiasi identificativo; nessun percorso da una persona alla sua registrazione

92 sessioni hanno visitor_id 'unknown'. Per tali registrazioni non esiste alcuna chiave che consenta di raggiungerle: i dati esistono, sono personali, contengono una riproduzione ed eventualmente un indirizzo e non possono essere recuperati da alcuna query attivabile da una richiesta di un interessato. Non è possibile eseguire per essi la cancellazione ai sensi dell’art. 17 né rispondere all’accesso ai sensi dell’art. 15. Misurato nuovamente il 16/10/2026: nessuna sessione ha più visitor_id 'unknown'; tuttavia il codice può ancora scrivere tale valore alla creazione di una sessione.

Il problema più ampio è peggiore delle 92 righe ed è già registrato come irrisolto nelle note del progetto. Anche quando esiste un visitor_id, risiede nel localStorage del visitatore e la persona non lo conosce. Non esiste un percorso da una persona reale — che può fornire un nome, un indirizzo e-mail, una data e una pagina — alle sue registrazioni. Un pulsante di cancellazione che la persona avente diritto a premerlo non può raggiungere è una finzione.

L’art. 11 offre una risposta parziale e scomoda: se il titolare del trattamento può dimostrare di non essere in grado di identificare l’interessato, gli artt. da 15 a 20 non si applicano — ma l’art. 11(2) impone al titolare di informarne l’interessato e quest’ultimo può fornire ulteriori informazioni che consentano l’identificazione. Quest’ultima clausola è il punto: il visitatore può fornire il proprio identificativo perché si trova nel suo browser. Una pagina di accesso autonomo ai dati che mostra a un visitatore il proprio mp_visitor_id trasformerebbe una richiesta impossibile in una richiesta ordinaria, il che rende difficile difendere il ricorso all’art. 11 finché non esiste tale pagina.

Probabilità — Concretizzato. Gravità — Significativa, che sale a Grave in combinazione con R1: la persona meno capace di raggiungere la propria registrazione è quella che non sa che una registrazione esiste. Deciso il 17/08/2026: verrà predisposto un accesso autonomo ai dati per i visitatori — una pagina in cui un visitatore vede il proprio identificativo e può attivare l’eliminazione delle proprie registrazioni, collegata dall’informativa sulla privacy. (decisione del titolare del trattamento, 17/08/2026) Operativa dal 17/08/2026 all’indirizzo /my-data (tedesco /meine-daten, polacco /moje-dane), collegata dal piè di pagina di ogni pagina. Mostra il numero di sessioni, il periodo e i domini interessati — nessuna registrazione: l’identificativo è un token al portatore e chiunque lo conosca potrebbe altrimenti visualizzare il comportamento altrui. L’eliminazione viene messa in coda ed eseguita dal worker utilizzando la catena esistente; la pagina stessa non elimina nulla.

Quanto ciò attenui R9 dipende da dove è stato registrato il visitatore e tale limite è tecnico: la memoria del browser è separata per origine. L’identificativo risiede nella memoria del sito web su cui è stato eseguito lo script, non nella nostra. Una pagina su mouseplayer.com non può quindi vederlo autonomamente — verificato sui dati, in cui nessun identificativo compare su più di un dominio. Ne derivano tre percorsi di accesso:

• I visitatori di mouseplayer.com stesso raggiungono direttamente i propri dati, perché qui la memoria del browser è nostra. Per loro R9 è eliminato.
• I visitatori di un sito web del cliente vi accedono tramite un link che il cliente inserisce nella propria informativa sulla privacy; MousePlayer.privacyUrl() lo restituisce già pronto, compreso l’identificativo. Non è un’elusione, ma la ripartizione dei ruoli ai sensi dell’art. 28: nei confronti dei propri visitatori il cliente è il titolare del trattamento e l’informativa ai sensi dell’art. 13 deve comunque figurare nella sua informativa sulla privacy. Forniamo lo strumento e siamo il destinatario.
• Chi conosce già il proprio identificativo lo inserisce nella pagina.

Se un cliente non inserisce il link, R9 rimane pienamente valido per i visitatori di tale cliente — la richiesta non è allora impossibile, ma passa dal cliente anziché da noi e per tale caso l’affermazione ai sensi dell’art. 11 rimane nell’informativa sulla privacy. Chi ha svuotato la memoria del browser non è raggiungibile tramite nessuno dei tre percorsi. La pagina quindi non elimina R9; lo sposta da "tecnicamente impossibile da soddisfare" a "soddisfacibile, purché il titolare indichi il percorso".

R10 — Nessuna cifratura a riposo, nessun TLS verso il database o Redis attraverso la LAN

Tre lacune dell’infrastruttura sono documentate come non implementate e sono state verificate, non presunte. La cifratura delle tabelle InnoDB, dei log e delle tabelle temporanee è disattivata e il disco non è cifrato, quindi l’intero insieme — 322,6 MB di eventi e 162,9 MB di istantanee di pagina — è a riposo in chiaro. La connessione al database non utilizza TLS: il server lo supporta, ma non sono configurati certificato, chiave o CA; la connessione è locale, il che attenua ma non elimina il problema. Fino al 16/08/2026 Redis operava senza protezione degli accessi pur persistendo su disco e le sue code contengono l’IP troncato, l’URL completo e il contenuto DOM in transito.

Probabilità — Possibile. Uno sfruttamento remoto è improbabile: alla rilevazione Redis e il database erano vincolati soltanto a localhost (per lo stato attuale si veda sotto), HTTPS è imposto e la connessione TLS del WebSocket termina con un certificato reale in nginx. I percorsi realistici sono fisici — furto della macchina, smaltimento del disco — e il percorso di backup in R5, che fino all’11/08/2026 portava ogni notte lo stesso testo in chiaro fuori dalla macchina e da allora trasferisce in forma cifrata; le copie non cifrate antecedenti a tale data sono state eliminate presso il fornitore il 12/08/2026. Gravità — Molto grave se si verifica, perché viene esposto tutto contemporaneamente.

Risposta del 17/08/2026: il server si trova in un locale chiuso a chiave e sottoposto a videosorveglianza a Lodz; l’accesso è riservato esclusivamente al titolare del trattamento. Il disco USB di backup si trova nello stesso locale del server. Risposta del 17/08/2026: la cifratura a riposo non verrà introdotta prima della produzione — non fattibile nella fase iniziale sul Raspberry Pi (decisione del titolare del trattamento). Questo rischio rimane quindi interamente: tutti i dati risiedono in chiaro sul disco e il disco USB di backup si trova nello stesso locale. La salvaguardia residua è fisica — un locale chiuso a chiave sotto videosorveglianza, accessibile soltanto al titolare del trattamento — e resiste al furto o allo smaltimento improprio di un disco soltanto quanto resiste tale locale. Da rivalutare non appena l’esercizio lascia il Raspberry Pi.

Stato al 17/08/2026. Una parte è risolta, un’altra si è spostata. Redis ha accesso limitato dal 16/08/2026; verificato sul servizio, rifiuta richieste senza autenticazione. La cifratura a riposo è ancora assente. L’ipotesi attenuante di questa sezione, tuttavia, non è più valida: dal 16/08/2026 Redis e il database non ascoltano più soltanto su localhost, ma anche sull’indirizzo LAN (bind-address = 127.0.0.1,192.168.20.2), così che un secondo nodo possa raggiungere lo stato condiviso; le righe ssl- della configurazione del server rimangono commentate. Finché è in esecuzione un solo nodo, ciò rimane teorico. Con il secondo, i contenuti delle sessioni e il traffico del database attraversano la rete in chiaro e i percorsi non sono più soltanto fisici. Il giudizio su questo rischio deve essere rivalutato prima che un secondo nodo entri in servizio.

Stato al 16/10/2026. Le connessioni da Internet sono cifrate con TLS; la cifratura termina in nginx e il server WebSocket ascolta soltanto su 127.0.0.1:8081, ossia sulla stessa macchina. MousePlayer utilizza una propria istanza Redis su 127.0.0.1:6381 con accesso limitato e persistenza su disco (file append-only); quindi anche i contenuti delle code e gli indirizzi IP non abbreviati mantenuti per la durata del blocco automatico (24 h) raggiungono il disco. Una precedente istanza Redis condivisa ascolta inoltre, con accesso limitato, sull’indirizzo LAN. MariaDB ascolta su 127.0.0.1 e sull’indirizzo LAN 192.168.20.2 senza TLS (nessun certificato configurato) e vi sono connessioni dalla rete locale. All’interno della nostra rete locale nello stesso luogo, le connessioni al database e a Redis operano quindi senza cifratura; hanno accesso limitato e sono raggiungibili soltanto dalla nostra rete locale (nessun port forwarding). La cifratura a riposo è ancora assente.

R11 — Nessuna registrazione di chi abbia visualizzato quale registrazione di sessione

Il log di audit registra le azioni di scrittura — creazione e revoca di condivisioni, eliminazione di commenti, sessioni e visitatori, blocchi automatici, azioni dei super amministratori, in totale 666 voci alla rilevazione. Non registra la lettura. Una chiamata alla pagina del lettore, all’endpoint degli eventi o a quello della modalità cinema non lascia traccia. Nessuno può accertare in seguito quale dipendente di un cliente abbia guardato la sessione di una persona identificata, quante volte o se lo abbia fatto un amministratore di MousePlayer. Dal 17/08/2026 almeno gli accessi ai link di condivisione vengono registrati (share_views); le chiamate degli utenti autenticati non lasciano traccia (stato al 16/10/2026).

Probabilità — Concretizzato come lacuna di controllo. Gravità — Significativa, con un effetto aggravante più rilevante di quello diretto: dopo qualsiasi incidente, l’art. 33 e l’art. 34 impongono al titolare di descrivere le categorie e il numero approssimativo degli interessati e delle registrazioni coinvolti. Senza log delle letture, tale descrizione non può essere prodotta sulla base di evidenze e ogni notifica diventa una stima.

R12 — Qualità della prova del consenso e adattatori CMP non testati

L’art. 7(1) pone l’onere della prova del consenso sul titolare del trattamento e il codice lo indica espressamente come motivo dell’esistenza del log del consenso. Nei dati misurati della rilevazione (agosto 2026), 671 sessioni su 706 hanno consent_source='testdata' con una marca temporale NULL, scritta da una fixture di sviluppo — non costituiscono prova di nulla. Le registrazioni autentiche erano allora 35: 27 dall’API, 5 da Google Consent Mode, 2 consensi tardivi, 1 revoca. Al 16/10/2026, 566 delle 8.648 sessioni umane hanno consent_source='testdata'; le altre hanno una registrazione dall’API (7.451), dall’adattatore Consented (620) o da Google Consent Mode (9). L’eliminazione alla revoca esiste come opzione ed è disattivata su tutti i progetti (stato al 16/10/2026), quindi una revoca interrompe le registrazioni future ma lascia quelle passate.

Dei sei adattatori CMP e dei tre livelli di rilevamento del consenso, soltanto tre percorsi sono stati verificati nella realtà: API diretta, Google Consent Mode e Cookiebot. TCF e cinque adattatori — Usercentrics, OneTrust, Consentmanager, Borlabs, Complianz — sono costruiti, ma non sono mai stati eseguiti con una CMP operativa. Dato il principio guida di blocco in caso di dubbio, un adattatore che interpreta male un segnale fallisce nella direzione di non registrare, che è la direzione sicura; il rischio riguarda quindi principalmente evidenze non verificate anziché registrazioni illecite.

Probabilità — Concretizzato per questo insieme di dati. Gravità — Grave in termini di produzione, perché un consenso che non può essere provato è, in una controversia, un consenso che non esisteva. Questa valutazione si applica ai dati di sviluppo e deve essere misurata nuovamente. da completare: percentuale misurata delle sessioni di produzione con una registrazione autentica del consenso e data in cui ogni adattatore CMP è stato verificato con un’installazione operativa

R13 — Richieste di assistenza inoltrate a Telegram con l’IP non abbreviato (trasferimento cessato l’11/08/2026)

Fino all’11/08/2026, quando veniva presentata una richiesta di assistenza, l’intera questione veniva inviata a Telegram: stato dell’account, indirizzo e-mail, oggetto, testo completo del messaggio, URL di origine e indirizzo IP non abbreviato. I token erano impostati, quindi il ramo era attivo. Chi presenta la richiesta spesso non è un cliente e il testo dell’assistenza non ha limiti — le persone descrivono situazioni sanitarie, controversie e circostanze finanziarie nei ticket di assistenza perché è ciò che il campo invita a fare. Dall’11/08/2026 cfg/lib.php invia esattamente una stringa fissa: "MousePlayer: es liegt eine neue Supportanfrage vor." Nessuna variabile raggiunge il messaggio, non esiste parse_mode e deliberatamente non vi sono un numero del caso — sarebbe un identificativo relativo a una persona — né un link costruito dal nome host richiesto, perché tale valore proviene dalla richiesta stessa. Un controllo (ai/pruefstand/test_telegram_signal.php) verifica la possibilità, non il risultato: quali variabili possano raggiungere il messaggio. Quattro sono consentite, 15 identificativi sono vietati e il testo deve essere una stringa tra apici singoli senza interpolazione; il controllo è stato eseguito su due versioni deliberatamente errate e le ha rilevate entrambe. Ciò a cui non è stato posto rimedio è la conservazione locale. La richiesta viene conservata senza modifiche in support_requests, compresi indirizzo e-mail e indirizzo IP — è intenzionale, servono al gestore per le controversie — e support_requests non aveva alcun periodo di conservazione fino al 17/08/2026; da allora la richiesta viene cancellata dopo 730 giorni (si veda R7). Il senso della modifica è che i dati non escano, non che scompaiano.

Probabilità — Concretizzato fino all’11/08/2026 a ogni invio; dall’11/08/2026 il trasferimento non avviene più. Gravità — Significativa: fino all’11/08/2026 perché Telegram si trova al di fuori dell’UE e non offre alcun accordo sul trattamento per i canali bot; da allora la stessa valutazione riguarda soltanto la conservazione locale, perché rimangono indirizzo e-mail, IP e testo libero senza limiti nel database del gestore — limitati a 730 giorni dal 17/08/2026. L’elemento del paese terzo è venuto meno, la conservazione ha un limite; viene trattata in R7. La decisione è stata presa e datata: il canale viene mantenuto e dall’11/08/2026 il messaggio non contiene dati. Una base giuridica e uno strumento di trasferimento per un trasferimento verso un paese terzo non sono quindi più necessari, perché nessun dato personale raggiunge Telegram; per questa operazione Telegram non è un responsabile del trattamento. Livello complessivo — medio fino all’11/08/2026, basso da allora.

R14 — Uscita verso destinatari scelti dal titolare del trattamento

MousePlayer offre connettori per l'invio di singoli elementi ai sistemi propri del titolare del trattamento: il suo sistema di gestione delle relazioni con i clienti, helpdesk, marketing, pubblicità, archiviazione o attività oppure un indirizzo da esso indicato. Soltanto il titolare effettua la scelta e conserva le credenziali; la trasmissione costituisce quindi una sua istruzione. I dettagli sono esposti nel Registro, sezione 4.1.

Dove risiede il rischio. Non nel volume: vengono trasmessi identificativi e nomi di eventi, mai i contenuti delle pagine registrati, la traccia del mouse o il testo dei moduli. Il rischio risiede nell’irreversibilità. Se ci perviene una richiesta di cancellazione ai sensi dell’art. 17, cancelliamo la nostra copia — non possiamo raggiungere quella presso il destinatario. Per quanto tempo la conservi, dove la porti e a chi la comunichi è al di fuori della nostra influenza e non è qualcosa che possiamo monitorare. Lo stesso vale per un trasferimento verso un paese terzo: il titolare determina la destinazione e, con essa, la garanzia ai sensi del capo V.

Che cosa è stato fatto al riguardo. L’informativa sulla privacy indica chiaramente entrambi gli aspetti — che cosa esce e che una richiesta di cancellazione non ha effetto presso il destinatario — e indirizza l’interessato al gestore del sito web, che ha preso tale decisione, per sapere quali destinatari siano attivati. Il DPA chiarisce che tali destinatari non sono sub-responsabili di MousePlayer. Tecnicamente il volume viene mantenuto ridotto e nome, indirizzo e-mail, numero di telefono e indirizzo IP sono espressamente esclusi dall’invio alle reti pubblicitarie. Dal 20/08/2026 ogni progetto conserva un log di consegna (Registro A.11), dal quale il titolare può leggere che cosa sia effettivamente uscito — prima non gli era visibile.

Che cosa rimane. Un rischio residuo che non può essere eliminato tecnicamente finché esiste la funzionalità: la comunicazione è intenzionale e le sue conseguenze sono al di fuori della nostra sfera. È a carico del titolare che attiva il connettore e gli viene indicato nel DPA e in questa valutazione.

8. (d) Misure previste per affrontare i rischi

Ogni misura seguente ha uno stato e gli stati non sono decorativi. Attuata significa verificata oggi nel sistema in esecuzione. Parziale significa che il meccanismo esiste ma non raggiunge ancora il proprio scopo. Prevista significa che non esiste. Una DPIA che presenta misure previste come già attuate è il rimprovero consueto mosso a questo strumento ed è quello che distrugge il valore del documento nell’unica situazione in cui il documento conta.

8.1 Attuate oggi — verificate

Misura	Riguarda	Evidenza
Controllo del consenso nel browser, con blocco in caso di dubbio: assenza di segnale, guasto della CMP, errore dello script e origine sconosciuta conducono tutti a "non registrare"	Liceità	Macchina a stati mpEinw in www/mp.js, dopo il controllo dei bot
Applicazione indipendente lato server: passano soltanto GRANTED o GRANTED_LATE oppure un’esenzione regionale esplicita; revoca, paese sconosciuto e qualsiasi situazione non chiara chiudono la connessione	Liceità	class/Server.class.php:977-1004; 24 connessioni bloccate registrate alla rilevazione
Elenco di esclusione dei percorsi applicato prima del controllo, con confronto soltanto sul percorso	Minimizzazione	class/Server.class.php:963-975; 71 connessioni bloccate registrate alla rilevazione
Troncamento degli IP al momento della lettura, prima di qualsiasi componente che utilizzi il valore	R3, soltanto per il futuro	class/Server.class.php:432-435; tutte le sessioni dal 07/08/2026 troncate
Mascheramento dei moduli con un limite minimo incondizionato per password e dati di pagamento con qualsiasi impostazione; tutti i progetti al livello più rigoroso	R2, soltanto per il futuro	www/mp.js:4818-4853
Nomi dei campi classificati anziché trasmessi	Minimizzazione	www/mp.js:4653-4674
Mascheramento DOM all’interno delle aree contrassegnate, applicato anche alle mutazioni dal vivo	R1, parzialmente	www/mp.js:3934-3970 e 4732-4768
Stringa TC conservata soltanto come hash SHA-256	Minimizzazione	visitor_sessions.tcf_hash
Contenuto della riproduzione deliberatamente escluso dall’API pubblica	R4	www/api/v1_session_detail.php:25
Link di condivisione: token a 160 bit, durata predefinita di 7 giorni e massima di 90 giorni, identificativi ricavati soltanto dal token, stringa di query sostituita anziché ignorata, ruolo NULL, tutti e tre gli endpoint vincolati, risposta identica per token inventati, scaduti e revocati, revoca disponibile	R4	cfg/lib.php mp_share_erstellen / mp_share_pruefen; www/.htaccess
Geolocalizzazione tramite file di database locali — nessuna chiamata a terzi in alcun punto del percorso di registrazione	Trasferimenti verso paesi terzi	class/IP2CityLite.class.php:37; class/Server.class.php:724
Modello di ruoli per area di lavoro; eliminazione riservata a owner e admin e sempre vincolata al progetto	Controllo degli accessi	www/player.php:267, 275-282
Log degli eventi di consenso conservato deliberatamente oltre l’eliminazione della sessione come prova che è avvenuta una revoca	Art. 7(1)	srv/db_worker.php:257-259
Log di audit delle azioni di scrittura	Responsabilizzazione	cfg/lib.php:2878-2890; 666 voci alla rilevazione
Sicurezza del trasporto: HTTPS imposto; TLS con un certificato reale termina in nginx, anche per il WebSocket (/mp_wss/), il tunnel HTTP (/mp_wst), il caricamento dell’istantanea (/mp_dom) e il punto di misurazione (/mp_wsfail); il server WebSocket ascolta soltanto sull’indirizzo di loopback. Le connessioni al database e a Redis all’interno della rete locale non sono cifrate (si veda R10)	Riservatezza	www/.htaccess; configurazione nginx (srv/nginx/); srv/server.php vincolato a 127.0.0.1:8081
Token CSRF da random_bytes con confronto a tempo costante; httponly, SameSite=Lax, cookie di sessione secure; hashing delle password; istruzioni preparate in tutti i percorsi di scrittura sottoposti ad audit; limite alla frequenza degli accessi; blocco automatico e limiti di connessione per IP; fail2ban in esecuzione	Riservatezza	cfg/lib.php:110-132; www/login.php; class/Server.class.php:449-455, 660-668
Segreti al di fuori del controllo di versione	Riservatezza	.gitignore include .env; soltanto .env.example è tracciato
Conservazione applicata per i log del portale: rispettivamente 60 giorni e 72 ore, più la scadenza dei blocchi	Limitazione della conservazione	srv/db_worker.php (esecuzione giornaliera delle eliminazioni)
Esecuzione giornaliera delle eliminazioni per livello e secondo periodi separati per le altre tabelle, più ogni ora i periodi delle sessioni contrassegnate come bot; la sua assenza viene segnalata da un processo di stato separato via e-mail e nei Log urgenti	Limitazione della conservazione, R7	srv/db_worker.php; srv/cron_status.php (sys_purge); voce più vecchia in audit_logs al 16/10/2026 al limite di 60 giorni
fail2ban con nove jail, tra cui mp-nginx-429, che blocca gli indirizzi che attivano ripetutamente il limite di frequenza nginx; più limiti di frequenza in nginx	Disponibilità, prevenzione degli abusi	fail2ban-client status, verificato il 16/10/2026
Archiviazione prima dell’eliminazione definitiva: l’eliminazione di progetti, aree di lavoro e account, nonché l’eliminazione per indirizzo IP o visitatore, nasconde inizialmente i dati e interrompe la registrazione; l’eliminazione definitiva segue dopo 30 giorni o prima su richiesta, eseguita e ricontata dal worker. L’eliminazione degli account inattivi non prevede un’archiviazione iniziale	Integrità, limitazione della conservazione	Migrazione 189; cfg/archivierung_lib.php; mp_loesch_archiv
Periodi delle sessioni contrassegnate come bot: registrazione svuotata (periodo in giorni: 1), riga della sessione eliminata dopo 14 giorni	Limitazione della conservazione	site_settings retention_bot_recording_days e retention_bot_session_days; srv/db_worker.php

8.2 Parziali — esistono, ma non raggiungono ancora il proprio scopo

Misura	Perché non è ancora efficace
Mascheramento DOM	Adesione esplicita per elemento. Protegge ciò che il visitatore digita, non ciò che la pagina produce — il contenuto sostanziale di R1
Eliminazione alla revoca	Implementata come opzione, disattivata su tutti i progetti (stato al 16/10/2026), quindi una revoca non rimuove ciò che è già stato registrato
Intestazioni noindex e no-referrer	La pagina che mostra la registrazione tramite un link di condivisione (player.php in modalità condivisione) contiene Referrer-Policy: no-referrer e Cache-Control: no-store, ma non un’intestazione X-Robots-Tag; noindex compare soltanto in www/share.php, la pagina di errore, e robots.txt consente tutto (verificato il 16/10/2026)

8.3 Previste — non attuate

Misura	Riguarda	Priorità
Cifrare la copia esterna prima del caricamento — eseguito l’11/08/2026: l’esecuzione giornaliera cifra sul nostro server prima del trasferimento (rclone crypt, compresi i nomi) e le chiavi risiedono in due file con modalità 600. Eliminare i dati pregressi non cifrati nella precedente cartella di destinazione — eseguito il 12/08/2026. Depositare i file delle chiavi in modo che sopravvivano alla distruzione della macchina — eseguito il 17/08/2026: vengono conservati in forma stampata in una cassaforte (dichiarazione del titolare del trattamento). Regolarizzare o cessare il rapporto con Google Drive – eseguito il 05/09/2026: da quel giorno la copia esterna è conservata in un bucket Google Cloud Storage nella regione europe-central2 (Varsavia) ed è coperta dal Google Cloud Data Processing Addendum. Quanto rimaneva nell’account Drive privato è stato eliminato il 06/09/2026, dopo il superamento del test di ripristino dalla nuova destinazione. Rimuovere i vecchi script di backup — eseguito il 16/10/2026.	R5	Non si applica più — eseguito
Invertire l’impostazione predefinita dei contenuti delle pagine: conservare il testo mascherato salvo esplicita abilitazione e richiedere una conferma scritta del cliente prima di acquisire il testo delle pagine parola per parola	R1	Prima
Politica contrattuale per i settori: quali settori siano ammessi e a quali condizioni aggiuntive	R1	Prima
Troncamento o eliminazione una tantum dei 236 + 291 + 666 + 5 indirizzi pregressi — eseguito il 17/08/2026: i dati pregressi nel percorso di registrazione e in audit_logs e user_ip_history sono abbreviati (si veda R3)	R3	Non si applica più — eseguito il 17/08/2026
Esaminare e cancellare le 173 righe di dati inseriti in chiaro — eseguito il 17/08/2026: eliminate senza esame (decisione del titolare del trattamento, si veda R2)	R2	Non si applica più — eseguito il 17/08/2026
Estendere l’eliminazione alle tredici tabelle non coperte; spostarla su una pianificazione monitorata; correggere la lacuna degli inner join per rendere raggiungibili le sessioni orfane	R7	Non applicabile — completato il 17/08/2026 (periodi e controllo automatico); la selezione con inner join rimane, non si creano sessioni orfane (si veda R7)
Registrare gli accessi in lettura al lettore e a entrambi gli endpoint dei dati	R11, art. 33	Alta
Referrer-Policy e X-Robots-Tag nella pagina del lettore; durata predefinita più breve della condivisione — Referrer-Policy: no-referrer è impostata in modalità condivisione (verificato il 16/10/2026); X-Robots-Tag e una durata predefinita più breve (ancora 7 giorni) rimangono da attuare	R4	Media
Ricerca autonoma affinché un visitatore possa recuperare il proprio identificativo, rendendo possibile rispondere alle richieste ai sensi dell’art. 15 e dell’art. 17 — eseguito il 17/08/2026: /my-data (tedesco /meine-daten, polacco /moje-dane), si veda R9	R9	Non si applica più — eseguito il 17/08/2026
Non esentare mai dal mascheramento lo stato delle caselle di controllo e dei pulsanti di opzione; estendere il mascheramento a essi	R1, R2	Media
Cifratura a riposo; TLS verso il database; protezione degli accessi per Redis — protezione degli accessi per Redis eseguito il 16/08/2026; la cifratura a riposo e TLS verso il database rimangono da attuare (si veda R10)	R10	Media
Rimuovere l’IP dalla notifica Telegram oppure sostituire il canale — completato l’11/08/2026: la notifica consiste ora in un testo di avviso fisso senza alcuna variabile (cfg/lib.php), protetto dal controllo ai/pruefstand/test_telegram_signal.php	R13	Non applicabile — completato l’11/08/2026
Periodo di conservazione per support_requests, audit_logs e user_ip_history	R7	Non applicabile — completato il 17/08/2026 per support_requests e audit_logs, il 24/09/2026 per user_ip_history
Confine tra clienti su visitor_nicknames	R6	Bassa
Percorso documentato di riesame e opposizione per il blocco automatico e il flag is_suspicious — per il blocco automatico eseguito il 17/08/2026 (scadenza allora dopo 7 giorni, ora dopo 24 h, opposizione tramite il modulo di assistenza, rimozione nell’area amministrativa, si veda R8); per il flag is_suspicious rimane da attuare	R8	Bassa
Verificare ogni adattatore CMP con un’installazione operativa prima di offrirlo	R12	Bassa

8.4 Procedure e salvaguardie ancora da definire

L’art. 35(7)(d) richiede salvaguardie, misure di sicurezza e meccanismi — che comprendono le procedure organizzative, non soltanto il codice. Alla rilevazione ne mancavano quattro; lo stato attuale è indicato per ciascuna.

• Definito il 17/08/2026. Rilevamento: il titolare del trattamento, un Cliente o un visitatore del sito web. Percorso di segnalazione a noi: privacy@mouseplayer.com. Decisione sulla notifica all’autorità di controllo: Lukas Wójcik, titolare, entro 72 ore ai sensi dell’art. 33(1). Informazione al Cliente: via e-mail, senza ingiustificato ritardo ai sensi dell’art. 33(2), al più tardi entro 48 ore (accordo sul trattamento dei dati, sezione 8). Invio: l’invio di e-mail è configurato dal 23/09/2026 tramite SMTP presso Namecheap Private Email (mittente office@mouseplayer.com); il percorso promesso al Cliente è quindi operativo. Finora non si è svolta alcuna esercitazione.
• Risposta del 17/08/2026: fino ad allora nessun test di ripristino era stato effettuato; era previsto un test mensile, con un obiettivo del tempo di ripristino non superiore a 24 ore. I due file delle chiavi sono conservati in forma stampata in una cassaforte accessibile soltanto al titolare del trattamento. Eseguito successivamente: un test di ripristino dalla nuova destinazione in Google Cloud Storage prima dell’eliminazione delle copie Drive (05/09/2026 e 06/09/2026) e il 07/10/2026 un ripristino completo dei dati dal backup cloud in un ambiente separato — circa 70 minuti, campioni dall’archivio e dal database senza errori. Ciò dimostra il recupero dei dati, non la ricostruzione di una macchina di produzione completa; non esiste alcun controllo automatico che ricordi il test successivo.
• Risposta del 17/08/2026: NON esistono avvisi automatici; il controllo è manuale. Misurato lo stesso giorno: il codice non contiene alcun monitoraggio di guasti, spazio su disco o successo del backup — le uniche occorrenze di Telegram si trovano in una libreria di terzi che nessuno chiama, srv/cron_status.php scrive soltanto un valore di stato in Redis e system_alerts è vuota. Fino al 17/08/2026 le TOM promettevano il contrario ("in caso di guasto del sistema l’amministratore riceve una notifica automatica"). Era una garanzia che il codice non forniva; è stata corretta lo stesso giorno. Risolto il 19/08/2026: srv/backup-crypt.sh registra ora l’esito di ogni esecuzione in un file di stato e srv/cron_status.php verifica, accanto ai cinque componenti esistenti, il successo del backup, lo spazio libero sui volumi di sistema e di backup e – come controllo giuridico anziché operativo – la soglia dell’art. 37. Ogni controllo fallito viene segnalato via e-mail al massimo una volta al giorno. Il controllo cerca l’ultimo backup riuscito anziché l’ultimo tentativo: uno script che inizia ogni notte e si interrompe ogni notte ha una marca temporale recente e nessun backup, ed è proprio così che l’aggiornamento GeoIP è passato inosservato per cinque giorni. Rimane un limite, dichiarato anziché lasciato intendere: il controllo viene eseguito sulla macchina che sorveglia e non può segnalarne il guasto totale; non vi era alcuna sonda esterna di disponibilità. Dal 02/10/2026 una seconda macchina nello stesso luogo controlla l’applicazione ogni minuto (TOM, sezione 5); un guasto della connessione Internet non viene ancora rilevato da essa. Le TOM sono state allineate lo stesso giorno (versione 1.2), quindi la correzione non è limitata a questo documento.
• Non sono state raccolte le opinioni degli interessati. Motivazione: nei confronti degli utenti finali osservati MousePlayer agisce esclusivamente come responsabile del trattamento e non dispone di un proprio canale verso di loro — qualsiasi contatto passerebbe dai siti web dei Clienti e costituirebbe di per sé un trattamento dei loro dati per una nuova finalità. Gli interessi degli interessati sono invece considerati indirettamente: tramite il controllo del consenso, che non registra nulla senza un segnale, il mascheramento dei dati inseriti e i periodi di cancellazione. Raccogliere le loro opinioni rimane possibile non appena esista un canale che li raggiunga senza acquisirne nuovamente i dati a tale scopo. (decisione del titolare del trattamento, 17/08/2026)

9. Rischio residuo e consultazione preventiva ai sensi dell’art. 36

L’art. 36(1) richiede la consultazione preventiva dell’autorità di controllo se una DPIA indica che il trattamento comporterebbe un rischio elevato in assenza di misure adottate per attenuare il rischio. Il criterio non è quindi se siano stati individuati rischi elevati — ne sono stati individuati due molto elevati — ma se rimanga un rischio elevato una volta attuate le misure ai sensi della lettera (d). Occorre rispondere onestamente a tale domanda per ciascuno dei due.

R5, la copia esterna giornaliera, poteva essere risolto con mezzi ordinari ed è stato risolto. Lo strato di cifratura prima del caricamento è presente dall’11/08/2026, i dati pregressi non cifrati presso il fornitore sono stati eliminati il 12/08/2026 e dal 05/09/2026 la copia è conservata in una regione europea nell’ambito del Google Cloud Data Processing Addendum. La questione del fondamento del trasferimento giornaliero ha quindi una risposta. Rivalutato il 17/09/2026, R5 è medio. La condizione posta dalla valutazione (rimozione dei vecchi script) è stata soddisfatta il 16/10/2026; la rivalutazione di R5 spetta al titolare del trattamento.

R1, categorie particolari nei contenuti delle pagine, non è interamente risolvibile. Il sistema non può sapere che cosa produca la pagina di un cliente e nessuna quantità di logica di mascheramento cambia tale fatto. Ciò che le misure possono ottenere è un’inversione dell’impostazione predefinita, così che la modalità di errore diventi una registrazione inutile anziché illecita, oltre a una politica contrattuale per i settori e una conferma del cliente. Ciò riduce sostanzialmente il rischio. Non lo elimina, perché un cliente può comunque abilitare il testo di una pagina che in seguito visualizza qualcosa di sensibile.

La conclusione sull’art. 36 ha due parti che non devono essere fuse. Formalmente, l’obbligo di consultazione spetta al titolare del trattamento — il cliente che gestisce il sito web — non a MousePlayer, che è il responsabile del trattamento per i dati dei visitatori che comportano il rischio elevato. MousePlayer non può consultare al posto di un cliente e un cliente non può delegare la decisione. Ciò che MousePlayer deve fare ai sensi dell’art. 28(3)(f) è fornire al cliente i fatti che gli consentano di prenderla, ed è a questo che servono le sezioni (a) e (c) del documento.

Nel merito: la consultazione preventiva non è indicata se le misure della sezione 8.3 vengono attuate prima dell’avvio della produzione, perché il rischio residuo scende allora sotto la soglia a cui si riferisce l’art. 36. La consultazione preventiva è indicata in una situazione specifica ed è una decisione, non un incidente: se il gestore decide di non invertire l’impostazione predefinita dei contenuti delle pagine continuando ad ammettere clienti nei settori sanitario, legale, finanziario o pubblico. Il rischio residuo rimane allora elevato per scelta e l’art. 36(1) si applica nei propri termini. Una seconda situazione che compariva qui fino al 17/09/2026 — la prosecuzione della copia esterna giornaliera senza uno strumento di trasferimento accertato — non esiste più dal 05/09/2026 (R5).

Un ulteriore punto va indicato qui perché è facile perderlo. L’art. 36 non è una sanzione e consultare non costituisce un’ammissione. È il meccanismo che il regolamento prevede esattamente per la situazione in cui si trova questo sistema — una tecnica effettivamente utile il cui rischio residuo dipende da un fattore che il gestore non può controllare completamente. Se un titolare intende proseguire con un rischio residuo elevato, la consultazione è il percorso lecito per farlo.

10. Riesame, versione e approvazione

L’art. 35(11) impone al titolare del trattamento di verificare se il trattamento sia effettuato conformemente a questa valutazione, almeno quando cambia il rischio. Tre eventi modificano qui sostanzialmente il rischio e ciascuno dovrebbe attivare una nuova esecuzione anziché una lettura: il primo cliente in un settore regolamentato; la prima attivazione dell’esportazione BigQuery o di un webhook; il momento in cui gli utenti finali monitorati superano la soglia registrata nella sezione 3.

La valutazione si fonda essenzialmente su misurazioni effettuate il 10/08/2026 e l’11/08/2026 sul sistema di sviluppo; è stata approvata il 17/08/2026 e aggiornata successivamente, da ultimo il 16/10/2026 mediante un confronto con lo stato tecnico. Rimangono aperti i segnaposto nelle sezioni 1, 3 e 4 e in R12, che soltanto il titolare può compilare, e la rivalutazione dei rischi le cui cause sono state rimosse interamente o parzialmente dalla rilevazione (R2, R3, R9, R10); la conclusione sul rischio residuo nella sezione 9 è subordinata alle misure ancora aperte nella sezione 8.3.

Voce	Contenuto
Titolare e responsabile del trattamento	LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82 lok. 301, 90-437 Lodz, Polonia - NIP PL7252266190 - office@mouseplayer.com
Responsabile della protezione dei dati	Non designato. Si veda la sezione 3 per l’analisi dell’art. 37 e la raccomandazione.
Documenti correlati	Registri delle attività di trattamento ai sensi dell’art. 30(1) e dell’art. 30(2), misure tecniche e organizzative, elenco dei sub-responsabili, accordo sul trattamento dei dati e informazioni sulla privacy
Base dei fatti	Codice sorgente, schema del database, conteggi delle righe, elenco dei processi, valori di configurazione e file di log del sistema di sviluppo, 10/08/2026 e 11/08/2026, aggiornati fino al 16/10/2026
Versione e data di approvazione	Approvata da Lukas Wójcik, titolare, il 17/08/2026. Non è stata ottenuta alcuna consulenza esterna sulla protezione dei dati. Riesaminata annualmente e a ogni modifica del trattamento; le versioni datate sono conservate nel controllo di versione sotto ai/cms/. Aggiunto il 17/09/2026 su istruzione del titolare: R5 rivalutato (sezioni 5.4, 6, 7, 8.3 e 9). Aggiunto il 16/10/2026: confronto con lo stato tecnico (intestazione, sezioni 1, 3, 4, 5, 7, 8 e 10); livelli di rischio invariati, rivalutazione di R2, R3, R9 e R10 da parte del titolare ancora aperta. Aggiunto il 16/10/2026 (secondo passaggio): periodi e durata del blocco automatico come impostazioni anziché numeri fissi, basi giuridiche per richieste di assistenza e commenti, custodia delle chiavi e raggiungibilità dei vecchi script di backup (R5), termine per informare il Cliente; livelli di rischio invariati, rivalutazione di R5 da parte del titolare ancora aperta. Aggiunto il 16/10/2026 (terzo passaggio): registrata la rimozione dei vecchi script di backup (R5), armonizzate le dichiarazioni sulla protezione degli accessi al database e a Redis (R10); livelli di rischio invariati, rivalutazione di R5 da parte del titolare ancora aperta.