Compliance di carta o sicurezza reale: il rischio nascosto delle normative cyber
Le nuove regole europee sulla sicurezza digitale stanno spingendo aziende e pubbliche amministrazioni a produrre policy, registri e procedure. Ma il punto decisivo resta un altro: quei documenti descrivono una capacità operativa reale o solo un ordine apparente?
Una crisi cyber raramente somiglia a un audit.
Non concede giorni per recuperare un documento, non aspetta che il responsabile sia disponibile, non segue l’ordine delle slide preparate per il board. Arriva quando un servizio non risponde più, quando i clienti iniziano a chiamare, quando un fornitore non garantisce tempi certi, quando il backup diventa improvvisamente l’unica cosa che separa l’azienda dal blocco operativo.
In quel momento la compliance mostra il suo vero valore. O il suo limite.
La procedura può anche esistere. Ma se nessuno l’ha mai provata, se il ripristino non è stato testato, se la catena decisionale è incerta, se i fornitori critici sono stati censiti senza comprenderne l’impatto reale, allora l’organizzazione scopre una cosa scomoda: essere ordinati sulla carta non significa essere pronti nella crisi.
È il rischio nascosto delle normative cyber. Non l’obbligo di fare compliance, ma l’illusione che la compliance basti.
Il paradosso della compliance
Le normative europee sulla sicurezza digitale stanno alzando il livello delle responsabilità per imprese, pubbliche amministrazioni e fornitori tecnologici. NIS2, DORA, GDPR, AI Act e Cyber Resilience Act spingono tutte nella stessa direzione: più governance, più tracciabilità, più controllo, più capacità di dimostrare cosa è stato fatto.
Il problema nasce quando questa spinta viene tradotta solo in produzione documentale.
La documentazione è necessaria. Senza policy non ci sono regole. Senza registri non c’è tracciabilità. Senza procedure non c’è metodo. Senza evidenze non esiste controllo. Ma un documento, da solo, non ferma un ransomware, non ripristina un servizio, non contiene una violazione e non coordina una crisi.
Il paradosso è qui. Un’organizzazione può apparire matura perché ha fascicoli completi, responsabilità assegnate e processi descritti. Poi, al primo incidente serio, scopre che quelle responsabilità non sono comprese, quei processi non sono stati provati e quei fascicoli non aiutano nessuno a decidere sotto pressione.
La compliance dovrebbe servire a costruire sicurezza reale. Quando diventa un fine in sé, produce una forma di tranquillità pericolosa: l’impressione di essere pronti senza aver mai verificato se lo si è davvero.
Quando la procedura non guida nessuno
Una procedura è utile solo se descrive qualcosa che l’organizzazione sa fare.
Se resta chiusa in un archivio documentale, diventa un oggetto rassicurante. È stata approvata, può essere mostrata durante un audit, dimostra che qualcuno ha lavorato sul tema. Ma durante un incidente non basta sapere che una procedura esiste. Bisogna sapere chi la attiva, chi decide, chi comunica, chi spegne un sistema, chi autorizza il ripristino, chi parla con il fornitore e chi informa il management.
Molte fragilità emergono proprio lì, nel passaggio dalla carta all’operazione.
Il piano di continuità è stato scritto, ma nessuno sa quanto tempo serva per recuperare il servizio più importante. Il playbook di incident response esiste, ma i team non lo usano nella pratica quotidiana. I ruoli di crisi sono stati assegnati, ma alcune persone hanno cambiato funzione o non lavorano più in azienda. Il registro dei fornitori è aggiornato, ma non dice quali dipendenze possano fermare davvero il business.
Tutto sembra sotto controllo finché il controllo non serve davvero.
La sicurezza reale richiede esercizio. Un piano di recovery va provato. Una catena di escalation deve essere chiara anche fuori dall’orario d’ufficio. Un fornitore critico va valutato per l’impatto che avrebbe un suo disservizio, non solo per la documentazione che ha fornito. Una policy sugli accessi deve riflettersi nei sistemi, nei log e nelle verifiche periodiche.
Una procedura non dimostra maturità perché è scritta bene. La dimostra quando funziona sotto pressione.
Le evidenze contano più delle dichiarazioni
La cybersecurity regolata si sta muovendo verso un criterio molto concreto: non basta dichiarare di avere controlli, bisogna dimostrare che quei controlli funzionano.
La differenza tra una compliance fragile e una sicurezza reale sta nelle evidenze.
Un backup non testato è una promessa. Un piano di incident response mai simulato è un’ipotesi. Un registro dei fornitori non collegato ai processi critici è un elenco, non uno strumento di governo. Una dashboard piena di indicatori verdi serve a poco se non aiuta a capire quali rischi possano fermare l’operatività.
Le evidenze utili sono quelle che raccontano il comportamento dell’organizzazione, non solo la sua intenzione. Test di ripristino, simulazioni di crisi, audit interni, azioni correttive, tempi di rilevamento e risposta, verifica delle vulnerabilità realmente esposte, tracciabilità delle decisioni prese durante un incidente.
Non servono solo a superare una verifica. Servono a capire se l’organizzazione è capace di reggere quando la pressione aumenta.
Un’organizzazione matura non dice soltanto di avere un piano. Sa mostrare quando lo ha testato, cosa non ha funzionato, quali correzioni sono state introdotte e quali rischi restano aperti. La sicurezza reale non elimina l’incertezza. La rende visibile e gestibile.
Il board deve decidere, non solo approvare
La compliance fragile nasce spesso da un equivoco: il management approva documenti, budget e procedure, ma resta distante dalle decisioni reali sul rischio cyber.
Il vertice aziendale non deve trasformarsi in un reparto tecnico. Deve però trattare il rischio digitale per quello che è: un rischio operativo, economico, legale e reputazionale. Non una materia da delegare interamente all’IT.
Le domande da portare in consiglio dovrebbero essere meno formali e più concrete. Quali servizi non possono fermarsi? Quanto tempo serve per ripristinarli? Quali sistemi non hanno alternative credibili? Quali fornitori possono generare un’interruzione critica? I backup sono stati testati o solo configurati? Le vulnerabilità vengono priorizzate in base all’impatto sul business o solo in base a un punteggio tecnico?
Qui si misura il passaggio dalla compliance formale alla governance.
La cybersecurity diventa utile al management quando aiuta a scegliere: dove investire, quali rischi accettare, quali dipendenze ridurre, quali processi rendere più resilienti. Se resta una sequenza di report periodici, produce informazione. Ma non necessariamente produce decisione.
Approvare una policy è facile. Governare il rischio che quella policy dovrebbe coprire è un’altra cosa.
Dove la compliance si rompe davvero
La compliance di carta si rompe nei punti in cui un documento dovrebbe trasformarsi in azione.
Il primo è il ripristino. Molte organizzazioni sanno dove si trovano le copie di backup e con quale frequenza vengono eseguite. Molte meno sanno dimostrare, con test recenti, quanto tempo serva per rimettere in piedi i sistemi critici e in quale ordine debbano tornare online.
Il secondo è la risposta agli incidenti. In una crisi cyber non bastano i tecnici. Entrano in gioco legale, comunicazione, customer care, direzione, fornitori, data protection e funzioni di business. Se questi soggetti si incontrano per la prima volta durante l’incidente, il piano è già in ritardo.
Il terzo è la catena dei fornitori. Non basta sapere chi sono. Bisogna sapere da chi dipende cosa. Un fornitore amministrativo e un fornitore che regge un servizio essenziale non hanno lo stesso peso. Metterli nello stesso registro non significa governarli allo stesso modo.
Il quarto è la gestione delle vulnerabilità. La gravità tecnica conta, ma non basta. Una vulnerabilità critica su un sistema isolato non ha lo stesso impatto di una vulnerabilità meno grave su un asset
esposto, connesso a un processo essenziale o già sfruttata attivamente. La priorità deve nascere dal rischio reale, non solo dal punteggio.
Il quinto è la misurazione. Tempi di rilevamento, tempi di risposta, risultati dei test, azioni correttive aperte, esposizione dei fornitori critici e vulnerabilità non sanate sono informazioni di governo. Se restano confinate nei team tecnici, il board vede solo una parte del rischio.
Dall’audit alla prova sul campo
Un audit può verificare la presenza di documenti, controlli e responsabilità. Ma la maturità si misura meglio dopo.
Cosa cambia dopo una verifica? Le lacune individuate vengono corrette? Le procedure vengono aggiornate? I test diventano periodici? I fornitori critici vengono rivalutati? Le metriche migliorano? Il board riceve informazioni più utili? I team sanno meglio cosa fare?
Se la risposta è no, l’audit ha prodotto solo un fascicolo in più.
La compliance utile lascia tracce operative: decisioni prese, rischi ridotti, controlli migliorati, processi testati, responsabilità chiarite. Non si limita a dimostrare che l’organizzazione ha scritto ciò che doveva scrivere. Dimostra che quelle regole hanno cambiato il modo in cui l’organizzazione lavora.
Per imprese e pubbliche amministrazioni il punto non è fare meno compliance. È farla meglio. Usarla come strumento per misurare la sicurezza reale, individuare le lacune e correggere ciò che non funziona.
La domanda da porre dopo ogni policy, ogni audit e ogni aggiornamento normativo è semplice: cosa siamo in grado di fare oggi che ieri non eravamo in grado di fare?
La sicurezza non vive nei fascicoli
Le normative cyber possono essere un acceleratore di maturità. Possono costringere le organizzazioni a conoscere meglio asset, fornitori, processi critici e responsabilità. Possono portare il rischio digitale nei luoghi in cui si prendono decisioni vere.
Ma possono anche produrre l’effetto opposto: una burocrazia rassicurante, piena di documenti e povera di capacità.
Il rischio nascosto non è l’eccesso di regole. È usarle come schermo invece che come strumento. Un’organizzazione può avere fascicoli completi e restare vulnerabile. Può superare una verifica formale e fallire nella crisi. Può dichiarare resilienza senza aver mai provato davvero a ripristinare ciò che dice di poter proteggere.
La compliance utile non sostituisce la sicurezza reale. La rende visibile, misurabile e verificabile.
Alla fine, la domanda non è se l’organizzazione abbia prodotto tutta la documentazione richiesta. La domanda è se quella documentazione descriva una capacità che esiste davvero.
Perché quando l’incidente arriva, non chiede di vedere una policy. Chiede se l’azienda sa ancora funzionare.
