Adozione di un Piano di disaster recovery e di business continuity alla luce dell’art. 32.1, lett. b) e c) e art. 83.4, lett. a) del Regolamento UE 2016/679 (GDPR).

Premesso che:

–  il Codice dell’Amministrazione Digitale (CAD), di cui al decreto legislativo n. 82 del 7 marzo 2005, così come modificato dal decreto legislativo n. 235 del 30 dicembre 2010, prevede a carico delle Pubbliche Amministrazioni l’obbligo, tra gli altri adempimenti, di adottare soluzioni tecniche al fine di garantire la salvaguardia dei dati e delle applicazioni informatiche;

– l’art. 32.1, lett. b) e c) del Regolamento UE 2016/679 (di seguito anche “GDPR”) dispone che la sicurezza del trattamento dei dati personali deve comprendere, anche, le seguenti misure tecniche ed organizzative, che a loro volta si traducono nella: “capacità di assicurare la disponibilità e la resilienza dei sistemi e dei servizi di trattamento” e nella “capacità di ripristinare tempestivamente la disponibilità e l’accesso dei dati personali in caso di incidente fisico o tecnico”;

– la direttiva (UE) 2016/1148 (“direttiva NIS”) adottata il 6 luglio 2016  recante misure per un livello comune elevato di sicurezza delle reti e dei sistemi informativi nell’Unione;

–  le  Technical Guidelines for the implementation of minimum security measures for Digital Service Providers di ENISA (dicembre 2016)  dettagliano le misure di sicurezza di cui all’art. 32 GDPR;

– il Regolamento 2019/881, relativo all’ENISA, l’Agenzia dell’Unione europea per la cibersicurezza, e alla certificazione della cibersicurezza per le tecnologie dell’informazione e della comunicazione, e che abroga il Regolamento (UE) n. 526/2013 («regolamento sulla cibersicurezza»), dispone che anche in ambito sanitario, “Le reti e i sistemi informativi e le reti e i servizi di comunicazione elettronica svolgono un ruolo essenziale” e “il settore pubblico dovrebbe configurare i prodotti TIC, servizi TIC o processi TIC progettati in modo da garantire un livello di sicurezza superiore che dovrebbe consentire al primo utente di ricevere una configurazione predefinita con le impostazioni più sicure possibili («sicurezza predefinita»)”.

Preso atto che la violazione delle disposizioni di cui all’art. 32.1, lett. b) e c) del Regolamento UE 2016/679 (GDPR) comporta la irrogazione di sanzioni amministrative pecuniarie fino ad un limite di 10 milioni di euro, in capo al Titolare del trattamento.

Con la presente si sottolinea la imprescindibile necessità, in capo all’ente/azienda (Titolare del trattamento), di dotarsi di un piano di Business continuity e di Disaster recovery come richiesto in capo a tutte le Pubbliche amministrazioni, anche in ottemperanza agli obblighi introdotti dal GDPR in materia di misure di sicurezza da adottare nel trattamento dei dati personali.

Per chiarezza espositiva si riportano, in estrema sintesi, le definizioni dei due termini sopra richiamati.

La Business Continuity (di seguito anche “BC”) è la capacità dell’azienda di mantenere la funzionalità operativa a seguito di eventi che ne minaccino le funzionalità a qualunque livello, non solo tecnologico. Il Business Continuity Plan (di seguito anche “BCP”) è lo strumento che stabilisce le strategie da adottare per mantenere la produttività.

Nel caso di eventi che compromettano l’infrastruttura tecnologica interviene il Disaster Recovery (di seguito anche “DR”) che, secondo la definizione che ne dà Wikipedia, è: “… l’insieme delle misure tecnologiche e logistico/organizzative atte a ripristinare sistemi, dati e infrastrutture necessarie all’erogazione di servizi di business per imprese, associazioni o enti, a fronte di gravi emergenze che ne intacchino la regolare attività.”

Alla luce dei seguenti standard:

•  ISO/IEC 27001 (definisce i requisiti per un SGSI – Sistema di Gestione della Sicurezza delle Informazioni) ed è progettata per garantire la selezione di controlli di sicurezza adeguati e proporzionati;  
• ISO 22301/2019 (definisce i requisiti per attuare, mantenere e migliorare un sistema di gestione per proteggere l’organizzazione, ridurre la probabilità che si verifichino, prepararsi, rispondere e riprendersi dalle interruzioni quando si verificano, cioè un efficace sistema di gestione per la continuità operativa BCMS (Business Continuity Management System);
• ISO/IEC 27031:2011 (“Information technology — Security techniques — Guidelines for information and communication technology readiness for business continuity”) per la quale diventa imprescindibile adottare un Disaster Recovery Plan che si basa su una valutazione del rischio (Risk Assessment), su una BIA (Business Impact Analisys), sulla comprensione dei sistemi più critici per il business, e di ciò che è necessario fare per farli funzionare nuovamente in un arco di tempo accettabile.

La determinazione dei tempi di Recovery Point Objective  (RPO) e di Recovery Time Objective (RTO) è il punto di partenza per la creazione del Disaster Recovery e per la definizione del DR Plan.

I tempi di RPO e di RTO sono controllabili tramite le tecnologie e possono arrivare a tendere allo zero, ma il costo di implementazione cresce esponenzialmente al diminuire del loro valore.

In casi particolari (uno di questi è sicuramente quello riguardante i dati sanitari contenuti in cartelle cliniche/referti/liste di prenotazione, sistema Ris/Pacs, ecc) si renderà necessaria la creazione di una infrastruttura identica a quella di produzione che viene replicata in modalità sincrona e rimane quiescente in attesa di essere eventualmente attivata in caso di necessità. Ciò significa che il tempo di ripristino deve essere pari a zero.

I passi da compiere, attraverso un’azione sinergica che veda il coinvolgimento e la collaborazione proattiva delle seguenti funzioni aziendali, sono stati individuati dallo scrivente ricorrendo agli obiettivi di sicurezza delle Linee guida tecniche di ENISA, a loro volta ispirate all’Allegato A della norma ISO/IEC 27001.

Nello specifico è stato previsto il coinvolgimento delle seguenti funzioni:

a) la UOSD Sistemi Informativi – che anche con il coinvolgimento, ove previsto o da prevedere, dei partner tecnologici – dovrà, in prima battuta ed in estrema sintesi, almeno:

a.1) censire, analizzare e contestualizzare le applicazioni SW, individuando le UU.OO. coinvolte nel loro utilizzo (distinguendo gli applicativi “verticali” che riguardano singole UU.OO. dagli applicativi “orizzontali”, che sono in uso presso una pluralità di UU.OO.);

a.2) eseguire un controllo degli accessi alla rete e ai sistemi, tenendo a mente che tutte le singole utenze siano associate ad uno o più profili di autorizzazione;

a.3) implementare una configurazione di base per macchine virtuali e fisiche, identificando i sistemi  critici all’interno del perimetro aziendale al fine di potere adeguatamente perimetrare il loro utilizzo;

a.4) in un’ottica di corretta gestione degli asset va regolamentato l’uso di supporti rimovibili, prevedendo: la loro sanitizzazione, il loro censimento e l’espletamento di controlli di sicurezza sugli stessi (lo scrivente ritiene che l’uso di supporti rimovibili debba essere vietato a favore del ricorso a share di rete aziendale);

a.5) adottare misure di sicurezza per garantire la resilienza dei sistemi e prevedere misure organizzative per la gestione degli incidenti (quest’ultimo adempimento da compiere anche con il coinvolgimento dell’Ufficio Privacy);

a.6) porre in essere sistemi di logging e di monitoring oltre a tool (strumenti) per il monitoring, con la previsione di alert;

a.7) assicurarsi che software e sistemi siano adeguatamente testati prima di essere messi in “produzione”, previa adozione di una procedura ad hoc; qualora sia necessario utilizzare dati personali in fase di test essi dovranno essere criptati (principio di minimizzazione). L’ambiente di test dovrà essere tenuto separato da quello di produzione. L’installazione o la disinstallazione delle patch dovranno avvenire mediante prassi note;

a.8) crittografia: assicurarsi che i sistemi e le applicazioni (sia quelli in uso che quelli da acquistare) siano in grado di proteggere ogni tipo di dato personale in transito per mezzo di esse o at rest (cioè memorizzato in esse);

a.9) prevedere protocolli sicuri per inviare o ricevere dati (ad es: HTTPS, SFTP, SSH).

b) L’Ufficio Privacy dovrà, di concerto con i sistemi informativi. e con le competenti funzioni aziendali, in prima battuta ed in estrema sintesi, almeno:

b.1) analizzare le applicazioni (SW): contratto, scheda tecnica, scadenze, attestazione di conformità al GDPR, ecc.,

b.2) elencare le modalità (cartacee, informatiche o miste) con le quali i dati personali vengono trattati, 

b.3) determinare quali applicazioni sono essenziali per l’attività e sono indispensabili per l’operatività aziendale. Successivamente provvederà a:

b.4) individuare le minacce relazionandole agli asset (ci si riferisce agli strumenti con i quali la organizzazione tratta i dati personali) ai quali sono rivolte; in estrema sintesi per ciascun asset sarà preso in considerazione un set di minacce, quali ad es: l’autenticazione, la integrità, il non ripudio, la riservatezza, la disponibilità (riferita ai dati o ai servizi) e l’autorizzazione.

b.5) calcolare il livello di rischio che una data minaccia si verifichi su un determinato asset;

b.6) assegnare la priorità ai rischi;

b.7) definire le azioni di remediation (mitigazione del rischio), attraverso l’adozione di misure di sicurezza tecniche ed organizzative in grado di abbassare il livello di rischio.

Di tutti i sopra citati adempimenti (lettere a. e b.) dovrà essere stilato un cronoprogramma e dovrà fornirsi evidenza al titolare del trattamento dei dati personali.

Questo processo, previa acquisizione del parere del D.P.O., è essenziale per la creazione di un BCP ed è chiamato Business Impact Analisys (di seguito anche “BIA”) che stabilisce protocolli e azioni per affrontare una crisi, dopo aver valutato l’impatto e i costi di un eventuale “tempo di fermo” (downtime) al livello più alto possibile, non solo quello tecnologico.

Come strumento operativo si suggerisce di prendere in esame, anche, il Registro dei trattamenti dei dati personali licenziato dal titolare del trattamento, quale prescrizione contenuta nel GDPR, che a sua volta dovrà essere arricchite di tali informazioni.

Appare evidente che dopo una valutazione del rischio e una BIA, le decisioni che riguardano RTO e RPO dovranno essere prese dalla Direzione aziendale, sentito il Dirigente dei Sistemi Informativi (o altra analoga funzione) con il contributo – ove richiesto – del D.P.O., ciò in quanto l’interruzione o il degrado delle attività comportano conseguenze che impattano su tutta l’ente/azienda a livello legale, assicurativo e di immagine, e non riguardano solo la mera disponibilità delle infrastrutture.

Una strategia di DR dovrà prevedere almeno un test annuale di recovery, con procedure e indicatori chiave di prestazione (KPI) definiti per verificare che il DRP sia aggiornato e funzionante. La simulazione di disastro dovrà consentire di verificare che:

a) il personale sia preparato a reagire,

b) tutte le figure indicate nel piano siano a conoscenza delle attività di loro competenza,

c) i processi siano adeguati a raggiungere il risultato desiderato.