Misure tecniche e organizzative (TOM)

1. Ambito di applicazione e finalità

Questo documento descrive le misure tecniche e organizzative (TOM) che MousePlayer adotta per garantire un livello di sicurezza adeguato al rischio, in conformità all’art. 32 GDPR. Si applica a ogni trattamento di dati degli Utenti finali effettuato per conto di un Titolare del trattamento (Cliente).

Gestore del servizio: LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82 lok. 301, 90-437 Łódź, Polonia · NIP PL7252266190.

2. Riservatezza – controllo degli accessi

2.1 Accesso fisico

Il servizio viene eseguito su hardware di nostra proprietà e da noi gestito, situato a Łódź, in Polonia. Nell’esercizio del servizio stesso non è coinvolto alcun centro dati, cloud o fornitore di hosting di terzi. I server sono gestiti internamente, in locali chiusi in Polonia. L’accesso è riservato esclusivamente al titolare del trattamento. Il locale è chiuso a chiave e sottoposto a videosorveglianza; nessun’altra persona — compresi locatori o servizi di pulizia — ha accesso (dichiarazione del titolare del trattamento, 17/08/2026). L’indirizzo preciso non è deliberatamente indicato qui.

2.2 Accesso al sistema

• L’accesso all’applicazione richiede un account utente individuale con password; le password sono conservate come hash con salt, mai in chiaro.
• Le interfacce amministrative sono separate dall’applicazione rivolta ai clienti e sono accessibili soltanto ai super amministratori; l’autorizzazione viene verificata sul server.
• Le richieste dell’interfaccia web autenticata che modificano lo stato sono protette da token CSRF; le interfacce di programmazione si autenticano con chiavi proprie.
• L’amministrazione del server avviene tramite SSH con autenticazione basata su chiavi.
• L’accesso può essere facoltativamente protetto con un secondo fattore (codici monouso basati sul tempo secondo RFC 6238). Il segreto è conservato cifrato e i codici di recupero soltanto come hash; un codice già utilizzato non viene accettato una seconda volta e ripetuti tentativi falliti bloccano temporaneamente il secondo fattore dell’account.
• Ogni accesso viene tracciato singolarmente (login_sessions). Il titolare dell’account vede l’elenco nelle impostazioni e può revocare singoli accessi o tutti gli altri; la revoca termina anche una sessione in corso e un token memorizzato di accesso persistente. Una modifica della password termina tutti gli altri accessi. Se un account accede da un dispositivo sconosciuto (impronta ricavata da browser, sistema operativo, tipo di dispositivo e intervallo di rete /24 o /48 dell’indirizzo IP), il titolare riceve un’e-mail.

2.3 Accesso ai dati (autorizzazione)

• Un modello di ruoli (owner, admin, viewer) disciplina ciò che un utente può vedere e fare all’interno di un’area di lavoro. L’eliminazione e la condivisione sono riservate a owner e admin; la restrizione è applicata sul server, non soltanto nell’interfaccia.
• Ogni interrogazione sui dati delle sessioni è vincolata all’area di lavoro dell’account richiedente. Non è possibile accedere a una registrazione di un altro cliente neppure conoscendone l’identificativo.
• I link di condivisione (si veda 4.3) sono l’unico modo per accedere a una registrazione senza un account. Vengono creati deliberatamente da un utente autorizzato, possono essere revocati e possono avere una data di scadenza.

2.4 Separazione

• I dati dei clienti sono separati logicamente per area di lavoro e progetto (canale). Ogni percorso di lettura e scrittura applica questa restrizione.
• Sviluppo e produzione vengono eseguiti in installazioni separate con database separati.

3. Pseudonimizzazione e minimizzazione dei dati

• Nessun trattamento prima del consenso. Lo script di tracciamento non effettua alcuna identificazione, memorizzazione, impostazione di cookie o connessione di rete finché non è presente un segnale di consenso. L’assenza di un segnale viene trattata come rifiuto, non come autorizzazione.
• Global Privacy Control. Un segnale GPC del browser viene rispettato in tutto il mondo e prevale su qualsiasi altro segnale.
• Identificativi pseudonimi. I visitatori vengono distinti mediante token generati casualmente. Il Servizio stesso non raccoglie nomi, indirizzi e-mail o numeri di telefono.
• Indirizzi IP. L’indirizzo IP completo di un visitatore viene utilizzato nella memoria di lavoro del server di registrazione per stabilire la connessione, determinare paese, città e fornitore di rete e difendersi dagli abusi; viene scritto nel database soltanto in forma troncata (per IPv4 a.b.c.xxx) e la dashboard non mostra mai un indirizzo IP completo di un visitatore. Eccezioni: per rilevare un afflusso eccessivo di connessioni, un indirizzo viene conteggiato in Redis per dieci secondi; se attiva il blocco automatico, viene mantenuto per intero per un massimo di 24 h come voce di blocco in Redis (mp_autoban:) e questa istanza Redis scrive su disco tramite AOF. Gli accessi tramite link di condivisione vengono registrati nei log con l’indirizzo IP completo (share_views) e vengono eliminati insieme al link.
• Rimozione di dati sensibili dagli URL. I valori dei parametri che comunemente contengono dati personali o credenziali di accesso (ad esempio ?email=, ?token=, ?code=) vengono rimossi prima della conservazione – sia nella stringa di query sia dopo il #, dove i servizi di accesso collocano le credenziali (ad esempio #access_token=). I percorsi delle applicazioni a pagina singola e le ancore interne alle pagine vengono mantenuti.
• Dati inseriti nei moduli – tre livelli, il più rigoroso per impostazione predefinita. Mascheramento completo (l’impostazione predefinita) sostituisce ogni carattere di ogni inserimento prima che lasci il browser. Mascheramento selettivo mantiene completamente mascherati nomi, indirizzi, e-mail, telefoni, campi di pagamento e aree di testo libero e altrove sostituisce soltanto le cifre, così che i termini di ricerca rimangano utilizzabili. Nessun mascheramento registra i dati così come vengono digitati. I due livelli più deboli non sono attivabili autonomamente: ciascuno richiede la nostra approvazione scritta per quella specifica proprietà, registrata con ora e soggetto che l’ha concessa. L’applicazione avviene lato server – un progetto il cui livello memorizzato supera quello approvato viene limitato al livello approvato prima che il valore raggiunga il browser; impostare direttamente il campo non produce quindi alcun effetto.
• Il limite minimo che nessuna approvazione rimuove. I campi riconosciuti come password o dati di pagamento rimangono completamente mascherati a ogni livello. Il riconoscimento legge gli attributi name, id, type del campo e l’attributo autocomplete e comprende termini inglesi, tedeschi e polacchi. Nulla di ciò si estende ai contenuti che il sito web stesso visualizza nella pagina; le aree contrassegnate data-mp-mask sono escluse interamente dalla registrazione.
• Elenco delle esclusioni. Il Titolare del trattamento può escludere dalla registrazione interi percorsi (ad esempio pagine di checkout o dell’account). L’esclusione è applicata sul server e vale anche quando un’applicazione a pagina singola naviga verso un percorso escluso senza aprire una nuova connessione.

4. Integrità – controllo della trasmissione e dell’inserimento

4.1 Trasporto

• Le connessioni da Internet sono cifrate con TLS; TLS termina in nginx sul server. Le richieste non cifrate sulla porta 80 vengono reindirizzate a HTTPS. Lo script di tracciamento si connette per impostazione predefinita tramite WSS (/mp_wss/). Se la connessione WebSocket non viene mai stabilita, utilizza in alternativa un tunnel HTTP su HTTPS (/mp_wst) che attraversa gli stessi controlli lato server; le istantanee di pagina molto grandi vengono caricate tramite HTTPS con un token firmato e a validità limitata (/mp_dom) e i tentativi falliti di connessione WebSocket vengono conteggiati da un endpoint di misurazione senza alcun identificativo visitatore (/mp_wsfail). Dietro nginx, il server WebSocket ascolta soltanto sull’interfaccia di loopback del server, senza TLS.
• All’interno della nostra rete locale nello stesso sito, le connessioni al database (MariaDB) e alla cache (Redis) non sono cifrate; la cifratura del trasporto di tali connessioni non è configurata. Entrambi hanno accesso limitato e sono raggiungibili soltanto dalla nostra rete locale (nessun port forwarding); l’istanza Redis dell’applicazione ascolta soltanto sull’interfaccia di loopback.
• I certificati vengono rinnovati automaticamente. Un certificato scaduto dell’applicazione verrebbe rilevato dal controllo ogni minuto effettuato da una seconda macchina (si veda la sezione 5), che interroga tramite HTTPS con verifica del certificato; non esiste un monitoraggio separato della durata residua dei certificati.

4.2 Controllo dell’inserimento

• Le azioni amministrative vengono registrate in un log di audit con account, ora e azione.
• Ogni modifica dello stato del consenso viene scritta come registrazione autonoma, insieme alla fonte (API esplicita, Consent Mode, TCF, adattatore CMP, GPC), così che lo stato al momento della registrazione rimanga verificabile.

4.3 Trasmissione successiva

• Lo script di tracciamento trasmette esclusivamente all’infrastruttura di MousePlayer. Durante la normale registrazione non viene contattato alcun terzo.
• Le interfacce opzionali (webhook, BigQuery, sistemi di gestione delle relazioni con i clienti, e-mail marketing e ticketing, fogli di calcolo e archiviazione a oggetti, interfacce di conversione delle reti pubblicitarie) sono configurate dal Titolare del trattamento; raggiungono sistemi scelti dal Titolare, sono inattive finché non vengono abilitate dal Titolare e trasmettono singoli elementi; soltanto l’esportazione BigQuery può, con il piano Enterprise e su richiesta, includere anche gli eventi grezzi della registrazione (mouse_events). Se il Titolare abilita un connettore verso uno strumento che ha incorporato nella propria pagina (come chat, monitoraggio degli errori o analisi web), lo script passa nel browser singoli elementi, come il link alla registrazione, a tale strumento; lo script dello strumento li trasmette al proprio fornitore. I destinatari non sono sub-responsabili di MousePlayer.
• I testi generati vengono formulati da un modello linguistico sulle nostre macchine con scheda grafica, nella stessa rete locale e nello stesso sito del server. Queste recuperano i risultati calcolati tramite HTTPS, con ogni richiesta firmata con un proprio segreto; la registrazione stessa non le raggiunge mai e nulla viene inviato a un servizio IA esterno – neppure mentre una di queste macchine è ferma per manutenzione: i processi attendono e l’interfaccia mostra la versione calcolata.
• I link di condivisione trasferiscono dati soltanto a chi possiede il link. Il Titolare del trattamento decide se crearne uno.

5. Disponibilità e resilienza

• Un backup completo del database, della cartella dell’applicazione e – dal 06/10/2026 – dell’archivio delle registrazioni viene creato ogni giorno alle 03:00; fino al 11/08/2026 veniva eseguito alle 02:00.
• Conservazione locale dei backup: 7 giorni. La copia locale è conservata non cifrata su un’unità collegata; la cifratura avviene quando la copia viene trasferita all’esterno. I dump non cifrati del periodo precedente al passaggio sono stati rimossi da lì il 12/08/2026, così che la cartella locale ora contenga soltanto i dump creati dopo il passaggio e vi si applichi tale conservazione. Oltre alla copia locale, il backup giornaliero viene trasferito all’esterno – dal 05/09/2026 in un bucket Google Cloud Storage nella regione europe-central2 (Varsavia); in precedenza in un account Google Drive privato; le copie ivi conservate sono state eliminate il 06/09/2026, dopo aver verificato un ripristino dalla nuova destinazione. Conservazione in tale sede: copie giornaliere per 7 giorni, copie settimanali (domenica) per 364 giorni. Entrambi i valori sono un’impostazione, non una costante in uno script: il backup li legge dalla stessa riga della configurazione citata in questa frase, così che la dichiarazione pubblicata e il comportamento non possano divergere. La copia contiene il database completo. Dopo 7 giorni gli eventi di una registrazione vengono spostati dal database in un archivio. Dal 06/10/2026 questo archivio fa parte del backup giornaliero; prima non veniva sottoposto a backup e le registrazioni più vecchie di 7 giorni non avevano una copia di backup. L’archivio risiede sullo stesso disco del sistema; la copia locale su un’unità separata e la copia esterna proteggono dal guasto di tale disco. Dal 11/08/2026 viene cifrato sul nostro server prima del trasferimento (rclone crypt); vengono cifrati anche i nomi di file e cartelle, così che il fornitore possieda soltanto blocchi senza significato riconoscibile. Le chiavi sono conservate in due file sul nostro server, leggibili e scrivibili soltanto dal proprietario (modalità file 600); il fornitore non le possiede e non può leggere il contenuto. È stata verificata la decifratura di una tale copia. La precedente cartella di destinazione non cifrata, contenente le copie complete antecedenti al 11/08/2026, è stata eliminata il 12/08/2026. Dal 19/08/2026 il successo del trasferimento viene monitorato automaticamente. Il backup scrive il proprio esito in un file di stato e il processo di controllo verifica l’ultima esecuzione riuscita anziché l’ultima esecuzione – uno script che inizia ogni notte e si interrompe ogni notte ha una marca temporale recente e nessun backup. Se non si è verificata un’esecuzione riuscita per un tempo superiore al periodo configurato (36 ore per impostazione predefinita, che consente esattamente una mancata esecuzione giornaliera), viene inviato un avviso via e-mail, al massimo una volta al giorno.
• I dati eliminati nel sistema in esercizio rimangono presenti nei backup finché non scade il backup corrispondente – al massimo 364 giorni dopo la cancellazione definitiva; successivamente non sono più contenuti in alcun backup. È una conseguenza inevitabile dell’avere backup; le richieste di cancellazione eseguite tramite l’amministrazione sottraggono immediatamente i dati al trattamento (archiviati, nascosti, non più registrati) e li cancellano definitivamente al più tardi dopo 30 giorni, senza attesa se ciò è espressamente richiesto; una richiesta presentata nella pagina dei dati /my-data viene eseguita senza archiviazione, di norma entro pochi minuti. Non viene effettuata la cancellazione selettiva all’interno di un backup: una copia è un unico archivio sigillato il cui scopo è costituire un’immagine fedele di un determinato momento; aprirlo, modificarlo e sigillarlo nuovamente distruggerebbe tale caratteristica e la capacità di dimostrare che nessuno lo ha manomesso. I backup servono esclusivamente a ripristinare il sistema dopo una perdita; non vengono sottoposti a ricerche, non vengono analizzati e non vengono divulgati. Se un backup viene ripristinato, le richieste di cancellazione registrate per gli utenti finali vengono nuovamente eseguite prima che il sistema torni in servizio – la registrazione della richiesta sopravvive alla cancellazione proprio perché possa essere ripetuta. Per un account cliente eliminato la situazione è diversa: l’eliminazione non lascia deliberatamente alcuna registrazione che lo identifichi, quindi una copia ripristinata conterrebbe un account eliminato dopo la data di tale copia.
• Monitoraggio. Un processo di controllo verifica, a intervalli di un minuto, il database e il processo di elaborazione degli eventi, il server WebSocket, il front end web, l’aggiornamento del database di geolocalizzazione, l’esecuzione giornaliera delle eliminazioni, il successo del backup e lo spazio libero sul volume di sistema e su quello di backup. Ogni risultato viene scritto nello stato condiviso e mostrato nell’area di amministrazione e ogni controllo fallito viene segnalato via e-mail al massimo una volta al giorno – un processo di controllo che invia e-mail ogni minuto viene disattivato e quindi non segnala più neppure il guasto reale. Prima del 19/08/2026 venivano verificati soltanto i primi cinque di questi aspetti e soltanto l’esecuzione delle eliminazioni generava un avviso; il resto era manuale e questo documento lo dichiarava.
• Ciò che questo monitoraggio non può fare, dichiarato anziché lasciato intendere: viene eseguito sulla macchina che controlla, perciò non può segnalarne il guasto totale. Dal 02/10/2026 una seconda macchina nello stesso luogo verifica ogni minuto se l’applicazione accetta registrazioni – database, cache, server WebSocket, processi in background, coda e script di tracciamento – e avvisa tramite Telegram dopo due controlli falliti consecutivi. Raggiunge il server tramite la rete locale: un guasto della connessione Internet, del router o del DNS non viene rilevato ed è ancora notato da una persona, non da un sistema di monitoraggio. Obiettivo del tempo di ripristino (RTO): non più di 24 ore. Test di ripristino: il ripristino dal backup esterno è stato testato il 05/09/2026 e il 06/09/2026 e il 07/10/2026 (ripristino completo dei dati); non è stata definita una pianificazione fissa.
• Sovraccarico e attacchi. nginx limita le richieste e le connessioni simultanee per indirizzo; un indirizzo che supera persistentemente il limite viene rifiutato al firewall da fail2ban per un’ora. Il server WebSocket blocca automaticamente per 24 h gli indirizzi che generano un afflusso eccessivo di connessioni; i blocchi impostati manualmente dal gestore sono conservati nel database.

6. Procedure di riesame periodico

• Le misure di questo documento vengono riesaminate quando cambia il trattamento e, altrimenti, con la frequenza indicata nella sezione 10.
• Un controllo dell’installazione verifica per ogni progetto Cliente se lo script è integrato correttamente e se arrivano registrazioni con una registrazione del consenso. I progetti privi di tale registrazione vengono segnalati nella dashboard.
• Attualmente non vengono commissionati test di penetrazione esterni e non si possiedono certificazioni di sicurezza. Ciò viene dichiarato qui anziché omesso: un documento TOM che tace su questo punto si legge come se tali test esistessero.
• Il numero di utenti finali osservati complessivamente per tutti i clienti viene misurato ogni giorno e confrontato con la soglia oltre la quale deve essere ripetuta la valutazione ai sensi dell’art. 37 GDPR (100000 al mese; si veda la sezione 9 del Registro delle attività di trattamento). Tale quantità è determinata dal traffico sui siti web dei clienti e non da noi; lasciarla senza controllo significherebbe quindi consentire che la valutazione diventi obsoleta senza che nessuno se ne accorga. Lo stesso processo controlla la ripetizione annuale.

7. Sub-responsabili

MousePlayer ricorre a sub-responsabili soltanto con l’autorizzazione generale scritta del Titolare del trattamento ai sensi del DPA. L’elenco attuale, comprese finalità, categorie di dati e luogo del trattamento, è pubblicato separatamente:

• Elenco dei sub-responsabili

Nessun terzo partecipa alla registrazione stessa: lo script di tracciamento trasmette esclusivamente all’infrastruttura di MousePlayer. Per i dati degli utenti finali esiste un ulteriore destinatario: una copia esterna giornaliera del database completo e dell’archivio delle registrazioni — comprese le registrazioni delle sessioni — è conservata presso Google (Google Cloud Storage, bucket a Varsavia). È conservata lì cifrata dal 11/08/2026: la cifratura avviene sul nostro server prima del trasferimento (rclone crypt) e comprende anche i nomi di file e cartelle; le chiavi sono detenute da MousePlayer. Google non le riceve e non può leggere il contenuto, ma rimane un sub-responsabile — la cifratura è una misura tecnica, non un cambiamento di ruolo. La precedente cartella di destinazione non cifrata, contenente le copie antecedenti al 11/08/2026, è stata eliminata il 12/08/2026.

8. Conservazione e cancellazione

La conservazione delle registrazioni delle sessioni dipende dal livello di abbonamento del Cliente:

• Gratuito: 7 giorni · Small: 30 giorni · Business: 90 giorni · Enterprise: secondo quanto concordato contrattualmente, individualmente.
• Dopo il passaggio a un livello inferiore si applica un periodo di tolleranza di almeno 30 giorni durante il quale continua la conservazione più lunga del livello precedente. Il passaggio a un livello superiore non abbrevia mai la conservazione.
• Il log dell’applicazione viene cancellato dopo 60 giorni, i log del server web dopo 14 giorni, i log di sicurezza dopo 72 ore.
• Per le sessioni identificate come accessi automatizzati, la registrazione viene rimossa dopo 1 giorno e la sessione viene cancellata dopo 14 giorni. Per un account con piano Gratuito contrassegnato come sospetto di abuso, viene registrata soltanto una parte delle visite e le registrazioni vengono eliminate dopo 1 giorno.
• Il log di consegna delle integrazioni viene cancellato dopo 30 giorni. Risiede in Redis anziché nel database e vi scade autonomamente; l’elenco è inoltre limitato a 25 voci per progetto. Non fa quindi parte neppure del backup giornaliero.
• La cancellazione alla scadenza di un periodo di conservazione avviene automaticamente e senza intervento umano; non richiede un’attivazione manuale.

Alla cessazione dell’account del Cliente, tutti i dati personali associati vengono cancellati entro 30 giorni, salvo che il diritto dell’Unione o di uno Stato membro richieda un’ulteriore conservazione. L’eliminazione viene avviata dal Cliente nelle impostazioni dell’account; non è necessaria una richiesta via e-mail. Inizialmente l’account viene archiviato: l’accesso termina immediatamente, non viene più registrato né mostrato nulla e per 30 giorni possiamo ancora ripristinarlo su richiesta qualora l’eliminazione sia stata un errore. Dopo tale periodo viene cancellato definitivamente; all’avvio dell’eliminazione, il Cliente può anche scegliere la cancellazione definitiva immediata. Anche un progetto o un’area di lavoro eliminati dal Cliente vengono inizialmente archiviati per 30 giorni e possono essere ripristinati nella dashboard durante tale periodo. Tre cose vengono deliberatamente conservate perché lo richiede la legge o perché documentano una decisione anziché una persona: la registrazione dell’accettazione di questi documenti, il log di sicurezza e delle modifiche (con il riferimento all’utente rimosso) e le richieste di assistenza. In deroga a quanto sopra, un account con piano Gratuito inutilizzato per 24 mesi viene cancellato definitivamente, senza archiviazione preventiva, 30 giorni dopo una comunicazione recapitata.

Le registrazioni del consenso sono conservate oltre la cancellazione della registrazione della sessione stessa. Non contengono dati comportamentali, ma soltanto il fatto, l’ora e la fonte della decisione sul consenso e servono ad adempiere all’obbligo di responsabilizzazione ai sensi dell’art. 5(2) GDPR.

9. Violazione dei dati personali

MousePlayer informa il Titolare del trattamento senza ingiustificato ritardo e al più tardi entro 48 ore da quando viene a conoscenza di una violazione dei dati personali che interessa i dati del Titolare. La notifica contiene le informazioni necessarie al Titolare per adempiere ai propri obblighi ai sensi dell’art. 33 GDPR.

Indirizzo per la segnalazione di problemi di sicurezza: office@mouseplayer.com

10. Stato e versione

• Versione: 1.5 · In vigore dal: 16/10/2026 · Prossimo riesame: 19/08/2027 · sostituisce la versione 1.4 del 07/10/2026. Modifiche: la sezione 2.2 indica l’accesso a due fattori, l’elenco degli accessi attivi con revoca e l’avviso di accesso; la sezione 2.3 indica i ruoli owner, admin e viewer; la sezione 3 indica le eccezioni per gli indirizzi IP completi; la sezione 4.1 descrive i percorsi di trasporto dello script e le connessioni non cifrate nella rete locale anziché affermare che non esistano percorsi non cifrati; la sezione 4.3 indica le altre interfacce; la sezione 5 documenta che l’archivio delle registrazioni è incluso nel backup dal 06/10/2026 e indica i test di ripristino effettuati e i limiti di sovraccarico; la sezione 8 aggiunge periodi di conservazione e l’eliminazione degli account inattivi. Inoltre, la sezione 2.2 dichiara lo stato dell’accesso SSH e la durata del blocco automatico è indicata come impostazione. La Versione 1.4 sostituiva la versione 1.3 del 17/09/2026. Modifiche: le sezioni 5 e 8 dichiarano che la cancellazione inizialmente archivia i dati – sottratti immediatamente al trattamento – e li cancella definitivamente al più tardi dopo 30 giorni. La Versione 1.3 sostituiva la versione 1.2 del 19/08/2026. Modifiche: la sezione 4.3 indica le macchine che eseguono il modello linguistico per i testi generati, come vi arrivano i risultati e che cosa accade durante la manutenzione. La Versione 1.2 sostituiva la versione 1.1 del 11/08/2026. Modifiche: la sezione 5 indica la conservazione dei backup come impostazione anziché come costante, descrive che cosa accade alle cancellazioni in caso di ripristino e documenta che il successo dei backup e lo spazio su disco sono ora monitorati automaticamente; la sezione 6 aggiunge la misurazione della soglia dell’art. 37.
• In caso di divergenze tra le versioni linguistiche, prevale la versione inglese.