Il quadro della situazione.
Nei precedenti articoli, dopo una visione delle problematiche di sicurezza, diretta ed indiretta, legate agli strumenti IT, abbiamo focalizzato l’attenzione sul regolamento europeo GDPR (General Data Protection Regulation), soprannominato anche “Gran Decreto Privacy”, e sulle sue conseguenze rispetto alla progettazione di nuovi servizi IT per il trattamento dati.
In questo articolo concentriamo l’attenzione su alcune delle richieste che il GDPR pone per i trattamenti dei dati in essere, specialmente per le persone che li svolgono usando gli appositi servizi IT:
la sicurezza dei dati;
il principio di responsabilità (accountability).
Sicurezza che non vale solo per i trattamenti nuovi, progettati dopo il maggio 2018, ma per tutti i trattamenti di dati personali in essere presso un’azienda od organizzazione.
L’obbligo della sicurezza.
In particolare partiamo dall’articolo 32 del GDPR, il cui paragrafo 1 afferma: “Tenendo conto dello stato dell’arte e dei costi di attuazione, nonché della natura, dell’oggetto, del contesto e delle finalità del trattamento, come anche del rischio di varia probabilità e gravità per i diritti e le libertà delle persone fisiche, il titolare del trattamento e il responsabile del trattamento mettono in atto misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio…”
Cosa significa in pratica questo? Che:
- Occorre una adeguata analisi del rischio, che presuppone la conoscenza
- dei trattamenti in essere,
- delle loro finalità,
- di chi li svolge (e con quale ruolo),
- di quali strumenti e servizi IT sono usati per tali trattamenti.
- L’analisi del rischio deve portare a determinare probabilità e impatto dei rischi che incombono rispetto ai diritti e le libertà delle persone.
- Devono essere predisposte le adeguate contromisure e quindi, per ogni singolo trattamento, sempre dall’articolo 32:
- “la capacità di assicurare su base permanente la riservatezza, l’integrità, la disponibilità e la resilienza dei sistemi e dei servizi di trattamento”;
- “la capacità di ripristinare tempestivamente la disponibilità e l’accesso dei dati personali in caso di incidente fisico o tecnico”;
- “una procedura per testare, verificare e valutare regolarmente l’efficacia delle misure tecniche e organizzative al fine di garantire la sicurezza del trattamento”.
Inoltre, per le aziende con più di 250 dipendenti o in cui i trattamenti sono a rischio per i diritti degli interessati, come ad esempio commercialisti, studi di medicina del lavoro, assicurazioni e altri, vale anche l’obbligo di realizzare un registro dei trattamenti contenente informazioni come:
- “il nome e i dati di contatto del titolare del trattamento e, ove applicabile, del contitolare del trattamento, del rappresentante del titolare del trattamento e del responsabile della protezione dei dati”;
- “le finalità del trattamento”;
- “una descrizione delle categorie di interessati e delle categorie di dati personali”.
Una serie di informazioni, dunque, che completano quanto visto prima. L’articolo 30 del GDPR, che definisce tale registro, prosegue elencando altre informazioni, tra cui:
- “ove possibile, i termini ultimi previsti per la cancellazione delle diverse categorie di dati”;
- “ove possibile, una descrizione generale delle misure di sicurezza tecniche e organizzative di cui all’articolo 32, paragrafo 1” riallacciandosi, quindi, a quanto abbiamo visto sopra.
Le conseguenze.
Un’azienda deve:
Conoscere obbligatoriamente i trattamenti dei dati al proprio interno.
Poter fare un’analisi del rischio (descritta nell’articolo precedente) per ciascun trattamento e prendere le eventuali contromisure adeguate.
Ovvero l’azienda deve conoscere bene sè stessa ed i processi entro cui avvengono i trattamenti dei dati. Il lavoro per realizzare una base di conoscenza che consenta questo è ampio e non può essere visto semplicemente come un mero adempimento ad un obbligo di legge. Va visto come un investimento per migliorare la propria efficienza e la propria robustezza.
Infatti, combinando insieme il tutto, osserviamo che:
- Conoscere i processi (e le attività interne ad essi) in cui avvengono i trattamenti significa avere una mappa dei processi conforme alla ISO9001 e avere coincidenza fra quanto è scritto e quanto si fa;
- Conoscere i trattamenti e le loro finalità di business significa conoscere il valore che i trattamenti hanno per l’azienda;
- Conoscere la base giuridica significa avere consapevolezza delle leggi e avere i documenti legali (contratti, consensi informati) associati ai trattamenti;
- Conoscere le categorie di dati trattati e gli interessati e definire i termini di conservazione dei dati stessi significa conoscere in modo preciso l’uso operativo dei dati;
- Conoscere i referenti interni e chi tratta i dati significa avere stabilito una catena di responsabilità entro l’organigramma (come previsto dagli standard sui processi come ISO15504);
- Conoscere i referenti esterni significa avere un legame tra la mappa dei fornitori ed i servizi di trattamento che questi offrono (condizione obbligatoria nelle buone pratiche di ITIL e di altri framework per la gestione dell’IT);
- Conoscere le categorie di destinatari dei dati significa conoscere i flussi di dati che partono dall’azienda, sia interni, sia oltre i confini dell’Unione Europea;
- Conoscere le modalità di trattamento dei dati significa conoscere gli strumenti tecnici (applicativi, servizi IT, interni ed esterni all’azienda) che vengono utilizzati per trattare i dati stessi; in questo caso avviene quindi una integrazione con il catalogo dei servizi previsto dagli standard come ITIL;
- Conoscere le misure di sicurezza significa avere sotto controllo la sicurezza dell’azienda e poter dimostrare di avere preso le misure idonee a ridurre al minimo i rischi.
Appare evidente da tutto questo come il GDPR è conforme (o, per meglio dire, ispirato) alle buone pratiche di framework internazionali come ITIL, COBIT e PMBoK e agli standard di sicurezza (ISO27001), di gestione del rischio (ISO 31000) e della privacy (ISO 29000).
Un esperto di normative ha definito il GDPR come “una normativa ISO imposta per legge e che trasuda ISO da tutte le parti”.
Un esempio operativo.
Con riferimento all’esempio dello scorso articolo sull’archivio clienti, supponiamo che tale archivio esista già. Come possiamo applicare i punti sopra descritti?
Nella figura è descritto in modo molto semplificato l’uso del catalogo dei servizi ITIL, con una mappa ispirata alla architettura enterprise di TOGAF, applicato all’esempio corrente.
- Il cliente ha bisogno di un servizio di assistenza ed interpella l’ufficio clienti attraverso una mail, una telefonata o l’apertura di una richiesta (ticket) su un portale Web di assistenza.
- L’ufficio clienti a sua volta ha bisogno, per poter esaudire la richiesta del cliente, di agire sulla scheda cliente (insieme di dati personali ed altro), contenuta nel servizio IT CRM.
- Il Servizio CRM è composto dall’applicazione software (applicativo) CRM che, per funzionare, necessita della postazione di lavoro (tipicamente il PC) che l’impiegato dell’ufficio clienti usa e, a livello più tecnico, del database, ossia lo strumento IT che contiene i dati;
- Il database opera entro un server ed utilizza un sistema di storage, ossia memorizzazione permanente; senza tali componenti non potrebbe operare ed i dati non sarebbero disponibili (violazione dell’articolo 32 e dei diritti del cliente);
- Sia la postazione di lavoro, sia il server hanno bisogno della rete per comunicare fra loro; quindi entrambi dipendono dalla rete, come indicato dalle frecce;
- Il buon funzionamento di tutte le componenti è garantito dai servizi di assistenza e supporto.
Seguendo lo schema possiamo farci alcune domande relative alla sicurezza:
- L’impiegato è adeguatamente addestrato per compiere tutte le operazioni che il ruolo di assistenza cliente richiede?
- Come l’impiegato accede al servizio IT CRM? Che tipo di credenziali sono utilizzate? Sono mantenute al sicuro? Quanto frequentemente sono cambiate?
- Qualora l’impiegato sia in ferie o in malattia il sostituto può svolgere il suo compito senza conoscere le sue credenziali, ma con altre credenziali che lo identifichino univocamente?
- Qualora l’impiegato stampi una scheda cliente contenente dei dati personali, esiste una procedura per minimizzare il rischio di accesso non autorizzato a questa stampa? Ad esempio, viene tenuta sotto chiave o in bella vista sulla scrivania?
- L’impiegato può accedere solo ai dati che gli servono per il suo ruolo o anche ad altri? Riallacciandoci al principio della minimizzazione e rovesciando la questione: nel sistema sono presenti più dati personali di quelli che effettivamente servono?
- Che misure vengono prese per garantire il buon funzionamento dei componenti tecnici come il database o il server? In caso di guasto, in quanto tempo il servizio può essere ripristinato (RPO e RTO, si veda l’articolo precedente)?
- Che misure di protezione vengono prese rispetto ad attacchi deliberati ai sistemi e/o ai dati? Ad esempio, che antivirus sono in dotazione?
- Che contratto esiste con i servizi di supporto? I suoi termini sono conformi al GDPR? Che livelli di servizio sono garantiti? E che tipo di accesso ai dati del database possono avere i servizi di supporto?
- Tutti questi aspetti sono verificati periodicamente?
Queste sono solo alcuni esempi di domande che è necessario porsi come base per un’analisi del rischio, primo passo verso l’adozione di opportune misure di sicurezza, se necessarie, o verso la convalida di una situazione esistente, se “adeguatamente” sicura.
Passare al GDPR.
Non dobbiamo mai dimenticare che il GDPR chiede ai titolari ed ai responsabili del trattamento di essere in grado di dimostrare di avere messo in atto “misure tecniche ed organizzative adeguate” e non minime!
Quindi, sicuramente, per giungere alla conformità prevista dal GDPR il primo passo è conoscere sé stessi, ovvero conoscere la propria azienda e sapere come funziona. Ed ecco perché il passaggio al GDPR comprende aspetti legali, organizzativi, tecnici e formativi delle risorse umane. L’approccio non può che essere multidisciplinare e i responsabili delle funzioni operative aziendali, che conoscono il funzionamento quotidiano dei processi, devono essere coinvolti nel processo di adeguamento. Ed è necessaria una “cabina di regia”, in grandi organizzazioni, guidata dall’ufficio qualità o compliance.
Presto saranno trattati aspetti legali per il GDPR mentre nel prossimo articolo tratteremo il concetto di servizio, dentro e fuori l’azienda, e il passaggio del mercato verso una logica “universale” del servizio.
Per saperne di più:
