Nel Regolamento Europeo per la Data Protection, 2016/679 General Data Protection Regulation – GDPR, volgarmente definito “nuova legge Privacy” da molti, l’analisi del rischio privacy ha un ruolo fondamentale: diventa lo strumento atto a dimostrare l’adeguatezza delle misure implementate a tutela dei dati trattati. Soprattutto per le aziende italiane questa è una grande novità in termini di approccio: abituati alle leggi basate su diritto latino, siamo assuefatti da anni a prescrizioni puntuali, alle famose checklist a cui ci aveva abituato, ad esempio, la cosiddetta “Legge Privacy” italiana, il D.lgs. 196/2003. Il GDPR, invece, non indica puntualmente le linee guida per proteggere le informazioni, ma chiede di essere in grado di dimostrare di averle protette in modo adeguato.
Diventa a questo punto molto utile, se non indispensabile, al fine di dimostrare la tanto citata accountability richiesta dal Regolamento (artt. 5, 24), seguire un percorso logico, che dimostri come si sono protette le informazioni gestite e quali rischi corrono gli interessati che autorizzano a trattare i loro dati.
In tutte le organizzazioni dove il Sistema di gestione della sicurezza delle informazioni ha raggiunto un livello minimo di maturità, è presente un documento di analisi dei rischi che viene applicato a processi, applicazioni, classi di informazioni e/o altri asset.
Questi documenti elencano le minacce da cui l’organizzazione intende tutelarsi e come lo fa.
Per raggiungere questo scopo viene innanzitutto definito il risk appetite, vale a dire quanto l’organizzazione è disposta ad esporsi all’impatto del realizzarsi di una minaccia.
Definito il risk appetite viene attribuito ad ogni minaccia il suo grado di probabilità potenziale di realizzarsi e quale è di conseguenza l’impatto che questo rischio avrebbe sull’organizzazione, in termini di riservatezza, integrità e disponibilità. Verificate quali misure sono state adottate per proteggere l’asset oggetto di valutazione, il rischio viene riclassificato, per verificare se l’impatto residuo è accettabile, secondo quanto definito dal risk appetite. Nel caso in cui l’impatto non sia accettabile, va pianificata una strategia tesa a mitigare il rischio, fino a renderlo accettabile [1].
Se l’approccio all’analisi del rischio sopra descritto è in linea con i più diffusi standard e best practice internazionali (es. ISO/IEC 27001:2013, ISO 31000:2009, etc.) il GDPR chiede di fare un passo in più: quello di svolgere l’analisi non nell’ottica del Titolare del trattamento, ma in quella dell’Interessato.
Come procedere quindi, ai fini dell’adeguamento al GDPR?
Innanzi tutto è indispensabile creare il Registro dei trattamenti (art. 30): in questo documento dovrei trovare almeno l’elenco dei trattamenti svolti dal Titolare, i processi a cui afferiscono e gli asset coinvolti nel trattamento oltre a quanto prescritto dal comma 1 dell’art. 30.
A partire da queste informazioni è possibile integrare le analisi del rischio esistenti o crearne una ad-hoc per la Data Protection. Integrandolo con le analisi del rischio precedentemente svolte è possibile utilizzare per gli stessi asset, le stesse minacce, le stesse probabilità ed aggiungere quindi gli impatti specifici, quelli nell’ottica dell’interessato.
Integrare la documentazione esistente, progettare un sistema di gestione integrato è sempre il metodo più efficace ed efficiente per garantire la maggior accuratezza ed il minor effort di gestione, non solo in fase di compilazione, ma soprattutto in fase di mantenimento. Progettare in modo lungimirante il framework di analisi del rischio privacy permette di tener conto di tutte le altre aree di applicazione del GDPR: l’output dell’analisi del rischio diventa indispensabile come input per la Data Protection Impact Analysis, DPIA (art. 35) e per garantire la Privacy by Design (art. 25). Diventa quindi chiara la centralità della valutazione del rischio: arriva ad influenzare la necessità di eventuali consultazioni preventive al Garante (art. 36), influenzando la DPIA.
Particolarmente illuminante il contenuto dell’art. 25, riportato in parte nella figura 4: le misure a tutela del trattamento da attuare dipendono si dal trattamento, ma anche dalle caratteristiche del Titolare. Una multinazionale probabilmente avrà una capacità di spesa che la metterà in grado di accedere a soluzioni di mercato (stato dell’arte) diverse da quelle di una PMI. Per questa ragione misure adottate da una PMI a tutela dei trattamenti potrebbero essere giudicate insufficienti per una multinazionale.
Un errore da evitare con attenzione è il considerare l’analisi dei rischi privacy una attività di esclusiva competenza dei Sistemi Informativi / Dipartimenti IT. L’analisi del rischio, infatti, deve tener conto di tutti i processi ed asset coinvolti nel trattamento, anche quelli non informatici. Tanto dovrò proteggere i database, ad esempio, tanto dovrò proteggere i faldoni ed i locali in cui essi sono conservati.
Un’altra grande differenza rispetto al D.lgs. 196/2003 è la modalità di mantenimento di tale documento. Non c’è più una scadenza di revisione annuale, ma viene richiesto che il documento sia sempre aggiornato. L’analisi dei rischi, come molti altri documenti, va aggiornata ogni volta in cui vengano introdotti nuovi trattamenti o avvengano variazioni sostanziali su quelli in essere. Tra le variazioni sostanziali, evidentemente, rientrano gli asset coinvolti: se cambio lo strumento con cui eseguo il trattamento non potrò aspettare il 31 marzo dell’anno successivo per adeguare la documentazione, ma dovrò tempestivamente valutare se è cambiato il profilo di rischio ed adottare eventuali misure necessarie a garantire il livello di sicurezza adeguato.
Alla luce di quanto esposto diventa chiaro l’incipit di questo breve excursus: definire il GDPR “legge Privacy” è quantomeno riduttivo. Si tratta dei requisiti per la messa in opera di un vero e proprio sistema di gestione della data protection in senso ampio e completo. In questo quadro la “privacy” è un sottoinsieme delle garanzie che è necessario vengano offerte dai Titolari del trattamento. Per questo è più corretto parlare di Data Protection Impact Assessment e non di Privacy Impact Assessment.
Inoltre, nonostante esistano alcune esenzioni rispetto alle attività descritte [2], una organizzazione che voglia tutelare in modo efficace se stessa, il proprio business ed i propri stakeholder, dovrebbe mantenere un sistema efficace di data protection, indipendentemente dai requisiti di legge. Dovrebbe infatti applicarsi lo stesso principio per cui faccio viaggiare mia figlia in auto sul seggiolino adatto e con la cintura allacciata: voglio garantire al massimo la sua incolumità, non evitare una banale multa.
[1] Oltre a mitigare il rischio è possibile anche eliminarlo o trasferirlo, ma la dissertazione di tali tecniche esula dallo scopo del presente contributo
[2] es. il registro dei trattamenti per le “imprese o organizzazioni con meno di 250 dipendenti, a meno che il trattamento che esse effettuano possa presentare un rischio per i diritti e le libertà dell’interessato, il trattamento non sia occasionale o includa il trattamento di categorie particolari di dati di cui all’articolo 9, paragrafo 1, o i dati personali relativi a condanne penali e a reati di cui all’articolo 10”, ex art. 30 comma 5
