Data breach via PEC con dati sanitari e IBAN
Il 12 maggio 2024, alle ore 9:00, un operatore della sede INPS di Bologna invia con PEC un file Excel non protetto a un CAF, invece che all'ufficio competente. Il file contiene 1.200 posizioni: codice fiscale, data di nascita, IBAN, importo del trattamento e, per 180 persone, la patologia indicata nella domanda di invalidità. L'errore viene scoperto dal CAF il 13 maggio 2024 alle ore 15:00, che lo segnala subito alla sede. Il file era già stato scaricato su due postazioni del CAF. La sede ha un RPD/DPO, un registro dei trattamenti e una procedura interna di gestione degli incidenti, ma non aveva previsto la cifratura dei file inviati via PEC. L'operatore aveva accesso a tutte le pratiche della sede.
1. Come va qualificato l'evento e quali notifiche vanno effettuate, a chi e entro quali termini?
Read the worked answer
Si tratta di un data breach ex art. 4, punto 12, GDPR: accesso e diffusione non autorizzati di dati personali, compresi dati relativi alla salute e IBAN, con rischio elevato per gli interessati.
Adempimenti:
- Notifica al Garante ex art. 33 GDPR, senza ingiustificato ritardo ed entro 72 ore dal momento in cui il titolare ne viene a conoscenza. Se la conoscenza si colloca il 13 maggio alle 15:00, il termine scade il 16 maggio alle 15:00.
- Contenuto: natura del breach, categorie e numero di interessati, dati del DPO, conseguenze probabili, misure adottate e proposte.
- Comunicazione agli interessati ex art. 34 se il rischio è elevato: qui è probabilmente dovuta per i 180 soggetti con dati sanitari e per i titolari di IBAN.
- Coinvolgimento del RPD/DPO e documentazione dell'incidente anche se la notifica non fosse dovuta.
Il CAF, se responsabile del trattamento ex art. 28, deve informare senza ritardo il titolare. La notifica al solo DPO non sostituisce quella al Garante.
2. Quali misure tecniche e organizzative avrebbero ridotto il rischio e quali responsabilità emergono?
Read the worked answer
Misure minime ex art. 32 GDPR:
- cifratura dei file in transito e a riposo, con password comunicata su canale separato;
- minimizzazione: inviare solo i dati necessari e, se possibile, oscurare IBAN e diagnosi;
- controllo degli accessi secondo il principio del bisogno di sapere: l'operatore non doveva vedere tutte le pratiche;
- log e monitoraggio degli invii, con alert su destinatari anomali;
- procedure di verifica del destinatario prima dell'invio PEC;
- formazione periodica e simulazioni di incidente.
Responsabilità:
- verso il Garante: sanzione amministrativa e possibili prescrizioni;
- verso gli interessati: risarcimento se provano il danno;
- interna: procedimento disciplinare per violazione delle istruzioni e delle misure di sicurezza;
- verso il CAF: verifica dell'accordo ex art. 28 e delle istruzioni impartite.
La procedura interna esisteva ma non era operativa: l'accountability richiede misure effettive, non solo documenti.
3. Se il file fosse stato cifrato con una password inviata su un canale separato, la valutazione del rischio cambierebbe? Argomentare.
Read the worked answer
Sì, cambierebbe sensibilmente. La cifratura robusta riduce la probabilità che il destinatario errato o un terzo possa leggere i dati: il rischio residuo dipende dalla forza della chiave, dalla separazione dei canali e dalla possibilità che la password sia stata intercettata.
Valutazione:
- se il file è cifrato e la password è trasmessa con un canale diverso e sicuro, il breach può avere rischio non elevato e la comunicazione agli interessati ex art. 34 può non essere necessaria;
- la notifica al Garante ex art. 33 resta dovuta se sussiste un rischio per i diritti e le libertà, anche non elevato; la cifratura non elimina automaticamente l'obbligo, ma ne riduce l'urgenza e il perimetro;
- se la password viaggia nella stessa PEC o è banale, la misura è inefficace e il rischio resta alto.
La decisione va documentata nel registro degli incidenti, con la valutazione del rischio e le ragioni della mancata notifica o comunicazione.