Se dovessi scegliere una sola parola per indicare cosa il legislatore europeo ritiene essere la caratteristica più importante per imprese e pubblica amministrazione nel contesto digitale e ICT, sceglierei “resilienza”.
Facciamo un veloce calcolo: resilienza compare 101 volte nella Direttiva CER, 91 volte nel Reg. DORA, 12 volte nella NIS2. Poi ancora quattro volte nel Data Act, tre nell’AI Act e, per chiudere, un’ultima volta nel GDPR. Il Cyber Resilience Act, poi, la mette nel titolo.
Non che dalla frequenza si possa desumere il peso giuridico di un concetto, chiaramente. Quell’unica occorrenza nel GDPR, infatti, impone la resilienza di sistemi e servizi di trattamento «su base permanente». Una sola richiesta piuttosto impegnativa, se ci pensiamo.
Come dovremmo giudicare la nostra idea di compliance se prendiamo la parola “resilienza” sul serio?
Indice degli argomenti
La resilienza come antidoto all’obsolescenza della compliance
In una risposta pubblicata su Reddit nel 2015, Elon Musk suggeriva di pensare alla conoscenza come a un albero semantico. Per imparare qualcosa occorre comprendere prima i principi fondamentali, il tronco e i rami principali; soltanto dopo ha senso occuparsi delle foglie, dei fiori e dei dettagli.
Altrimenti manca ciò a cui collegarli. È un’immagine che mi piace molto, che sento vera e che soprattutto trovo utile anche per il diritto (in particolare, quello del digitale).
Le foglie sono moltissime: obblighi informativi, valutazioni, registrazioni, notifiche, clausole contrattuali, misure tecniche. Ciascuna ha una funzione. Ma se cominciamo a raccoglierle senza capire come si tengano insieme, possiamo accumulare una grande quantità di adempimenti senza aver compreso il progetto o, come si dovrebbe dire, la ratio della norma. Non avremo un bel castagno, ma un sacco della spazzatura.
Dalla resistenza alla capacità di adattarsi
La resilienza, nel contesto in esame, è una parola importante perché ci aiuta a puntare lo sguardo verso il tronco: la resilienza è la capacità dell’organizzazione di continuare a proteggere persone, dati e servizi mentre cambiano le condizioni in cui opera. È una richiesta che attraversa settori economici, contesti, discipline: la flessibilità di saper attuare, nel continuum del tempo, obblighi e tutele.
Parlo di flessibilità perché è ciò che, a livello semantico, aggiunge qualcosa al concetto di resistenza per trasformarla in resilienza. La resistenza misura la capacità di opporsi e resistere, appunto. La resilienza indica la capacità di assorbire e adattarsi. Un’organizzazione non deve solamente essere forte abbastanza da resistere, ma anche avere la capacità di riconoscere le perturbazioni, saperne contenere gli effetti, saperci convivere, quindi migliorare. È l’arte del saper cambiare; una capacità profondamente umana, che le organizzazioni devono coltivare anche mentre affidano sempre più attività alla tecnologia.
Quando la compliance si scolla dalla realtà
C’è poi un tema meno visibile rispetto al consueto affanno che si crea attorno ad ogni arrivo di norme nuove: la compliance invecchia, va in obsolescenza, anche quando la legge non è mutata. Resilienza è, allora, anche la capacità di mantenere flessibile la propria struttura di compliance, intesa come persone, procedure, flussi, controlli, sistemi.
I cambiamenti che rendono obsoleto un presidio
Pensiamo a un piano di gestione degli incidenti predisposto con cura. Le persone coinvolte conoscono i propri compiti, i contatti sono corretti, le procedure corrispondono ai sistemi utilizzati. Poi un responsabile cambia ruolo, una funzione viene esternalizzata, entra un nuovo fornitore, un’applicazione diventa essenziale per un servizio che prima poteva farne a meno, un sistema AI rivoluziona il modo di fare che era prassi aziendale. Il piano rimane identico, ma l’organizzazione è andata avanti.
Non mi sto riferendo a casi di consulenza svolta male o di adempimenti puramente cosmetici (la c.d. paper-compliance). Il presidio poteva essere sensato, proporzionato e funzionante quando è stato adottato. Ma questo presidio, ad un certo punto, può essersi scollato dalla realtà. Eppure, la sua presenza continua a rassicurare: il piano c’è, è stato approvato, qualcuno lo ha anche firmato.
Potremmo chiamarla obsolescenza della compliance. Una distanza crescente fra le condizioni sulle quali abbiamo costruito un presidio e quelle nelle quali pretendiamo che continui a funzionare.
Il problema si manifesta con più probabilità quando l’adeguamento è affidato a professionisti che lavorano separatamente, consegnano ciascuno la propria parte e poi escono di scena. Chi ha curato gli aspetti giuridici non incontra chi gestisce i sistemi; chi acquista un servizio non sa quali valutazioni dovrebbero essere riaperte; chi riceve una segnalazione non conosce la persona in grado di interpretarla.
L’adeguatezza, insomma, ha anche una dimensione temporale.
Manutenzione e controlli contro l’obsolescenza dei presidi
Da questa osservazione discende una conseguenza pratica: quando realizziamo un presidio dobbiamo progettare anche il modo in cui verrà mantenuto. Chi ne risponde? Da chi riceve informazioni? Quali cambiamenti ne richiedono il riesame? Come ci accorgiamo che sta perdendo efficacia?
Revisioni, prove e responsabilità della compliance
Una revisione periodica è utile, ma tra due revisioni può cambiare molto. L’introduzione di una tecnologia, la sostituzione di un fornitore, una diversa destinazione dei dati, un incidente o una prova fallita dovrebbero poter attivare una valutazione a prescindere dal calendario.
Per farlo, serve un allenamento specifico. Leggere una procedura non equivale a saperla usare quando il sistema è indisponibile e le informazioni arrivano incomplete. Serve provare, con le persone che dovranno decidere: chi riconosce il problema, chi lo valuta, chi può interrompere un servizio, chi comunica e a chi. È anche durante queste prove che funzioni abituate a lavorare separatamente imparano a conoscersi.
Naturalmente, l’obiettivo non può essere riscrivere tutto di continuo. Un documento datato può descrivere ancora un presidio efficace; uno aggiornato ieri può essere già fuori dalla realtà. La manutenzione va rivolta alla capacità concreta dell’organizzazione. Il documento deve seguirla e saperla raccontare, rendendo verificabili le scelte compiute, le attività svolte e i loro esisti. E’ questo il senso dell’accountability,
Backup e ripristino: la compliance alla prova della resilienza
Torniamo al buon vecchio GDPR per un primo esempio piuttosto esplicito. L’art. 32, par. 1, lett. b), c) e d) collega la resilienza permanente alla capacità di ripristinare tempestivamente disponibilità e accesso ai dati personali e a una procedura per testare, verificare e valutare regolarmente l’efficacia delle misure.
Verificare che i dati siano davvero recuperabili
Supponiamo che, in un determinato contesto, sia stato individuato un sistema di backup come parte delle misure necessarie. Acquistarlo, configurarlo e descriverlo nella documentazione sono passaggi utili. Per capire se il presidio resta adeguato occorre anche verificare che i dati siano recuperabili, in tempi coerenti con i rischi del trattamento, e che qualcuno sappia effettivamente recuperarli.
Se l’organizzazione aggiunge una nuova applicazione, quei dati entrano nel perimetro del backup? Se la persona che conosceva la procedura non è disponibile, un’altra riesce a eseguirla? Se il ripristino impiega molto più tempo del previsto, chi valuta le conseguenze e decide gli interventi?
La resilienza entra nel presidio quando queste domande trovano un responsabile, una prova concreta e, dove occorre, una correzione verificata. L’esito della prova modifica le scelte tecniche, la formazione o la valutazione del rischio. Conservare soltanto il verbale lascerebbe intatto il problema.
DORA e il ciclo di apprendimento della compliance
Il secondo esempio viene da DORA. È significativo che il suo art. 13 sia intitolato “Apprendimento ed evoluzione”. Nel quadro ordinario di gestione del rischio informatico, gli insegnamenti ricavati dagli incidenti e dai test previsti dalla norma devono alimentare la valutazione dei rischi e le revisioni dei presidi. L’art. 24 chiede alle entità finanziarie diverse dalle microimprese di mantenere e riesaminare un programma di test e di affrontare le carenze emerse, verificando che siano state risolte.
Dalla simulazione alla correzione verificata
Immaginiamo una simulazione nella quale un servizio essenziale diventi indisponibile. I tecnici individuano il problema, ma il referente del fornitore è irreperibile. La funzione legale riceve informazioni troppo vaghe; chi dovrebbe autorizzare una soluzione temporanea non sa quali rischi comporti. La prova ha fatto emergere una debolezza che difficilmente avremmo trovato controllando la sola esistenza delle procedure.
Per correggerla potrebbero servire un diverso accordo con il fornitore, informazioni minime da trasmettere fra le funzioni, sostituti individuati in anticipo, poteri decisionali più chiari. A ogni intervento occorre associare qualcuno che lo realizzi, un termine e una verifica. La prova successiva dovrà consentire di capire se l’organizzazione ha davvero imparato.
È questo il passaggio che rende la compliance viva. La realtà produce informazioni; le persone le interpretano; le decisioni modificano i presidi; nuove verifiche consentono di valutarne l’effetto. Se la sequenza si interrompe dopo la raccolta delle evidenze, l’obsolescenza prosegue anche in un’organizzazione molto diligente nel documentare le proprie attività.
Torniamo allora alla domanda iniziale. Il legislatore insiste sulla resilienza perché le tutele devono continuare a funzionare in condizioni che non possiamo fissare una volta per tutte. Un incidente non dimostra, da solo, che ogni misura fosse inadeguata. Allo stesso modo, l’assenza di incidenti non ci dice quanto ancora possiamo affidarci a un presidio che abbiamo smesso di osservare.
Un progetto di adeguamento può avere una data di chiusura. La responsabilità di mantenere adeguati i suoi risultati vive di giorno in giorno.
Partecipa alla community