Una procedura di sicurezza può essere ben scritta e comunque non funzionare. Succede quando in cartelle condivise, email e desktop circolano tre versioni dello stesso documento e nessuno sa quale usare.
Il problema non è formale. Una policy obsoleta può far applicare regole superate; una procedura modificata ma non comunicata può lasciare le persone senza istruzioni nel momento in cui servono; un registro non aggiornato rende difficile dimostrare come è stata presa una decisione.
Nel percorso verso la ISO/IEC 27001, documenti e informazioni documentate devono sostenere il sistema di gestione della sicurezza delle informazioni (SGSI), non diventare un archivio da difendere. L’obiettivo è semplice: chi deve decidere o operare deve trovare rapidamente la versione valida, capirne lo stato e sapere chi la mantiene.
Il punto di partenza: distinguere i documenti che guidano il lavoro
Non tutti i file meritano lo stesso livello di governo. Trattare allo stesso modo una bozza di lavoro e una procedura approvata produce soltanto attrito.
Conviene partire da una mappa essenziale delle informazioni che guidano davvero il SGSI. In genere rientrano in questa categoria:
- policy e linee di indirizzo approvate dalla direzione;
- procedure operative, ad esempio per gestione accessi, incidenti o fornitori;
- istruzioni destinate a gruppi specifici;
- registri ed evidenze, come decisioni, riesami, verifiche e azioni di miglioramento;
- modelli utilizzati per raccogliere informazioni in modo uniforme.
Per ciascun elemento basta chiarire quattro aspetti: a cosa serve, chi ne è proprietario, chi può approvarlo e dove si trova la fonte ufficiale. Questa distinzione evita una confusione frequente: un file può essere utile, ma non per questo è un documento che deve indirizzare il comportamento dell’intera organizzazione.
Una versione valida deve essere riconoscibile in pochi secondi
La regola pratica è che una persona non debba ricostruire la storia di un documento per capire se può usarlo. La versione valida dovrebbe riportare in modo chiaro titolo, identificativo, data di efficacia, numero o stato di revisione e soggetto che l’ha approvata.
Non serve introdurre codici complessi se l’azienda non ne ha bisogno. Serve invece evitare denominazioni come “procedura_finale_v7_definitiva”. Un nome coerente e una tabella di revisione sono spesso più efficaci di una tassonomia elaborata.
Pensiamo alla procedura per l’ingresso di un nuovo dipendente. Se il team HR usa un modulo che non prevede il coinvolgimento dell’IT, mentre il team IT segue una checklist aggiornata, l’errore non dipende dalla volontà delle persone. Dipende dal fatto che il processo non ha una fonte unica e riconoscibile.
Approvare non basta: bisogna distribuire e ritirare
L’approvazione è un passaggio importante, ma non conclude il lavoro. Una nuova versione produce valore solo quando arriva alle persone interessate e sostituisce quella precedente nei punti in cui viene utilizzata.
Un flusso snello può prevedere questi passaggi:
- il proprietario propone la modifica e ne descrive il motivo;
- chi ha l’autorità prevista la verifica e la approva;
- la versione valida viene pubblicata in un repository definito;
- i destinatari ricevono una comunicazione proporzionata al cambiamento;
- la versione superata viene archiviata o resa non utilizzabile operativamente.
La comunicazione non deve sempre essere una formazione formale. Per una correzione editoriale può bastare una notifica; per un cambiamento che modifica attività, responsabilità o tempi di escalation occorre invece verificare che le persone coinvolte abbiano compreso cosa cambia.
Il repository ufficiale conta più dello strumento scelto
Un SGSI può usare una piattaforma documentale, un sistema qualità, un intranet o una struttura controllata in cloud. Lo strumento migliore non è necessariamente il più sofisticato: è quello che rende affidabile la fonte ufficiale senza rallentare chi lavora.
La domanda utile non è “dove salviamo i PDF?”, ma “dove cerca una persona quando deve applicare una regola?”. Se la risposta cambia in base al reparto, alla sede o al singolo responsabile, il rischio di usare versioni incoerenti cresce rapidamente.
Il repository dovrebbe consentire almeno di separare documenti in elaborazione, documenti approvati e archivi storici. I permessi devono essere coerenti con i ruoli: chi consulta non deve poter modificare accidentalmente; chi aggiorna deve poterlo fare nel perimetro assegnato. Questo non richiede di bloccare il lavoro quotidiano, ma di rendere chiaro chi può fare cosa.
Riesame e cambiamento: quando una procedura smette di essere adatta
Un documento non diventa obsoleto solo perché passa il tempo. Può esserlo perché cambia un servizio, entra un nuovo fornitore, si modifica un’applicazione, emerge un incidente o si rileva che il processo reale è diverso da quello descritto.
Per questo è utile associare a policy e procedure una frequenza di riesame ragionevole e, soprattutto, alcuni eventi che fanno scattare una verifica. Un’azienda può riesaminare ogni anno una policy generale, ma aggiornare subito un’istruzione se un nuovo sistema cambia il modo in cui vengono gestiti gli accessi.
Il riesame deve rispondere a domande concrete: il documento descrive ancora il lavoro reale? Le responsabilità sono aggiornate? Le evidenze richieste sono disponibili? Esistono istruzioni duplicate o in conflitto? Se la risposta è negativa, la modifica diventa un’azione di miglioramento, non un adempimento amministrativo.
Misurare se il governo documentale sta funzionando
Per capire se il metodo è efficace non serve creare una reportistica pesante. Alcuni segnali operativi sono sufficienti: quante versioni non controllate vengono ancora usate, quanto tempo serve per trovare una procedura valida, quante modifiche restano senza approvazione e quante persone ricevono una comunicazione quando cambia un’attività che le riguarda.
Anche un audit interno o una verifica di processo può offrire indicazioni utili. Se durante un colloquio persone con lo stesso ruolo descrivono istruzioni diverse, non è un problema di memoria: è un segnale che la fonte ufficiale o il processo di distribuzione vanno rivisti.
Conclusione
Governare le versioni dei documenti del SGSI non significa moltiplicare firme, cartelle e registri. Significa rendere affidabili le istruzioni che orientano decisioni e attività quotidiane. Una fonte ufficiale, responsabilità chiare, modifiche tracciabili e comunicazioni proporzionate permettono di trasformare i documenti da archivi passivi a strumenti concreti di sicurezza e governance.