Gli allegati A e B al Codice di condotta approvato dal Garante per la protezione dati con il provvedimento n.618 del 17 ottobre 2024 contengono misure organizzative e tecniche per lo sviluppo di applicazioni gestionali in ottica privacy by design e by default, nonché per la gestione e supporto dei sistemi sia on premise che in cloud.
Rappresentano dunque un importante punto di riferimento per i rapporti fra i ruoli soggettivi del trattamento, ed i punti di controllo possono essere utilizzati in comode checklist per la prequalificazione o per il monitoraggio dei fornitori. Vediamo come.
Indice degli argomenti
Gli allegati A e B al Codice di condotta per le imprese di sviluppo e produzione di software gestionale
Si è già scritto molto sull’importanza di questo recente Codice di Condotta, promosso da AssoSoftware con l’intento di rafforzare gli obiettivi di fiducia fra committenti e fornitori digitali, in conformità all’Art. 40 del GDPR.
Una attenta lettura per una piena comprensione dei 22 articoli di questo Codice di condotta, approvato dall’Autorità Garante per la protezione dati personali con il Provvedimento del 17 ottobre 2024 – n. 10075998 – scritto tra l’altro in modo molto chiaro e semplice proprio per aiutare anche le piccole imprese di sviluppo e gestione di soluzioni gestionali, è essenziale per acquisire una piena consapevolezza dei ruoli soggettivi rispetto ai trattamenti di dati personali, e ciò non vale soltanto per le software house, ma anche per le Organizzazioni che selezionano tali società per acquistare soluzioni applicative ed i relativi di gestione e assistenza.
Se per l’adesione al Codice di Condotta è obbligatoria l’applicazione delle misure previste negli Allegati A e B, è ormai noto a tutti gli addetti ai lavori che tali misure costituiscono ormai un nuovo “stato dell’arte” – per cui le aspettative delle organizzazioni committenti non possono non tenerne conto, allo stesso modo in cui le Linee Guida ACN – ad esempio quelle sugli algoritmi di hashing delle passwords – vengono considerate una sorta di “misure minime di sicurezza”.
Vediamo dunque questi allegati A e B, che contengono tabelle con punti di controllo che possono avere interessanti risvolti applicativi, suddivise in :
- Misure tecniche e organizzative applicate dalle SWH per garantire i requisiti di Privacy by Design e by Default nelle Attività di sviluppo dei Software Gestionali;
- Misure di sicurezza applicate per lo svolgimento dei Servizi riguardanti i Software Gestionali impiegati nei contesti “on-premise”;
- Misure di sicurezza applicate per lo svolgimento dei Servizi riguardanti i Software Gestionali impiegati nei contesti in cloud.
Ogni tabella contiene elenchi di misure suddivise per ambito, catalogazione, requisito di dettaglio, riferimenti a controlli di Standard ISO o alle Misure minime di sicurezza ICT per le pubbliche amministrazioni” emanate dall’AgID, e i parametri della proprietà della sicurezza delle informazioni (Riservatezza, Integrità, Disponibilità e, per i Servizi online, la Resilienza).
Come preparare delle semplici checklist
Perché preparare delle Checklist con queste 3 tabelle? La risposta è molto semplice: la checklist è forse lo strumento che meglio riesce a rendere il più oggettivo e standard possibile qualsiasi processo di controllo, verifica e audit.
Ad esempio una società di sviluppo software che volesse aderire al codice di condotta, dovrà valutare progressivamente il grado di applicazione delle misure inserite negli allegati A e B (con le diverse peculiarità dello svolgimento dei servizi). Inizialmente, è possibile che una tale misura non sia ancora implementata, ma poi, lavorando con processi di miglioramento, dovrà portare quel requisito ad essere pienamente soddisfatto.
Quindi una prima applicazione della Checklist è proprio il monitoraggio dei diversi requisiti e punti di controllo, fino ad una piena applicazione.
Il primo, più immediato strumento che possiamo utilizzare è un foglio di calcolo elettronico.
Le 3 Tabelle possono dunque essere create in 3 sheet, come nell’immagine rappresentata sotto.
Ovviamente un foglio di calcolo, con i filtri, consente anche di ricercare velocemente anche gli attributi delle Tabelle, che abbiamo visto essere ambito, catalogazione, requisiti di dettaglio, riferimenti e parametri.
Dobbiamo però aggiungere ulteriori attributi per valutare i gradi di applicazione, con punteggi; dobbiamo dunque stabilire dei criteri. Ad esempio, considerando ogni misura/requisito un punto di controllo con uno specifico grado di applicazione, nello sheet Criteri possiamo inserire dei valori come quelli esposti nell’immagine che segue.
Nell’esempio, viene utilizzata una semplice ratio per il grado di applicazione di una misura, con punteggi crescenti da 1 a 4, che va dall’inadeguato, al parzialmente adeguato, al quasi adeguato, fino allo stato di adeguato, verificato e ben applicato (oltre al valore 0 per il non applicabile).
Nelle tabelle, si specifica poi per ogni misura un grado di applicazione, che restituisce il relativo punteggio.
Si può sviluppare un software, per gestire una checklist, ma i fogli elettronici sono di semplice e rapida realizzazione, e sono davvero alla portata di tutti.
Nell’immagine che segue, un esempio applicato alla Tabella dell’Allegato A A al codice di condotta.
Come si può facilmente notare, le prime colonne non sono altro che il contenuto nelle tabelle (Allegati in formato grafico) al codice di condotta; la colonna RID, però, è stata suddivisa in 3 colonne per potere selezionare, e anche contare, i parametri R – I – D (nella seconda Tabella dell’Allegato B sui Servizi Cloud, va aggiunta la colonna Res per la resilienza).
Il valore da imputare per ogni punto di controllo è appunto il grado di applicazione – con il relativo score ottenibile ediante una semplice formula “CERCA.VERT” nella tabella dei criteri. Inoltre, c’è una colonna note e giustificazioni nella quale andrebbero inseriti i motivi per l’assegnazione del grado di applicazione, e altri appunti (es. programmazione di attività, redazione di procedure in corso, etc.).
In questo modo, si realizza facilmente una Gap analysis rispetto alla piena applicazione di tutte le misure previste.
Inoltre, viene da sé che per chiunque abbia un po’ di dimestichezza con i fogli di calcolo, grazie a qualche formula come “SOMMA” o “CONTA.SE” si possono inserire in fondo alcuni totali e percentuali, come evidenziato nell’immagine rappresentata di seguito.
Contando poi il numero di controlli che hanno come grado di applicazione 1 – inadeguato, 2, parzialmente adeguato, etc. in pochi minuti si possono impostare grafici di sintesi, come quello mostrato nell’immagine sotto.
Ovvio che la condizione a cui tendere è una piena applicazione delle misure, sicuramente necessaria per l’adesione al Codice di condotta, ma anche, a tendere, per superare verifiche da parte delle Organizzazioni committenti; si deve dunque ambire ad una torta completamente verde.
Chiaramente, le metriche ed i criteri possono essere impostati a proprio piacimento. Negli esempi rappresentati, si è scelto un quadro comune di indicazione del livello di applicazione di una misura. Anche l’indicazione dell’efficacia dei parametri RID e Resilienza può risultare molto utile, perché ricordiamo che un titolare del trattamento, nella propria valutazione dei rischi, deve sempre includere le valutazioni svolte dai propri fornitori, in caso di affidamento di attività all’esterno, e per la mitigazione degli scenari di sicurezza dei trattamenti l’efficacia dei controlli posti in essere, anche in termini RID e Resilienza, è importantissima.
Esempi di utilizzo per i fornitori tecnologici
Come già spiegato, utilizzare una checklist del genere, in fase di preparazione per l’adesione al codice di condotta promosso da AssoSoftware e approvato dall’Autorità Garante per la protezione dati personali, aiuta nel processo; sia per una prima Gap Analysis, sia per monitorare nel tempo i miglioramenti. Suggerirei però anche di creare un’ulteriore checklist basata sugli adempimenti previsti negli articoli del codice di condotta.
Ovviamente, quanto riportato nel grado di applicazione delle misure deve corrispondere a verità. La sicurezza non si risolve di certo con un grafico colorato in un foglio di calcolo; quanto scritto deve effettivamente rappresentare gli sforzi compiuti. Se quanto scritto è distante dalla realtà delle cose, un Audit dell’organismo di monitoraggio, o una verifica da parte di un’Organizzazione Cliente lo evidenzieranno chiaramente. Chi, come lo scrivente, esegue Audit GDPR già da tempo, entrando nel merito di aspetti anche tecnici, è ben preparato a scovare tali “distanze” fra quanto detto e quanto effettivamente applicato.
Esempi di utilizzo per la prequalificazione e la selezione dei fornitori da parte delle Organizzazioni pubbliche e private
Le Organizzazioni che si accingono invece ad acquisire soluzioni applicative gestionali da fornitori, ovvero a far gestire a fornitori i servizi di assistenza, sia on premise che in cloud, es. in modalità SaaS, potranno invece far compilare una checklist del genere in fase di selezione e prequalificazione, anche al fine di valutare le garanzie di affidabilità di cui all’Art. 28 p.1 GDPR – che – ricordiamo – è probabilmente più importante dell’Accordo protezione dati di cui all’Art. 28 p.3 del GDPR.
Inoltre, come giù spiegato, saggiare la capacità dell’impresa sviluppatrice o erogatrice di servizi in termini di efficacia delle misure a protezione del trattamento è fondamentale nella valutazione dei rischi.
A tal proposito, è bene rammentare che:
- L’individuazione degli scenari di rischio che possono ledere i rischi e le libertà è sempre a carico del titolare; come spiegato anche nel codice di condotta, gli aspetti relativi alla liceità, correttezza, trasparenza, pertinenza e adeguatezza, compatibilità della finalità, minimizzazione e limitazione della conservazione sono sempre in capo al Titolare del trattamento; nella progettazione di una soluzione applicativa, ad ogni modo il responsabile, al fine di ottenere la fiducia dei committenti, deve inserire dinamiche di privacy by design e by default per garantire la conformità al GDPR. Nell’esercizio, poi, sono più che altro gli aspetti correlati alla sicurezza del trattamento quelli che vedono coinvolto il responsabile, che appunto dovrebbe poter proteggere i dati come asset informativi (da qui il richiamo alle proprietà della sicurezza dell’informazione, ossia riservatezza, integrità, disponibilità, e resilienza).
- Una checklist del genere NON è uno strumento di valutazione dei rischi; può aiutare a comprendere l’efficacia della mitigazione, ma non si parte mai dai controlli per valutare i rischi.
Creare consapevolezza e fiducia
In uno scenario di progressiva iper-regolazione per limitare i rischi derivanti dai trattamenti di dati personali, il Codice di condotta promosso da AssoSoftware ed approvato dal Garante per la protezione dati personali si conferma uno strumento che, a prescindere dall’adesione, può creare consapevolezza e fiducia. Ben scritto, semplice e alla portata di tutti, prevede Allegati molto utili.
Abbiamo visto come riportare le tabelle in semplici fogli di calcolo, e impostare criteri di applicazione, può aiutare, anche in modo pressochè gratuito, sia le imprese di sviluppo e gestione servizi relativi a software gestionali, sia le Organizzazioni clienti.
Bibliografia
Provvedimento del 17 ottobre 2024 – Codice di condotta per il trattamento dei dati personali effettuato dalle imprese di sviluppo e produzione di software gestionale [10075998] dell’Autorità Garante per la protezione dati personali – https://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/10075998
