Cosa c’entra la Block Chain con il GDPR?
La prima cosa necessaria da capire per affrontare la questione è che la Block Chain (BC) non è il Bitcoin!
Si tratta di una metodologia di “hashing ricorsivo” (riassunto all’osso), che è precedente al Bitcoin, anche se alle monete elettroniche si deve la esplosione di notorietà dell’argomento.
Essenzialmente la BC, che in Italia giustamente da molti viene associata funzionalmente al “libro mastro” mutuato al mondo della contabilità, permette informaticamente una “Notarizzazione“. Lo so, di per sé non è una bella parola, ma tecnologicamente ci sono parole in informatichese che rendono l’idea e anche il senso di cose complesse in modo essenziale.
Mai come in questi tempi, bisogna semplificare le cose ai Titolari del Trattamento! Diversamente non solo non “scuciono” una lira, ma soprattutto non comprendono loro stessi quali scelte corrette fare per le aziende che devono essere in compliance con il Reg.679/16 (il GDPR della UE).
Sono molte le attività che riguardano un Sistema di Privacy e Protezione dei Dati che possono beneficiare della BC. qui citiamo alcuni esempi basandoci non tanto su un ordine di fattibilità, quanto su un ordine di priorità di adempimenti che i TDT dovranno inevitabilmente considerare.
Primo fra tutti certamente il Registro dei Trattamenti (Art.30). Questo pilastro di un Sistema di Protezione dei Dati (SPD), che in questo contesto diamo per conosciuto, è una evidenza documentale (cartacea e/o elettronica) che comprova (Accountability by Design – Artt. 24 e 25) che dopo una Analisi dei Rischi ed eventuale Valutazione degli impatti Privacy, l’Azienda abbia classificato tutti i trattamenti di dati personali in base alle priorità di rischio cosi da individuare e pianificare un Piano di Adeguamento (misure e investimenti) per raggiungere la compliance di cui sopra.
Purtroppo non è recepito correttamente, ma il Registro dei Trattamenti non è una cosa che si fa una volta! Si tratta di un sistema documentale vivo che deve essere manutenuto e sottoposto a controllo di misure organizzative (Procedure, prassi, registrazioni ecc.)
Ecco dove viene utile un meccanismo di BC. Ogni trattamento definito nel Registro, può cambiare in qualunque momento. Non solo in sè e per sè, ma anche semplicemente perché, ad esempio, cambia la tecnologia sw o degli apparati, cambiano le esigenze del cliente che in quel Trattamento è coinvolto, o ancora, e più semplicemente, cambia perché il soggetto autorizzato (ricordiamo che gli incaricati non esistono nel nuovo Regolamento) è stato licenziato.
Per il monitoraggio continuo dello “status” del Registro è indispensabile comprovare sia il time-stamp che la identità digitale del cambiamento e/o modifica. Solo così il Titolare potrà fronteggiare una eventuale ispezione della Autorità di Controllo (Dal 26 Maggio 2018 non esisterà più il Garante Privacy!)
Un’altro ambito estremamente critico per la coerenza di un SPD riguarda quello della gestione dei Log; anche se nella percezione comune questo sembra essere un problema che riguarda solo gli informatici, così non è.
I log traversano molti adempimenti, alcuni completamente nuovi. E’ questo il caso del Data Breach (Art.33). Non si tratta della installazione di un anti-virus e/o un firewall. Solo chi è rimasto alla medioevale e soporifera filosofia del DPS e delle misure minime, può crederlo.
Si tratta di un sistema completo di gestione per la resilienza continua nei confronti degli incidenti informatici. Anche in questo caso non ci sogniamo di dire oltre e rimandiamo agli altri nostri articoli, ma riallacciamo qui la BC che calza perfettamente.
Se la Azienda usa sistemi IDS/IPS o DLP (oltre alle misure procedurali previste dal Regolamento), tutte le attività di alerta e/o contromisure a difesa dei beni societari (non solo dati personali ma anche di business) devono essere “notarizzate” per poter essere valutate Ex Post dal gruppo di gestione degli incidenti. La BC assiste non solo gli informatici ma anche il Responsabile e il Titolare del Trattamento in caso di incidente informatico grazie alla ricostruzione esatta della time-line di tutti gli eventi monitorati dal sistema.
L’adempimento del “Data breach” prescrive che le Autorità di controllo siano informate tempestivamente ed esaurientemente. Occorre quindi, anche in questo caso, poter comprovare l’esattezza della sequemza degli accadimenti in modo terzo, oggettivo e sicuro… Ecco perchè marcare temporalmente (notarizzare) e in modo identificativo univoco i processi sottoposti a controllo, è l’unico sistema per non venir meno agli obblighi legali.
In sintesi abbiamo fatto due esempi di integrazione tra la block-chain e il GDPR, ma solo a scopo di paradigma potremmo considerare anche :
- nomine e designazioni organigramma privacy
- validazione censimenti infrastrutture IT
- validazione verbali di Piani di formazione
- governo proattivo di contromisure legittime su email e navigazione internet
- validazioni contrattuali SLA e PLA con Responsabili Esterni/Contitolari
- Data Transfer Agreements e accordi vincolanti di azienda
E’ chiaro che non si potrà mai avere una Accountability vera senza una tracciabilità vera.
Chi scrive è perfettamente consapevole che questo articolo è diretto a chi il Regolamento deve aiutare ad applicarlo. Le aziende, sia a livello imprenditoriale che di staff non hanno consapevolezza di questo ordine di complessità!
Che dire, buon lavoro e buona privacy con i nostri webinars nel corso multimediale su youtube!
Per chi poi desidera approfondire il tema della Data Protection sul campo segnaliamo anche il primo sforzo editoriale pubblicato di un Fac Simile elettronico di un Manuale di Sistema Privacy cosi come reso fruibile via web Intralan aziendale
Salvo Reina
Privacy 4.0 e Data Protection 