La sicurezza di un sito web è fondamentale per proteggere i dati e le informazioni degli utenti e dei gestori.

Sappiamo (dalla ISO 27001 e dal GDPR in primis) che la sicurezza va declinata nelle sue proprietà: Riservatezza, Integrità e Disponibilità. Dunque, non solo è importante garantire la riservatezza dei dati, ma anche la loro integrità (esattezza, correttezza) e la loro disponibilità in tempi idonei laddove attraverso il sito web si fornisce un servizio a clienti effettivi e potenziali. Inoltre, l’indisponibilità del sito web a causa di un attacco hacker (attacco DDOS, defacement del sito web) comporta un grave rischio reputazionale per il suo proprietario.

L’impresa deve dunque assicurarsi che il gestore del sito lo mantenga adeguatamente protetto, perché la sicurezza di un sito web è fondamentale per proteggere i dati personali e le informazioni degli utenti e dell’impresa proprietaria del sito. Tuttavia, esistono diverse vulnerabilità che possono compromettere la sicurezza di un sito web e renderlo esposto agli attacchi informatici. Alcune di queste vulnerabilità sono:

• L’iniezione di codice, che consiste nell’inserire dei comandi o delle query malevoli nel sito web, sfruttando le sue interfacce di input. Questo può portare a modificare, cancellare o rubare i dati del sito web o ad eseguire azioni indesiderate.
• Il cross-site scripting (XSS), che consiste nell’inserire dei codici JavaScript nel sito web, sfruttando le sue pagine web dinamiche. Questo può portare a manipolare il contenuto del sito web o a rubare le informazioni degli utenti, come i cookie o le credenziali di accesso.
• Il cross-site request forgery (CSRF), che consiste nell’indurre gli utenti a eseguire delle richieste non autorizzate al sito web, sfruttando la loro sessione attiva. Questo può portare a modificare le impostazioni del sito web o a effettuare delle operazioni dannose, come il trasferimento di denaro o l’invio di e-mail spam.
• Il furto di identità, che consiste nell’ottenere le informazioni personali degli utenti, come il nome, l’e-mail, il numero di telefono o i dati bancari. Questo può portare a utilizzare queste informazioni per scopi fraudolenti, come l’accesso ai loro account online o l’effettuazione di acquisti non autorizzati.

Per prevenire queste vulnerabilità e rendere il sito web più sicuro, esistono diverse misure di sicurezza che possono essere adottate. Alcune di queste misure sono le seguenti:

• Utilizzare un protocollo HTTPS per criptare le comunicazioni tra il sito web e i visitatori. Questo impedisce che i dati possano essere intercettati o modificati da terze parti malintenzionate. Inoltre, i siti “non https” vengono considerati come pericolosi dai browser e dagli antivirus e indicizzati con priorità bassa da Google, per cui risultano meno accessibili.
• Mantenere aggiornato il software del sito web, compresi i temi, i plugin e il sistema di gestione dei contenuti (CMS quali WordPress, Joomla od altri). Questo riduce il rischio di vulnerabilità e bug che potrebbero essere sfruttati dagli hacker.
• Impostare delle regole di accesso al sito web, come l’utilizzo di password forti, l’autenticazione a due fattori e il blocco degli indirizzi IP sospetti. Questo limita le possibilità di accesso non autorizzato al sito web e ai suoi dati.
• Effettuare dei backup regolari del sito web e dei suoi dati, in modo da poter ripristinare il tutto in caso di danni o perdite. Questo garantisce la continuità del servizio e la salvaguardia delle informazioni.
• Monitorare il traffico e le attività sul sito web, per individuare eventuali anomalie o tentativi di intrusione. Questo permette di intervenire tempestivamente in caso di problemi e di prevenire ulteriori danni.

Queste sono solo alcune delle misure di sicurezza che possono essere adottate per rendere un sito web più sicuro. Ogni sito web ha delle esigenze specifiche e richiede una valutazione personalizzata delle minacce che incombono su di esso, delle sue vulnerabilità e delle sue soluzioni. Per questo, è consigliabile affidarsi a dei professionisti del settore, che possano offrire una consulenza qualificata e un supporto tecnico adeguato.

Talvolta, infatti, le web agency sono molto preparate sulle tecniche di digital marketing e di pubblicità on-line, ma lo sono meno gli sviluppatori del sito web dal punto di vista della sicurezza.

In questo ambito, poi, si inserisce il rispetto del GDPR. Il General Data Protection Regulation (GDPR) è la normativa europea che stabilisce le regole sulla protezione dei dati personali dei cittadini dell’Unione Europea. Il GDPR (Regolamento UE 2016/679) ha un impatto diretto sulla gestione dei dati personali dei visitatori del sito web. Infatti, se il sito web che raccoglie dati personali dei visitatori, è importante che rispetti il GDPR. Ecco alcune delle caratteristiche che il sito web dovrebbe avere per essere conforme al GDPR:

1. Politica sulla privacy: Il sito web deve avere una privacy policy facilmente accessibile e comprensibile per i visitatori. La politica sulla privacy dovrebbe spiegare come i dati personali verranno raccolti, elaborati e utilizzati. Inoltre, dovrebbe essere indicato chi è il titolare del trattamento dei dati personali e come i visitatori possono esercitare i loro diritti di protezione dei dati.
2. Cookie banner e Cookie policy: in conformità alle disposizioni relative ai cookie e tecnologie similari il sito deve presentare, all’apertura, un c.d. banner che permette di accettare o rifiutare, oppure personalizzare, la gestione dei cookie non necessari (cookie tecnici), richiamando la cookie policy (spesso inclusa nella privacy policy generale). Tale funzionalità può essere efficacemente attuata tramite appositi plugin dei CMS, progettati allo scopo.
3. Consenso informato: I visitatori del sito web devono essere informati in modo chiaro e trasparente sui dati personali che verranno raccolti e su come verranno utilizzati. Inoltre, i visitatori devono essere invitati ad accettare o rifiutare l’utilizzo dei loro dati personali in modo esplicito e inequivocabile. Questo processo di consenso – necessario se i dati raccolti verranno utilizzati per finalità di marketing – dovrebbe essere documentato in modo che si possa dimostrare di aver ottenuto il consenso informato dei visitatori. Anche i moduli di contatto, form nei quali l’utente compila alcuni dati personali e formula una richiesta, dovranno comprendere un riferimento all’informativa privacy con un flag di spunta che attesta, almeno formalmente, che l’utente ha letto e compreso tale informativa.
4. Protezione dei dati: Il sito web deve garantire la sicurezza e la protezione dei dati personali dei visitatori. Ciò significa che deve utilizzare misure di sicurezza tecniche e organizzative per proteggere i dati personali da accessi non autorizzati, perdite o danni. Inoltre, si dovrebbe implementare un piano di gestione dei dati personali che preveda la cancellazione dei dati personali una volta che non sono più necessari.
5. Diritti degli interessati: I visitatori del sito web hanno diritti specifici in relazione ai loro dati personali. Questi diritti includono il diritto di accesso, il diritto di rettifica, il diritto all’oblio, il diritto di limitazione del trattamento, il diritto alla portabilità dei dati e il diritto di opposizione. Il sito web dovrebbe fornire ai visitatori un modo semplice ed efficace per esercitare questi diritti.
6. Responsabile del trattamento dei dati: Il proprietario del sito web dovrebbe nominare un responsabile del trattamento dei dati personali nella figura del fornitore della gestione del sito (normalmente la web agency). Questo soggetto dovrebbe essere responsabile di garantire che il tuo sito web rispetti le regole del GDPR e dovrebbe essere in grado di rispondere alle istanze dei visitatori sulla gestione dei dati personali. Si ricorda che anche siti dinamici semplici, realizzati con CMS quali WordPress, memorizzano in un database del sito i dati di coloro che si iscrivono alla newsletter o compilano form di richiesta contatto. Dunque, chi gestisce il sito ha accesso ai dati personali memorizzati nel database del sito.
7. Trasferimento dati extra–UE: i dati personali memorizzati nel sito potrebbero essere ospitati in un servizio cloud collocato al di fuori dello Spazio Economico Europeo e dunque soggetto a decisioni di adeguatezza della UE oppure ad altri meccanismi atti  a garantire la conformità dei trattamenti di dati svolti fuori UE. Anche se la recente decisione della Commissione Europea (Data Protection Framework USA-UE) dovrebbe regolarizzare l’esportazione di dati personali negli Stati Uniti, occorre comunque tenere in considerazione questo aspetto, anche in considerazione dell’utilizzo di plugin specifici.

In sintesi, per essere conforme al GDPR, il sito web deve rispettare le regole sulla protezione dei dati personali dei visitatori. Ciò significa che occorre garantire la trasparenza nella raccolta e nel trattamento dei dati personali, la sicurezza dei dati e il rispetto dei diritti degli interessati. Se il sito web rispetta queste regole, i visitatori avranno maggiore fiducia nella gestione dei loro dati personali e il proprietario del sito potrà evitare pesanti sanzioni.

Normalmente i soggetti che entrano in gioco nella progettazione, sviluppo e gestione del sito web sono i seguenti:

• Impresa committente che vuole realizzare un nuovo sito web, proprietaria del dominio internet;
• Web Agency che gestisce le attività di digital marketing;
• Sviluppatori software del sito
• Cloud Service Provider che ospita il sito (hosting)

La prima risulta titolare del trattamento, gli altri nella maggior parte delle situazioni sono Responsabili del Trattamento e devono avere un apposito atto ai sensi dell’art. 28 del Reg. UE 679/2016 che li vincola al titolare del trattamento. Questo aspetto deve essere visto da entrambe i punti di vista: del committente e del fornitore. Da un lato il committente dovrà predisporre un contratto coerente con i requisiti del Regolamento UE 679/2016 e che fornisca sufficienti garanzie al proprietario del sito che ne risponde nei confronti della legge, dall’altro il fornitore potrà proporre il proprio contratto a tutti i propri clienti per semplificare la gestione e regolarizzare il rapporto definendo compiti e responsabilità di ciascuno. Per quest’attività spesso è opportuno rivolgersi ad un consulente legale affiancato da un esperto delle tecnologie utilizzate.

Chiaramente se attraverso il sito web si vendono prodotti (e-commerce) le cose si complicano e le responsabilità aumentano, per non parlare dei siti di e-commerce per la vendita di farmaci, parafarmici, cosmetici ed altri prodotti che possono far presumere uno stato di salute dell’acquirente.

L’azienda titolare del dominio è direttamente responsabile di eventuali violazioni del sito (data breach) che possono comportare conseguenze negative ai diritti e alle libertà delle persone che hanno i propri dati memorizzati nel sito, ma spesso da un lato è spinta dalla web agency che vorrebbe attuare azioni di marketing non rispettose della normativa privacy, dall’altro non riesce a controllare l’efficacia delle misure di sicurezza del sito web.

Spesso capita che l’impresa committente non si preoccupi della corretta gestione dei consensi raccolti per l’invio delle newsletter, delle c.d. “fidelity card” o di altri concorsi a premi gestiti attraversò il sito web ed eventuali app per mobile collegate ad esso e nemmeno dei corretti tempi di conservazione dei dati degli utenti nelle diverse situazioni.

Dal punto di vista del fornitore del sito è invece opportuno puntualizzare che cosa ne farà l’azienda del sito web e chi sarà responsabile della predisposizione delle informative privacy.

In conclusione, i rischi per l’impresa che commissiona la realizzazione e gestione di un sito web sono molteplici, ma anche il ruolo del fornitore deve essere correttamente inquadrato, infatti diverso è il caso di chi progetta, realizza e mantiene il sito – azioni di marketing digitale annesse – e quello del fornitore che realizza il sito, lo avvia presso un cloud provider qualsiasi e poi lo consegna all’impresa che dovrà mantenere tutto secondo normativa privacy.

In quest’articolo andremo a commentare le nuove revisioni delle due più importanti norme della famiglia ISO 27k, avvenute nel corso del 2022:

• ISO/IEC 27001:2022 – Information security, cybersecurity and privacy protection — Information security management systems — Requirements
• ISO IEC 27002:2022 Information security, cybersecurity and privacy protection — Information security controls

La seconda è stata anche pubblicata dall’UNI con il prefisso UNI CEI EN alcuni mesi fa, ma di fatto l’Ente di Normazione Italiano si è astenuto dal tradurre le 170 pagine di norma, limitandosi alla traduzione del titolo (“Sicurezza delle informazioni, cybersecurity e protezione della privacy – Controlli di sicurezza delle informazioni”) e poco più, lasciando molti delusi visto che la precedente versione era stata tradotta. Ora ci si aspetta la pubblicazione della UNI CEI EN ISO 27001 con traduzione in italiano che dovrebbe costare pochi sforzi viste le limitate differenze rispetto alla versione precedente e le similitudini con altre norme con struttura HLS. Aspettative che non dovrebbero andare eluse visto che la ISO 27001 è anche una norma certificabile.

Le modifiche alla ISO 27001, oltre al recepimento dei “corriggendum” della precedente versione della norma e l’allineamento alla struttura HLS delle altre norme sui sistemi di gestione, sono veramente minime. I cambiamenti che hanno un impatto sui sistemi di gestione della sicurezza delle informazioni (SGSI) sono sostanzialmente:

• Definire quali requisiti delle parti interessate saranno affrontate nel SGSI (punto 4.2)
• Esplicitazione dei processi necessari al sistema di gestione (punto 4.4)
•  Pianificazione dei cambiamenti – al punto 6.3, completamente nuovo – in piena analogia con le altre norme sui sistemi di gestione
• Al punto 7.4 deve essere stabilito “come si deve comunicare”, ma i sottopunti d) ed e) precedenti eliminati non dicevano cose tanto diverse
• I riferimenti ai controlli di sicurezza al punto 6.1.3 e nell’Annex A.

Proprio quest’ultimo è il cambiamento più significativo della norma in quanto stabilisce che l’elenco dei controlli dell’Annex A (e della ISO 27002) sono solo una possibile lista di controlli di sicurezza sulla quale basare il SGSI e la Dichiarazione di Applicabilità (S.o.A.).

Poiché, salvo alcune realtà particolari, non credo che la gran parte delle organizzazioni si rivolga a framework diversi da quello proposto dalla ISO 27002, direi che è proprio questa norma che apporta modifiche sostanziali al SGSI.

Dunque, i controlli della ISO 27001, che sono diventati 93 (dai 114 precedenti) restano i capisaldi della SoA e per ognuno di essi si dovrà esplicitare le eventuali motivazioni di non applicabilità e le motivazioni di applicabilità (requisiti cogenti, requisiti contrattuali o di business, esigenza derivante dalla valutazione del rischio…).

La ISO 27002, oltre ad essere stata modificata – in parte – nei contenuti dei controlli di sicurezza, è anche stata completamente cambiata nella sua struttura che risulta semplificata.

Ora, infatti, i controlli sono suddivisi in 4 (macro) temi:

• controlli organizzativi (37 controlli);
• controlli sulle persone (8 controlli);
• controlli fisici (14 controlli);
• controlli tecnologici (34 controlli)-

Anche se la maggior parte dei controlli sono classificati come “organizzativi”, fra di essi vi sono molti controlli di forte caratterizzazione tecnologica ed ICT, ad esempio:

• A.5.7    Threat intelligence (Monitoraggio delle minacce)
• A.5.11  Return of assets (Restituzione degli asset)
• A.5.15  Access control (Controllo degli accessi)
• A.5.16  Identity management (Gestione delle identità)
• A.5.17  Authentication information (Informazioni di autenticazione)
• A.5.21  Managing information security in the information and communication technology (ICT) supply-chain (Sicurezza delle informazioni nella filiera di fornitura ICT)
• A.5.23  Information security for use of cloud services (Sicurezza delle informazioni per l’uso dei servizi cloud)
• ….

Appare evidente che non solo alcuni controlli riguardano, nella stragrande maggioranza di casi, “oggetti” ICT (A.5.11: per lo più si restituiscono dispositivi elettronici, A.5.17: stiamo parlando di username e password…), ma alcuni riguardano proprio solamente informazioni in formato digitale (A.5.23). Evidentemente l’Ente normatore (ovvero il Gruppo di lavoro che ha preparato la norma) ha inteso enfatizzare la componente “gestionale” di tali controlli.

Per analogia con le “misure di sicurezza tecniche ed organizzative” richieste dal GDPR si dovrebbe – ad esempio – comprendere il “controllo degli accessi (logici)” fra le misure di sicurezza organizzative e così via.

Al di là della numerosità dei controlli nelle 4 tematiche, è interessante la suddivisione dei controlli tenendo chiaramente separati i controlli relativi alla sicurezza fisica ed ambientale, dai controlli che mettono al centro il fattore umano, dai controlli organizzativi a quelli legati alla sicurezza informatica.

Dal pinto di vista contenutistico i cambiamenti nei controlli possono essere così riassunti

• 11 nuovi controlli
• 35 invariati
• 24 accorpati da controlli esistenti
• 58 aggiornati.

In realtà se andiamo a leggere con attenzione i 93-11= 82 controlli che non sono “nuovi” troviamo molte novità, non solo dovute ad aggiornamenti tecnologici e dello stato dell’arte della cybersecurity e della data protection. Pertanto, in fase di transizione dei SGSI esistenti occorre fare molta attenzione anche ai controlli i cui contenuti non sono apparentemente variati.

Altre novità interessanti della norma riguardano la terminologia e l’introduzione degli attributi.

La norma, infatti, riporta un ampio spettro di termini, definizioni e glossario di abbreviazioni che integrano i contenuti della ISO 27000. Peccato che sia mancata la traduzione nella nostra lingua.

Ma la novità forse più rilevante è stata l’introduzione di una serie di attributi associati ad ogni controllo, una sorta di tag o metadati che caratterizzano i controlli stessi.

Ogni controllo viene caratterizzato, infatti, dai seguenti attributi:

• Tipo di Controllo: Preventivo, di Monitoraggio (detective) o Correttivo
• Proprietà: Riservatezza, Integrità, Disponibilità
• Cybersecurity concepts: Identify, Protect, Detect, Respond, Recover
• Operational capabilities: Governance, Asset management, Information protection, Human resource security, Physical security, System and network security, Application security, Secure configuration, Identity and access management, Threat and vulnerability management,         Continuity, Supplier relationships security, Legal and compliance, Information security event management, Information security assurance
• Security domains: Governance and Ecosystem, Protection, Defense, Resilience.

Quindi, a parte le Proprietà dei Controlli (Confidentiality, Integrity e Availability in inglese) che costituiscono una mezza novità in quanto le stesse proprietà della Sicurezza delle Informazioni sono note da tempo, ma non erano state ufficialmente associate ai controlli, gli altri attributi costituiscono una grossa novità della norma al fine di classificare/categorizzare i controlli.

A fini puramente statistici possiamo notare che i controlli sono classificati in 83 Preventivi, 13 di Monitoraggio (Detective) e 14 Correttivi, da cui appare chiaro che ogni controllo può essere classificato in più di un solo tipo. Emerge anche il fatto che prevale l’ottica di prevenzione degli incidenti e delle violazioni di sicurezza. Ci si aspetterebbe che i controlli preventivi siano focalizzati alla riduzione della probabilità che una minaccia si concretizzi in un rischio di sicurezza delle informazioni, ad esempio attraverso l’eliminazione di vulnerabilità. Per i controlli classificati come Detective (o di monitoraggio) ci si aspetterebbe un indicatore di monitoraggio dell’efficacia delle misure di sicurezza adottate.

Più equilibrio c’è sulle proprietà dei controlli (R I D) dove si hanno 87 controlli che impattano la Riservatezza, 84 l’Integrità, 85 la Disponibilità: dunque sono pochi i controlli che non mirano a tutelare tutte e tre le Proprietà di sicurezza dell’informazione.

Curiosamente l’attributo Physical Security del gruppo di attributi “Operational capabilities” comprende 16 controlli di cui 2 non appartenenti al tema dei “controlli fisici”: “Procedure operative documentate” e “Lavoro da remoto”. Naturalmente ciò si giustifica per il fatto che devono essere presenti procedure documentate sui controlli fisici e che il lavoro da remoto (lavoro agile e/o smartworking) comprende aspetti che riguardano i controlli fisici (dove svolgo il lavoro da remoto? Come proteggo la postazione di lavoro da accessi fisici non autorizzati?).

Lasciando da parte queste statistiche sulla classificazione dei controlli nei vari attributi, la cui importanza ed utilità probabilmente si evidenzierà nelle fasi applicative della norma, veniamo ad esaminare alcuni aspetti pratici.

Cosa deve fare un’organizzazione certificata ISO 27001 per migrare alla nuova versione della norma?

Come anticipato le modifiche alla ISO 27001 sono davvero poco significative e il grosso del lavoro riguarderà i controlli dell’Annex A ovvero della ISO 27002:2022.

Sono reperibili, anche nella norma ISO 27002:2022 stessa, delle tabelle di conversione tra i vecchi controlli (114) ai nuovi controlli (93). Alcuni esperti consigliano di partire da qui per “convertire” la vecchia S.o.A. nella nuova S.o.A., cercando di coprire i nuovi controlli.

Questo approccio è valido nella maggior parte dei casi e ci permette di fare una gap analysis che comunque sarà richiesta anche dagli enti di certificazione nell’eventuale audit di sorveglianza 2024 laddove l’organizzazione non sia già pronta per la migrazione alla nuova norma.

È comunque opportuno valutare se non sia il caso di ristrutturare completamente il sistema di gestione della sicurezza delle informazioni, partendo dalla valutazione dei rischi. Questo requisito, infatti, è stato rielaborato dalla norma ISO 27005:2022 che ora considera due diversi approcci e molti esperti ritengono che modelli di risk assessment diversi da quello proposto dalla linea guida ISO 27005 siano migliori, perché più snelli e più facilmente applicabili nelle nostre imprese.

Dunque, si potrebbe passare dall’approccio classico, basato su asset – minacce – vulnerabilità – probabilità – gravità, ad un approccio basato sugli scenari o solo sulle vulnerabilità, intese come assenza o inefficacia dei controlli. Al proposito si segnala la disponibilità del tool gratuito VERA di Cesare Gallotti per la valutazione dei rischi ISO 27001:2022.

Dopo la valutazione dei rischi occorre riprogettare la S.o.A., evidentemente riconsiderando solamente i documenti che descrivono l’implementazione dei vari controlli di sicurezza.

Se le policy di sicurezza e le istruzioni operative relative ai controlli erano legate alla vecchia nomenclatura dei controlli sarebbe opportuno modificare la struttura del SGSI.

Se esiste un Manuale del Sistema di Gestione (che magari copre anche altre normative, ISO 9001, ISO 14001…)  si potrebbe partire da esso per richiamare i documenti di secondo livello del SGSI, ovvero le policy o le procedure. Esse dovrebbero riportare la descrizione dei processi e delle policy di sicurezza nei vari ambiti (controlli relativi alle persone, controlli di sicurezza fisica, controllo degli accessi logici, protezione dal malware, continuità operativa, gestione relazioni con i fornitori, ecc.), comprendenti le responsabilità ed i principi generali di scurezza delle informazioni.

Tali procedure potrebbero poi richiamare delle istruzioni operative di dettaglio che descrivono le modalità operative di attuazione dei controlli, richiamando eventuali documenti di consultazione, database o prospetti consultabili da sistema informatico (applicativi, funzioni del sistema operativo, tabelle Excel o Word, ecc.).

Procedure/policy ed istruzioni operative dovrebbero poi essere richiamate nella Dichiarazione di Applicabilità (SoA) in corrispondenza dei vari controlli.

Non è efficiente predisporre una procedura o una istruzione per ogni controllo della ISO 27002, ma determinate procedure potrebbero comprendere più controlli assimilabili ad una medesima attività.

Chiaramente esisteranno documenti prodotti ed aggiornati periodicamente che dovranno rispondere ad uno o più controlli nella SoA, ad es. il Business Continuity Plan.

Una struttura con dettagli crescenti a partire dal vertice della cosiddetta “Piramide della Documentazione”, nota nei sistemi qualità da alcuni lustri, costituito dal Manuale del Sistema di Gestione, favoriscono anche una classificazione dei documenti del SGSI. Infatti Manuale e Procedure/Policy avranno un livello di astrazione tale da poterli trasmettere anche all’esterno a clienti e partner che lo richiedono, mentre le istruzioni operative ed i documenti ad essa allegati o richiamati – quali ad esempio l’elenco degli asset informatici, la mappa della rete, l’elenco degli utenti con le relative autorizzazioni, le configurazioni ICT, ecc. – dovrebbero essere classificati come documenti riservati, accessibili, anche internamente, ad un numero limitato di persone.

Naturalmente, come avviene per qualunque sistema di gestione ed a maggior ragione per i SGSI, la struttura modulare della documentazione deve essere progettata in modo che le modifiche più frequenti ai documenti riguardino un piccolo insieme di documenti a livello più basso nella Piramide della Documentazione, in quanto si tratta dei documenti di maggior dettaglio.

Per quelle organizzazioni che dispongono anche di una certificazione ISO 27017 e/o ISO 27018 la cattiva notizia è che i controlli di queste normative saranno allineati successivamente alla ISO 27002:2022, dunque, in attesa che ciò avvenga, bisogna cercare di barcamenarsi alla meglio fra nuovi e vecchi controlli e ciò non sarà poco complicato.

Infine, per chi si approccia con questa nuova versione della norma alla progettazione di un nuovo SGSI il consiglio è quello di non farsi condizionare dall’approccio minimalista della documentazione dei sistemi qualità ISO 9001 di questi tempi: nel SGSI ISO 27001 è necessario documentare molto di più, soprattutto gli aspetti di dettaglio; non solo perché sono richiesti dagli Organismi di Certificazione, ma anche perché per una gestione interna efficace ed efficiente solo mantenendo un elevato livello di documentazione delle attività operative – soprattutto quelle in ambito ICT – si riesce a mantenere il controllo delle stesse a fronte di cambiamenti di tecnologie e di persone e a garantire l’accountability del sistema, anche lato privacy (il GDPR docet).

Molte imprese si sono trovate a dover nominare il Responsabile della Conservazione (RdC) per ottemperare ai requisiti delle nuove Linee Guida AgiD sulla conservazione dei documenti digitali. Tale adempimento non riveste, infatti, solo le Pubbliche Amministrazioni, ma tutte le imprese che utilizzano sistemi di conservazione “a norma” (archiviazione sostitutiva), compresi i sistemi di fatturazione elettronica, ormai divenuti obbligatori per tutte le organizzazioni.

Chi è il Responsabile della Conservazione?

Il Responsabile della Conservazione Digitale è una figura chiave nell’ambito della conservazione e gestione dei documenti digitali, in particolare per quanto riguarda le pubbliche amministrazioni. Secondo l’Agenzia per l’Italia Digitale (AgID), il Responsabile della Conservazione Digitale (Responsabile della Conservazione) ha il compito di garantire che i documenti digitali prodotti o conservati dall’ente siano adeguatamente gestiti e conservati nel rispetto delle norme e delle linee guida stabilite a livello nazionale.

Il Responsabile della Conservazione deve essere un professionista con conoscenze specifiche nel campo della conservazione digitale e delle tecnologie informatiche, in grado di gestire le complessità tecniche e normative legate alla gestione dei documenti digitali. Deve essere in grado di pianificare, coordinare e controllare tutte le attività relative alla conservazione digitale, garantendo che siano rispettati i criteri di completezza, integrità, accessibilità e leggibilità dei documenti.

Il Responsabile della Conservazione è anche responsabile di garantire la conformità alle norme in materia di privacy e protezione dei dati personali, di assicurare la corretta gestione dei sistemi di conservazione digitale e di gestire la sicurezza delle informazioni digitali.

Inoltre, il Responsabile della Conservazione deve essere in grado di collaborare con altre figure professionali all’interno dell’ente, come l’archivista o il responsabile dell’informatica, per garantire la massima efficienza e integrità delle attività di conservazione digitale.

In sintesi, il Responsabile della Conservazione Digitale è un professionista chiave per la conservazione e gestione dei documenti digitali delle pubbliche amministrazioni, con il compito di garantire che i documenti siano conservati in modo sicuro, completo e accessibile, in conformità con le norme e le linee guida stabilite.

Il Responsabile del Servizio di Conservazione è una figura chiave nell’ambito della conservazione e gestione dei documenti digitali delle pubbliche amministrazioni. Secondo l’Agenzia per l’Italia Digitale (AgID), il Responsabile del Servizio di Conservazione (RSC) è responsabile della definizione, implementazione e gestione delle politiche e delle attività relative alla conservazione digitale all’interno dell’ente.

Chi è il Responsabile del Servizio di Conservazione?

Il RSC deve essere un professionista con competenze specifiche nel campo della conservazione digitale e delle tecnologie informatiche, in grado di pianificare, coordinare e controllare tutte le attività relative alla conservazione digitale. Deve anche essere in grado di garantire la conformità alle norme in materia di privacy e protezione dei dati personali, e di gestire la sicurezza delle informazioni digitali.

Il Responsabile del Servizio di Conservazione è anche responsabile di assicurare la completezza, l’integrità, l’accessibilità e la leggibilità dei documenti digitali conservati, e di collaborare con altre figure professionali all’interno dell’ente per garantire la massima efficienza e integrità delle attività di conservazione digitale.

Inoltre, il Responsabile del Servizio di Conservazione deve essere in grado di monitorare e valutare costantemente le attività di conservazione digitale e di adottare le misure necessarie per garantire che i documenti digitali siano conservati in modo sicuro e che siano rispettati i criteri stabiliti dalle norme e dalle linee guida.

In sintesi, il Responsabile del Servizio di Conservazione è un professionista chiave per la conservazione e gestione dei documenti digitali delle pubbliche amministrazioni, con il compito di pianificare, coordinare e gestire le attività di conservazione digitale in modo da garantire che i documenti siano conservati in modo sicuro, completo e accessibile, e che siano rispettati i criteri stabiliti dalle norme e dalle linee guida.

Secondo la normativa italiana, tutte le pubbliche amministrazioni devono nominare un Responsabile del Servizio di Conservazione (RSC) per la gestione dei documenti digitali. Questo include enti locali, regioni, amministrazioni centrali, enti pubblici non economici e altre organizzazioni pubbliche.

Inoltre, anche alcune organizzazioni private che gestiscono informazioni sensibili o documenti di interesse pubblico possono essere tenute a nominare un Responsabile del Servizio di Conservazione.

La nomina del Responsabile del Servizio di Conservazione deve essere effettuata con un atto formale da parte dell’organizzazione interessata e deve essere pubblicata sul sito web dell’ente. Il RSC deve essere un professionista con competenze specifiche nel campo della conservazione digitale e delle tecnologie informatiche, in grado di garantire la corretta gestione dei documenti digitali dell’ente.

Il Responsabile del Servizio di Conservazione (RSC) deve possedere alcuni requisiti specifici per garantire una gestione corretta e conforme alle norme dei documenti digitali delle pubbliche amministrazioni.

Questi requisiti includono:

1. Competenze specifiche nel campo della conservazione digitale e delle tecnologie informatiche.
2. Conoscenza delle norme e delle linee guida in materia di conservazione digitale, privacy e protezione dei dati personali.
3. Capacità di pianificare, coordinare e gestire le attività di conservazione digitale, garantendo la sicurezza, la completezza e l’accessibilità dei documenti digitali conservati.
4. Conoscenza delle tecnologie e delle soluzioni utilizzate per la conservazione digitale, inclusi sistemi di gestione dei documenti digitali e di archiviazione.
5. Capacità di monitorare e valutare costantemente le attività di conservazione digitale e di adottare le misure necessarie per garantire la massima efficienza e integrità.

Inoltre, è importante che il Responsabile del Servizio di Conservazione abbia una buona conoscenza della lingua italiana e delle norme sulle pubbliche amministrazioni, in modo da garantire la comprensione e l’applicazione delle norme e delle linee guida in materia di conservazione digitale.

In sintesi, il Responsabile del Servizio di Conservazione deve essere un professionista con competenze specifiche nel campo della conservazione digitale e delle tecnologie informatiche, in grado di garantire la corretta gestione dei documenti digitali dell’ente e di rispettare le norme in materia di privacy e protezione dei dati personali.

Invece il Responsabile della Conservazione, figura interna all’organizzazione, deve possedere i seguenti requisiti:

1. Competenze specifiche nel campo della conservazione digitale e delle tecnologie informatiche.
2. Conoscenza delle norme e delle linee guida in materia di conservazione digitale, privacy e protezione dei dati personali.
3. Capacità di pianificare, coordinare e gestire le attività di conservazione digitale, garantendo la sicurezza, la completezza e l’accessibilità dei documenti digitali conservati.
4. Conoscenza delle tecnologie e delle soluzioni utilizzate per la conservazione digitale, inclusi sistemi di gestione dei documenti digitali e di archiviazione.
5. Capacità di monitorare e valutare costantemente le attività di conservazione digitale e di adottare le misure necessarie per garantire la massima efficienza e integrità.

Inoltre, è importante che il Responsabile della Conservazione abbia una buona conoscenza della lingua italiana e delle norme sulle pubbliche amministrazioni, in modo da garantire la comprensione e l’applicazione delle norme e delle linee guida in materia di conservazione digitale.

In sintesi, il Responsabile della Conservazione Digitale deve essere un professionista con competenze specifiche nel campo della conservazione digitale e delle tecnologie informatiche, in grado di garantire la corretta gestione dei documenti digitali dell’ente e di rispettare le norme in materia di privacy e protezione dei dati personali.

Ma non tutti i responsabili di funzione o direttori di funzione o area possono ricoprire il ruolo di RdC.

Infatti, secondo l’AgiD (Agenzia per l’Italia Digitale), i seguenti responsabili di funzione interne all’organizzazione non possono ricoprire il ruolo di Responsabile della Conservazione Digitale:

1. Il responsabile del trattamento dei dati personali, poiché questa figura ha responsabilità diverse in materia di privacy e protezione dei dati personali.
2. Il responsabile della sicurezza del sistema informatico, poiché questa figura ha la responsabilità di garantire la sicurezza del sistema informatico e non quella della conservazione digitale.
3. Il responsabile del sistema informativo, poiché questa figura ha la responsabilità di gestire il sistema informativo dell’ente e non la conservazione digitale dei documenti digitali.

In sintesi, il Responsabile della Conservazione Digitale deve essere una figura distinta e indipendente da altri responsabili di funzione interne all’ente, in grado di garantire la corretta gestione dei documenti digitali in conformità alle norme in materia di conservazione digitale e di privacy.

Il Manuale della Conservazione

Uno dei compiti non delegabili del RdC è la redazione del Manuale della Conservazione.

Il Manuale della Conservazione Digitale è un documento che definisce le procedure, le politiche e le linee guida per la corretta gestione dei documenti digitali conservati da un’organizzazione. Il manuale è un supporto importante per il Responsabile della Conservazione Digitale (Responsabile della Conservazione) nell’esercizio delle proprie funzioni e nella realizzazione delle attività di conservazione digitale.

Il manuale della conservazione digitale comprende:

1. Le politiche e le linee guida per la gestione dei documenti digitali, inclusi il processo di acquisizione, catalogazione, conservazione e accesso.
2. Le procedure per la verifica dell’integrità e la verifica periodica dei documenti digitali conservati.
3. Le procedure per la gestione delle modifiche e degli eventuali danni ai documenti digitali.
4. Le linee guida per la sicurezza dei documenti digitali, inclusi i requisiti per la protezione dei dati personali e la protezione dei documenti digitali da eventuali perdite o danneggiamenti.

In sintesi, il manuale della conservazione digitale è uno strumento fondamentale per garantire la corretta gestione dei documenti digitali conservati da un’organizzazione, in conformità alle norme e alle linee guida in materia di conservazione digitale e privacy.

In un precedente articolo abbiamo trattato della valutazione del rischio privacy per adempiere ai requisiti del GDPR (Regolamento UE 2016/679 sulla protezione dei dati personali), ma chi ha o deve implementare un sistema di gestione per la sicurezza delle informazioni come deve considerare la valutazione dei rischi sui trattamenti di dati personali? Tale valutazione è implicita nella valutazione dei rischi sulla sicurezza delle informazioni, ovvero è un “di cui” di essa? Oppure, come sostengono alcuni esperti di privacy, è tutta un’altra cosa e va considerata separatamente? Cerchiamo di chiarire questi aspetti.

Cos’è il rischio per la sicurezza delle informazioni?

Partiamo dalla valutazione del rischio per la sicurezza delle informazioni, ovvero essenzialmente per i sistemi di gestione certificati ISO 27001.

Prima di parlare di valutazione del rischio dovremmo soffermarci sulla terminologia: sicurezza delle informazioni non è “sicurezza informatica” e non è “cybersecurity”. Tralasciamo le discussioni sul termine cybersecurity (in italiano “sicurezza cibernetica”?) che per taluni equivale alla sicurezza informatica, per altri è la protezione delle informazioni digitali da attacchi informatici (non da incidenti naturali!), per altri ancora ha a che fare con la sicurezza degli appartai IT e OT…

La sicurezza informatica è un sottoinsieme della sicurezza delle informazioni? Dunque, la valutazione del rischio ICT è una parte della valutazione del rischio per la sicurezza delle informazioni?

Non è proprio così, ma quasi: la sicurezza informatica riguarda gli apparati ICT che normalmente trattano informazioni digitali. Ora un problema tecnico, dovuto ad un attacco informatico deliberato oppure ad un evento accidentale, comporta anche un rischio per la sicurezza delle informazioni? In teoria non è sempre così perché un attacco informatico ad una infrastruttura critica (ad es. un acquedotto o una rete elettrica) generalmente non comporta conseguenze sulla sicurezza delle informazioni, ovvero sulla sua declinazione in riservatezza, integrità e disponibilità. Perciò non costituisce un rischio per la sicurezza delle informazioni? Ma le apparecchiature informatiche e le infrastrutture ICT cosa trattano? Non trattano byte, ovvero informazioni? Facciamo un esempio su un fatto accaduto di recente: il blocco del traffico aereo alcuni giorni fa negli Stati Uniti è stato provocato da un incidente informatico, pare fosse colpa di un file “corrotto” (ma anche se fosse stato un attacco di hacker Russi, cosa che non ci diranno mai, la sostanza non cambierebbe): ebbene è considerato un incidente sulla sicurezza delle informazioni, ovvero si è concretizzato un rischio sulla sicurezza delle informazioni? Apparentemente no perché le conseguenze sono state il blocco dei voli con disagi per i passeggeri, maggiori costi per Compagnie Aeree e passeggeri e così via. Ma la causa di tutto questo non è stata la mancanza di informazioni (= mancata disponibilità di informazioni) sulla sicurezza dei voli che ha fatto prudentemente mantenere a terra molti aeromobili?

Ovviamente tutto dipende dal contesto in cui si trova l’organizzazione che deve valutare i rischi e qual è il campo di applicazione del sistema di gestione ISO 27001 che, nel caso, ci chiede la valutazione del rischio.

Il viceversa – ovvero che la sicurezza informatica non copra tutta la sicurezza delle informazioni – è dimostrabile in modo più semplice: le informazioni su supporto cartaceo devono essere protette e la loro protezione generalmente non riguarda la sicurezza informatica.

La valutazione del rischio sulla sicurezza delle informazioni

Fatta questa premessa andiamo ad esaminare cosa ci dice la teoria e la letteratura sul risk assessment per l’information security, ovvero per il SGSI ISO 27001.

In principio fu la vecchia versione della ISO 27005 a guidare queste valutazioni del rischio sulla sicurezza delle informazioni. In sintesi, questa norma ci diceva di partire dal censimento degli asset dell’organizzazione, di andare a vedere quali informazioni essi trattano (information asset) e, quindi, fare una valutazione del valore degli asset riguardo alle caratteristiche di sicurezza, ovvero riservatezza, integrità e disponibilità.

Poi occorreva identificare le minacce alla sicurezza delle informazioni (gli attacchi hacker, gli incendi, gli errori di configurazione dei sistemi, ecc.) e le vulnerabilità presenti negli asset (sistemi non aggiornati, assenza di protezione fisica del CED, mancanza di consapevolezza del personale, ecc.).

Una combinazione di questi elementi, ovvero una minaccia che sfrutta una vulnerabilità per far concretizzare un rischio su un determinato asset veniva ponderata in base alla probabilità di accadimento (in realtà viene usato il termine verosimiglianza) x la gravità delle conseguenze/danno potenziale x il valore dell’asset, al fine di ottenere un determinato livello di rischio quali-quantitativo.

Oggi l’ultima versione della medesima norma prende in considerazione due approcci:

• Approccio basato sugli eventi: i rischi possono essere identificati attraverso le considerazioni della Direzione e il contesto dell’organizzazione. Questo permette di concentrare gli sforzi sui rischi più critici, senza disperdersi nella valutazione di numerosi rischi che poi giudicherò minori e non degni di essere considerati con azioni di trattamento.
• Approccio basato sugli asset: i rischi possono essere identificati attraverso l’ispezione di asset, minacce e vulnerabilità. È quello già previsto dalla precedente edizione della ISO 27005.

Altri metodi di valutazione del rischio possono essere utilizzati, classificati in genere in metodi quantitativi (basati su un calcolo più o meno “preciso” del rischio, a fronte di valutazioni della probabilità matematica di accadimento dell’evento negativo e di valutazione quantitativa del danno, ad es. in termini economici) e qualitativi (il valore del rischio: “Alto”, “Medio”, “Basso”, ecc. non è espresso in valori assoluti, ma rappresenta solo un metodo di confronto fra i vari rischi).

In generale questi metodi qualitativi, secondo alcuni esperti, portano sempre ad un calcolo del rischio basato sulla formula:

r(m, a, v) ∝ p(m) ⋅ i(m, a) ⋅ g(v)

dove r rappresenta la funzione “rischio” che dipende da m= minacce, a= asset, v= vulnerabilità in modo proporzionale alla probabilità di accadimento della minaccia, all’I=impatto della minaccia sull’asset e alla g=gravità della vulnerabilità.

Un approccio completamente diverso, proposto da altri esperti, non prende in considerazione le minacce, ma parte dalle vulnerabilità presenti per determinare i rischi concreti che dovranno essere valutati attraverso la classica formula Rischio =Possibilità di accadimento x Gravità del danno o delle conseguenze provocate dal concretizzarsi del rischio.

Le fasi successive del processo di valutazione dei rischi, dopo la loro identificazione, sono sempre le stesse: analisi dei rischi, ponderazione dei rischi, scelta delle opzioni di trattamento, determinazioni dei controlli/contromisure necessari, confronto con i controlli dell’Annex A della ISO 27001 e definizione della Dichiarazione di Applicabilità (S.o.A.).

Tra i modelli disponibili per il calcolo del rischio sulla sicurezza delle informazioni secondo la ISO 27001 segnaliamo il tool VERA di Cesare Gallotti (https://www.cesaregallotti.it/Pubblicazioni.html ) che prevede l’identificazione di una serie di Minacce/Rischi per le quali sono attribuiti una probabilità di accadimento ed un impatto fino a costituire il c.d. “rischio puro” o “rischio intrinseco”. Quindi vengono stabilite le vulnerabilità che non sono altro che l’inversamente proporzionale ai controlli, ovvero all’efficacia degli stessi. Combinando il rischio intrinseco con le vulnerabilità/controlli si ottiene il valore del rischio calcolato sulla sicurezza delle informazioni. Tale modello comprende anche una parte legata alla privacy (comunque cogente anche in ambito SGSI) nella quale si valutano i soli rischi (minacce) attinenti alla privacy e le relative conseguenze.

Altri esperti definiscono il “rischio inerente” come il rischio derivante dalla combinazione di probabilità/possibilità di accadimento dell’evento e dalla gravità delle conseguenze. Applicando i controlli di sicurezza, ovvero le contromisure (le misure di sicurezza tecniche ed organizzative in termini privacy) si ottiene il “rischio residuo”, che dovrà poi essere confrontato con i criteri di accettabilità per stabilirne le opzioni di trattamento.

Altri schemi e standard prevedono valutazioni dei rischi sulla sicurezza ICT, che oggi costituisce parte preponderante della sicurezza delle informazioni. Gli approcci possono essere leggermente diversi, ma sostanzialmente non si discostano dalla seguente metodologia-

1. Identifico le minacce che incombono sui sistemi e sui dati (es. virus ransomware o, più in dettaglio le tecniche che rendono possibile un attacco ransomware: phishing, social engineering, attacchi di forza bruta a siti web per la ricerca di credenziali di accesso, ecc.)
2. Identifico gli eventi che, se si concretizza la minaccia, possono costituire un rischio per i miei dati
3. Valuto le misure di mitigazione che sono state implementate per fronteggiare il rischio.
4. Valuto la probabilità di accadimento dell’evento.
5. Valuto l’impatto che comporta tale rischio per i dati e tutto quel che ne consegue.
6. Calcolo il valore del rischio (residuo).
7. Definisco le azioni di trattamento del rischio (accettare il rischio oppure adottare ulteriori misure di prevenzione o protezione per ridurre il rischio o addirittura eliminarlo.

La valutazione del rischio privacy

Quando si valuta il rischio relativo alla privacy, è possibile identificare minacce specifiche per la privacy. Tra di esse vi sono:

• rappresentazione scorretta, se i dati relativi a una persona sono errati, oppure presentati o elaborati in modo non corretto possono provocare danni all’interessato; questa minaccia può anche riguardare i risultati della profilazione di una persona (che, ad esempio, potrebbe essere esclusa da programmi sanitari o economici), eventualmente anche con strumenti basati sull’intelligenza artificiale;
• distorsione, ossia l’interpretazione volutamente o inavvertitamente scorretta dei dati, con potenziali impatti negativi sulla singola persona; questa minaccia è, in pratica, quella del pettegolezzo e della maldicenza, che può portare al biasimo, alla stigmatizzazione, all’isolamento e anche alla perdita di libertà di una persona;
• sorveglianza, attraverso l’uso dei dati, soprattutto in ambito informatico; è necessario riconoscere la differenza tra logging (ossia la raccolta di dati per assicurare la sicurezza delle persone e della proprietà) e la sorveglianza (che porta, anche se non sempre per scelta deliberata, a discriminazione, perdita di fiducia, autonomia o libertà, danni fisici o materiali);
• blocco alla conoscenza dei dati trattati, ossia segretezza in merito al fatto che i dati personali sono trattati e alle modalità con cui lo sono; questo può portare all’uso dei dati personali iniquo e, per le singole persone fisiche, alla mancanza di autodeterminazione, alla perdita di fiducia e a perdite economiche;

In pratica le minacce per la privacy potrebbero essere diverse da quelle per la sicurezza delle informazioni, o meglio alcune (la maggioranza) coincidono, altre sono differenti. Ma se consideriamo che l’informazione è anche un dato personale e che la stessa ISO 27001 comprende un controllo denominato “Privacy e protezione dei dati personali” (controllo A.18.1.4 della versione 2013 della ISO 27001-27002) capiamo bene che – nella valutazione del rischio per la sicurezza delle informazioni – dobbiamo considerare anche gli impatti che una determinata violazione di dati personali può avere sui diritti e le libertà dell’interessato e non solo sul business dell’organizzazione.

Dunque un medesimo evento rischioso, ad esempio un data breach sul portale web dell’azienda oppure un ransomware che non comporta un’esfiltrazione di dati (anche personali), ma “soltanto” un blocco dei sistemi per un paio di giorni, potrebbe portare ad una valutazione e, quindi, ad un indice (livello) di rischio differente semplicemente perché – a parità di probabilità di verificarsi dell’evento – l’impatto sui diritti e le libertà dell’interessato, piuttosto che sul business dell’organizzazione, può essere sensibilmente diverso.

Quindi la valutazione dei rischi potrebbe essere unica a patto di considerare i differenti effetti a fronte del verificarsi di medesimi eventi.

Naturalmente ogni organizzazione avrà i suoi parametri e le sue specificità: dal punto di vista dell’interessato: un conto è un blocco dei sistemi informativi per un paio d giorni di un Ospedale ed un conto è il medesimo blocco per un’azienda manifatturiera dove probabilmente il fatto di non poter accedere ai dati dei dipendenti per un paio di giorni non costituirebbe un gran problema (salvo che non sia il giorno di pagamento degli stipendi…).

Tuttavia, alcuni esperti della materia privacy potrebbero obiettare: ma per il GDPR devo valutare i rischi sui trattamenti di dati personali, quindi considerare i rischi per ogni trattamento! Allora bisognerebbe riprendere il concetto di “Asset” dove i dati personali (dei dipendenti, dei clienti, ecc.) costituiscono un “asset informativo” con un certo valore, dato dalla combinazione delle diverse caratteristiche di sicurezza (Riservatezza, Integrità e Disponibilità).

Spesso, però, si può semplificare considerando il caso peggiore (worst case), ovvero dato un determinato evento rischioso (ad es. un data breach sul portale web) consideriamo lo scenario peggiore per tutti i trattamenti di dati personali. Allora per i trattamenti dei dati personali dei dipendenti avrò un determinato impatto, mentre per i dati personali dei clienti avrò un impatto di tipo e valore diverso: nel nostro caso di esempio per l’Ospedale il rischio maggiore sarebbe sui dati dei pazienti e dei relativi trattamenti (es. prenotazioni, refertazione visite ed esami, ecc.), mentre per l’azienda manifatturiera il rischio più elevato sarà sui trattamenti dei dati dei dipendenti (elaborazione paghe, ecc.).

Evidentemente la valutazione del rischio privacy per ogni singolo trattamento di dati personali che abbiamo inserito nel Registro delle Attività di Trattamento (ai sensi dell’art. 30 del GDPR) potrebbe risultare parecchio oneroso e non giustificato per una medio-piccola organizzazione. È comunque sempre opportuno raggruppare più trattamenti sui quali incombono i medesimi fattori di rischio. Ad esempio in un’organizzazione che gestisce tutti i dati in formato digitale attraverso file di Office conservati in un file Server ed un unico applicativo gestionale è perfettamente inutile replicare le medesime minacce ed eventi di rischio legati all’IT su diversi trattamenti. Eventuali vulnerabilità o misure di sicurezza non completamente efficaci legate al controllo degli accessi degli utenti, agli strumenti anti-malware, ai backup o alla (scarsa) consapevolezza del personale impattano su tutti i trattamenti di dati personali e basterà considerare solo il caso peggiore, ovvero l’impatto di gravità più alta su tutti i trattamenti per “risolvere” il problema della valutazione del rischio privacy. Infatti, ai fini della protezione dei dati personali, il trattamento del rischio che andremo ad attuare sarà finalizzato a prevenire il rischio (abbassare la probabilità che la minaccia si concretizzi) oppure a proteggere il dato dall’evento che non può essere completamente evitato (ridurre la gravità dell’impatto), dunque miglioreremo la protezione dei dati personali su tutti i trattamenti effettuati.

In conclusione il problema non è pensare di coprire anche la valutazione del rischio privacy attraverso una valutazione più ampia sulla sicurezza delle informazioni, ma fare quest’ultima valutazione in modo incompleto, senza considerare nel modo corretto i rischi associati alla protezione dei dati personali.

Come spesso accade, se si fanno le cose per bene si può fare (quasi) tutto.

Oggi le imprese tendono ad esternalizzare molti processi ed attività secondarie al fine di ottimizzarne i costi e la qualità del servizio risultante che, se svolto da personale specializzato, è spesso superiore a quello ottenibile impiegando il personale interno.

Alcune di queste attività – ad esempio la gestione delle paghe e del personale, l’acquisizione di documenti e dati in formato digitale e la relativa archiviazione sostitutiva, la gestione contabile e fiscale, i servizi informatici, ecc. – prevedono la gestione di informazioni critiche del punto di vista della riservatezza e degli aspetti legali e di compliance ad essi correlati.

Per questo motivo alcune aziende internazionali – multinazionali o grandi gruppi con sedi all’estero, in particolare negli Stati Uniti – richiedono, alle loro filiali o consociate italiane, evidenza della buona gestione dei servizi affidati in outsourcing.

Per le aziende soggette a tale standard la Sezione 404 del Sarbanes-Oxley Act (SOX) richiede che i fornitori di servizi in outsourcing siano provvisti di una particolare certificazione, il Report SSAE 18, per garantire che controlli e processi interni siano appropriati alla gestione delle informazioni dei propri clienti.

La crescente richiesta di servizi in outsourcing pone, quindi, l’esigenza da parte delle organizzazioni che forniscono tali servizi delle tipologie sopra elencate (payroll, contabilità, gestione documentale, ecc.) di fornire ai propri clienti e ad altri soggetti un rapporto di revisione completo sui sistemi di controllo e sui processi, al fine di assicurare che i servizi erogati alla clientela siano sicuri e conformi a uno standard riconosciuto.

La certificazione SSAE no. 18 è il nuovo standard per effettuare la reportistica sui controlli nelle aziende di servizi – sostituendo le precedenti SSAE no. 16 e SAS no. 70 – e risponde alla domanda crescente di disporre di regole conformi a standard internazionali riconosciuti in tutto il mondo, migliorativi rispetto ad una semplice certificazione ISO 9001 o ad una ISO 27001. Le modifiche apportate dal nuovo standard richiedono alle aziende di prendere maggiore controllo e proprietà dei propri controlli interni, relativamente all’identificazione e alla classificazione del rischio e alla gestione appropriata delle relazioni con i fornitori di terze parti.

Il report SSAE 18 (Statement on Standards for Attestation Engagements no. 18) viene rilasciato da auditor indipendenti qualificati dall’AICPA (dall’American Institute of Certified Public Accountants) dopo un articolato processo di analisi dei processi interni, confronto degli stessi con un’apposita matrice di controlli che produrrà una gap analysis la quale costituirà il punto di partenza per portare, attraverso l’introduzione di idonei controlli ed apposita documentazione procedurale, alle verifiche di efficacia dei controlli implementati atti a garantire l’adeguatezza degli stessi e delle informazioni processate.

Il report SSAE 18 costituisce un’esaustiva fotografia del funzionamento dell’organizzazione di servizi e dei controlli implementati per garantire non solo la conformità del servizio, ma anche la sicurezza nella gestione dei dati elaborati.

Il processo che porta alla certificazione SSAE 18 comprende una dettagliata mappatura dei processi organizzativi e dei flussi informativi che permette di effettuare la mappatura degli obiettivi di controllo, delle criticità e dei rischi, finalizzata alla valutazione dei rischi (risk assessment), imprescindibile punto di partenza per qualsiasi sistema di controllo interno.

Sebbene questo schema SSAE 18 ricalchi per alcuni elementi la certificazione ISO 9001 e la certificazione ISO 27001, esso presenta una valenza particolare in determinati settori e costituisce il logico completamento in un percorso di miglioramento e di qualificazione dell’organizzazione di servizi nei confronti del cliente.

Tale certificazione, si ribadisce, è rivolta in particolare alle seguenti organizzazioni di servizi:

• Servizi di gestione paghe del personale
• Acquisizione dati e documenti in formato digitale
• Conservazione sostitutiva
• Servizi contabili e fiscali
• Servizi di assistenza e sviluppo software

La normativa IATF 16949 prevede alcuni requisiti che riguardano la sicurezza delle informazioni dell’organizzazione automotive ed infatti le Sanctioned Interpretation riguardano anche la sicurezza delle informazioni gestite. Ricordiamo che una Sanctioned Interpretation modifica l’interpretazione di una regola o di un requisito della IATF 16949 e diventa essa stessa la base di una non conformità.

In particolare, alcune di esse riguardano ai punti seguenti:

6.1.2.3 PIANI DI EMERGENZA

L’organizzazione deve:

a) – b) (…)

c) preparare piani di emergenza per la continuità della fornitura in caso si verifichino: guasti di apparecchiature chiave (vedere anche sezione 8.5.6.1.1), interruzione dei prodotti, processi e servizi di fornitura esterna, disastri naturali, incendi, interruzione di servizi, attacco informatico ai sistemi informativi, mancanza di manodopera o problemi alle infrastrutture.

S.I.: “Le organizzazioni devono affrontare la possibilità di un attacco informatico che potrebbe interrompere le proprie attività produttive e logistiche, inclusi i ransomware. Le organizzazioni devono assicurarsi di essere preparate in caso di attacco informatico.”

7.1.3.1 PIANIFICAZIONE DELLO STABILIMENTO, DEI MEZZI E DELLE APPARECCHIATURE

…l’organizzazione deve… implementare la protezione informatica delle apparecchiature e dei sistemi di supporto della produzione

S.I.: “La sicurezza informatica non si limita alle funzioni di supporto e alle aree degli uffici che utilizzano i computer. Anche la produzione utilizza controlli e attrezzature computerizzati potenzialmente a rischio in caso di attacchi informatici. L’aggiunta di questo requisito guida verso l’implementazione delle protezioni necessarie per garantire il continuo funzionamento e l’ininterrotta produzione, al fine di soddisfare le esigenze dei clienti”

Le suddette prescrizioni restano generiche e non entrano molto nel merito di una disciplina molto articolata e complessa come quella della sicurezza delle informazioni in generale e della sicurezza informatica in particolare.

Per questa ragione è uscito lo standard TISAX® (Trusted Information Security Assessment eXchange), che rappresenta uno schema a fronte del quale le aziende automotive più importanti (OEM, Tier 1) richiedono l’assessment ai loro fornitori in quanto essi trattano informazioni critiche dal punto di vista della Riservatezza, dell’Integrità e della Disponibilità delle stesse.

È facile immaginare che alcune informazioni scambiate nella catena di fornitura automotive, richiedono una certa protezione. Si tratta di: dati di prodotti e di componenti (specifiche tecniche, documenti progettuali e disegni dimensionali, dati di validazione file PPAP/APQP, dati di collaudo e omologazione), dati aziendali fondamentali per il business (schede processi, programmi di produzione, software di produzione e manutenzione, informazioni personali, strategie aziendali, dati di marketing e di vendita), dati collegati ai rapporti tra fornitori e clienti del settore (offerte, contratti, ordini di componenti, fatture, piani di consegne, dati e informazioni su clienti e fornitori), dati su veicoli (anomalie, guasti, richieste di assistenza, …).

TISAX è un meccanismo di valutazione e di scambio dei risultati di un assessment fra le organizzazioni della catena di fornitura automotive, nato per iniziativa del VDA tedesco – attualmente responsabile dello schema – e che si sta affermando come una declinazione degli standard di sicurezza delle informazioni (ISO 27001 su tutti, ma anche SPICE ISO 15504 per il software automotive) nel settore automotive.

Il sistema TISAX si basa su:

1. Una registrazione dell’azienda al TISAX®
2. La scelta di un organismo (audit provider) che effettua audit secondo questo schema
3. L’esecuzione dell’assessment da parte dell’organismo indipendente
4. La condivisione dei risultati dell’assessment con i partecipanti al TISAX e l’accesso ai dati degli altri partecipanti.

I partecipanti registrati al TISAX possono anche essere OEM che si ritengono partecipanti “passivi” in quanto non effettuano un assessment, ma invitano i loro fornitori a farlo per poi accedere ai risultati dell’assessment stesso.

L’intero meccanismo è monitorato dall’ENX, associazione no profit che svolge un ruolo simile ad un Ente di Accreditamento.

L’audit o assessment TISAX porta ad ottenere una “Label” mediante un processo che è del tutto simile a quello delle certificazioni dei sistemi di gestione.

L’assessment TISAX ha uno scopo, un ambito di applicazione per il quale viene valutato dall’audit provider (esiste lo scopo di tipo Standard, Narrow ed Extended).  L’ambito di applicazione di una valutazione TISAX, però, non può essere determinato dall’organizzazione, ma deve necessariamente comprendere tutti i processi e le risorse coinvolte nel trattamento di informazioni afferenti all’industria automobilistica.

Dallo scopo derivano gli obiettivi dell’assessment che permettono di ottenere una “Label” di un determinato tipo (Livello di Maturità da 0 = Incomplete a 5 = Optimizing).

La documentazione (tutta in lingiua inglese o tedesca) resa disponibile per questo schema è ampia e comprende un TISAX Handbook dettagliato, un TISAX Simplified Group Assessment e soprattutto una check-list per l’autovalutazione. Tutti i documenti aggiornati sono reperibile al link https://portal.enx.com/en-US/TISAX/downloads/.

Anche l’audit non è di un unico tipo: esiste l’audit di livello 1 (AL 1) che essenzialmente è una autovalutazione dell’organizzazione, quello di livello 2 (AL 2) che consiste in una verifica di quanto indicato dall’azienda nel questionario di valutazione, condotta prevalentemente da remoto, infine l’audit di livello 3 (AL 3) è più completo ed approfondito, dunque più severo per l’organizzazione.

Probabilmente molte organizzazioni a cui è stato richiesto dai loro clienti un assessment TISAX non sanno rispondere alle domande della check-list di autovalutazione, oppure risponderebbero in modo errato senza una consulenza competente in grado di guidarli verso l’audit/assessment TISAX senza rischiare di fare un buco nell’acqua.

La check-list per l’assessment TISAX propone, per ciascun punto di controllo, uno o più obiettivi di controllo ai quali sono associati requisiti obbligatori (must), requisiti auspicabili (should), requisiti aggiuntivi necessari laddove è richiesto un elevato livello di protezione delle informazioni e, tra le altre informazioni, il riferimento al requisito ISO 27001 dell’appendice A (equivalente al controllo ISO 27002) corrispondente.

I controlli sono suddivisi in tre aree: Information security, Prototype protection e Data protection.

I risultati degli obiettivi di controllo sono poi riepilogati nella scheda dei risultati (Result) che produrrà la valutazione complessiva e genererà un grafico Radar complessivo per evidenziare i livelli di maturità per i diversi punti di controllo, oltre a grafici radar per singola area.

Sono infine riportati alcuni esempi, anche di KPI significativi per monitorare l’adeguatezza della gestione della sicurezza delle informazioni in ambito automotive.

La copertura dei controlli ISO 27001 Appendice A – ISO 27002 è solo parziale, ma l’obiettivo è far raggiungere anche ad aziende medio-piccole che operano nel settore automotive un livello di maturità accettabile sulla sicurezza delle informazioni, senza pretendere di ottenere l’ardua ed onerosa certificazione ISO 27001.

Tuttavia, un’azienda del settore manifatturiero che opera in questo settore spesso non ha risorse IT interne adeguate per gestire un progetto di adeguamento al TISAX e l’infrastruttura tecnologica implementata potrebbe non fornire adeguate garanzie dal punto di vista della sicurezza.

Occorre dunque effettuare una sorta di gap analysis per capire qual è lo stato attuale dell’organizzazione rispetto alla sicurezza delle informazioni, per capire quali azioni occorre mettere in campo per poter raggiungere il livello di maturità richiesto e la conseguente Label TISAX. Credo che alcune organizzazioni, però, si attiveranno subito con l’iscrizione al TISAX per avviare il processo, senza sapere cosa li aspetta.

I costi per l’ottenimento di una determinata Label TISAX variano in funzione del numero dei siti e degli scopi, ma sono comunque ripartiti nei seguenti:

• Costo di registrazione al TISAX (a partire da € 405)
• Costi per l’audit da parte di un Audit Provider (dipendono dal livello di audit e sono ricorrenti per rinnovare la Label ogni 3 anni, ma non sono previsti audit di sorveglianza)
• Costi per l’eventuale consulenza finalizzata al raggiungimento del livello di maturità richiesto
• Costi del personale interno per seguire il progetto (personale IT, qualità, direzione, risorse umane, …)
• Speseper adeguamento di hardware e software
• Costi per eventuale assistenza sistemistica esterna.

Come noto il Regolamento UE 679/2016 (GDPR) non prevede più – a differenza del previgente D.Lgs 196/2003 – di attuare delle misure “minime” di sicurezza” a protezione dei dati personali trattati da un’organizzazione (titolare o responsabile del trattamento), bensì misure di sicurezza adeguate, stabilite a fronte di una valutazione dei rischi sui trattamenti.

In particolare, all’Articolo 32 del GDPR: Sicurezza del trattamento (Considerando 83), si riporta quanto segue:

In altri articoli di questo blog abbiamo esaminato varie misure di sicurezza, tecniche ed organizzative, che ogni titolare o responsabile del trattamento dovrebbe adottare e non è l’obiettivo di questo articolo fare un’elencazione delle possibili misure di sicurezza. Si veda al proposito Misure di sicurezza di un’applicazione web per essere conformi al GDPR, Prime esperienze di applicazione del GDPR, Come gestire il Responsabile del trattamento ai sensi del GDPR, Come gestire il Responsabile del trattamento ai sensi del GDPR.

In questo articolo vorrei invece soffermarmi su un aspetto, la valutazione di “adeguatezza” di una misura di sicurezza e la possibilità di un’organizzazione di dimostrare a terzi (soggetti di cui tratta dati personali in qualità di titolare, altri titolari del trattamento per i quali svolge il ruolo di responsabile del trattamento, Garante per la Protezione dei Dati Personali a fronte di eventuali ispezioni) di aver fatto tutto quello che poteva per proteggere i dati personali, ovvero di dimostrare l’accountability.

Molte organizzazioni chiedono ai consulenti privacy ed ai loro DPO (o RPD, Responsabile della Protezione Dati) quali misure di sicurezza minime devono adottare, oppure se le misure adottate sono sufficienti. Ma è difficile rispondere a questa domanda in quanto il panorama delle misure di sicurezza, soprattutto sul fronte ICT, è profondamente mutato dal 2004 quando entrò in vigore il vecchio D. Lgs 196/2003 ed in particolare il suo Allegato B (ora abrogato).

Occorre fare una valutazione dei rischi che incombono sul trattamento, basata sulla valutazione della probabilità e della gravità dell’impatto che determinati eventi negativi, rispettivamente, si verifichino e delle conseguenze che possono portare ai dati personali trattati. Inoltre, nella determinazione delle misure di sicurezza, occorre contestualizzare (l’art. 25 del GDPR cita: «Tenendo conto dello stato dell’arte e dei costi di attuazione, nonché della natura, dell’ambito di applicazione, del contesto e delle finalità del trattamento…») e non tutte le misure di sicurezza sono uguali a sé stesse in tutti i contesti.

Cerchiamo di capire meglio, partendo da una domanda che un auditor o consulente privacy formula normalmente al responsabile di un’organizzazione – di medio-piccole dimensioni – per la quale deve svolgere un assessment sullo stato di adeguatezza rispetto al GDPR.

Auditor: «Quali misure di sicurezza tecnologiche avete adottato per proteggere i dati trattati su supporto e lettronico?»

Responsabile organizzazione: «Abbiamo tutte le misure richieste dalla normativa: antivirus, firewall, backup, password…»

I problemi per il bravo auditor o consulente privacy iniziano a questo punto: bisogna capire quali di queste misure specifiche sono implementate e come, ovvero come sono configurate. Infatti, il GDPR ci chiede di considerare lo stato dell’arte della tecnologia, ma anche delle minacce apportate ai dati personali dai “cattivi”, ovvero gli hacker, il personale infedele, i malintenzionati in genere. Inoltre ci sono da considerare anche i rischi di origine ambientale, quali catastrofi naturali, terremoti, ecc.. Purtroppo, anche in questo ambito lo “stato dell’arte” negli ultimi 10-15 anni ha fatto aumentare la probabilità di eventi quali terremoti ed alluvioni in zone nelle quali non si erano mai verificati eventi gravi (vedi ad es. Emilia – Romagna). Anche la pandemia Coronavirus, sebbene non abbia portato ad aumentare i rischi diretti di perdita di dati o di perdita di riservatezza degli stessi, ha comportato – essenzialmente attraverso il lavoro a distanza – a cambiare il “perimetro” entro il quale i dati vengono trattati, generando nuove vulnerabilità presto sfruttate da malintenzionati che hanno prontamente creato nuove minacce per attaccare i dati delle aziende.

Prendendo spunto da provvedimenti e sanzioni già comminate dal Garante Privacy relativamente alle misure di sicurezza non adeguate, a fronte di una violazione (data breach) verificatasi, vorrei esaminare alcune misure di sicurezza implementate da quasi tutte le organizzazioni.

Premesso che il GDPR ci chiede di scegliere le misure di sicurezze anche in base al costo di attuazione, dunque non può chiedere ad una piccola organizzazione (ad es. uno Studio Professionale o una piccola Società di servizi che tratta anche dati particolari) le stesse misure di sicurezza adottate da un’azienda a livello Enterprise – ad es. sistemi antintrusione molto evoluti, appliance di sicurezza informatica o altri strumenti “top di gamma” – è comunque necessario dimostrare di non aver trascurato il problema, per noncuranza oppure per eccessiva riduzione dei costi.

Partiamo dall’antivirus, ormai meglio denominato anti-malware, il cui obiettivo è prevenire virus informatici, tra cui i tanto temuti ransomware, ma anche syware (programmi spia che raccolgono dati a fini pubblicitari, quando va bene) e simili.

Ci sono antivirus gratuiti (ma attenzione che molti di essi non sono freeware per uso commerciale, per cui si rischia di incorrere in sanzioni per assenza di licenza) che offrono una discreta protezione, ma non certamente ottimale come quella fornita dalle corrispondenti versioni a pagamento. Tra gli anti-malware gratuiti c’è anche Microsoft Defender (o Windows Defender), incluso e preinstallato in Windows 10 che offre anch’esso una discreta protezione, ma non ha performance eccellenti nella protezione dal ransomware e non costituisce una scelta ottimale per chi tratta dati particolarmente critici (ad es. dati sanitari).

La scelta di non adottare una soluzione a pagamento è sostenibile? Se tutto va bene non ci sono problemi, ma se siamo colpiti da un ransomware che ci blocca l’attività e ci costringe a segnalare la violazione dati al Garante Privacy (difficile nascondere la violazione se, come nel caso di una Farmacia lombarda bisogna stare chiusi e mettere un cartello in strada nel quale si informa la gentile clientela che si resta chiusi per problemi informatici…) è difficile sostenere che le nostre misure di sicurezza erano adeguate. Come si giustifica la scelta di non spendere per un antivirus commerciale? A fronte del costo di circa una cinquantina di euro l’anno per la protezione di 3 PC è difficile sostenere la motivazione economica.

Ma acquistare un antivirus professionale non basta, occorre configurarlo correttamente.

Pensate che un software di sicurezza completo di anti-malware, firewall ed altri tool di sicurezza accessori (aggiornamento applicazioni, analisi vulnerabilità, protezione webcam, ecc.) tra i più noti, come Kaspersky Internet Security, presenta oltre una quarantina di parametri da configurare per ottenere un giusto compromesso fra prestazioni del computer e delle applicazioni e livello di protezione, con la necessità di configurare opportunamente alcuni parametri per poter utilizzare determinate applicazioni. Ad esempio, per poter utilizzare una semplice chiavetta per la firma digitale al fine di accedere al portale di accesso del Processo Civile Telematico (necessario per avvocati e CTU come il sottoscritto) occorre disabilitare il controllo delle connessioni crittografate, impostata per default dall’antivirus come attiva. L’utilizzo di applicazioni web – dal semplice home-banking ai siti di e-commerce, ai portali specifici utilizzati da alcune organizzazioni per determinate attività lavorative – richiedono talvolta impostazioni specifiche, anche dipendenti dai browser usati, relativamente ad anti-banner, cookie, navigazione in incognito e così via.

Naturalmente in caso di diversi PC collegati in rete con un server che accede a internet la situazione si complica. In sostanza bisogna saper configurare correttamente i tool di protezione oppure ricorrere ad un consulente informatico esterno.

Per il firewall vale il discorso fatto per l’antivirus, sia per quanto riguarda le soluzioni gratuite, sia per quanto riguarda la corretta configurazione. Come ulteriore complicazione si aggiunge il firewall hardware offerto ormai da quasi tutti i modem/router delle compagnie telefoniche, che deve essere configurato in modo da evitare incompatibilità con il firewall software e la struttura informatica interna. Tra l’altro spesso le incompatibilità riscontrate da utenti non esperti portano ad eliminare alcune misure di sicurezza per evitare problemi. Anche in questo caso spesso è difficile rinunciare ad un tecnico esperto esterno, in particolare per le piccole organizzazioni che non hanno un vero responsabile ICT interno in grado di gestire e risolvere la maggior parte dei problemi.

Se poi l’organizzazione deve accedere ad applicazioni web o ha installate sul proprio server applicazioni gestionali che devono essere fruibili anche esternamente, c’è l’esigenza di esporre servizi ed applicazioni all’esterno per renderle visibili e/o rendere visibili dall’esterno a determinate risorse (PC o server) interne.

In tutti questi casi occorre ancora l’intervento di uno specialista e spesso non basta un intervento “una tantum”. Purtroppo, molte organizzazioni di piccole dimensioni, che magari trattano dati particolari (di cui all’art. 9 del GDPR), scelgono di spendere per servizi professionali esterni solo quando strettamente necessario, mentre spesso ci sarebbe bisogno di una manutenzione costante dei sistemi informatici, almeno dal punto di vista sistemistico. Infatti, col tempo le configurazioni degli strumenti di protezione cambiano, oppure cambiano le modalità di fruizione delle applicazioni e gli strumenti di protezione non vengono riconfigurati di conseguenza.

Qui andiamo ad introdurre l’argomento dell’Amministratore di Sistema, figura tanto discussa a causa del provvedimento del Garante per la Protezione Dati Personali di ormai 10 anni fa (cfr. Misure e accorgimenti prescritti ai titolari dei trattamenti effettuati con strumenti elettronici relativamente alle attribuzioni delle funzioni di amministratore di sistema – 27 novembre 2008; aggiornato in base al provvedimento del 25 giugno 2009).

Da un punto di vista puramente formale è bene precisare che tale Provvedimento NON è stato abrogato, sebbene in talune situazioni può essere derogata la nomina dell’Amministratore di Sistema (AdS) e il GDPR non citi questa figura. Da un punto di vista sostanziale non si può negare che la nomina formale – con compiti e responsabilità precise – dell’AdS costituisca una misura di sicurezza di tipo organizzativo. Al di là di questo il fatto di delegare il controllo dei propri sistemi informatici ad uno o più AdS in modo continuativo garantisce il Titolare (o Responsabile) del trattamento che i sistemi informatici siano ben configurati.

Ricordiamo la definizione di AdS, secondo l’Autorità Garante:

«Con la definizione di “amministratore di sistema” si individuano generalmente, in ambito informatico, figure professionali finalizzate alla gestione e alla manutenzione di un impianto di elaborazione o di sue componenti. Ai fini del presente provvedimento vengono però considerate tali anche altre figure equiparabili dal punto di vista dei rischi relativi alla protezione dei dati, quali gli amministratori di basi di dati, gli amministratori di reti e di apparati di sicurezza e gli amministratori di sistemi software complessi.»

Purtroppo, queste regole sono sovente disattese per due ragioni fondamentali:

1. Molte organizzazioni si rivolgono a consulenti informatici e tecnici sistemisti esterni solo “alla bisogna”, ovvero quando c’è da installare una nuova risorsa hardware o un nuovo software, oppure quando si verifica un problema. Già questo non va proprio bene alla luce dei discorsi fatti sopra: il titolare del trattamento potrebbe non avere sotto controllo le misure di sicurezza implementate “una tantum”.
2. Altre organizzazioni hanno un rapporto continuativo con un soggetto esterno che, di fatto, svolge il ruolo di AdS (spesso nominato Responsabile ICT esterno) in quanto detiene continuativamente le credenziali di system administrator (usiamo il termine inglese per distinguerlo dal termine italiano che rievoca il provvedimento del Garante) e svolge manutenzione periodica sui sistemi informatici dell’organizzazione, ma non è stato formalmente nominato Amministratore di Sistema. Perché? Spesso perché non ha il controllo completo sui sistemi, in quanto altri soggetti possono operare con le credenziali di system admin (talvolta le medesime) sui sistemi dell’organizzazione, perché non tutte le risorse hardware ed i software vengono installati e configurati dal Responsabile ICT esterno, il quale, quindi, non vuole garantire determinate misure di sicurezza perché non è in grado di assicurarlo. Altre volte è la stessa Direzione dell’organizzazione che desidera eludere alcune misure di sicurezza ritenute “adeguate” dall’AdS ed addirittura le c.d. misure minime di sicurezza di cui al Disciplinare tecnico (allegato B) del vecchio Codice Privacy. Altre volte, infine, è solo questione di soldi.

In molte situazioni – che rientrano in ambedue le casistiche sopra citate – come aggravante c’è il problema dei log e della loro conservazione. Infatti, il provvedimento impone che siano conservati i log degli AdS, in formato non modificabile dagli stessi, per almeno sei mesi. Poiché per realizzare ciò normalmente occorre un applicativo a ciò dedicato (oppure occorre sviluppare apposite procedure informatiche), talvolta la Direzione dell’organizzazione non vuole spendere per acquistare tale applicativo e, dunque, il candidato AdS (in questo caso può essere anche interno all’organizzazione, ovvero un dipendente) non accetta la nomina perché non è in grado di adempiere ai propri compiti relativamente alla conservazione dei log.

In entrambe le tipologie di situazioni i Titolari (o Responsabili) del trattamento devono solo pregare di non subire un data breach importante, perché nel caso la sanzione dell’Autorità Garante è assicurata in quanto non si riuscirebbe ad assicurare l’accountability del Titolare (o Responsabile) del trattamento.

Altro caposaldo delle misure di sicurezza è il backup, che – rimanendo strettamente nell’ambito del GDPR, ovvero nel trattamento di dati personali – può avere livelli di importanza molto diversi. Infatti, garantire la disponibilità dei dati ha un impatto differente per un Ospedale oppure per un’azienda manifatturiera.

Anche in questo caso non basta dire avere il backup, ma bisogna porsi altre domande:

• Viene fatto un backup sempre completo? Oppure viene fatto un backup incrementale o differenziale?
• Qual è la frequenza del backup?
• Su quali e quanti supporti viene salvato il backup?
• Dove e come vengono conservati i supporti?
• Il backup è accessibile on-line? È cifrato?
• Qual è la retention dei backup (ovvero fino a quanto tempo nel passato riesco a recuperare i file)?
• Vengono eseguite prove di ripristino (restore) complete o parziali?
• E così via.

Una regola sui backup è quella del “3-2-1”, ovvero mantenere almeno 3 copie dei dati (compreso l’originale), su 2 supporti, almeno 1 in una location remota.

È inutile aggiungere che anche se il backup può essere eseguito automaticamente (salvo poi gestire i supporti off-line e portarli con una certa frequenza in un’ubicazione remota), la configurazione dello stesso deve essere eseguita da personale un minimo esperto; e quindi ci riallacciamo al discorso fatto in precedenza.

L’ultimo elemento della domanda iniziale sulle misure di sicurezza è costituito dalle password, ovvero dalle credenziali di autenticazione, meglio descritte dall’espressione “controllo degli accessi logici” ai sistemi informatici.

Molti ritengono di essere a norma dotandosi di accessi con password di almeno 8 caratteri, da cambiare periodicamente. Sulla variazione periodica della password molti sorvolano, ma se da un lato esistono tesi valide che ritengono che la variazione periodica, soprattutto con frequenza breve (mensile o trimestrale) della password sia non solo inutile, ma anche controproducente, dall’altro molte organizzazioni hanno sposato questa tesi in modo inconsapevole, direi quasi incosciente.

Come al solito bisogna avere una visione completa del problema: si può eliminare il cambiamento della password a condizione di adottare una strategia di sicurezza adeguata come usare password complesse (caratteri alfanumerici, numerici e simboli, ecc.) ed introdurre l’autenticazione a due fattori. Questo è molto più importante se stiamo parlando dell’autenticazione ad un’applicazione web alla cui pagina di login potrebbero facilmente accedere anche soggetti esterni malintenzionati.

C’è poi il principio del minimo privilegio che andrebbe soddisfatto, ovvero ogni utente dovrebbe poter accedere esclusivamente alle risorse di cui ha bisogno per lavorare. Purtroppo, invece, molte piccole organizzazioni concedono a tutti di vedere tutto, basandoci sulla fiducia che tutti i collaboratori si comportino correttamente, anche al fine di evitare problemi di accesso in caso di assenza di personale.

Da un lato questa prassi può essere pericolosa perché, pur credendo alla buona fede di tutti, nel caso in cui un utente clicchi su un allegato malevolo o su una pagina web contenente malware, si rischia di compromettere tutte le risorse del sistema informatico portandosi in casa un ransomware. Analogamente se le credenziali di accesso di un utente venissero compromesse (per attacchi informatici o tramite attività di social engineering) un malintenzionato avrebbe accesso a tutte le risorse dei sistemi.

Dall’altro lato le esigenze della Direzione e/o della proprietà dell’organizzazione possono essere soddisfatte da sistemi informatici adeguatamente configurati, acquisendo gli strumenti giusti, da parte di un tecnico esperto. Dunque, anche in questo caso, spesso è questione di costi.

Da ultimo vorrei brevemente affrontare il problema delle comunicazioni elettroniche, tra cui la mail riveste un ruolo principe.

È facile vedere che molte piccole organizzazioni e singoli professionisti utilizzano indirizzi di posta elettronica gratuiti (le estensioni vanno da @libero.it a @tin.it a @gmail.com e così via). Chiaramente questi servizi di posta sono gratis a discapito della privacy, pertanto sono spesso origine di spam perché i provider rivendono gli indirizzi ed i dati di profilazione a terzi.

Visto il costo di 10-15 euro l’anno di un indirizzo di posta elettronica a pagamento, è difficile giustificare un soggetto che utilizza la posta elettronica anche per trasmettere e ricevere dati particolari (ex dati sensibili). In caso di data breach del gestore (per “libero.it” è già successo) o dell’utente, ad esempio per aver subito l’intercettazione della posta, trasmessa con protocolli non cifrati (ad es. “tin.it” non utilizza i protocolli SSL o TLS), anche in questo caso, non ci sono giustificazioni plausibili.

Altre possibili misure di sicurezza non implementate, quali l’impiego di protocolli di comunicazione obsoleti o deprecati per comunicazioni di dati particolari, l’invio di buste paga o altre informazioni personali che ricadono fra le particolari categorie di dati attraverso e-mail in chiaro (non cifrate) e così via, dovrebbero essere prese in considerazione.

Si ribadisce che occorre comprendere che una determinata misura di sicurezza tecnica non è, di per sé, adeguata o meno in assoluto. A seconda del contesto in cui si opera, della natura dei dati trattati, del costo (nell’ottica che abbiamo esplicitato sopra) e dei vincoli che esistono per svolgere una determinata attività, una certa scelta dell’imprenditore – adeguatamente documentata – può essere ritenuta accettabile in una realtà e reputata inadeguata in un’altra, magari semplicemente perché non si ravvisa una scelta consapevole, supportata da ragionamenti ed evidenze oggettive da parte del titolare (o responsabile) del trattamento.

Il consiglio è, quindi, di farsi documentare dal consulente informatico esterno o amministratore di sistema, in un’apposita relazione sulle misure di sicurezza dei sistemi informatici, tutte le misure di sicurezza effettivamente implementate e di mantenere aggiornato tale documento.

Il campo delle misure di sicurezza tecniche ed organizzative a protezione dei dati personali è molto ampio: esistono le norme ISO 27001 e soprattutto i controlli della ISO 27002 sui sistemi di gestione della sicurezza delle informazioni, integrate dalla ISO 27701 specifica sulla protezione dei dati personali, le Linee Guida ENISA, il Cybersecurity Maturity Model, le Linee Guida NIST, le Misure di Sicurezza AGID (specifiche per la P.A.) e così via. Facendo riferimento a documenti normativi riconosciuti o best practice consolidate si riesce a dimostrare l’adeguatezza delle proprie misure di sicurezza nei confronti di terzi.

Qualcuno obietta sempre: «Ma se gli hacker sono riusciti a violare Enti governativi molto importanti ed aziende molto grandi e strutturate, che volete che possa fare io nella mia piccola organizzazione?». Naturalmente i malintenzionati cercano sempre di “pescare” i pesci più grossi, anche se alle volte vanno “a strascico” per cui anche i più piccoli devono difendersi facendo quello che è nelle loro possibilità.

In conclusione, le piccole organizzazioni devono stare molto attente a non ritenere che la privacy possa essere risolta con qualche adempimento formale e dichiarando di applicare alcune misure di sicurezza minimali per essere conformi; in altre parole con la compilazione/redazione di qualche documento da firmare e tenere nel cassetto, come certe soluzioni “preconfezionate” vorrebbero far credere.

Nella gestione della privacy di un’organizzazione talvolta ci si trova a valutare la conformità al GDPR (Regolamento UE 2016/679) di una applicazione web o web application fornita, spesso con modalità SaaS (Software As A Service) da un fornitore esterno.

Da un lato l’art. 28 del GDPR ci chiede di affidarci solo a responsabili del trattamento che garantiscano adeguate misure di sicurezza e la conformità al GDPR stesso, dall’altro l’art. 25 ci chiede che gli applicativi software che trattano dati personali siano “privacy by design” e “privacy by default”, ma cosa significa tutto ciò? Cosa dobbiamo realmente chiedere al fornitore di una web application? Anzi cosa dobbiamo pretendere per garantirci la conformità al GDPR?

Al di là degli obblighi del GDPR, molti imprenditori si pongono queste domande:

1. Dove sono conservati i miei dati?
2. Chi li può visionare?
3. Saranno sempre nella mia disponibilità?

Le responsabilità in capo al Titolare del trattamento in caso di violazione dei dati personali gestiti attraverso un sito web sono pesanti se esso non ha provveduto, da un lato a garantirsi contrattualmente la conformità del responsabile del trattamento e dall’altro ad assicurarsi che l’applicazione web sia adeguatamente sicura. In pratica il titolare rischia di essere accusato di “culpa in eligendo” e “culpa in vigilando”, relativamente al rapporto con il responsabile del trattamento.

Il più elevato livello di garanzie che un titolare del trattamento può ottenere è la certificazione ai sensi dell’articolo 42 (e 43) del gdpr del fornitore responsabile del trattamento per il prodotto utilizzato. Al momento tale certificazione non è ancora pienamente disponibile, ma manca veramente poco perché i primi schemi di certificazione ai sensi dell’articolo 42 del GDPR siano abilitati da Accredia (o da altri enti di accreditamento europei mutuamente riconosciuti nella UE) attraverso l’accreditamento dei primi Organismi di Certificazione ai sensi della norma ISO 17065 per la certificazione del GDPR. Ad esempio, lo schema ISDP©10003 è l’unico schema di certificazione italiano accreditato e, quindi, potrà costituire uno strumento per poter certificare processi, prodotti o servizi sotto accreditamento ISO 17065 e, quindi, certificare la conformità di un prodotto software come un applicativo web al Regolamento Europeo sulla Protezione dei Dati Personali 679/2016.

Ma in assenza di un prodotto software certificato quali sono i requisiti di sicurezza che possiamo ragionevolmente richiedere ad una web application si tratta dati personali di dipendenti, clienti e fornitori dell’organizzazione titolare del trattamento?

Vediamo un elenco non esaustivo di possibili misure di sicurezza, suddivise per categorie.

1. Controllo degli accessi: il sistema web deve prevedere un’autenticazione mediante credenziali del tipo username e password univoche (o rese tali). Devono essere implementati criteri di sicurezza per le password come ad esempio una lunghezza minima (almeno 8 caratteri sono indispensabili), una complessità minima della password (ad esempio potrebbe essere richiesta la presenza di almeno un carattere alfabetico maiuscolo, alfabetico minuscolo, un numero ed un carattere speciale), la password dovrebbe essere cambiata al primo accesso dell’utente e a frequenza prestabilita, sebbene la variazione della password non sia più un must della sicurezza informatica; infatti sistemi come l’autentificazione a due fattori richiesta anche saltuariamente  (ad esempio in caso di collegamento da un nuovo dispositivo ) potrebbe rendere maggiormente sicuro il portale web. Poi dovrebbe comunque essere impedito l’accesso contemporaneo con il medesimo codice utente da due dispositivi differenti. Inoltre, l’utente dovrebbe essere automaticamente scollegato dalla sessione dopo un certo periodo di tempo. Infine, le password dovrebbero essere mantenute in forma cifrata nel database dell’applicativo per evitare hacker possano appropriarsi delle credenziali degli utenti.
2. Anti-malware: il portale web dovrebbe implementare sistemi antivirus attivi e firewall per contrastare eventuali attacchi dall’esterno.
3. Profilazione degli utenti: tutti gli utenti dovrebbero avere accesso alle sole risorse di cui necessitano e le utenze amministrative ovvero quelle di amministratore di sistema dovrebbero essere utilizzate soltanto per necessità specifiche.
4. Log degli accessi: dovrebbe essere implementato un sistema di raccolta di log degli accessi degli amministratori di sistema (mantenuti almeno sei mesi in formato non modificabile come richiesto dal provvedimento del Garante Privacy) e degli utenti.
5. Aggiornamento software: dovrebbero essere mantenuti costantemente aggiornati contro minacce alla sicurezza i sistemi operativi ed i software di base della piattaforma nella quale opera l’applicativo web; dunque aggiornamenti costanti delle versioni di mySQL, PHP ed Apache nella piattaforma open source LAMP, aggiornamenti di MSSQL e relativi componenti software della piattaforma Microsoft, ecc..  
6. Comunicazioni sicure: le connessioni fra client e web devono essere crittografate (protocollo SSL/TLS) con certificati validi, prassi ormai consolidata per siti web che applicano le connessioni “https”.
7. Politica di backup: dovrebbe essere attuata una policy di backup adeguata alle esigenze di disponibilità dei dati, in termini di tempi di ripristino dei dati e massima perdita dei dati ammissibile. I tempi di retention dei backup dovrebbero essere coerenti con le esigenze di ripristino di dati passati ed eventuali cancellazioni. Le copie di backup dovrebbero essere protette contro il ransomware, attraverso cifratura, conservazione off-line, esecuzione dei backup con profili utente separati. Per garantirsi contro disastri ambientali e causati dall’uomo almeno una copia di backup periodica dovrebbe essere conservata in un’ubicazione remota (oltre 50-100 km dal datacenter).
8. Disaster recovery: il fornitore dei servizi cloud dove è installato l’applicativo dovrebbe fornire un piano di disaster recovery adeguato alle esigenze dell’organizzazione cliente.
9. Piano di Business Continuity: il fornitore dei servizi cloud deve prevedere un piano di continuità operativa che contempli, oltre al piano di DR, contromisure per garantire la disponibilità dei servizi a fronte di disastri ed altre situazioni di crisi non legate all’infrastruttura IT (come ad es. una pandemia, un incendio, un’alluvione, un terremoto, ecc.).
10.  Monitoraggio di log di accesso e sistemi antintrusione: dovrebbero essere implementate attività di monitoraggio dei log di accesso degli utenti e degli amministratori e di sistemi antintrusione (Intrusion Prevention System) e dei relativi log.
11. Sicurezza fisica ed ambientale del datacenter: il datacenter ove risiede il cloud dell’applicativo dovrebbe essere dotato di misure di sicurezza fisica ed ambientale come impianti antincendio e antiallagamento, sistemi di allarme e di videosorveglianza, controllo degli accessi fisici del personale, ecc..
12. Sicurezza informatica del datacenter: devono essere previste, a protezione dei dati ,misure quali firewall e anti-malware, gestione delle utenze amministrative/privilegiate e MFA sulla piattaforma cloud, monitoraggi/audit sulla sicurezza, censimento degli asset, ecc..
13. Sicurezza delle apparecchiature e dei servizi accessori: l’infrastruttura del datacenter deve essere dotata di adeguati sistemi di raffreddamento, sicurezza fisica dei cablaggi, misure di alimentazione di emergenza quali gruppi elettrogeni, ecc..
14. Conformità al GDPR dell’ubicazione del datacenter: i dati personali conservati in cloud dovrebbero comunque risiedere all’interno della UE o in un Paese per il quale esistono adeguate garanzie secondo quanto previsto dal Reg. UE 679/2016 e dalla Commissione Europea.

In sé la web application dovrebbe essere progettata con maschere video e funzioni che permettano di gestire il minor numero di dati personali possibile, consentendo agli utenti di visionare solo i dati effettivamente necessari per operare e prevedere la pseudonimizzazione dei dati nelle tabelle del database, separando i dati più sensibili dagli altri e rendendoli associabili all’individuo attraverso codici anonimi. Questi aspetti richiedono, però, una progettazione dell’applicativo già orientata alla protezione dei dati personali ed ai principi del GDPR, cosa non certo comune.

Naturalmente ognuna di queste misure di sicurezza potrà rivestire un’importanza diversa a seconda del tipo di dati gestiti nell’applicativo in cloud e della loro importanza o valore in termini di Riservatezza, Integrità e Disponibilità.

In conclusione, prima di adottare un software web per trattare dati riservati occorre esaminare bene anche questi aspetti per non trovarsi cattive sorprese in futuro.

Dopo l’introduzione – da parte di ACCREDIA su indicazioni IAF (si veda il documento IAF ID03 “Management of Extraordinary Events or Circumstances Affecting  ABs”,  CABs  and  Certified  Organization e la circolare ACCREDIA DC 02/2020) – della modalità di effettuazione degli audit a distanza legati alla certificazione dei sistemi di gestione, il recente articolo L’AUDIT A DISTANZA. CONSIDERAZIONI GENERALI, MODALITÀ DI GESTIONE E SPUNTI  OPERATIVI pubblicato sul sito ACCREDIA, fornisce alcuni spunti di riflessione sulle modalità operative di gestione degli audit da remoto che gli Organismi di Certificazione (OdC) hanno iniziato a svolgere per mantenere il ritmo delle attività di sorveglianza e rinnovo delle certificazioni dei sistemi di gestione.

L’attività di auditing ha evidentemente un discreto impatto sui contatti interpersonali: interviste a varie persone, consultazione di documenti cartacei, visualizzazione di documenti digitali e siti internet, visione di reparti produttivi, ecc..

Per non bloccare per molto tempo queste attività, soprattutto in questa Fase 2 dell’emergenza Coronavirus nella quale quasi tutte le attività produttive sono riprese, anche se molte persone continuano giustamente a lavorare in smartworking, gli audit in campo sarebbero comunque difficili da condurre nel rispetto dei vari protocolli aziendali che prevedono misure molto rigide nei confronti dei fornitori che potrebbero avere accesso all’azienda, compresi i consulenti e gli auditor degli OdC. Sebbene le regole applicate siano molto disomogenee e i protocolli approvati dal Governo siano oggi esagerati se applicati a singole persone che accedono ai locali aziendali, quali auditor e consulenti, l’approccio degli OdC sembra sia fortemente orientato a svolgere comunque gli audit pianificati con le modalità “a distanza”, come previsto da ACCREDIA.

L’articolo sopra menzionato – sebbene non costituisca una regola da seguire da parte degli OdC – fornisce molti interessanti spunti di riflessione per comprendere se svolgere gli audit a distanza, quando svolgerli e come svolgerli.

Questa opportunità, commercialmente molto favorevole per gli OdC che altrimenti si vedrebbero bloccate le attività ed i conseguenti ricavi per diverso tempo, dovrebbe essere sfruttata cum grano salis, effettuando preliminarmente una valutazione dei rischi basata su diversi elementi, che comprendono la tipologia dell’organizzazione auditata, il tipo di verifica, la norma di riferimento, la complessità dell’organizzazione e del suo sistema di gestione, ecc.

Il rischio che si corre nell’attuare questa nuova modalità è quello di non svolgere un audit efficace, ovvero di effettuare delle valutazioni non sufficientemente esaustive e corrette, ovviamente a tutto “vantaggio” dell’organizzazione auditata che si vedrebbe così ad essere certificata, ovvero a continuare ad esserlo, con una certa facilità.

L’analogia con la Didattica a Distanza (DAD) è pienamente calzante: come la verifica delle competenze degli alunni deve cambiare modalità per garantire un giusto livello di severità della scuola, così devono cambiare le modalità di raccolta e valutazione delle evidenze dell’audit.

Il rischio vero, però, è quello di sminuire ulteriormente un settore (quello delle certificazioni del sistema di gestione) che già ha perso molta credibilità a causa di audit troppo soft.

Certe tecniche estremamente efficaci utilizzate negli audit degli anni novanta, e non sempre riprese nel corso degli anni 2000, potrebbero non essere applicabili negli audit a distanza. Ad esempio prendere un DDT a caso di un prodotto in fase di spedizione e ripercorrere tutta la vita del prodotto “all’indietro”, ovvero richiedere evidenza dei controlli di produzione, dei controlli sulla materia prima, dei controlli sulle lavorazioni esterne, della qualifica dei relativi fornitori, degli ordini/contratti con i fornitori, della gestione dell’ordine del cliente (e relativi termini di consegna), dell’offerta e magari anche della progettazione del prodotto, se applicabile. Oppure scegliere a caso una commessa, un ordine o un prodotto e poi verificare tutti gli annessi e connessi.

Anzitutto bisognerebbe stabilire con precisione modalità e mezzi di conduzione di un audit a distanza. Ad esempio, quale piattaforma collaborativa utilizzare: quella stabilita dall’OdC o quella utilizzata dal cliente/organizzazione. La scelta non può essere dettata dal caso o dall’auditor di turno, spesso un consulente esterno, che magari sceglie a sua discrezione una piattaforma che conosce meglio. Infatti, nel corso dell’audit possono transitare anche informazioni di una certa riservatezza e l’impiego di una piattaforma che garantisca adeguate misure di sicurezza e rispetto per la privacy dei dati personali usata in modo corretto è sicuramente un requisito necessario. Recentemente si sono verificate violazioni di dati su piattaforme molto diffuse e, inoltre, la conservazione dei dati in cloud ubicati fuori UE non garantisce sempre il rispetto del Regolamento UE 679/2016 (GDPR).

Dato che l’audit è svolto sotto la responsabilità dell’OdC è il medesimo a dover assicurare la sicurezza dei dati che vengono trasmessi dall’organizzazione, la quale potrebbe avere qualcosa da obiettare nel fornire direttamente su file alcune informazioni riservate: un conto è far visionare un’offerta commerciale ad un auditor che viene presso la mia sede e che neanche volendo riuscirebbe a ricordarsi i dettagli una volta uscito dall’azienda, un conto è fornire direttamente all’auditor il file completo dell’offerta con prezzi, codici di articoli, modalità di fornitura, ecc. Se anche solo per superficialità o per inadeguatezza delle misure di sicurezza del notebook dell’auditor la stessa offerta finisse nelle mani di un concorrente quali sarebbero le conseguenze? Normalmente gli auditor esterni all’Ente di Certificazione utilizzano propri notebook, non controllati dall’OdC stesso, che vengono portati in viaggio e possono essere smarriti o rubati…. dovrebbero avere tutti gli hard disk cifrati.

Probabilmente sarebbe opportuno che certi documenti contenenti informazioni più riservate (o comunque classificati) non siano trasmessi dall’organizzazione auditata all’auditor via e-mail o condivisi attraverso la piattaforma di comunicazione, ma semplicemente visualizzati condividendo uno schermo, come tutti i software di videoconferenza consentono, da Microsoft Teams a Google Meet, da Skyoe a GoToMeeting, a Webex, ecc.

Alcune informazioni raccolte dall’auditor sono contenute in documenti digitali (es. verbali di riesame della direzione, rapporti di audit interni, procedure, ecc.) altri sono invece reperibili da un sistema informatico, dunque si può tranquillamente prevedere la condivisione dello schermo da parte di un responsabile dell’organizzazione che apre un sistema gestionale e mostra – esattamente come farebbe durante un audit in presenza – gli ordini del cliente, gli ordini di produzione, la pianificazione della produzione, i controlli eseguiti, ecc.. In questo modo l’auditor può mantenere il controllo dell’audit e farsi mostrare l’elenco di tutti gli ordini o commesse e scegliere autonomamente quella/a da visionare. In molte realtà aziendali il sistema gestionale produce offerte, conferme d’ordine del cliente, ordini di acquisto, ordini di produzione ed altro già in formato pdf pronto da essere stampato per i reparti interni o per essere trasmesso via e-mail al cliente o al fornitore, dunque trasmettere o semplicemente visualizzare nella video-riunione (per i motivi di riservatezza di cui sopra) questi documenti all’auditor dovrebbe essere molto semplice.

Le classiche riunioni di apertura e chiusura e le interviste a responsabili normalmente svolte negli uffici possono essere tranquillamente condotte in conference call con il supporto della condivisione dello schermo per visionare documenti in formato digitale oppure documenti cartacei opportunamente scansionati al momento, ma come svolgere le verifiche nei reparti produttivi?

La valenza di un audit in un’azienda manifatturiera è fortemente in dubbio: l’audit della produzione è praticamente obbligatorio in tutte le aziende produttive e potrebbe essere condotto efficacemente solo in certe realtà, connettendosi a terminali dell’ufficio produzione e controllo qualità, ma anche attraverso smartphone connessi con la videocamera accesa per poter visionare i reparti produttivi, intervistare operatori in produzione, raccogliere evidenze di strumenti utilizzati, macchine di produzione, materiale immagazzinato e così via. È evidente che l’azienda potrebbe “guidare” l’audit un po’ più del solito rispetto all’audit in presenza.

Uno degli elementi che ACCREDIA invita a considerare nella valutazione del rischio sulla conduzione dell’audit è costituito dalla conoscenza dell’organizzazione da parte dell’auditor: naturalmente un auditor che ha visitato già l’azienda due o tre volte è in grado di valutare anche da remoto cosa è opportuno visionare e cosa no. Nelle indicazioni di ACCREDIA si invita gli OdC a visionare anche i layout/planimetrie degli stabilimenti dell’organizzazione per decidere quali reparti sarebbe opportuno visionare, se sono stati visionati in passato e così via.

Il documento IAF MD4:2018 (IAF MANDATORY DOCUMENT FOR THE USE OF INFORMATION AND COMMUNICATION TECHNOLOGY FOR AUDITING/ASSESSMENT PURPOSES) costituisce la guida per gli OdC per la conduzione degli audit da remoto, così come la circolare ACCREDIA e il documento IAF ID03, ma poiché permangono molti dubbi sull’applicabilità di questa modalità in diversi contesti sono state pubblicate anche delle FAQ sul sito IAF (https://iaffaq.com/).

Certamente permangono alcune perplessità sull’applicazione degli audit a distanza nella verifica di sistemi di gestione ISO 14001, ISO 27001 e altri, piuttosto che di sistemi ISO 9001. Oltre che all’applicabilità ad aziende di produzione, imprese di costruzione, installatori e manutentori di impianti, società di ingegneria con direzioni lavori.

Infine, resta da valutare la competenza dell’auditor nel gestire le tecnologie utilizzate per la conduzione dell’audit a distanza ed eventualmente a colmarle.

Sicuramente l’audit a distanza o da remoto è una grossa opportunità per mantenere la continuità operativa degli Organismi di Certificazione e di tutto il mondo delle certificazioni e dell’accreditamento (anche ACCREDIA ha attuato gli audit da remoto), contenendo anche i costi di spostamento degli auditor, ma è importante mantenere alta l’attenzione affinché questa metodologia non riduca l’audit di certificazione ad una mera formalità, minacciando l’attendibilità di tutto il sistema delle certificazioni.

Soprattutto in questo periodo è estremamente attuale essere
in grado di pianificare la continuità operativa delle imprese, almeno per
quanto possibile.

Anche le aziende più preparate a gestire la business
continuity, forse, non hanno previsto una pandemia come quella del Covid-19,
o forse si erano prefigurati scenari diversi, nei quali le persone non sono in
grado di andare al lavoro a causa di epidemie di influenza o altre cause. In
questa fase che stiamo attraversando l’assenza di personale non è dovuta –
nella maggior parte dei casi – allo stato di malattia delle persone, ma alla
necessità di “isolamento sociale” delle risorse umane di un’intera azienda. Per
certi aspetti, dunque, il panorama è meno catastrofico, in quanto le persone
sono quasi tutte operative ed in grado di lavorare, ma non possono accedere
ai locali aziendali per un periodo di tempo che potrebbe essere considerevole.

Come potrebbe (o poteva) l’azienda lungimirante e preparata,
affrontare situazioni di emergenza come questa che stiamo attraversando? O
meglio, come potrà pensare di affrontarle in futuro se si verificheranno?

Ci viene in soccorso lo standard UNI EN ISO 22301 (Sicurezza e resilienza – Sistemi di gestione
per la continuità operativa – Requisiti titolo originale “Security
and resilience – Business continuity management systems – Requirements”),
recentemente revisionato (edizione 2019) e tradotto in italiano dall’UNI e
pubblicati a febbraio 2020.

Come già visto in un precedente articolo sulla vecchia versione della norma (pubblicata dall’ISO nel 2012) , lo standard specifica i requisiti per progettare, implementare e gestire efficacemente un Sistema di gestione della continuità operativa.

Le modifiche alla norma non hanno aggiunto nuovi
requisiti, ma solamente chiarito quelli già presenti, allineato la
norma alle altre norme sui sistemi di gestione e riorganizzato il capitolo 8,
vero cuore dello standard.

Il sistema di gestione della continuità operativa (business continuity management system o BCMS)
enfatizza l’importanza di:

• comprendere le esigenze dell’organizzazione e le necessità per
  stabilire la politica e gli obiettivi per la continuità operativa;
• gestire e mantenere processi, capacità e
  strutture di risposta per garantire che l’organizzazione sopravviva a
  interruzioni;

• implementare e rendere operativi controlli e misure per gestire la
  capacità di un’intera organizzazione nella gestione delle interruzioni (discontinuità)
  dell’operatività dovute a cause accidentali;
• monitorare e riesaminare le
  prestazioni e l’efficacia del sistema di gestione della continuità
  operativa;
• migliorare in modo continuo
  il BCMS basato su metriche qualitative e quantitative (obiettivi misurabili).

Si ricorda che anche la norma ISO/IEC 27031 “Information technology — Security techniques
— Guidelines for information and communication technology readiness for
business continuity” tratta la business continuity, ma nel contesto dell’ICT
e delle tecniche di sicurezza strettamente correlata alla ISO 27001 che
contiene i requisiti per la
certificazione dei sistemi di gestione della sicurezza delle informazioni.

La ISO 22301 evidenzia i componenti chiave del sistema di
gestione della continuità operativa, peraltro presenti anche in altri sistemi
di gestione. Tra essi la politica,
le persone con le loro responsabilità definite, la gestione dei processi correlati a
politica, pianificazione, attuazione e funzionamento del BCMS, valutazione
delle prestazioni, riesame di
direzione e miglioramento,
nonché le informazioni documentate in grado di fornire evidenze
verificabili anche tramite audit sul
sistema di gestione della continuità operativa.

Il vantaggio di disporre di un BCMS correttamente
funzionante è quello di far sì che l’organizzazione sia preparata – attraverso
processi, procedure, responsabilità, risorse, controlli, competenze, ecc. – a
mantenere l’operatività a seguito di un’interruzione, ovvero di un evento
destabilizzante (in inglese viene utilizzato il termine “disruption”) che
mina i processi operativi critici.

Anche questa norma recepisce il metodo del “PLAN DO CHECK ACT” già noto da altre
norme dei sistemi di gestione.

Per questa norma il concetto di “parti interessate” o stakeholders è molto importante in
quanto una discontinuità (interruzione) nell’operatività dell’organizzazione,
una indisponibilità dei servizi essenziali per i clienti, un fermo delle
attività produttive per un periodo più o meno lungo, possono causare danni, sia
dal punto di vista commerciale, sia da quello finanziario, ma anche da quello
delle altre parti interessate, quali personale interno, individui della
collettività che subiscono danni anche fisici, fornitori, ecc..

Scopo della norma per la gestione della business continuity
è quello di specificare i requisiti atti proteggere l’organizzazione da interruzioni
quando accadono, ma non solo. Il BCMS ha anche l’obiettivo di ridurre la
probabilità che tali eventi negativi avvengano, prepararsi ad essi e rispondere
in modo adeguato a ripristinare l’operatività nel più breve tempo possibile
qualora si verifichi un evento che provoca l’interruzione dell’operatività.
Naturalmente non si può pensare che un’azienda metta in atto azioni volte a
prevenire calamità naturali o pandemie, ma – facendo un esempio estremamente
attuale – una volta che sia stata conclamata un’epidemia su larga scala,
potrebbe porre in essere misure volte a prevenire il contagio fra i dipendenti e,
quindi, volte ad evitare che si verifichi un’interruzione totale dell’operatività
aziendale causata da un contagio interno molto diffuso. Questo, naturalmente,
al di là delle decisioni e delle disposizioni governative che hanno limitato l’operatività
di molte attività, ma non di tutte. Addirittura alcune aziende dovevano porsi l’interrogativo
se chiudere anticipatamente in base alla probabilità di contagio nella propria
zona fra personale dipendente.

La norma ISO 22301 definisce alcuni termini specifici sulla
materia tra cui il termine di continuità operativa (business continuity),
piano di continuità operativa (business continuity plan), analisi di
impatto operativo (business impact
analysis o BIA).

Oltre ad altri termini consueti delle norme della serie ISO
9000, altro termine significativo mutuato dalle norme della serie ISO 27000 è
quello di incidente che è definito
come “evento che può o potrebbe condurre ad un’interruzione, a una perdita,
a un’emergenza o a una crisi” Al proposito la norma utilizza spesso il
termine interruzione che
rappresenta “un incidente che causa una deviazione negativa, non pianificata
dell’erogazione prevista dei prodotti e servizi secondo gli obiettivi di un’organizzazione”;
modificando significativamente la definizione della precedente versione della
norma, forse più concreta e facilmente comprensibile ai più.

Verranno successivamente introdotti dalla norma degli
indicatori specifici per questa tematica come:

• Maximum
  Tolerable Period of Disruption (MTPD) ovvero
  il tempo massimo accetabile che può trascorrere a fronte degli impatti
  negativi conseguenti ad una interruzione come risultato della mancata
  fornitura di un prodotto, erogazione di un servizio o svolgimento di un’attività
  operativa.
• Recovery Time Objective (RTO):
  periodo di tempo entro il quale – dopo l’interruzione – i servizi erogati,
  la produzione, i servizi di supporto e le funzionalità operative devono
  essere ripristinati ad un livello minimo accettabile.

Il capitolo 4 della norma denominato “Contesto dell’organizzazione” contiene
gli elementi per comprendere il contesto dell’organizzazione, tra cui i fattori
interni ed esterni che influenzano la sua capacità di conseguire i risultati
del BCMS. La norma stabilisce che nell’ambito del Sistema di gestione per la
continuità operativa debbano essere identificati i requisiti dell’organizzazione e delle sue parti interessate, che
dovranno essere tenuti in debito conto nella progettazione del sistema di
gestione dell’organizzazione

Tra i requisiti da prendere in considerazione viene dedicato
un punto specifico ai requisiti legali e regolamentari, ovvero quei
requisiti cogenti che determineranno gli obiettivi di minima del BCMS e dei
piani di continuità operativa. Ciò aiuterà nella definizione dello scopo e campo di applicazione del sistema di gestione
di continuità operativa. A tale riguardo la norma stabilisce le modalità
attraverso le quali l’organizzazione deve stabilire i confini del BCMS e quali
processi, prodotti e servizi sono compresi nel sistema di gestione e quali
parti dell’organizzazione agiscono all’interno di esso, dettagliando eventuali
esclusioni che, comunque, non possono influenzare negativamente i risultati del
sistema di gestione ed i livelli di operatività stabiliti nell’analisi di
impatto.

Al punto 4.4 la norma stabilisce che l’organizzazione deve
implementare, mantenere attivo e migliorare continuamente un sistema di
gestione della continuità operativa, inclusi i processi necessari e le relative
interazioni fra essi, in accordo con i requisiti di questo standard
internazionale (ISO 22301).

Il capitolo 5 della norma è denominato “Leadership”. In esso la norma
stabilisce che l’alta direzione (ovvero il top
management) deve possedere leadership e dimostrare un impegno preciso
rispetto al sistema di gestione per la continuità operativa. L’impegno del management
viene poi esplicitato attraverso una serie di responsabilità della direzione
relative al sistema di gestione quali, ad esempio, assicurare che politiche ed obiettivi
siano stabiliti, che le risorse necessarie siano messe a disposizione e che vi
sia un’adeguata comunicazione all’interno dell’organizzazione relativamente ai
requisiti del sistema di gestione della continuità operativa.

Sono poi stabiliti requisiti relativi alla definizione della
politica per la continuità operativa
e la definizione della struttura
organizzativa dell’organizzazione, quindi la definizione di ruoli
responsabilità ed autorità.

Il capitolo 6, denominato “Pianificazione” stabilisce che:

• L’organizzazione deve attuare
  azioni rivolte ad affrontare i
  rischi ed alle opportunità, in particolare assicurando che il sistema riesca
  a perseguire gli obiettivi ed i risultati stabiliti, prevenire o ridurre
  gli effetti indesiderati sul BCMS e mirare al miglioramento continuo.
• Vengano definiti obiettivi per la business continuity e soluzioni/piani per raggiungerli;
  tale aspetto, con le dovute modifiche, è del tutto analogo ad altri
  sistemi di gestione: gli obiettivi devono essere misurabili, devono essere
  monitorati, occorre stabilire chi è responsabile, che cosa deve fare,
  quali risorse sono richieste, quando dovranno essere completate le azioni
  finalizzate al perseguimento degli obiettivi e come dovranno essere
  valutati i risultati. Unica differenza rispetto ad altri sistemi di
  gestione è che nella definizione degli obiettivi bisognerà tenere conto di
  un livello minimo di servizio o di prodotto fornito ritenuto accettabile
  dall’organizzazione nel raggiungimento dei suoi obiettivi.

Viene anche chiarito, in una nota, che i rischi di questa
sezione sono quelli che influenzano l’intero BCMS, non i rischi che minacciano
la continuità operativa, trattati al successivo punto 8.2.

Il capitolo 7 della norma denominato “Supporto” stabilisce i requisiti per
alcune attività e processi di supporto, quali – in generale – la gestione delle risorse, le competenze del personale, la consapevolezza dello stesso personale
relativamente al sistema di gestione della continuità operativa e la comunicazione, sia essa interna che
esterna. In particolare, per questo tipo di sistema di gestione, le modalità ed
i mezzi di comunicazione sono molto importanti per garantire la continuità del
servizio anche durante i periodi di indisponibilità delle risorse critiche.

Infine, l’ultima parte di questo capitolo è dedicato alle informazioni documentate, i cui
requisiti relativi riguardano le modalità di gestione di documenti, dei dati e
delle registrazioni richieste dalla norma.

A questo riguardo è opportuno precisare che, nell’ambito
della business continuity, i
documenti – in particolare i piani, le procedure e le istruzioni operative –
necessarie per ripristinare nel più breve tempo possibile i servizi richiesti
durante i periodi di crisi successivi ad un’interruzione, dovrebbero essere
accessibili dai responsabili nominati, dunque occorre prevedere supporti
alternativi per i documenti che potrebbero non essere disponibili nel formato
originario, su supporto elettronico o cartaceo. Pertanto, tali documenti
dovrebbero essere resi disponibili su supporti ed ubicazioni realmente
utilizzabili in funzione del tipo di crisi (scenario) previsto in fase di pianificazione.

Il capitolo 8 della norma, denominato “Attività operative”, è quello che è
stato maggiormente modificato rispetto alla versione precedente della norma e rappresenta
il cuore della ISO 22301 in quanto tratta gli aspetti di pianificazione e controlli
operativi, l’analisi di impatto e la valutazione dei rischi e, infine, la strategia di business continuity e le
relative soluzioni adottate, ovvero tutto ciò che l’organizzazione intende fare
per garantire la continuità operativa, compresa la definizione dei business
continuity plan o piani di continuità operativa, la loro applicazione e
test/esercizio.

Nei suddetti paragrafi sella sezione 8 vengono specificate,
tra l’altro, le modalità di effettuazione e documentazione della analisi di impatto operativo e della valutazione del dei rischi, per la quale può essere preso come
riferimento quanto indicato nella ISO 31000 (UNI ISO 31000 – Gestione del rischio – Principi e linee guida). Occorre
precisare che sia l’analisi di impatto sia la valutazione dei rischi dovranno
prendere in considerazione i rischi che possono impattare la continuità
operativa, quindi i rischi che si verifichino incidenti distruttivi che portino
a situazioni di crisi o di interruzione dell’operatività e, conseguentemente, a
situazioni insostenibili per i requisiti stabiliti di continuità operativa e
per la propensione al rischio dell’organizzazione. A fronte di tali situazioni,
in base ai risultati della valutazione dei rischi, dovranno essere determinate
e poste in essere le azioni conseguenti per mantenere la continuità operativa.

Le soluzioni per garantire la continuità operativa
devono essere finalizzate a:

• rispettare i requisiti di continuità e di
  recupero delle attività prioritarie entro le tempistiche prestabilite e
  capacità concordate;
• proteggere le attività prioritarie dell’organizzazione;
• ridurre le probabilità di un’interruzione;
• accorciare la durata di un’interruzione entro
  limiti tollerabili;
• limitare l’impatto di un’interruzione sui
  prodotti e servizi dell’organizzazione;
• provvedere alla disponibilità di risorse
  adeguate a poter affrontare le situazioni di crisi.

Le soluzioni identificate devono essere scelte in base ai
requisiti da soddisfare, i rischi ritenuti accettabili, i costi ed i benefici. Per
attuarle dovranno essere stabiliti i requisiti e le necessità di risorse umane,
tecnologiche, infrastrutturali, ecc.

Il punto 8.4 della norma fornisce indicazioni su come progettare
i piani di continuità operativa e le procedure da mettere in atto per
garantire la continuità operativa dell’organizzazione a fronte di un’interruzione.

Il capitolo 9 della norma tratta la “Valutazione delle prestazioni”. Vengono
qui illustrati i requisiti relativi al monitoraggio,
alle misurazioni, all’analisi ed
alla valutazione dei processi che
hanno un impatto sulla continuità operativa; in particolare vengono esplicitati
i requisiti relativi ad indicatori e
metriche finalizzate al monitoraggio
dell’efficacia del BCMS.

Nel capitolo 9 vengono anche trattati i requisiti
standard per i sistemi di gestione riguardanti gli audit interni ed il riesame di
direzione. Anche qui, rispetto alle altre normative sui sistemi di gestione,
il focus è sui rischi risultanti dall’analisi di impatto e sul risk assessment.

Nel capitolo 10, denominato “Miglioramento”, sono trattati le non conformità, le azioni correttive ed il miglioramento
continuo. Relativamente a non conformità ed azioni correttive la gestione è
analoga ai sistemi gestionali descritti nelle altre normative sui sistemi di
gestione (ISO 9001 in primis). Sono inoltre introdotte le azioni che vengono
messe in atto al fine di perseguire il miglioramento continuo del sistema e
delle sue prestazioni.

Premesso ciò, le non conformità relative al sistema di
gestione della continuità operative – normalmente incidenti ed altri eventi che hanno generato interruzioni oltre
ad altre situazioni nelle quali si verifica il non soddisfacimento dei
requisiti procedurali – dovranno essere identificate e dovranno essere attuate
prontamente correzioni per eliminare, quando possibile, gli effetti della non
conformità stessa e le relative conseguenze. Inoltre, si deve valutare la
necessità di intraprendere azioni correttive finalizzate ad eliminare le cause
della non conformità.

In conclusione, le organizzazioni che vorranno adeguarsi a tale
normativa e certificarsi secondo le proprie esigenze di business, quasi
certamente avranno già messo in atto e certificato un sistema di gestione per
la qualità ISO 9001, ma probabilmente alcune di queste organizzazioni avranno
anche già implementato il sistema di
gestione della sicurezza delle informazioni ISO 27001, pertanto lo sforzo
per conformarsi a questa norma sulla business
continuity non sarà eccessivo. Infatti, molti requisiti sono comuni fra la
norma ISO 22301 e la norma ISO 27001 nella quale esiste già un obiettivo di
controllo riguardante la continuità operativa che impone di predisporre uno o
più business
continuity plan per garantire la continuità nell’erogazione del
servizio o nella produzione, ma a fronte di interruzioni dovute a
indisponibilità di informazioni.

Al proposito occorre notare che la norma tratta la gestione
di tutti i tipi di discontinuità o interruzioni di servizio, non
necessariamente solo quelli legati all’indisponibilità dei sistemi informatici,
anche se quasi tutte le organizzazioni vedono come principale pericolo per la
propria continuità operativa il blocco dei sistemi informatici che ormai
governano quasi tutte le attività aziendali.

Gli esempi di situazioni nelle quali la continuità operativa
non è minacciata da interruzioni e disastri legati ai sistemi informatici sono
sotto i nostri occhi in questo periodo.