Dal primo settembre 2023 è in vigore in Svizzera la nuova legge federale sulla protezione dei dati (nLPD). Come già noto, genera un rafforzamento della protezione dei dati in Svizzera, sia per allinearsi all’evoluzione sociale e tecnologica imposta dalla crescita dei servizi Internet, sia verso il GDPR europeo, per acquisire una decisione di adeguatezza (GDPR art.45) e consentire un più semplice trasferimento dati tra i due spazi economici.
Nella pratica, per le aziende che hanno già confidenza con il GDPR, il passo per giungere alla conformità è veramente breve vista la forte somiglianza tra le due leggi. Non ci sono ostacoli a far convivere l’approccio usato nel GDPR con i requisiti della nLPD. Si può seguire passo a passo la sequenza degli articoli della legge, implementando di volta in volta quanto richiesto, ma se dovesse sembrare troppo burocratico, c’è un altro modo di raggiungere la conformità. Quello di procedere all’inverso pensando di elencare le azioni che la legge si aspettava ma che risultano mancanti o che non hanno funzionato e causato l’incidente.
Supponiamo sia accaduto un data breach e proviamo a chiederci cosa avrebbe dovuto essere fatto preventivamente per evitarlo o contenerlo secondo i requisiti dell’information security, nonché quelli legati alla legge, sia essa europea o svizzera. L’analisi a ritroso è più coinvolgente, perché mette immediatamente in luce l’obiettivo finale della legge stessa, il motivo per cui si devono approntare azioni adeguate, ossia la protezione dei dati personali dell’individuo (GDPR e nLPD, art.1). Quindi, dalla compromissione ripercorriamo all’indietro le tappe che servono a costruire il sistema di protezione.
Indice degli argomenti
Come affrontare un data breach con l’nLPD e il GDPR
Tra GDPR e nLPD, le fasi della notifica sono formalmente diverse ma non nella sostanza. Nel GDPR (art.33), in caso di violazione si informa l’Autorità di controllo, senza ingiustificato ritardo, entro le 72 ore e solo nel caso ci possano essere effetti significativi sugli individui interessati. Nell’LPD (art.24) si deve, quanto prima, informare l’incaricato federale della protezione dei dati e della trasparenza (IFPDT) se ne risulta presumibilmente un elevato rischio per le persone interessate.
Perciò, dobbiamo avere almeno una procedura che definisce le responsabilità interne all’azienda per decidere se notificare o meno, e come farlo. Il primo passo sono i concetti di “rischio elevato” (nLDP) ed “effetti significativi” (GDPR) che dobbiamo riuscire a capire e gestire. Sono legati tra loro in modo lineare (il rischio è una combinazione di probabilità ed impatto) e quindi nella sostanza dobbiamo essere in grado di sviluppare una valutazione di rischio. Le metodologie di risk management ci danno tutte le informazioni che ci servono per individuare gli oggetti necessari allo sviluppo di un piano di trattamento del rischio, mantenendo però una focalizzazione sui requisiti legali da considerare nel valutare l’impatto sull’interessato.
Servono, non solo procedure ma anche mezzi, come la tenuta di un registro di tutte le violazioni e non solo quelle significative per la notifica. Tutto questo ci viene comunque richiesto dall’information security. La ragione è quella di essere in grado di poter analizzare le situazioni anomale accadute (“lesson learnt“) con lo scopo di migliorare il sistema di protezione. Il registro è una delle sorgenti di determinazione delle minacce e vulnerabilità necessarie a creare lo scenario di rischio.
La valutazione del rischio nell’nLPD e nel GDPR
Le azioni che vengono intraprese per rafforzare la sicurezza informatica sono incluse nel piano di trattamento del rischio (RTP) durante la selezione di una risposta adeguata al livello di rischio valutato. L’RTP è sia uno strumento di sintesi delle valutazioni di rischio che di controllo d’insieme dello stato di avanzamento delle attività collegate alla mitigazione del rischio. Questo documento, come menzionato, è il risultato della valutazione del rischio, che inizia con l’identificazione del rischio stesso tramite lo scenario del rischio dove, oltre alle minacce, entrano in gioco gli asset coinvolti. Nella preparazione della lista degli asset organizzativi, rilevanti per il business, vanno inclusi anche quelli relativi alla privacy. È facile recuperarli perché sono nel registro dei trattamenti (GDPR art.30, nLPD art.12).
Ogni asset è ben definito, non solo in termini di operatività e classificazione, ma anche con l’attribuzione delle responsabilità. Il registro dei trattamenti potrebbe essere integrato nella lista degli asset organizzativi, ma mantenerlo a parte è più pratico per focalizzarlo sulla conformità legale con uno specifico dettaglio. Nel registro degli asset organizzativi si riportano solo alcune categorie per semplificare l’analisi riducendo il numero di asset da considerare. Continuando a seguire la strada tracciata dall’information security, indipendentemente dal framework di sicurezza adottato, troviamo un costante parallelismo, ma anche sovrapposizione, con le attività richieste dalla privacy.
Organizzazione del sistema
Risulta evidente che la gestione della privacy non è una singola attività ma un sistema che integra relazioni con tutti i processi aziendali che trattano dati. Significa dover creare un’organizzazione specifica di gestione privacy, in completa relazione con il sistema di protezione delle informazioni. Sia il GDPR con le misura di sicurezza (art.32), che la nLPD con i requisiti minimi di sicurezza (art.8), ci portano in questa direzione. Anziché aspettare di affrontare le conseguenze di un data breach, dobbiamo preoccuparci di adottare tutte le misure necessarie alla protezione delle informazioni e questo implica l’aver definito i corretti ruoli organizzativi, di coordinamento e controllo del sistema, secondo ogni prospettiva ed esigenza di sicurezza.
L’information security designa a questo compito la figura del CISO (Chief Information Security Officer) per progettare e coordinare il sistema, nonché controllare e valutare il raggiungimento degli obiettivi assegnati. Non manca neppure il supporto consulenziale svolto verso i responsabili dei processi interni per migliorare la protezione dei dati classificati e trattati dall’azienda. È in assonanza con i compiti attribuiti alla relativa figura prevista nella regolamentazione privacy, il data protection officer del GDPR (DPO, art.37-39) o il Consulente per la protezione dei dati della nLPD (art.10). Il termine usato da nLPD suona meglio della traduzione dell’acronimo DPO nel GDPR ossia “Responsabile della protezione dei dati”. Questa figura (GDPR, art.39) deve “informare e fornire consulenza al titolare del trattamento” o ad altri “che eseguono il trattamento in merito agli obblighi derivanti dal presente regolamento”. Ma anche sorvegliarne l’applicazione o fornire un parere in merito alla valutazione d’impatto o essere un punto di contatto per le tematiche di sicurezza. Tutte attività che non sono estranee al CISO e vien da chiedersi se non sia questa la figura più idonea a ricoprire tale ruolo di legge sulla privacy.
Security by design e default
I principi di sicurezza, ai cui termini siamo oramai abituati, come confidentiality, integrity, availability, authentication, accountability, nonrepudiation, least privilege, need-to-know, clean desk e altri ancora, trovano il loro percorso di applicazione nel security by design e by default. Sono anche riproposti nei concetti del “data protection by design and by default” (GDPR art.25) o della “protezione dei dati personali sin dalla progettazione e per impostazione predefinita” (nLPD art.7).
Fondamentale è l’efficacia della protezione dei dati garantita all’interessato, che si attua implementando le misure proposte dai framework internazionali di sicurezza, giustificate dalla risk analysis e verificando costantemente la maturità dei controlli sugli obiettivi di contenimento del rischio. Quest’ultimi ovviamente si intendono inclusivi anche dei requisiti della privacy. Gli articoli di legge sulle misure di sicurezza sintetizzano in modo generale i risultati attesi o desiderati dal sistema di protezione. In tal modo non è necessario rivedere il testo di legge a ogni evoluzione tecnologica ma, per questo compito di aggiornamento progressivo, si rimanda agli aggiornamenti degli standard e dei framework adottati.
Il percorso di conformità alla legge sulla privacy è semplice da attuarsi vista l’esposizione estremamente lineare della legge, orientata ai principi di una protezione definita con logica e non burocratica, piuttosto che limitarsi ad elencare delle misure tecniche da realizzare obbligatoriamente, con il risultato che in un breve tempo rischiano di divenire obsolete. Queste leggi preferiscono responsabilizzare il titolare nell’identificare la soluzione più adeguata al suo contesto operativo. L’assenza di imposizione di misura tecniche da implementare lascia maggior libertà al titolare e consente la giusta flessibilità operativa per migliorare ciclicamente il sistema, tramite la valutazione del rischio, per fronteggiare l’evolvere della tecnologia e le vulnerabilità nell’implementazione. In questo modo, avendo una privacy risk-based, anche i costi sono ottimizzati sul modello di business perché le metodologie di risk management considerano anche questo aspetto.
Gestione degli incidenti
Evitare il data breach è un obiettivo insito in entrambe le leggi. Per poter “capire” quando siamo in presenza di un “elevato rischio per le persone interessate”, dobbiamo aver predisposto preventivamente un metodo per avere la capacità di valutare il livello di rischio, e organizzato un set di procedure, sia per la gestione dell’emergenza (attenuazione dell’impatto) che della capacità di ripristinare delle condizioni di funzionamento accettabili per il business e per gli interessati.
Nel caso di obbligo di notifica, non deve essere vista come il primo passo verso una sanzione e quindi da nascondere se possibile, quanto il giusto percorso per accrescere la conoscenza comune verso uno specifico scenario di rischio e consentire a tutti (anche esterni) di apportare le opportune correzioni ai propri sistemi per perseguire la protezione dei dati. La notifica segue l’idea di rendere noto un fatto importante, anche se negativo, a chiunque abbia un interesse per creare una conoscenza condivisa e permettere una adeguata reazione al ripetersi dell’evento. A livello di legge non è una novità condividere la narrazione di un incidente. È già comparsa varie volte ed anche da diverso tempo, ad esempio, nel 2013 con l’Executive Order 13636: Improving Critical Infrastructure Cybersecurity, una pietra miliare della cybersecurity. Il senso della “notifica” di incidenti e quindi di relative nuove minacce è quello di coinvolgere chi è in grado di poter predisporre nuovi sistemi di contrasto da esse, e conseguentemente rendere patrimonio comune la soluzione.
Obbligatorietà o opzione
Di proposito sono state ommesse tutte le considerazioni sulle eccezioni o sulla non obbligatorietà ad adempiere a talune regole, sia GDPR che nLPD, perché quando parliamo di sicurezza, la bussola da seguire è solo l’analisi del rischio. Anche se la legge concede l’opzione di non aderire ad una certa regola, è più prudente valutare il rischio del non fare ed i costi del fare, prima di scegliere la via apparentemente più breve del fare solo se obbligatorio.
Il mescolare l’information security con i requisiti delle due leggi sulla privacy, ha lo scopo di enfatizzare i punti di contatto che significa, sinergie, miglior qualità ed equo costo. Il trattamento deve essere rispettoso del valore del dato (GDPR art.5, nLPD art.6) e “ogni misura dovrebbe essere appropriata, necessaria e proporzionata” (GDPR, recital 129) al rischio di mancare la conformità. Anche se la forma delle due leggi è diversa, fortunatamente sono sovrapponibili come requisiti operativi per le aziende e comunque, coerenti con i requisiti dell’information security.
@RIPRODUZIONE RISERVATA
