Quando si parla di compliance ho spesso la sensazione che IT e governance stiano descrivendo la stessa cosa con due linguaggi diversi.
Da una parte ci sono requisiti, policy, audit ed evidenze. Dall’altra firewall, identità, EDR, backup, patching, logging e procedure operative.
Il rischio nasce quando questi due mondi smettono di incontrarsi.
Una policy non è un controllo
Possiamo scrivere che l’MFA è obbligatoria. Ma esistono utenze escluse? Account di servizio? Autenticazioni legacy? Possiamo dimostrare che il controllo viene applicato nel perimetro che pensiamo?
Possiamo avere una policy di backup perfetta. Ma l’ultimo restore test quando è stato fatto? Quanto impiegheremmo davvero? Le credenziali del sistema di backup sono separate dal dominio che dovrebbe proteggere?
È qui che “essere compliant” e “essere sicuri” possono prendere strade diverse.
NIS2 rende bene il concetto
L’articolo 21 della Direttiva NIS2 parla esplicitamente di misure tecniche, operative e organizzative adeguate e proporzionate per gestire il rischio. ENISA ha poi pubblicato guidance tecnica per alcuni settori coperti dal regolamento di esecuzione, includendo temi come incident handling, business continuity, supply chain, access control, asset management e verifica dell’efficacia delle misure.
Non è quindi solo una questione di “avere il documento”. Il documento dovrebbe descrivere qualcosa che esiste, viene applicato e può essere verificato.
La domanda che farei durante un assessment
Per ogni requisito proverei a chiedere: qual è il controllo tecnico o operativo che lo implementa? Chi ne è responsabile? Come misuriamo che funzioni? Quale evidenza possiamo produrre?
Se non riusciamo a rispondere, probabilmente abbiamo ancora un requisito sulla carta e non un controllo maturo.
Compliance come occasione
Vista così, la compliance può essere molto utile. Costringe a mettere ordine, assegnare responsabilità, documentare eccezioni e soprattutto rendere visibili dipendenze che altrimenti resterebbero nascoste.
Non sostituisce la sicurezza. Può però diventare il meccanismo che ci obbliga a dimostrare che la sicurezza non esiste soltanto nelle intenzioni.
Questo Insight è una riflessione tecnica e non costituisce consulenza legale sul perimetro o sugli obblighi NIS2 applicabili a una specifica organizzazione.