Un registro della sicurezza utile all’audit deve permettere di ricostruire una verifica senza dipendere dalla memoria di chi l’ha eseguita. Per ogni controllo servono un responsabile, un perimetro preciso, un esito e le prove che lo sostengono. Una riga con scritto «backup verificato» non basta se mancano data, sistemi coinvolti e risultato del ripristino.
Qui parliamo di sicurezza delle informazioni e controlli organizzativi, non del registro dei controlli antincendio o della documentazione sulla sicurezza sul lavoro. La struttura proposta è un modello operativo per CISO, compliance manager e auditor: aiuta a organizzare le evidenze, ma non sostituisce la verifica degli obblighi applicabili alla singola organizzazione.
Definire perimetro e finalità prima del modello
Il primo passaggio è stabilire che cosa rappresenta una riga. La soluzione più leggibile separa l’anagrafica del controllo dalle sue singole esecuzioni: il controllo descrive che cosa verificare e con quali criteri; ogni esecuzione registra data, risultato ed evidenze.
Per esempio, «riesame degli accessi amministrativi» è un controllo. Il riesame relativo al secondo trimestre, con elenco degli account e approvazione del responsabile, è una sua esecuzione. Se si sovrascrive ogni volta la stessa riga, si perde lo storico necessario a ricostruire il periodo sottoposto ad audit.
Il registro della sicurezza dovrebbe quindi funzionare come un indice verificabile, collegato ai documenti originali, non come un contenitore in cui copiare indistintamente rischi, incidenti e verbali.
Un rischio descrive uno scenario e la sua valutazione. Un incidente documenta un evento. Una non conformità segue uno scostamento e la relativa correzione. Questi oggetti possono essere collegati allo stesso controllo, ma mantengono identità e cicli di gestione distinti. Anche il registro dei trattamenti privacy ha una finalità diversa e non viene sostituito da questo modello.
I campi del registro della sicurezza che servono all’auditor
Prima di scegliere il software, definisci un insieme di campi obbligatori. La tabella distingue le informazioni stabili del controllo dai dati da registrare a ogni esecuzione.
| Campo | Che cosa registrare | Regola di compilazione |
|---|---|---|
| ID del controllo | Identificativo stabile, per esempio SEC-012 | Non riutilizzarlo per controlli diversi |
| Obiettivo | Risultato che il controllo deve verificare | Descriverlo in termini verificabili |
| Perimetro | Sistemi, processi, sedi o fornitori inclusi | Indicare anche le esclusioni rilevanti |
| Requisiti collegati | Norma, requisito contrattuale o policy interna | Specificare il riferimento pertinente |
| Responsabilità | Owner, esecutore e verificatore | Distinguere gestione, esecuzione e validazione |
| Criterio di esito | Condizioni per considerare il test superato | Definirle prima della verifica |
| Frequenza e trigger | Cadenza prevista ed eventi che richiedono un nuovo controllo | Non limitarsi alla prossima scadenza |
| ID dell’esecuzione | Identificativo della singola verifica | Collegarlo al controllo principale |
| Data ed esito | Quando è stata svolta e che cosa è emerso | Separare esito e stato del processo |
| Evidenze | Collegamenti a report, ticket, log o verbali | Identificare versione, data e ambito |
| Scostamenti e azioni | Problema rilevato, owner e termine previsto | Collegare l’eventuale azione correttiva |
| Validazione e storico | Chi ha verificato, quando e con quali osservazioni | Conservare le modifiche significative |
Una scadenza senza owner è difficile da gestire; un owner senza criterio di verifica non sa quale risultato produrre. Evita inoltre campi liberi come «tutto OK»: rendono impossibile distinguere un test effettivo da una semplice dichiarazione.
Collegare ogni esito a prove pertinenti
Per ogni esecuzione, l’evidenza deve rispondere a quattro domande: riguarda il sistema giusto, copre il periodo richiesto, documenta l’attività dichiarata e sostiene l’esito registrato?
Nel registro della sicurezza, il collegamento al file è soltanto l’inizio. Un report estratto a ottobre non dimostra automaticamente che un controllo sia stato eseguito a giugno. Analogamente, uno screenshot di configurazione può documentare un’impostazione, ma non prova da solo che quella configurazione abbia funzionato durante un test.
Definisci quindi per ciascun controllo la prova attesa. Per un riesame degli accessi possono servire l’elenco iniziale, le decisioni del responsabile e i ticket di revoca. Per un ripristino servono il verbale del test, i tempi misurati e la verifica dell’integrità dei dati recuperati. La guida alle evidenze di audit approfondisce come rendere queste prove verificabili e contestualizzate.
Mappare i requisiti senza dichiarare una conformità automatica
L’articolo 32 del GDPR comprende, tra le misure da considerare secondo il rischio, una procedura per testare, verificare e valutare regolarmente l’efficacia delle misure tecniche e organizzative. Un record ben compilato può documentare una verifica specifica, non dimostrare da solo tutta la conformità al regolamento.
Per i soggetti interessati, l’articolo 21 della direttiva NIS2 include politiche e procedure per valutare l’efficacia delle misure di gestione dei rischi di cibersicurezza. L’applicazione concreta richiede di considerare anche il recepimento nazionale e gli atti applicabili al soggetto.
La mappatura deve spiegare quale parte del requisito viene supportata dalla prova. Associare dieci riferimenti normativi a un documento, senza questa spiegazione, aggiunge etichette ma non rende più solida la verifica.
Assegnare ruoli e gestire le eccezioni
L’owner mantiene operativo il controllo: assicura che venga eseguito, sollecita le azioni e porta le criticità al livello decisionale appropriato. L’esecutore svolge l’attività. Il verificatore valuta se le prove sostengono l’esito. Nelle strutture piccole alcuni ruoli possono coincidere, ma questa sovrapposizione va resa visibile.
Nel registro della sicurezza conviene distinguere almeno tre dimensioni: lo stato dell’attività, l’esito del test e lo stato delle azioni conseguenti. «Eseguito» non significa «superato»; «azione completata» non significa «efficacia verificata».
Anche le eccezioni richiedono una gestione esplicita. Se un controllo non può essere svolto, registra la motivazione, il perimetro scoperto, le eventuali misure compensative e la data di riesame. «Non applicabile» richiede una motivazione verificabile, non deve diventare un modo per eliminare una scadenza.
Tenere separata l’accettazione del rischio
Una prova insufficiente non diventa adeguata perché qualcuno accetta il rischio. L’accettazione è una decisione distinta, che deve indicare soggetto autorizzato, motivazione, durata e condizioni di riesame secondo la governance aziendale.
Per chiarire il collegamento tra owner, rischio residuo e soglie decisionali, può essere utile la guida al registro dei rischi e alla tolleranza al rischio. È un approfondimento formativo, non una fonte normativa europea.
Il record del controllo deve continuare a mostrare l’esito reale, anche quando il rischio residuo viene accettato. In questo modo l’auditor distingue una debolezza conosciuta e governata da una verifica conclusa positivamente.
Un esempio compilato: test di ripristino non superato
Consideriamo un caso interamente esemplificativo. Il controllo SEC-012 verifica il ripristino di un’applicazione gestionale. La procedura interna prevede, per quel servizio, un obiettivo di ripristino di quattro ore e una verifica dell’integrità dei dati. Non si tratta di una soglia universale.
L’esecuzione SEC-012-2026-03 viene svolta il 3 ottobre. Il ripristino richiede sei ore e venti minuti: il test è stato eseguito, ma non ha rispettato il criterio temporale.
La registrazione nel registro della sicurezza dovrebbe rendere leggibili questi elementi:
- Perimetro: applicazione, database, ambiente di prova e copia di backup utilizzata.
- Responsabilità: responsabile infrastrutture come owner, tecnico incaricato come esecutore e referente del servizio come verificatore.
- Esito: non superato per il tempo di ripristino, con risultato della verifica d’integrità documentato separatamente.
- Evidenze: verbale del test, log delle operazioni e misurazioni dell’inizio e della fine del ripristino.
- Remediation: azione correttiva assegnata, scadenza e nuovo test necessario per valutarne l’efficacia.
L’apertura di un ticket non risolve lo scostamento. Serve a renderlo gestibile. La chiusura del ticket tecnico e la validazione del controllo devono restare due passaggi distinguibili.
Chiudere l’azione senza cancellare il risultato precedente
Dopo la correzione, una nuova esecuzione deve verificare nuovamente il risultato. Supponiamo che il secondo test richieda tre ore e quaranta minuti e che l’integrità dei dati sia confermata: il verificatore può registrare l’esito positivo sulla base delle nuove prove.
La prima esecuzione resta nello storico con il suo risultato negativo. La seconda richiama l’azione correttiva e documenta perché questa può essere chiusa. Se cambiano ambiente, volume dei dati o condizioni del test, le differenze vanno esplicitate: altrimenti il confronto può risultare fuorviante.
Questo storico permette di dimostrare non soltanto che il controllo oggi funziona, ma anche come è stata individuata e risolta la debolezza precedente.
Preparare un’estrazione che l’auditor possa ricostruire
L’estrazione deve riferirsi a un periodo e a un perimetro dichiarati. Prima dell’audit, definisci una data di riferimento e conserva la versione del registro usata per produrre il pacchetto. Le modifiche successive devono restare distinguibili.
Un audit pack operativo comprende l’indice dei controlli inclusi, le esecuzioni del periodo, le evidenze richiamate e lo stato delle eccezioni. Non occorre duplicare ogni documento: occorre garantire che i riferimenti rimangano accessibili ai destinatari autorizzati e che le versioni esaminate siano identificabili.
Il registro della sicurezza deve consentire anche il controllo inverso: partendo da una prova, l’auditor dovrebbe poter risalire al controllo, all’esecuzione e al criterio applicato. Un file denominato «report_finale_v3_definitivo» non offre questa ricostruibilità se manca un collegamento stabile al record.
Verifica inoltre permessi, tempi di conservazione e presenza di dati personali o informazioni riservate. La conservazione va definita in base a finalità, obblighi applicabili ed esigenze documentate, non impostata indefinitamente per comodità.
Per gestire le modifiche, stabilisci quali eventi tracciare: cambio dell’owner, sostituzione di un’evidenza, modifica dell’esito e approvazione della chiusura. Le best practice per l’audit trail aiutano a progettare questa ricostruzione senza confondere lo storico delle modifiche con le prove dell’esecuzione.
Gli errori che indeboliscono il registro
Sovrascrivere il passato. Aggiornare la data dell’ultimo controllo eliminando quello precedente impedisce di dimostrare che cosa è avvenuto nel periodo richiesto.
Usare solo indicatori sintetici. Un indicatore verde può nascondere verifiche parziali, evidenze mancanti o azioni ancora aperte. L’indicatore deve derivare da criteri dichiarati e lasciare accessibili i dettagli.
Collegare prove fuori perimetro. Un test sul sistema pilota non dimostra automaticamente l’efficacia del controllo su tutte le applicazioni. La copertura deve essere esplicita.
Chiudere sulla dichiarazione dell’esecutore. Quando è prevista una validazione, il record deve riportare la verifica svolta e le prove considerate, non soltanto «risolto».
Confondere assenza di prove e mancata esecuzione. Nel registro della sicurezza, «esecuzione non dimostrata» è una condizione diversa da «controllo non eseguito». La distinzione consente di assegnare l’azione corretta: recuperare una prova attendibile oppure svolgere la verifica mancante.
Domande frequenti
Esiste un modello unico obbligatorio? La struttura presentata è una proposta operativa per i controlli di sicurezza delle informazioni. Non va considerata il modello obbligatorio per ogni settore né confusa con registri specifici previsti da altre discipline.
È sufficiente un foglio di calcolo? Può essere adeguato per un perimetro contenuto se sono gestiti identificativi, permessi, versioni, collegamenti alle prove e storico. Diventa fragile quando la gestione richiede numerosi passaggi manuali o non permette di ricostruire chi ha modificato un esito.
Ogni quanto va aggiornato? Registra le esecuzioni quando avvengono e aggiorna responsabilità, eccezioni e azioni quando cambiano. La frequenza dei controlli va definita in funzione di rischio, requisiti applicabili e procedure interne, prevedendo anche verifiche attivate da cambiamenti o incidenti.
Il registro dimostra da solo la conformità? No. Serve a collegare attività e prove, ma la dimostrazione dipende anche dalla pertinenza dei controlli, dalla loro effettiva esecuzione e dalla qualità delle evidenze. Questa guida offre indicazioni organizzative, non un parere legale.
Organizzare il lavoro prima del prossimo audit
Se il problema è mantenere collegati controlli, responsabilità ed evidenze, valuta AuditReady per il percorso NIS2. La piattaforma centralizza le prove con ownership, versioni e audit trail, mantenendo il collegamento con rischi e remediation. Il criterio resta concreto: ogni esito deve poter essere ricostruito e verificato.
audit-ready evidence pack demo / not legal advice