⚖️ Come gestire i dati sensibili in azienda

I dati sensibili sono dati personali ai quali il GDPR riserva una protezione rafforzata. Il regolamento li definisce categorie particolari di dati personali e vi include, per esempio, informazioni sulla salute, dati biometrici usati per identificare una persona, convinzioni religiose o politiche, appartenenza sindacale e vita o orientamento sessuale.

Riconoscere queste informazioni è necessario perché il modo in cui devono essere gestite dipende dallo scopo per cui vengono raccolte e dall’uso che ne fa l’azienda. Uno studio dentistico tratta dati sanitari per curare i pazienti. Un datore di lavoro può acquisirli per gestire assenze e obblighi relativi al rapporto di lavoro. Un sito vetrina, invece, può riceverli quando un utente descrive una patologia nel form. Nei tre casi cambiano le persone che possono accedere ai dati, i documenti necessari e i tempi di conservazione.

La raccolta non è sempre programmata dall’azienda. Un utente può inserire spontaneamente un dato sensibile nel campo libero di un form, in un ticket di assistenza o in un documento allegato. Dal momento in cui l’informazione entra nei sistemi aziendali, occorre decidere se possa essere utilizzata e per quanto tempo debba essere conservata. L’invio spontaneo o accidentale non elimina questa responsabilità.

La verifica parte dalla necessità dell’informazione. Se il dato non serve per gestire la richiesta, il consenso dell’utente non ne giustifica la raccolta: devono essere modificati il form o il processo e devono essere gestiti anche i dati già ricevuti. Se serve, l’azienda deve verificare che possa utilizzarlo per quella specifica attività, stabilire chi vi avrà accesso e individuare tutte le copie conservate nei software.

L’informativa può descrivere soltanto scelte che l’azienda ha già definito. Non corregge i permessi troppo ampi nel CRM. L’accesso del fornitore deve essere disciplinato nel contratto e anche le copie rimaste nelle email devono avere un termine di conservazione.

Quali sono i dati sensibili di una persona?

Cosa sono i dati sensibili o particolari

Nel linguaggio comune vengono definiti sensibili molti dati che preferiremmo non rendere pubblici. Il GDPR, però, usa una classificazione precisa: password, IBAN, situazione patrimoniale e documenti di identità sono dati personali da proteggere, ma la loro riservatezza non li fa rientrare automaticamente nella categoria dei dati particolari.

Sono dati sensibili quelli che rivelano:

• l’origine razziale o etnica;
• le opinioni politiche;
• le convinzioni religiose o filosofiche;
• l’appartenenza sindacale;
• caratteristiche genetiche;
• caratteristiche biometriche utilizzate per identificare una persona in modo univoco;
• informazioni sulla salute;
• la vita o l’orientamento sessuale.

I dati relativi a condanne penali e reati seguono una disciplina ancora diversa. 

Per capire quali dati tratta un’azienda bisogna esaminare le informazioni effettivamente raccolte, non le etichette utilizzate nei software. Se un segmento del CRM raggruppa gli utenti in base a una patologia, chiamarlo “preferenze prodotto” non modifica la natura dei dati. Allo stesso modo, sapere quali libri acquista una persona non rivela necessariamente le sue convinzioni politiche o religiose: dipende dalle informazioni che vengono ricavate e dall’uso successivo.

La classificazione può quindi dipendere anche dall’elaborazione compiuta dal software. Succede quando un sistema usa una fotografia per riconoscere in modo univoco una persona o quando un’app combina dati diversi e ne ricava un’informazione sulla salute.

Quando una fotografia diventa un dato biometrico

Una fotografia che permette di riconoscere una persona è un dato personale. Diventa un dato biometrico, quindi particolare, quando viene sottoposta a uno specifico trattamento tecnico destinato a identificare o autenticare quella persona in modo univoco.

Ad esempio, durante l’onboarding, quando un software ricava dall’immagine del volto un modello da confrontare con il documento di identità, oppure quando il riconoscimento facciale permette di accedere a un account. La semplice pubblicazione della fotografia sul sito non produce lo stesso risultato.

Il Garante lo ha ribadito nel provvedimento del 23 ottobre 2025: le immagini possono contenere dati identificativi senza essere, per questo, dati biometrici. Servono sia il trattamento tecnico sia la finalità di identificazione univoca.

Se raccogli una fotografia per creare un account o la pubblichi online, devi comunque valutare la finalità, l’informativa, la condizione che permette di utilizzarla e le regole sul diritto all’immagine. Quando il software estrae le caratteristiche del volto per riconoscere la persona, si applicano anche le garanzie previste per i dati biometrici. L’articolo di Legal for Digital su dati biometrici e GDPR approfondisce questa seconda situazione.

Quali informazioni sono dati sanitari

Sono dati sanitari le informazioni che descrivono la salute fisica o mentale di una persona, comprese quelle relative a una malattia, a un trattamento ricevuto o al rischio di sviluppare una determinata condizione. Possono provenire da un medico, da un dispositivo indossabile, da un’app o da una piattaforma di prenotazione. Il software nel quale vengono raccolte non ne modifica la natura.

Il movimento registrato da uno smartwatch può descrivere una semplice attività quotidiana. Se l’app combina quel valore con altri parametri e restituisce una valutazione sulle condizioni fisiche o sul rischio cardiovascolare, produce un’informazione sulla salute. Per classificare correttamente il dato bisogna quindi esaminare anche ciò che il software ricava dalle informazioni inserite dall’utente.

Una piattaforma può ricevere dati sanitari prima della visita. La specializzazione del medico cercato, la prestazione prenotata o il testo scritto per motivare l’appuntamento possono rivelare il problema di salute dell’utente.

Il Compendio del Garante dedicato alle piattaforme che mettono in contatto pazienti e professionisti sanitari separa le funzioni amministrative, come la creazione dell’account e la prenotazione, dall’attività di diagnosi e cura svolta dal professionista. La separazione è necessaria perché, all’interno della stessa piattaforma, possono cambiare i dati utilizzati, le finalità e i soggetti che vi accedono.

Quando la piattaforma viene usata per una televisita o per il telemonitoraggio, possono essere caricati referti, prescrizioni, immagini diagnostiche e parametri clinici. Possono rimanere anche i messaggi scambiati con il professionista o le registrazioni, se il servizio le prevede. La telemedicina porta quindi nel software informazioni che fanno parte direttamente del rapporto di cura.

La Piattaforma nazionale di telemedicina ha una disciplina specifica, costruita per un’infrastruttura pubblica articolata tra livello nazionale e regionale. Il parere del Garante dedica disposizioni distinte ad accessi, ruoli, conservazione e sicurezza. Quella disciplina non può essere trasferita automaticamente alle app private, ma mostra quali aspetti devono essere definiti quando il servizio sanitario dipende da una piattaforma digitale.

Prima di redigere l’informativa, chi offre o sviluppa il servizio deve separare la prenotazione dall’attività sanitaria e ricostruire quali informazioni siano accessibili al gestore, al medico e agli altri fornitori. Le condizioni che permettono di trattare i dati e le responsabilità dei diversi soggetti dipendono da questa ricostruzione.

Quando un form raccoglie dati sensibili che non avevi chiesto

Nel reclamo già esaminato, il cliente ha allegato un certificato medico a un form che chiedeva soltanto il motivo del reso. L’azienda non aveva previsto di ricevere dati sanitari, ma il documento è ormai nel ticket e potrebbe essere stato inviato anche all’operatore incaricato di rispondere. La comunicazione spontanea dell’utente non sottrae quel dato alla responsabilità dell’azienda. Per gestire la richiesta potrebbero essere sufficienti il prodotto acquistato, la data e la reazione segnalata; il certificato completo può contenere diagnosi, terapie e altre informazioni che l’assistenza non ha motivo di conservare.

Con un sondaggio, questa valutazione deve essere svolta prima della pubblicazione. Chiedere quali prodotti alimentari interessano a una persona non equivale necessariamente a raccogliere dati sulla salute. La situazione cambia se l’azienda domanda quali allergie siano state diagnosticate e utilizza le risposte per creare un segmento nel CRM.

Il principio di minimizzazione interviene in due momenti:

• prima della raccolta, quando si stabiliscono le domande, i campi e gli allegati ammessi;
• dopo la ricezione, quando si decide quali informazioni conservare e quali eliminare.

I campi liberi e la possibilità di caricare documenti richiedono una progettazione attenta, perché consentono all’utente di comunicare molte più informazioni di quelle richieste dall’azienda. Se alcune opzioni predefinite permettono di gestire la richiesta, si può ridurre lo spazio destinato al testo libero. Se gli allegati servono soltanto per determinati reclami, il caricamento può essere mostrato dopo che l’utente ha selezionato il motivo pertinente.

Anche l’avviso inserito accanto al campo deve essere specifico. Una formula generica sui dati personali aiuta poco chi sta descrivendo il proprio caso. È più utile indicare quali informazioni non devono essere inserite e quali documenti occorrono per esaminare la richiesta. L’avviso perde utilità se il form accetta qualsiasi allegato e il ticket rimane visibile a persone che non partecipano alla gestione del reclamo.

Il controllo prosegue dopo l’invio. In un servizio di assistenza gestito tramite chatbot, la conversazione può rimanere nella piattaforma del fornitore, essere trasferita al software usato dagli operatori e generare una nota nel CRM. Lo stesso dato viene così riprodotto in ambienti diversi, con accessi e tempi di conservazione che possono non coincidere.

Applicare la privacy by design richiede di stabilire quali parti della conversazione debbano essere trasferite, se il chatbot possa elaborarle e quali informazioni debbano raggiungere il CRM. Queste scelte devono risultare anche dalle impostazioni dei software, dalle istruzioni date agli operatori e dagli accordi con i fornitori.

Se l’informazione va eliminata, la cancellazione deve raggiungere anche le copie generate dal servizio, nel rispetto dei tempi di conservazione stabiliti.

Chi può vedere i dati nel CRM, nei ticket e nelle cartelle condivise

La password impedisce l’accesso al software da parte di chi non possiede le credenziali. All’interno del sistema, però, sono i permessi a stabilire quali informazioni possa leggere ciascun utente.

Riprendiamo il reclamo accompagnato dal certificato medico. L’operatore incaricato di esaminare la richiesta potrebbe avere bisogno del documento. Il commerciale che riceve automaticamente tutti i nuovi ticket nel CRM non dovrebbe invece visualizzarlo, anche se gli serve accedere al nome del cliente e allo storico degli acquisti.

L’autorizzazione deve corrispondere alle attività affidate alla persona. L’appartenenza a un reparto o l’utilizzo dello stesso CRM non giustificano l’accesso a tutte le informazioni presenti nella scheda del cliente.

Alcuni software permettono soltanto di scegliere tra l’accesso completo alla scheda e la sua esclusione. In una configurazione simile, una nota sanitaria inserita nel CRM diventa visibile anche a chi deve consultarne soltanto i dati commerciali. Prima di caricare il documento, occorre verificare se possa essere separato e conservato in un’area riservata agli operatori che gestiscono il reclamo.

La limitazione deve comprendere anche ciò che esce dal software. Un ticket può essere riservato nel sistema e comparire per intero nell’email inviata a una casella condivisa. Le anteprime delle notifiche, gli allegati scaricati e le esportazioni possono allargare nuovamente l’accesso.

Ogni persona dovrebbe utilizzare credenziali individuali e ricevere istruzioni coerenti con il proprio incarico. Le utenze condivise rendono difficile ricostruire chi abbia consultato, modificato o esportato un documento. Anche i registri delle attività perdono utilità se tutte le operazioni risultano eseguite dallo stesso utente.

L’utenza amministratore deve essere riservata alle operazioni che richiedono quei privilegi. Usarla ogni giorno per gestire ticket o schede clienti espone a persone e funzioni aziendali una quantità di dati superiore a quella necessaria.

Le autorizzazioni vanno aggiornate quando cambiano mansioni e collaborazioni. Un dipendente trasferito a un’altra funzione o un professionista che ha concluso l’incarico non dovrebbe conservare gli accessi precedenti perché nessuno ha modificato la sua utenza.

Quando un fornitore tratta i dati per conto dell’azienda

CRM, helpdesk, servizi cloud e chatbot sono spesso gestiti da fornitori che possono accedere ai dati inseriti dall’azienda o dai suoi utenti. Il contratto può indicarli come responsabili del trattamento, ma la qualifica dipende dalle attività che svolgono e dalle decisioni che assumono sui dati.

Il fornitore opera come responsabile quando utilizza le informazioni per erogare il servizio richiesto dall’azienda e segue le sue istruzioni. Se impiega gli stessi dati per uno scopo proprio, assume un ruolo diverso rispetto a quell’utilizzo. Le linee guida dell’EDPB sui ruoli di titolare e responsabile richiedono di verificare le attività svolte, senza fermarsi alla qualifica riportata nel contratto.

Un fornitore di customer care può conservare le conversazioni per permettere agli operatori dell’azienda di rispondere agli utenti. Se utilizza quelle conversazioni per addestrare un proprio sistema di intelligenza artificiale o sviluppare servizi destinati ad altri clienti, introduce un ulteriore utilizzo che deve essere esaminato separatamente.

Quando il fornitore tratta i dati per conto dell’azienda, la nomina a responsabile del trattamento deve indicare almeno:

• quali attività svolge e per quanto tempo;
• quali dati e persone sono coinvolti;
• quali istruzioni deve rispettare;
• quali misure di sicurezza deve applicare;
• se può affidare alcune attività ad altri fornitori;
• come deve restituire o cancellare i dati alla fine del servizio.

La dicitura “GDPR compliant” pubblicata sul sito del fornitore non dice chi possa leggere i ticket durante l’assistenza tecnica, dove siano conservate le copie o se i contenuti vengano usati per migliorare il prodotto. Le risposte devono risultare dal contratto, dalla documentazione tecnica e dalle impostazioni disponibili nel software.

Per un servizio che può ricevere dati sensibili, occorre verificare anche se sia possibile limitare gli accessi per campo, separare gli allegati dalla scheda commerciale e disattivare l’utilizzo dei contenuti per l’addestramento di sistemi di intelligenza artificiale.

Devono essere individuati anche gli eventuali sub-responsabili e i Paesi dai quali i dati possono essere consultati. La presenza dei server nell’Unione europea non esclude che il supporto tecnico acceda alle informazioni da un Paese terzo. Questa organizzazione può comportare un trasferimento di dati fuori dallo Spazio economico europeo e richiede una verifica specifica.

La scelta del fornitore determina anche quali protezioni l’azienda potrà applicare. Se il CRM non permette di separare un certificato medico dalla scheda commerciale, limitare le copie o cancellare il documento alla scadenza, queste caratteristiche devono essere considerate prima di affidargli i dati.

Registro dei trattamenti, DPIA e DPO: quando sono obbligatori

Un cliente può allegare un certificato medico per chiedere la sospensione di un abbonamento. Una piattaforma di telemedicina può invece raccogliere ogni giorno referti, anamnesi e informazioni sulle terapie di migliaia di pazienti.

In entrambi i casi vengono trattati dati sanitari. Cambiano però il ruolo che questi dati assumono nel servizio, il numero di persone coinvolte e le conseguenze che potrebbe produrre un loro utilizzo scorretto.

Il registro documenta le attività svolte dall’azienda. La DPIA deve precedere i trattamenti che possono comportare un rischio elevato. Il DPO è obbligatorio soltanto quando ricorrono specifiche condizioni.

Il registro riguarda anche le imprese con meno di 250 dipendenti

La soglia dei 250 dipendenti non esonera automaticamente le imprese più piccole. L’esenzione viene meno, tra gli altri casi, quando il trattamento riguarda dati sensibili.

Una società con dodici dipendenti che riceve stabilmente certificati sanitari attraverso un’area riservata deve quindi documentare questa attività. Lo stesso vale per una piattaforma che raccoglie informazioni sulla salute durante la registrazione o permette agli utenti di caricare referti.

Per le organizzazioni con meno di 250 dipendenti, il registro può essere limitato alle attività che rendono obbligatoria la sua tenuta. Lo precisa il Garante nelle FAQ sul registro delle attività di trattamento. Se i dati sanitari compaiono soltanto nella gestione di determinate richieste, l’azienda può descrivere quel processo senza estendere la scheda a operazioni estranee.

La voce “CRM” non descrive un trattamento. Indica soltanto il software utilizzato. La scheda dovrebbe spiegare, per esempio, che il CRM riceve la documentazione sanitaria allegata alle richieste di sospensione dell’abbonamento.

Per quella specifica attività dovranno essere indicati almeno:

• le persone e le categorie di dati coinvolte;
• lo scopo per cui le informazioni vengono utilizzate;
• la condizione che autorizza il trattamento dei dati sensibili;
• chi può accedere ai documenti e quali fornitori li ricevono;
• gli eventuali trasferimenti verso Paesi terzi;
• i tempi di conservazione e le misure di sicurezza adottate.

Il registro deve corrispondere a ciò che accade nei sistemi. Se viene aggiunto un campo al form, cambia il software di assistenza o un nuovo fornitore può accedere agli allegati, la relativa scheda deve essere aggiornata.

Quando serve la DPIA

La presenza di un dato sanitario non rende automaticamente obbligatoria la valutazione d’impatto. Un certificato inviato occasionalmente da un cliente e accessibile a due operatori presenta caratteristiche diverse da un servizio che raccoglie in modo sistematico le informazioni sanitarie di molte persone. Per stabilire se occorre una DPIA bisogna considerare il numero degli interessati, la quantità e la varietà dei dati, la durata del trattamento, l’estensione geografica, le tecnologie utilizzate e le possibili conseguenze per le persone.

La documentazione del Garante sulla DPIA comprende anche i criteri e l’elenco dei trattamenti per i quali la valutazione è richiesta.

In una piattaforma di telemedicina, i dati sanitari sono necessari per permettere il rapporto tra medico e paziente. Il servizio può includere consulti a distanza, condivisione di referti, raccolta dell’anamnesi, prescrizioni e telemonitoraggio. Le informazioni possono inoltre essere consultate da professionisti diversi e attraversare più fornitori tecnologici.

Quando questi trattamenti avvengono su larga scala, la DPIA è obbligatoria. Può essere richiesta anche in presenza di monitoraggio sistematico, decisioni automatizzate o tecnologie che aumentano il rischio per gli interessati.

La valutazione deve essere svolta prima di attivare il trattamento, perché il suo esito può richiedere modifiche al servizio. Potrebbe essere necessario separare gli ambienti, restringere i permessi, ridurre i dati acquisiti oppure impedire che le informazioni sanitarie vengano utilizzate da alcune funzioni del software.

Una DPIA già svolta deve essere riesaminata quando cambiano le modalità di raccolta, le tecnologie impiegate o gli utilizzi dei dati. L’introduzione di un sistema di intelligenza artificiale che analizza referti o conversazioni non può essere assorbita automaticamente nella valutazione relativa alla precedente versione della piattaforma.

Se le misure individuate non riducono il rischio a un livello accettabile, il titolare deve consultare il Garante prima di avviare il trattamento.

Quando deve essere nominato il DPO

La presenza di dati sensibili in azienda non rende sempre obbligatoria la nomina del Data Protection Officer. Una piccola impresa che gestisce alcuni certificati medici dei dipendenti o riceve occasionalmente documenti sanitari dai clienti può svolgere queste operazioni come attività accessorie.

La situazione cambia quando il trattamento su larga scala dei dati sensibili appartiene alle attività principali dell’organizzazione. Una piattaforma che offre consulti medici, percorsi terapeutici o telemonitoraggio utilizza i dati sanitari per erogare il proprio servizio. Se il trattamento raggiunge una larga scala, deve designare il DPO.

Non esiste una soglia numerica valida per tutte le imprese. La valutazione considera:

• il numero di persone interessate;
• il volume e la varietà dei dati;
• la durata del trattamento;
• l’estensione geografica del servizio.

Le FAQ del Garante sul DPO nel settore privato distinguono le attività principali da quelle accessorie e riportano tra gli esempi le organizzazioni che operano nella cura della salute, nella prevenzione e nella diagnostica sanitaria.

L’azienda può nominare un DPO anche quando non è obbligata. Se procede con una designazione formale, deve garantirgli autonomia, accesso alle informazioni e risorse adeguate. La nomina non trasferisce al DPO la responsabilità delle decisioni assunte dall’azienda e non può essere utilizzata come attestazione generica di conformità.

Dove restano le copie dei dati e per quanto tempo

Il certificato medico allegato a un ticket può essere copiato nel CRM, inviato via email, scaricato da un operatore o trasferito in un ambiente di test. Per stabilire quando eliminarlo bisogna ricostruire tutte queste copie e applicare a ciascuna il periodo di conservazione previsto. La cancellazione dalla schermata utilizzata dal cliente non elimina il documento dagli altri sistemi dell’azienda.

La cancellazione riguarda anche email, esportazioni e backup

Il GDPR non stabilisce una durata uguale per tutti i dati. L’articolo 5 impone di conservarli in una forma che permetta di identificare la persona soltanto per il tempo necessario alla finalità del trattamento.

Un certificato inviato per sospendere un abbonamento può servire a gestire la richiesta e, in determinate circostanze, a documentare il rapporto con il cliente. Questo non autorizza a lasciarlo senza scadenza nel CRM o nella casella condivisa dell’assistenza. Il termine deve essere definito in relazione alla ragione per cui il documento viene conservato e alle eventuali norme che richiedono di mantenerlo.

Il periodo individuato deve comparire nel registro dei trattamenti e nell’informativa. La data retention deve poi essere applicata nei sistemi: una scadenza scritta non produce alcun effetto se il software non elimina i dati o se nessuno riceve l’incarico di verificare le copie rimaste.

La procedura deve considerare almeno:

• il database utilizzato dal servizio;
• il CRM e il sistema di ticketing;
• le caselle email e gli allegati scaricati;
• i file esportati per assistenza, analisi o migrazione;
• gli ambienti di sviluppo e di test;
• i backup gestiti internamente o dal provider.

I backup non autorizzano una conservazione indefinita. Se la tecnologia non consente di eliminare subito un singolo file senza compromettere l’integrità della copia, l’azienda deve conoscere il ciclo di sovrascrittura, impedire l’uso ordinario dei dati e stabilire cosa accade in caso di ripristino. Altrimenti un documento già eliminato può ricomparire nel sistema insieme agli altri dati recuperati.

Nel febbraio 2026, l’EDPB ha indicato la cancellazione nei backup e la definizione dei periodi di conservazione tra le difficoltà riscontrate nell’applicazione dell’articolo 17. Il rapporto raccomanda procedure documentate, aggiornate e capaci di assegnare responsabilità precise.

Una richiesta di cancellazione richiede comunque una verifica giuridica. L’articolo 17 del GDPR prevede casi nei quali alcuni dati possono o devono essere conservati, per esempio per adempiere un obbligo legale o difendere un diritto. In questi casi occorre separare le informazioni ancora necessarie da quelle che hanno esaurito la propria funzione. L’articolo LFD sul diritto alla cancellazione dei dati approfondisce condizioni ed eccezioni.

Pseudonimizzare non equivale ad anonimizzare

Sostituire il nome del paziente con un codice permette a un gruppo di lavoro tecnico di analizzare errori o sviluppare una funzione senza vedere gli identificativi diretti. Se l’azienda conserva la tabella che collega il codice alla persona, può comunque ricostruirne l’identità. La tabella deve essere separata e accessibile soltanto a chi ne ha bisogno.

Per l’azienda che può ristabilire il collegamento, i dati pseudonimizzati rimangono dati personali. Continuano quindi a richiedere una finalità, un presupposto giuridico, tempi di conservazione e misure di sicurezza. Devono essere gestiti anche i diritti delle persone interessate.

L’anonimizzazione richiede una valutazione diversa. Eliminare il nome e l’indirizzo email da un archivio non permette, da solo, di considerare anonime le informazioni che rimangono.

Le Linee guida EDPB 02/2026 sull’anonimizzazione chiariscono che il risultato può cambiare a seconda del soggetto che riceve o utilizza i dati. Sono state adottate nel luglio 2026 e rimarranno in consultazione pubblica fino al 30 ottobre 2026: il testo non è ancora definitivo.

Un insieme di dati potrebbe essere anonimo per un destinatario che non dispone di mezzi ragionevolmente utilizzabili per riconoscere le persone. Le stesse informazioni rimangono personali per l’azienda che conserva la tabella di associazione o possiede altri dati che permettono di identificarle.

Per svolgere questa valutazione occorre individuare i soggetti che possono utilizzare i dati e verificare se siano in grado di:

• distinguere il record riferibile a una persona dagli altri;
• collegare informazioni presenti nello stesso archivio o in archivi differenti;
• ricavare attraverso inferenze informazioni riferite a una persona.

Se una di queste operazioni rimane possibile, l’EDPB richiede un ulteriore esame prima di considerare anonimi i dati.

Con le informazioni sanitarie, la rimozione degli identificativi diretti lascia spesso elementi che possono essere combinati. Una patologia poco diffusa, il comune di residenza, l’età e le date delle prestazioni potrebbero consentire di risalire al paziente o di distinguerlo dagli altri interessati.

Prima di qualificare un archivio come anonimo, l’azienda deve quindi documentare chi potrà utilizzarlo, quali altre informazioni siano disponibili e quali mezzi possano essere ragionevolmente impiegati per ristabilire il collegamento. Fino a quando questa valutazione non dimostra il contrario, l’archivio deve essere gestito come contenente dati personali.

Come Legal for Digital verifica l’uso dei dati sensibili nel tuo servizio digitale

Dal 2018 lavoriamo con imprese, SaaS, piattaforme, e-commerce, agenzie e professionisti del digitale. Quando ci occupiamo di dati sensibili, partiamo dal servizio e dagli strumenti attraverso i quali le informazioni vengono raccolte e utilizzate.

Ricostruiamo il percorso dei dati dal form ai software e ai fornitori, verificando chi vi accede e dove rimangono le copie. L’analisi individua anche gli interventi necessari: eliminare un campo, separare gli allegati, restringere i permessi, modificare le istruzioni date a un fornitore oppure svolgere una DPIA prima di attivare una nuova funzione.

Se stai progettando un servizio che utilizza dati sanitari o biometrici, oppure hai scoperto che form, ticket e chatbot stanno già raccogliendo informazioni che non avevi previsto, puoi richiedere il Check Up Privacy di Legal for Digital.

Durante la consulenza analizziamo i dati trattati, il loro percorso, i soggetti che possono accedervi e la documentazione privacy collegata. Avrai indicazioni sugli interventi necessari e sulle parti del servizio che devono essere riesaminate. Il Check Up dura fino a 60 minuti e non comprende la modifica o la redazione dei documenti legali.