Governance della privacy per il session replay ai sensi del GDPR e di ISO 27701

La demo che ha trasformato gli insight di prodotto in evidenze privacy

La schermata della demo sembrava una svolta. Sarah, CISO di una società SaaS in forte crescita, osservava il team di prodotto riprodurre una sessione reale di onboarding dalla nuova piattaforma di analytics. Il cursore si muoveva nell’interfaccia, un utente esitava al terzo passaggio, tornava indietro due volte, apriva un tooltip di aiuto e poi abbandonava il percorso.

Il product manager era entusiasta. Il session replay avrebbe mostrato con precisione dove i clienti incontravano difficoltà. Le heatmap avrebbero evidenziato quali campi generavano attrito. La diagnostica dei crash avrebbe indicato all’ingegneria quali browser non funzionavano. La telemetria mobile avrebbe aiutato a prioritizzare le correzioni in base alla versione del dispositivo. Sembrava una miniera d’oro per l’esperienza utente.

Poi Sarah vide che cosa lo strumento aveva effettivamente acquisito.

Un utente aveva digitato per errore una password nel campo del nome utente. Un altro aveva incollato un numero identificativo nazionale in un campo di testo libero. Un addetto al supporto aveva aperto l’account di un cliente durante una sessione di troubleshooting, esponendo dati finanziari a schermo. I log dei crash contenevano indirizzi e-mail, indirizzi IP, nomi di route, stato di autenticazione, identificativi dei dispositivi e feature flag che rivelavano il workflow interno del cliente.

Il fornitore di analytics si qualificava come responsabile del trattamento. Il contratto con il cliente stabiliva che i PII di produzione non potessero essere utilizzati per analytics senza approvazione. L’informativa privacy indicava solo che l’azienda utilizzava analytics per migliorare il servizio. Non menzionava session replay, monitoraggio comportamentale, identificativi dei dispositivi, mascheramento, conservazione, destinatari o trasferimenti internazionali.

Il team di prodotto vedeva dati operativi innocui. Sarah vedeva informazioni personali identificabili, PII, non strutturate, non mascherate e non governate, all’interno di una piattaforma cloud con accessi interni estesi e una base giuridica poco chiara.

Questo è il vero problema della telemetria di prodotto e della governance della privacy del session replay. Il rischio non è l’esistenza della telemetria. Il rischio è trattarla come un residuo tecnico a basso rischio, invece che come un’attività di trattamento governata che coinvolge base giuridica, informativa privacy, screening DPIA, contratti con i fornitori, mascheramento, controllo degli accessi, conservazione, risposta agli incidenti ed evidenze di audit.

Ai sensi di ISO/IEC 27701:2025, le organizzazioni hanno bisogno di un Sistema di gestione delle informazioni sulla privacy, PIMS, che tratti la privacy come un modello operativo. Ai sensi del GDPR, i titolari del trattamento devono dimostrare la conformità a principi quali liceità, correttezza, trasparenza, limitazione della finalità, minimizzazione dei dati, limitazione della conservazione, integrità, riservatezza e responsabilizzazione. Il session replay e la telemetria di prodotto rientrano direttamente in quest’area di responsabilizzazione, perché spesso monitorano il comportamento di persone identificabili all’interno di un servizio digitale.

L’approccio di Clarysec consiste nel portare la telemetria fuori dalle zone d’ombra e inserirla in una catena di governance tracciabile: inventario, qualificazione dei ruoli, base giuridica, screening DPIA, informativa privacy, valutazione dei fornitori, mascheramento, conservazione, controllo degli accessi, evidenze e riesame continuo. Questa catena è supportata da Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, dalle politiche PIMS di Clarysec e da Zenith Controls: The Cross-Compliance Guide Zenith Controls.

Perché la telemetria di prodotto non è solo analytics ai sensi del GDPR

Il GDPR definisce i dati personali in modo ampio, includendo gli identificativi online e le informazioni riferite a una persona fisica identificata o identificabile. Definisce in modo ampio anche il trattamento, includendo raccolta, conservazione, uso, comunicazione, cancellazione e distruzione. La telemetria di prodotto può quindi diventare trattamento di dati personali quando include dati relativi a utenti, tenant, amministratori, dipendenti o utenti finali dei clienti, vi si collega o può ragionevolmente essere associata a tali soggetti.

I punti dati di telemetria più comuni includono:

• ID utente, indirizzi e-mail, ID tenant e ID account
• Indirizzi IP, identificativi dei dispositivi, fingerprint del browser e ID pubblicitari mobili
• Utilizzo delle funzionalità, percorsi di clic, profondità di scorrimento, interazioni con i moduli e comportamenti di errore
• Dump dei crash, nomi di route, frammenti di payload API e log diagnostici
• Registrazioni di session replay, snapshot DOM, eventi di digitazione e heatmap
• Metadati di supporto, screenshot, registrazioni dello schermo e feedback degli utenti
• Eventi di prestazione collegati ad account, ruolo, area geografica o segmento di clientela

La questione privacy diventa più rilevante quando la telemetria rivela comportamenti. GDPR Article 3 può applicarsi anche a fornitori SaaS non UE quando offrono beni o servizi a persone nell’Unione o monitorano il loro comportamento all’interno dell’Unione. Session replay, heatmap e product analytics sono spesso monitoraggio comportamentale nel linguaggio corrente, anche quando la finalità aziendale è il miglioramento del prodotto e non la pubblicità.

GDPR Article 6 richiede una base giuridica per ciascuna finalità del trattamento. Il consenso può essere appropriato quando il tracciamento è opzionale, invasivo o disciplinato da norme ePrivacy locali. Il legittimo interesse può essere possibile per una telemetria limitata, ma solo dopo aver valutato necessità, proporzionalità e diritti e libertà delle persone. Il contratto può supportare la telemetria strettamente necessaria per erogare il servizio, ma non ogni ottimizzazione di prodotto o caso d’uso di replay rientra agevolmente nella base contrattuale.

Conta anche il rischio relativo alle categorie particolari di dati personali. GDPR Article 9 limita il trattamento di dati che rivelano informazioni sanitarie, biometriche, politiche, religiose o altre categorie sensibili. Molti fornitori SaaS presumono di non raccogliere tali dati, per poi scoprire che i clienti li incollano in moduli di supporto, campi di workflow, note, registrazioni HR, descrizioni di pratiche legali, richieste mediche o screenshot acquisiti dagli strumenti di replay.

La Politica di protezione dei dati e privacy Enterprise di Clarysec Politica di protezione dei dati e privacy rende esplicite base giuridica e minimizzazione:

Tutti i trattamenti devono fondarsi su un valido presupposto giuridico, ad esempio consenso, contratto od obbligo legale.

Dalla sezione “Requisiti di applicazione della politica”, clausola 6.1.1.

Possono essere raccolti e trattati solo i dati necessari per una finalità aziendale specifica e legittima.

Dalla sezione “Requisiti di applicazione della politica”, clausola 6.2.1.

Per i team più piccoli, la Data Protection and Privacy Policy-sme Politica di protezione dei dati e privacy - SME richiede disciplina nell’inventario:

Il Coordinatore privacy deve mantenere un registro di tutte le attività di trattamento dei dati personali, comprendente categorie di dati, finalità, base giuridica e periodi di conservazione.

Dalla sezione “Requisiti di governance”, clausola 5.2.1.

Fornisce inoltre ai team di prodotto e ingegneria una chiara baseline di privacy by design:

La privacy by design e by default deve essere applicata in tutti i nuovi sistemi e servizi.

Dalla sezione “Requisiti di governance”, clausola 5.3.1.

La correzione di governance è semplice: non chiedersi se la telemetria sia “analytics”. Occorre chiedersi se sia un’attività di trattamento che coinvolge PII, monitoraggio comportamentale, profilazione, accesso dei fornitori, conservazione e controlli di sicurezza.

Partire dalla chiarezza dei ruoli ai sensi di ISO 27701:2025

La governance della privacy secondo ISO/IEC 27701:2025 funziona al meglio quando le organizzazioni definiscono innanzitutto il proprio ruolo. Si agisce come titolare del trattamento dei PII, decidendo perché viene usato il session replay e quali dati vengono acquisiti? Si agisce come responsabile del trattamento, acquisendo telemetria per conto di un cliente sulla base di istruzioni documentate? Oppure si ricoprono entrambi i ruoli, a seconda della funzionalità e della configurazione del cliente?

Il set di politiche PIMS di Clarysec utilizza tag di ruolo per rendere questo aspetto operativo. “Both” si applica indipendentemente dal fatto che l’organizzazione agisca come titolare del trattamento o responsabile del trattamento. “Controller” si applica quando l’organizzazione determina finalità e mezzi. “Processor” si applica quando il trattamento è effettuato su istruzioni documentate.

Un fornitore SaaS può essere titolare del trattamento per la telemetria usata per migliorare il proprio prodotto, individuare attriti nella UX o prioritizzare decisioni di roadmap. Lo stesso fornitore può essere responsabile del trattamento per la telemetria acquisita all’interno di uno spazio di lavoro controllato dal cliente, quando il cliente determina la finalità. In casi rari può configurarsi una contitolarità del trattamento quando entrambe le parti determinano congiuntamente finalità e mezzi. In altre catene, il fornitore può essere un sub-responsabile che gestisce telemetria per un altro responsabile del trattamento.

La Politica sull’inventario dei trattamenti di dati personali e sulla base giuridica Enterprise Politica sull’inventario dei trattamenti di dati personali e sulla base giuridica rende concreto il primo gate:

[Both] Il Proprietario del processo / Business Owner DEVE creare una registrazione dell’inventario dei trattamenti REG02 prima dell’avvio di qualsiasi nuova attività di trattamento di PII.

Dalla sezione “Baseline dell’inventario dei trattamenti”, clausola 4.1.1.

Per la telemetria di prodotto, REG02 non dovrebbe contenere una riga generica “analytics”. Dovrebbe separare finalità e flussi di dati.

ISO/IEC 27001:2022 supporta questo lavoro PIMS fornendo all’organizzazione la struttura per contesto, requisiti delle parti interessate, ambito di applicazione, leadership, ruoli, valutazione del rischio, pianificazione del trattamento del rischio, controllo operativo e servizi forniti dall’esterno. Il SGSI chiede quali siano asset, rischi, proprietari, controlli ed evidenze. Il PIMS chiede quali PII siano trattati, perché, in quale ruolo, con quali diritti, misure di sicurezza e informative.

Insieme, prevengono il classico divario privacy in cui i team di prodotto abilitano il tracciamento più rapidamente di quanto la governance riesca a classificarlo.

Trigger DPIA: quando l’insight di prodotto diventa trattamento ad alto rischio

Non ogni evento di telemetria richiede una DPIA completa. Tuttavia session replay e behavioral analytics richiedono spesso uno screening DPIA, perché possono comportare monitoraggio sistematico, profilazione, trattamento su larga scala, contenuti sensibili, utenti vulnerabili, tecnologie innovative o modifiche sostanziali del trattamento.

La Privacy Risk Assessment and DPIA Policy Politica di valutazione del rischio privacy e DPIA è esplicita per i titolari del trattamento:

[Controller] Il Proprietario del processo / Business Owner DEVE sottoporre al Privacy Lead / Responsabile del PIMS in REG04, prima dell’inizio del trattamento, i trattamenti che coinvolgono monitoraggio sistematico su larga scala, profilazione, decisioni automatizzate, categorie particolari di PII, dati relativi a condanne penali o reati, interessati vulnerabili, tecnologie innovative o modifiche sostanziali del trattamento.

Dalla sezione “Trigger DPIA e determinazione del requisito”, clausola 4.2.2.

Uno screening DPIA sul session replay dovrebbe porre domande pratiche:

• Il replay acquisisce input dei moduli, contenuto delle pagine, testo delle chat, documenti caricati o payload di errore?
• Il mascheramento avviene prima che i dati lascino il browser o solo dopo l’ingestione dei dati?
• Lo strumento può acquisire password, token, secret, codici monouso o campi di pagamento?
• Le sessioni sono collegate a utenti nominativi, account, indirizzi IP o identificativi dei dispositivi?
• I dipendenti possono cercare i replay per utente, cliente, segmento, errore, URL o comportamento?
• Il fornitore usa i dati per analytics, pipeline di addestramento dell’IA, benchmarking o miglioramento del prodotto?
• Sono previsti trasferimenti internazionali?
• Quale periodo di conservazione è configurato, e la cancellazione può essere applicata per tenant o utente?
• I clienti possono disabilitare il replay, configurare il mascheramento o richiedere la cancellazione?
• Dipendenti, amministratori e utenti finali dei clienti sono coperti dalle informative?
• Esiste il rischio di acquisire dati personali di minori, dati sanitari, dati finanziari o dati HR?

La Politica di protezione dei dati e privacy Enterprise rafforza la soglia di alto rischio:

La modellazione delle minacce e le valutazioni d’impatto sulla protezione dei dati (DPIA) sono obbligatorie per i sistemi di trattamento ad alto rischio.

Dalla sezione “Requisiti di applicazione della politica”, clausola 6.3.4.

Una lezione importante di Clarysec emersa dagli audit è che il rischio del session replay non è solo un tema privacy. È anche un tema di architettura di sicurezza. Se gli snapshot DOM acquisiscono bearer token, ID interni, campi nascosti o workflow sensibili dei clienti, l’organizzazione ha creato un nuovo archivio di dati ad alto valore al di fuori del normale perimetro di logging, DLP e riesame degli accessi.

Trasformare lo strumento di replay in un asset idoneo all’audit

Il modo più rapido per ridurre il rischio della telemetria è smettere di trattare gli strumenti come componenti invisibili del prodotto. Nel Zenith Blueprint, fase Gestione del rischio, Passaggio 9, “Identifying Assets, Threats, and Vulnerabilities,” Clarysec indica alle organizzazioni di inventariare gli asset e registrare proprietario, ubicazione e classificazione. Specifica inoltre che gli asset relativi a dati personali devono essere contrassegnati per la rilevanza GDPR e che gli asset critici per il servizio devono essere annotati per una potenziale applicabilità NIS2.

Il Blueprint inquadra un asset informativo come qualsiasi elemento di valore che potrebbe subire un danno a causa di un incidente di sicurezza, inclusi informazioni, software, servizi cloud, servizi/processi e servizi di terze parti. Per la governance della telemetria, ogni piattaforma di analytics, fornitore di replay, SDK, pipeline di eventi, data lake, dashboard, esportazione e repository delle registrazioni di supporto diventa un asset idoneo all’audit.

Questo collega la governance privacy alle evidenze del SGSI. I team di prodotto, privacy, ingegneria e audit possono fare riferimento alla stessa registrazione invece di mantenere narrazioni separate.

Usare Zenith Controls come asse della conformità trasversale

Clarysec utilizza Zenith Controls come guida di conformità trasversale, non come sostituto dei framework ufficiali. Per la telemetria e il session replay, i temi centrali di ISO/IEC 27002:2022 sono privacy e protezione dei PII, governance dei servizi cloud, rapporti con i fornitori, mascheramento dei dati, inventario degli asset, classificazione, controllo degli accessi e gestione delle modifiche.

In Zenith Controls, il controllo ISO/IEC 27002:2022 5.34, Privacy and protection of PII, è l’ancora. Il suo fondamento pratico è la consapevolezza dei dati:

Il fondamento di questo controllo è la consapevolezza dei dati. L’organizzazione deve sapere quali PII raccoglie, dove risiedono, perché vengono trattati e chi può accedervi.

Da Zenith Blueprint, fase Controls in Action, Passaggio 23, Controllo 5.34, Privacy and Protection of Personally Identifiable Information.

Zenith Controls mappa 5.34 a controlli di supporto ISO/IEC 27002:2022 quali 5.9 inventario delle informazioni e degli altri asset associati, 8.11 mascheramento dei dati, 5.23 sicurezza delle informazioni per l’uso dei servizi cloud, 5.12 classificazione delle informazioni, 5.14 trasferimento delle informazioni, 5.15 controllo degli accessi, 5.16 gestione delle identità, 5.19 sicurezza delle informazioni nei rapporti con i fornitori, 5.8 sicurezza delle informazioni nella gestione dei progetti e 8.32 gestione delle modifiche.

Per il mascheramento dei dati, Zenith Controls identifica il controllo ISO/IEC 27002:2022 8.11 come preventivo e focalizzato sulla riservatezza. Lo collega inoltre a 8.3 limitazione dell’accesso alle informazioni, 8.10 cancellazione delle informazioni, 8.12 prevenzione della perdita di dati, 8.24 uso della crittografia e 8.33 informazioni di test. Questo è importante perché il mascheramento del session replay non può essere cosmetico. Deve essere progettato, testato e supportato da evidenze.

La Data Masking and Pseudonymization Policy-sme Politica di mascheramento dei dati e pseudonimizzazione - SME fornisce una regola semplice che si applica anche agli analytics di prodotto:

Non devono essere usati dati personali dei sistemi in esercizio in test, strumenti esterni o analytics, salvo autorizzazione formale.

Dalla sezione “Ruoli e responsabilità”, clausola 4.4.1.

Un workflow Clarysec pratico per approvare il session replay

Immaginiamo che il team di prodotto voglia abilitare il replay per tutte le sessioni di checkout non riuscite in un’app fintech. Il business case è reale: l’abbandono del checkout incide su ricavi e soddisfazione dei clienti. La domanda di governance è se tale insight possa essere raccolto in modo lecito, proporzionato e sicuro.

Passaggio 1: creare REG02 prima della messa in esercizio dell’SDK

Usare REG02 ai sensi della Politica sull’inventario dei trattamenti di dati personali e sulla base giuridica. Registrare finalità, categorie di dati, categorie di utenti, fonte, destinatari, conservazione, trasferimenti, proprietario del sistema, base giuridica e ruolo.

Non scrivere “analytics”. Scrivere “session replay per la risoluzione dei problemi di checkout non riuscito e il miglioramento della conversione”. Elencare i campi specifici, inclusi ID utente, ID tenant, indirizzo IP, ID dispositivo, eventi di clic, route delle pagine, snapshot DOM, campi dei moduli mascherati, codici di errore e stato del flusso di pagamento.

Passaggio 2: determinare la base giuridica

Per la diagnostica di base dei crash e le metriche di prestazione aggregate, il legittimo interesse può essere difendibile se l’organizzazione documenta necessità, proporzionalità, misure di protezione e aspettative degli utenti. Per il session replay completo, soprattutto su schermate autenticate, il consenso può essere più chiaro quando le regole locali o il livello di invasività lo richiedono.

Un approccio ibrido è spesso più pratico: usare il legittimo interesse per una telemetria limitata, non invasiva e mascherata, e richiedere opt-in esplicito o abilitazione a livello di tenant per il session replay. Qualunque sia la risposta, deve essere documentata e riflessa in informative, contratti e configurazione.

Passaggio 3: eseguire lo screening dei trigger DPIA in REG04

Il replay di checkout non riusciti può coinvolgere comportamenti finanziari, autenticazione, schermate di pagamento e monitoraggio sistematico. Il Proprietario del processo sottopone l’attività al Privacy Lead. Lo screening valuta necessità, proporzionalità, aspettative delle persone, mascheramento, controlli degli accessi, uso da parte del fornitore, conservazione e alternative come metriche aggregate del funnel.

La Privacy by Design and Default Policy Politica di privacy by design e by default richiede una specifica analisi di minimizzazione:

[Both] Il Proprietario del processo / Business Owner DEVE documentare in REG04 la fattibilità di de-identificazione, pseudonimizzazione, aggregazione o trattamento di dati non identificabili prima di approvare PII identificabili per test, analytics, reportistica o uso operativo secondario.

Dalla sezione “Minimizzazione dei dati e progettazione privacy by default”, clausola 4.2.5.

Passaggio 4: configurare le impostazioni privacy predefinite prima dell’acquisizione in produzione

L’ingegneria dovrebbe configurare l’SDK per:

• Disabilitare per impostazione predefinita l’acquisizione degli eventi di digitazione
• Mascherare tutti i campi di input salvo approvazione espressa
• Bloccare l’acquisizione del replay su pagine di pagamento, password, MFA, salute, HR o testo libero sensibile
• Rimuovere token, header di autorizzazione e campi nascosti
• Sostituire l’ID utente con un ID analytics pseudonimo, ove fattibile
• Troncare gli indirizzi IP o conservarli separatamente con accesso ristretto
• Applicare una breve conservazione dei replay grezzi
• Abilitare l’opt-out a livello di tenant quando richiesto contrattualmente
• Instradare l’accesso tramite SSO, MFA e approvazione basata sui ruoli
• Abilitare i log di audit per visualizzazione, esportazione e cancellazione dei replay

Passaggio 5: aggiornare informativa privacy e documentazione per i clienti

La Privacy Notice and Transparency Policy Politica sull’informativa privacy e la trasparenza richiede che il contenuto dell’informativa sia ricavato da REG02:

[Controller] Il Proprietario del processo / Business Owner DEVE includere in REG07, prima di sottoporre un’informativa privacy all’approvazione, le categorie di PII, le categorie di interessati, la categoria della fonte quando indiretta, le categorie di destinatari, il riferimento alla conservazione e il riferimento al trasferimento tratti da REG02.

Dalla sezione “Contenuto dell’informativa e informazioni di trasparenza”, clausola 4.2.3.

L’informativa dovrebbe spiegare product analytics e replay con linguaggio chiaro: che cosa viene acquisito, perché, se è opzionale, chi lo riceve, per quanto tempo viene conservato, dove viene trasferito e come gli utenti possono esercitare i propri diritti.

Passaggio 6: valutare il fornitore e gli obblighi contrattuali a cascata

Prima di approvvigionamento, onboarding, rinnovo o modifica sostanziale di una funzionalità, usare REG08 ai sensi della Processor, Subprocessor and Third-Party Privacy Management Policy Politica di gestione privacy di responsabili del trattamento, sub-responsabili e terze parti:

[All] Il Proprietario del processo / Business Owner DEVE identificare in REG08 ogni rapporto proposto con terze parti che tratterà, accederà a, riceverà, conserverà, trasmetterà, supporterà o comunque inciderà sui PII prima di approvvigionamento, onboarding, rinnovo o modifica sostanziale privacy relativa a terze parti.

Dalla sezione “Identificazione e classificazione del rapporto”, clausola 4.1.2.

Il riesame del fornitore dovrebbe coprire ubicazione dei dati, sub-responsabili, cifratura, controlli degli accessi, notifica della violazione, cancellazione, diritti di audit, uso dei dati dei clienti, esclusioni dall’addestramento IA, accesso per il supporto, conservazione, controlli sulle esportazioni e cooperazione sugli incidenti.

La Politica di protezione dei dati e privacy Enterprise ricorda inoltre ai team:

I contratti con i responsabili del trattamento devono includere:

Dalla sezione “Applicazione e conformità”, clausola 8.5.1.

La Third-Party and Supplier Security Policy-sme SME Politica di sicurezza delle terze parti e dei fornitori - SME rafforza che:

I contratti devono includere clausole obbligatorie relative a:

Dalla sezione “Requisiti di governance”, clausola 5.3.

La domanda di audit è diretta: si può dimostrare che il fornitore di replay è vincolato agli obblighi di privacy, sicurezza, conservazione, cancellazione, assistenza e gestione degli incidenti?

Passaggio 7: produrre evidenze sui controlli tecnici

Nel Zenith Blueprint, fase Controls in Action, Passaggio 19, “Technological Controls I,” Clarysec indica ai team di verificare cancellazione e conservazione automatizzate, riesaminare mascheramento e pseudonimizzazione nei test e negli analytics e valutare i controlli DLP.

Per il replay, conservare evidenze quali:

• Screenshot della configurazione dell’SDK
• Definizioni delle regole di mascheramento
• Acquisizioni di test che dimostrano il blocco dei campi sensibili
• Configurazione della conservazione
• Log di cancellazione
• Registrazioni dei riesami degli accessi
• DPA del fornitore ed elenco dei sub-responsabili
• Log di audit sulla visualizzazione dei replay
• Approvazione della DPIA o esito documentato dello screening
• Approvazione dell’informativa privacy

Questo trasforma la privacy by design da slogan a evidenze idonee all’audit.

Mappatura della conformità trasversale per la governance della telemetria

La governance della telemetria inizia spesso come tema GDPR, ma raramente resta confinata lì.

GDPR Article 5 richiede liceità, correttezza, trasparenza, limitazione della finalità, minimizzazione dei dati, esattezza, limitazione della conservazione, sicurezza e responsabilizzazione. Article 6 richiede una base giuridica. Article 4 chiarisce i ruoli di titolare del trattamento, responsabile del trattamento e violazione. Article 9 innalza la soglia quando categorie particolari di dati personali compaiono nei contenuti acquisiti. Per il session replay, questi principi si traducono in informative chiare, acquisizione minimizzata, campi mascherati, conservazione limitata, controlli degli accessi, contratti con i fornitori ed evidenze DPIA.

NIS2 può diventare rilevante per SaaS, cloud, infrastruttura digitale, MSP, MSSP e determinati fornitori digitali, a seconda di dimensione, settore e criticità del servizio. Article 20 rende la governance della cibersicurezza una responsabilità dell’organo di gestione. Article 21 richiede misure di gestione del rischio, incluse politiche, gestione degli incidenti, continuità, sicurezza della catena di fornitura, sviluppo sicuro, efficacia dei controlli, igiene cyber, crittografia, sicurezza HR, controllo degli accessi e gestione degli asset.

DORA si applica a molte entità finanziarie e introduce, dal 17 gennaio 2025, un regime settoriale di resilienza operativa digitale. Le sue aspettative di gestione del rischio ICT coprono governance, mappatura di asset e dipendenze, protezione, rilevamento, continuità, ripristino, formazione e vigilanza sulle terze parti. Per la telemetria fintech, un’impostazione coerente con DORA chiede se gli strumenti di replay supportino o incidano su funzioni essenziali o importanti, se il fornitore sia un fornitore terzo di servizi ICT e se i contratti includano assistenza per audit e incidenti.

NIST CSF 2.0 aggiunge un livello pratico di integrazione. La funzione GOVERN richiede di comprendere parti interessate, dipendenze, obblighi legali, normativi, contrattuali e privacy. Gli esiti IDENTIFY, PROTECT, DETECT, RESPOND e RECOVER si mappano naturalmente ad asset di telemetria, flussi di dati, controllo degli accessi, logging, triage degli incidenti, contenimento e ripristino.

Gli auditor COBIT 19, o i valutatori formati ISACA che utilizzano principi di governance, chiederanno di norma se la telemetria supporta gli obiettivi aziendali, se la titolarità del rischio è chiara, se i benefici sono bilanciati rispetto al rischio, se le politiche sono applicate e se il monitoraggio dimostra la prestazione del controllo.

Come gli auditor testano lo stesso workflow di replay

Un auditor privacy parte da REG02, REG04 e REG07. Seleziona un’attività di replay e chiede finalità, base giuridica, categorie di PII, categorie di interessati, destinatari, conservazione, trasferimenti, screening DPIA, testo dell’informativa e accordi con i responsabili del trattamento. Verifica se la configurazione effettiva dell’SDK corrisponde alla registrazione del trattamento approvata. Se la registrazione indica che i campi di input sono mascherati, richiede evidenze.

Un auditor ISO/IEC 27001:2022 parte da ambito di applicazione, valutazione del rischio, Dichiarazione di Applicabilità, controlli sui fornitori ed evidenze operative. Può collegare la telemetria a inventario degli asset, controllo degli accessi, servizi cloud, gestione dei rapporti con i fornitori, sviluppo sicuro e preparazione agli incidenti. Se il replay è stato introdotto tramite una modifica di prodotto, chiede se la valutazione del rischio è stata aggiornata e se i servizi forniti dall’esterno sono stati controllati.

Un auditor DORA in un contesto fintech chiede se il fornitore di telemetria è elencato nel registro ICT delle terze parti, se il servizio supporta una funzione essenziale o importante, se i contratti includono ubicazioni, regioni di trattamento dei dati, assistenza sugli incidenti, diritti di audit, diritti di risoluzione, requisiti di continuità operativa e supporto alla transizione.

Un valutatore NIST CSF parte dal profilo attuale. Il session replay è documentato come dipendenza tecnologica e attività di trattamento dei dati? Esiste uno stato target? Le lacune sono tracciate in un Registro dei rischi o in un piano di azione? I requisiti dei fornitori sono espressi nei contratti? Sono definiti ruoli di rilevamento e risposta se i dati di replay vengono esposti?

Un auditor COBIT 19 o di impostazione ISACA chiede se la governance è efficace. Il sistema di gestione ha definito la titolarità? Le parti interessate sono state consultate? Il rischio è accettato al livello corretto? Le metriche dei controlli sono riesaminate? Le eccezioni sono visibili alla direzione? L’insight di prodotto vale il rischio privacy e fornitori?

Il valore di Zenith Controls è che un unico workflow di replay può essere mappato su controlli privacy e sicurezza senza creare pacchetti di evidenze scollegati. Le stesse evidenze di mascheramento supportano protezione dei PII, prevenzione della perdita di dati, restrizione degli accessi e privacy by design. Lo stesso riesame del fornitore supporta governance cloud, governance dei responsabili del trattamento, sicurezza della catena di fornitura NIS2 e rischio ICT di terze parti DORA. Lo stesso inventario supporta la responsabilizzazione GDPR, le registrazioni PIMS ISO 27701:2025, la gestione degli asset ISO/IEC 27001:2022 e gli esiti sugli asset del NIST CSF.

Risultanze ricorrenti nei riesami della telemetria

Gli audit sulla telemetria rivelano di solito schemi ricorrenti.

Primo, l’inventario dei trattamenti riporta “analytics” ma non distingue crash reporting, heatmap, replay, registrazioni di supporto e insight di prodotto basati sull’IA. Questo rende impossibile validare base giuridica, informativa e conservazione.

Secondo, il mascheramento esiste ma non è testato. I team presumono che il fornitore mascheri le password, ma campi di testo libero, campi nascosti, completamento automatico, componenti personalizzati o schermate mobili aggirano le regole.

Terzo, l’accesso ai replay è troppo ampio. Prodotto, ingegneria, supporto e customer success hanno tutti accesso alla dashboard, ma mancano una giustificazione aziendale, un riesame periodico o un riesame dei log di audit.

Quarto, i valori predefiniti di conservazione sono eccessivi. Le registrazioni grezze delle sessioni vengono conservate per mesi perché il valore predefinito del fornitore non è mai stato modificato, anche se il valore per la risoluzione dei problemi decade rapidamente.

Quinto, i contratti con i fornitori non seguono l’evoluzione dell’uso effettivo. Il fornitore è stato inserito come strumento di product analytics, ma in seguito ha abilitato replay, sintesi IA, integrazioni di supporto o esportazioni di dati senza un riesame privacy aggiornato.

Sesto, le informative privacy sono generiche. Menzionano gli analytics ma non replay comportamentale, identificativi dei dispositivi, destinatari, conservazione o scelte degli utenti.

Settimo, le modifiche di prodotto aggirano lo screening DPIA. Nuove funzionalità dell’SDK vengono abilitate tramite toggle di configurazione, non tramite approvvigionamento, e quindi i team privacy e sicurezza non vedono mai la modifica.

La correzione Clarysec non consiste nel vietare la telemetria. Consiste nel costruire un gate di controllo leggero ma obbligatorio per le modifiche alla telemetria.

Checklist pratica di governance della telemetria

Usare questa checklist prima di abilitare, estendere o rinnovare telemetria di prodotto, analytics mobili, crash reporting, heatmap o session replay.

Collegare la checklist ai passaggi del Zenith Blueprint: Passaggio 9 per l’identificazione degli asset, Passaggio 19 per evidenze di cancellazione, mascheramento e DLP, e Passaggio 23 per la protezione dei PII in azione. Usare poi Zenith Controls per mappare i controlli ISO/IEC 27002:2022 5.34, 5.23, 5.19, 8.11, 5.15, 5.16, 5.8 e 8.32, così le stesse evidenze supportano conversazioni su GDPR, PIMS ISO 27701:2025, SGSI ISO/IEC 27001:2022, NIST CSF, NIS2 e DORA.

Il messaggio per il consiglio di amministrazione: la telemetria è un controllo di fiducia

La telemetria di prodotto offre valore reale alle organizzazioni. Aiuta i team a correggere workflow interrotti, migliorare l’accessibilità, ridurre il carico sul supporto, rilevare crash, prioritizzare il lavoro dell’ingegneria e comprendere i risultati dei clienti. Ma il session replay può anche diventare un livello di sorveglianza se è invisibile, eccessivo o non adeguatamente protetto.

Per i CISO e i responsabili della conformità, il messaggio al consiglio di amministrazione è semplice: la telemetria non è solo una capacità di ottimizzazione del prodotto. È un controllo di fiducia. Se governata correttamente, migliora la qualità del servizio nel rispetto della privacy. Se governata male, crea monitoraggio non documentato, rischio dei fornitori non controllato ed esposizione evitabile a violazioni.

NIS2 rafforza la responsabilità della direzione per la gestione dei rischi di cibersicurezza. DORA rende centrale la governance delle terze parti ICT e della resilienza per le entità finanziarie. Il GDPR attribuisce la responsabilizzazione al titolare del trattamento. ISO 27701:2025 aiuta a rendere operativi ruoli privacy, registrazioni, informative, DPIA e governance dei responsabili del trattamento. ISO/IEC 27001:2022 fornisce il motore SGSI per rischio, titolarità, controlli ed evidenze.

Clarysec riunisce questi elementi attraverso politiche, registri, il Zenith Blueprint e Zenith Controls.

Rendere la telemetria idonea all’audit prima del prossimo rilascio

Se l’organizzazione usa product analytics, session replay, crash reporting, heatmap, telemetria mobile o registrazioni dello schermo per il supporto, partire da una domanda: si può dimostrare che cosa viene acquisito, perché, con quale base giuridica, per quanto tempo, da chi, tramite quale fornitore e con quale mascheramento?

Usare Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint per inventariare gli asset di telemetria, riesaminare i controlli di mascheramento e cancellazione e valutare la governance dei fornitori. Usare Zenith Controls: The Cross-Compliance Guide Zenith Controls per mappare controlli privacy, cloud, mascheramento, accessi e fornitori tra i framework. Usare le politiche PIMS di Clarysec, incluse Politica sull’inventario dei trattamenti di dati personali e sulla base giuridica, Politica di valutazione del rischio privacy e DPIA, Politica di privacy by design e by default, Politica sull’informativa privacy e la trasparenza e Politica di gestione privacy di responsabili del trattamento, sub-responsabili e terze parti, per rendere tracciabile ogni workflow di telemetria.

Prima che il prossimo toggle SDK vada in esercizio, svolgere un riesame della governance privacy della telemetria. Il team di prodotto continuerà a ottenere insight, ma auditor, clienti e utenti otterranno qualcosa di più prezioso: evidenze di fiducia.