Il 2017 \u00e8 l\u2019anno nel quale le aziende hanno iniziato ad implementare le prescrizioni previste dal GDPR.<\/p>\n
Un compito non certo facile vista la complessit\u00e0 e gli impatti di una normativa che richiede interventi di natura tecnica, organizzativa, legale nonch\u00e9 un radicale cambio di mentalit\u00e0 (con conseguente attivit\u00e0 di formazione e sensibilizzazione). Purtroppo la complessit\u00e0 della materia spesso non viene percepita, cos\u00ec come quali siano i reali impatti nei vari ambiti sopra citati. Spesso nelle aziende \u00e8 la funzione IT a prendere l\u2019iniziativa, altre volte \u00e8 la funzione legale, ma in entrambi i casi vi \u00e8 il rischio di una visione molto parziale che si traduce, nel caso in cui siano coinvolti fornitori esterni, in richieste di offerte generiche, mal poste, senza alcun capitolato e senza una conseguente capacit\u00e0 di confronto delle offerte dei diversi fornitori.<\/p>\n
Ovviamente i fornitori di soluzioni tecniche proporranno i loro prodotti come una panacea, gli esperti di sicurezza proporranno qualche schema di certificazione, i legali si limiteranno agli aspetti formali, ma nella realt\u00e0 solo un approccio olistico ed integrato pu\u00f2 portare ad essere pronti nel maggio del 2018.<\/p>\n
Senza la pretesa di essere esaustivo, nel seguito dell\u2019articolo propongo una riflessione quantomeno sui possibili impatti nel mondo IT dell\u2019applicazione del GDPR e sui\u00a0 conseguenti interventi da effettuare.<\/p>\n
Tale esposizione pu\u00f2 anche essere utile per valutare (almeno lato IT) un potenziale fornitore al quale si \u00e8 richiesta una generica offerta di adeguamento al GDPR.<\/p>\n
Troppo spesso per quanto attiene all\u2019IT sento parlare di interventi nell\u2019ambito della sicurezza, dimenticando che ben pi\u00f9 ampia \u00e8 la portata delle richieste del GDPR.<\/p>\n
LA PROTEZIONE FIN DALLA PROGETTAZIONE<\/strong><\/p>\n Assolutamente trasversale a tutto il GDPR \u00e8 l\u2019articolo 25, che richiede espressamente l\u2019adozione di misure organizzative o tecniche, previa valutazione del titolare, quali la PSEUDONIMIZZAZIONE.<\/strong><\/p>\n Protezione dei dati fin dalla progettazione e protezione per impostazione predefinita (C75-C78)<\/strong><\/p>\n Ovviamente il titolare pu\u00f2 valutare altre tipologie di soluzioni, ma \u00e8 certo che oneroso \u00e8 il lavoro di analisi progettuale necessario per individuare le soluzioni che meglio si adattino alle esigenze della singola organizzazione, valutandone nel contempo i relativi impatti economici.<\/p>\n Va precisato che tale analisi dovrebbe spingersi al di l\u00e0 del considerare le comuni misure di sicurezza e dovrebbe portare ad esempio a distinguere fra la lecita accessibilit\u00e0 al dato (determinata da un profilo autorizzativo) ed il legittimo accesso effettuato da un incaricato (determinato dal fatto che l\u2019accesso sia giustificato da una reale finalit\u00e0 del titolare e non gi\u00e0 da un interesse dello stesso incaricato).<\/p>\n Una capacit\u00e0 di analisi quindi che richiede una grande padronanza della materia, ma anche della propria organizzazione e dei propri processi (al riguardo ricordo che uno dei requisiti del DPO \u00e8 proprio la conoscenza specifica del settore nel quale andr\u00e0 ad operare, requisito che vanifica le ambizioni di molti consulenti candidatosi come potenziali DPO per i pi\u00f9 diversi settori).<\/p>\n LE MISURE DI SICUREZZA<\/strong><\/p>\n Quando si parla di GDPR e di IT vengono subito in mente le misure tecniche ed organizzative che un titolare deve mettere in atto al fine di garantire, in base ad una valutazione del titolare, un adeguato livello di sicurezza al trattamento dei dati e che comprendono, in base a quanto previsto dall\u2019articolo 32 – 1:<\/p>\n Gli aspetti da considerare per effettuare tale valutazione sono declinati dall\u2019articolo 32 – 2:<\/p>\n Nel valutare l\u2019adeguato livello di sicurezza, si tiene conto in special modo dei rischi presentati dal trattamento che derivano in particolare dalla distruzione, dalla perdita, dalla modifica, dalla divulgazione non autorizzata o dall\u2019accesso, in modo accidentale o illegale, a dati personali trasmessi, conservati o comunque trattati.<\/em><\/p>\n e nel considerando 83.<\/p>\n Nella valutazione del rischio per la sicurezza dei dati \u00e8 opportuno tenere in considerazione i rischi presentati dal trattamento dei dati personali, come la distruzione accidentale o illegale, la perdita, la modifica, la rivelazione o l’accesso non autorizzati a dati personali trasmessi, conservati o comunque elaborati, che potrebbero cagionare in particolare un danno fisico, materiale o immateriale.<\/em><\/p>\n Quelli citati non sono i soli riferimenti alle misure di sicurezza presenti nel GDPR.<\/p>\n Gi\u00e0 l\u2019articolo 5- 1 f recita infatti:<\/p>\n \u2026<\/em><\/p>\n f ) trattati in maniera da garantire un\u2019adeguata sicurezza dei dati personali, compresa la protezione, mediante misure tecniche e organizzative adeguate, da trattamenti non autorizzati o illeciti e dalla perdita, dalla distruzione o dal danno accidentali (\u00abintegrit\u00e0 e riservatezza\u00bb).<\/em><\/p>\n e il relativo considerando 39:<\/p>\n \u00c8 opportuno adottare tutte le misure ragionevoli affinch\u00e9 i dati personali inesatti siano rettificati o cancellati. I dati personali dovrebbero essere trattati in modo da garantirne un’adeguata sicurezza e riservatezza, anche per impedire l’accesso o l’utilizzo non autorizzato dei dati personali e delle attrezzature impiegate per il trattamento.<\/em><\/p>\n I PRINCIPI<\/strong><\/p>\n L\u2019articolo 5 (Principi) appena citato, prevede altre prescrizioni che hanno rilevanti impatti sui sistemi informativi.<\/p>\n Pur non presentando sostanziali novit\u00e0 rispetto alla normativa vigente, il mancato rispetto di quanto prescritto da questo articolo comporta l\u2019applicazione della sanzione amministrativa pi\u00f9 alta fra quelle previste dal GDPR (l\u2019attuale normativa non prevede viceversa specifiche sanzioni).<\/p>\n Sono in particolare il principio di ESATTEZZA (dati esatti e aggiornati) ed il principio di LIMITAZIONE DELLA CONSERVAZIONE (dati conservati per il tempo strettamente necessario) che hanno un impatto diretto sui sistemi informativi.<\/p>\n Il concetto di dato ESATTO non va confuso e limitato a quello di dati INTEGRO, che costituisce uno dei punti cardini degli aspetti di sicurezza.<\/p>\n Di un dato si pu\u00f2 garantire l\u2019integrit\u00e0 una volta che sia stato caricato sul sistema informativo, ma se questo era sbagliato all\u2019origine avremo un dato integro, ma non esatto. Ne consegue che il rispetto di questo principio rientra in un pi\u00f9 generale processo di gestione della qualit\u00e0 dei dati che parte gi\u00e0 dalla raccolta e caricamento degli stessi sul sistema informativo.<\/p>\n Se infatti qualche dato personale pu\u00f2 essere frutto di elaborazioni o di acquisizione automatizzata, nella maggior parte dei casi vi \u00e8 ancora una originale imputazione manuale dei dati.<\/p>\n Ovviamente la prima parte del processo nulla ha a che fare con il sistema informativo. In fase di raccolta si dovranno prevedere dei controlli che consentano di verificarne la validit\u00e0, ma \u00e8 all\u2019atto del caricamento che il sistema informativo pu\u00f2 essere di aiuto anche nel valutarne la correttezza (si pensi ad un codice fiscale ed all\u2019algoritmo di controllo della sua validit\u00e0).<\/p>\n In questo contesto la esattezza del dato viene garantita se il sistema informativo mette in atto una serie di controlli e facilitazioni per l\u2019incaricato addetto al caricamento del dato stesso (controlli sui campi, facilit\u00e0 d\u2019uso delle applicazioni, verifica di coerenza e completezza dei dati, formazione degli incaricati in merito all\u2019uso delle applicazioni, flussi informativi fra applicazioni che evitino una doppia imputazione dello stesso dato su diversi applicativi\u2026).<\/p>\n Tabella 1 \u2013 I fattori di mitigazione degli errori nel caricamento dei dati<\/strong><\/p>\n \u00a0<\/strong><\/p>\n\n
\n
\n