Un database può essere protetto dagli accessi esterni e contenere comunque informazioni che non avrebbe dovuto ricevere. È una possibilità che merita attenzione: per valutare la sicurezza bisogna osservare anche come i dati vengono raccolti, trasformati e trasferiti. Il caso IQVIA rende questo passaggio particolarmente concreto.

Quando l’anonimato dichiarato non basta

Nel comunicato del 2 ottobre, il Garante descrive una banca dati alimentata da circa 800 medici di medicina generale e utilizzata per studi commissionati anche da aziende farmaceutiche.

IQVIA sosteneva che le informazioni fossero anonime. L’Autorità ha concluso diversamente: il codice associato a ciascun paziente permetteva di seguirlo nel tempo. Combinato con informazioni dettagliate su salute, anno di nascita, sesso e localizzazione, rendeva possibile la reidentificazione con mezzi ragionevoli.

La sanzione riguarda anche altri aspetti, tra cui base giuridica, informativa, conservazione, valutazione d’impatto e misure di sicurezza. Ridurre tutto a un errore software sarebbe quindi fuorviante.

Il punto debole nei campi liberi

Un passaggio del provvedimento completo aiuta a capire il problema operativo. Nella violazione notificata dalla società, alcuni medici avevano inserito informazioni identificative nei campi a testo libero. Il processo previsto prima della trasmissione non le aveva eliminate. Nomi, codici fiscali e recapiti erano così confluiti nelle estrazioni.

Occorre distinguere i numeri: circa un milione di pazienti è la dimensione della banca dati ritenuta non anonima. I 3.370 pazienti riguardano invece gli identificativi diretti presenti nella violazione notificata. Le fonti non descrivono il furto dell’intero archivio da parte di attaccanti.

La lezione per chi gestisce dati è semplice: un controllo deve reggere anche quando l’utilizzo reale si discosta da quello previsto.

Dalla procedura alle evidenze

Per un’azienda, verificare un controllo significa tradurre una promessa in una prova osservabile. Se un filtro deve rimuovere informazioni personali, va testato anche con dati inattesi. Se un accesso deve essere limitato, bisogna controllare quali operazioni consenta davvero.

Assessment e test mirati aiutano a individuare queste distanze. Un penetration test verifica la resistenza di applicazioni e infrastrutture attraverso una simulazione autorizzata; anonimizzazione e flussi informativi richiedono verifiche specifiche, insieme alle competenze privacy.

La domanda utile per la direzione diventa: quando abbiamo verificato questo controllo, con quali scenari e con quale risultato?

Verificare oggi, presidiare ciò che cambia

Dopo una verifica, l’ambiente continua a evolvere: cambiano utenti, software, configurazioni e collegamenti tra sistemi. Le evidenze raccolte devono quindi tradursi in correzioni, verifiche successive e monitoraggio.

ARGUS — Managed Security Operations Center by Redaxer affianca questo percorso con monitoraggio dell’infrastruttura, rilevamento degli eventi di sicurezza, allarmi, reportistica e supporto alla risposta iniziale. Le verifiche sull’anonimizzazione restano un’attività specifica; il presidio gestito offre visibilità su ciò che accade nei sistemi nel tempo.

Per chi dirige un’azienda, il passo concreto è individuare i controlli più importanti, chiedere evidenze del loro funzionamento e definire chi seguirà le anomalie.

Fonti e riferimenti