Il considerando 88 del GDPR richiede almeno una procedura per la notifica della violazione dei dati personali. Tale richiesta, in una logica sistemica, deve considerare da un lato tutto il processo di gestione di un evento di Data Breach e non solo la gestione del singolo evento, e dall’altro non solo le situazioni di Data Breach ma anche quelle di potenziale evento che mina la sicurezza delle informazioni.A tal riguardo è evidente, anche alla luce delle definizioni, che gli eventi che minano o potenzialmente potrebbero minare la sicurezza delle informazioni, formano un insieme ben più ampio di quelli considerati come Data Breach, in altri termini un Data Breach è un particolare tipo di evento sulla sicurezza delle informazioni.

La maggior parte delle procedure disponibili sul Data Breach tratta, spesso in modo egregio, del singolo evento. Ovvero documenta: tempi, modalità e responsabilità per la gestione di un evento di Data Breach tenendo conto del già citato considerando 88.

Per quanto tale approccio sia ineccepibile, esso non soddisfa appieno una corretta gestione dell’evento; il Titolare ed il DPO (quanto presente) dovrebbero richiedere diverse integrazioni a tale procedura.

Da questo punto di vista la ISO/IEC 27001:2013 attraverso il set di controlli A 16 “Gestione degli incidenti sulla sicurezza delle informazioni” – si vedano anche i controlli da 5.24 a 5.28 e 6.8 della ISO/IEC 27002:2022, richiede un approccio ben più articolato da cui poter trarre agevolmente spunto per il miglioramento della procedura in questione.

Ad esempio al controllo A.16.1.3 richiede la “Segnalazione dei punti di debolezza relativi alla sicurezza delle informazioni” (nella ISO/IEC 27002:2022 controllo 6.8) o il controllo A.16.1.6 “Apprendimento dagli incidenti relativi alla sicurezza delle informazioni (nella ISO/IEC 27002:2022 controllo 5.27). Si tratta di due controlli che impongono un approccio proattivo e non meramente correttivo.

D’altra parte, come ovvio, la procedura richiesta dal GDPR prevede (considerando 88) che siano tenuti in debito conto, anche nelle fasi di indagine, i legittimi interessi delle autorità incaricate dell’applicazione della legge; questo aspetto, peraltro, non è assolutamente considerato dalla ISO/IEC 27001. Così come (considerando 86) nella medesima procedura deve essere valutata la contrapposizione tra i tempi di comunicazione all’interessato, che devono essere il più possibile anticipati, e la necessità di ritardare la comunicazione agli stessi per contrastare gli effetti della violazione. In altri termini un mix tra i requisiti del GDPR e quelli della ISO/IEC 27001:2022 migliora la qualità della procedura.

La logica PDCA applicata alla procedura sul Data Breach – Alla luce di quanto sopra, non va inteso che il GDPR, rispetto alla ISO/IEC 27001, sottovaluti gli eventi di Data Breach, a cui dedica ben 2 articoli e diversi considerando. Piuttosto, considera la valutazione dei singoli eventi, ma non richiede necessariamente una gestione di carattere preventivo. Per tale motivo, la maggiore parte delle procedure relative al Data Breach, come già indicato, trattano dell’evento in quanto tale e trascurano un approccio basato sul modello PDCA (Plan Do Check Act), che prevede un approccio maggiormente reattivo e quindi i seguenti aspetti:

– Plan alla pianificazione – le azioni da mettere in atto per gestire al meglio l’evento, se e come si presenterà;
– Check al controllo – per valutare la messa in atto di azioni volte a prevenire il ripetersi del singolo evento (azioni correttive);
– Act alla standardizzazione – per valutare l’efficacia dell’intero processo di gestione degli eventi di Data Breach (ad esempio nell’arco di un periodo, come un anno) e definire eventuali azioni per migliorarlo.

Ovviamente la fase “do” è assorbita dalla gestione dell’evento di Data Breach.

Un esempio può aiutare a comprendere – Una procedura sul Data Breach strutturata secondo tale logica, ovviamente in una realtà complessa, dovrebbe prevedere, indipendentemente dal singolo evento:

– Plan – incontri regolari del team per analizzare indicatori o altri segnali che potrebbero far presagire una situazione anche potenzialmente critica ed allenare il team, attraverso incontri periodici, a lavorare in modo sinergico, per essere più coeso nel corso della fase critica di gestione di un evento;
– Check – a valle di un evento valutare l’efficacia delle azioni poste in atto per la risoluzione dello stesso, ma considerare anche la presa in carico delle azioni (tempi, modi, responsabilità, budget) volte ad evitare che l’evento si ripeta (azione correttiva), anche ricorrendo ancora una volta alla misura degli indicatori;
– Act – incontri del team per analizzare l’intero processo della gestione dei Data Breach (ad esempio approfondendo la modalità di gestione di quelli occorsi negli ultimi 6/12 mesi), e valutare se è necessario apportare modifiche al processo, da sperimentare e documentare successivamente.

Audit – Infine non va dimenticato che, trattandosi di una procedura, la stessa dovrebbe essere, ad intervalli:

– oggetto di revisione per valutare che sia adeguata ed efficace e se del caso rivista e modificata;
– oggetto di verifica per valutare che sia correttamente applicata

Nell’ambito dell’attività di audit, sia di conformità legislativa che di sistema di gestione, tale aspetto deve essere considerato, così come nell’ambito di audit di seconda parte ai Responsabili del trattamento, qualora la modalità di gestione di tale evento non sia, come dovrebbe essere (almeno nei tempi e modi della comunicazione), già regolamentata nell’atto di designazione a Responsabile.

Conclusioni – Approcciare la gestione del Data Breach e documentarla attraverso una procedura, con un modello che tragga spunto dai sistemi di gestione ISO/IEC 27001:2013 , ovvero dalla logica PDCA, può essere con certezza considerata una misura di accountability. infatti le differenze che emergono nelle definizioni di un evento avverso possono suggerire diversi spunti di miglioramento su cui riflettere, al fine di affinare costantemente tale strumento come espressamente richiesto dal GDPR e come evidenza dell’applicazione dell’accountability..