Una politica di sicurezza informatica stabilisce chi decide, quali regole valgono per i sistemi dell’organizzazione e come vengono gestite le eccezioni. Il risultato utile è un documento applicabile: una persona deve poter capire cosa fare quando concede un accesso, acquista un servizio, perde un dispositivo o scopre un incidente. Un elenco di principi privo di responsabili e procedure non basta a guidare queste decisioni.
La struttura proposta comprende: perimetro, rischi, responsabilità, procedure, continuità, adozione e riesame. Il riferimento giuridico generale per i dati personali rimane l’articolo 32 GDPR, che richiede misure adeguate al rischio. Le metodologie delle autorità straniere possono aiutare il lavoro tecnico; non costituiscono automaticamente obblighi italiani né certificazioni del documento adottato.
Delimitare il perimetro prima di scrivere le regole
Indicate le società, le sedi, i servizi e le persone cui si applica la politica. Comprendete personale interno, collaboratori e fornitori quando operano sui sistemi inclusi. Descrivete come il documento raggiunge questi soggetti: contratto, regolamento interno, istruzione operativa o processo di onboarding. La semplice presenza di un file nella intranet non dimostra che un manutentore esterno conosca le regole.
Partite dalla mappatura dei sistemi informativi: un’applicazione dimenticata nell’inventario rischia di restare esclusa anche dalle misure. Per ciascun servizio identificate un referente che possa confermare utenti, dati, dipendenze e modalità di assistenza. Se il perimetro è ancora incompleto, dichiarate i limiti e programmate l’estensione; non presentate una politica sperimentale come copertura dell’intera organizzazione.
Separate il documento stabile dalle configurazioni che cambiano spesso. La politica può imporre autenticazione adeguata per gli accessi remoti, mentre una procedura collegata stabilisce i metodi ammessi, il recupero delle credenziali e il controllo delle eccezioni. Questa divisione consente di aggiornare la tecnologia senza riscrivere ogni volta le responsabilità approvate dalla direzione.
Collegare le priorità a rischi comprensibili
Raccogliete scenari riconoscibili dalle funzioni aziendali: impossibilità di erogare un servizio, consultazione indebita di fascicoli, perdita di documenti, alterazione di coordinate bancarie. Descrivete le conseguenze per le persone, oltre al costo organizzativo. Un archivio sanitario indisponibile e una presentazione commerciale smarrita richiedono valutazioni diverse, anche se entrambi risiedono sullo stesso server.
Per ogni scenario annotate misure già attive, lacune e dipendenze. Distinguete una misura dichiarata da una misura verificata. Un contratto che promette il backup non dimostra che l’organizzazione sappia ottenere i dati ripristinati; un elenco utenti non dimostra che gli account degli ex dipendenti siano disabilitati. La politica deve quindi prevedere anche la produzione di evidenze.
Il piano di igiene informatica aiuta a ordinare le prime azioni. Date precedenza alle esposizioni che consentono accessi estesi o impediscono il recupero: credenziali condivise, sistemi non supportati, accessi amministrativi pubblici e copie di sicurezza mai provate. Una scadenza interna deve considerare la gravità concreta e la fattibilità della correzione, senza trasformarsi in un termine legale inventato.
Attribuire decisioni e responsabilità
La direzione approva gli obiettivi e mette a disposizione risorse coerenti. Il responsabile della sicurezza propone i presidi e coordina la verifica tecnica. I responsabili dei servizi confermano quali attività devono continuare e quali accessi sono necessari. Le risorse umane comunicano ingressi, cambi di mansione e uscite attraverso un processo che raggiunga effettivamente gli amministratori dei sistemi.
Il DPO, quando designato, mantiene il proprio ruolo di consulenza e sorveglianza. Non attribuitegli automaticamente la gestione quotidiana di tutti i controlli o l’accettazione del rischio aziendale. La disciplina della nomina e dei compiti del DPO serve a distinguere questa funzione dalle responsabilità operative del titolare.
Una tabella di responsabilità dovrebbe comprendere almeno decisione, proposta, attuazione e controllo. Evitate caselle con dieci nomi senza un referente. Per i fornitori precisate chi richiede le evidenze, chi valuta le risposte e chi può sospendere un accesso quando emergono anomalie. Il referente commerciale del contratto può coordinare il rapporto, ma deve poter coinvolgere chi comprende il rischio tecnico.
Trasformare ogni regola in un’azione osservabile
Una buona regola contiene un soggetto, un oggetto e una condizione verificabile. «Gli accessi devono essere sicuri» lascia troppe interpretazioni. «Il referente del servizio approva i privilegi prima dell’attivazione; l’amministratore conserva la richiesta e verifica la revoca alla cessazione» permette invece di controllare un processo reale.
| Area | Decisione della politica | Evidenza operativa |
|---|---|---|
| Identità | Accessi personali e privilegi coerenti con il ruolo | Richiesta, approvazione e verifica della revoca |
| Informazioni | Protezione proporzionata a contenuto e destinazione | Classificazione e autorizzazione alla condivisione |
| Modifiche | Valutazione delle variazioni che incidono sulla sicurezza | Esito del collaudo e piano di ritorno |
| Incidenti | Canale riconoscibile e presa in carico | Segnalazione, cronologia e responsabile |
| Continuità | Priorità di servizio approvate | Esercitazione e verifica del ripristino |
Per autenticazione e recupero collegate la politica password e MFA. Per la tracciabilità definite quali eventi devono essere disponibili e rimandate alla progettazione dei log. Non inserite nella politica password, indirizzi di gestione riservati o dettagli che faciliterebbero un attacco: tali informazioni appartengono a documenti tecnici con accesso limitato.
Prevedere deroghe che non diventino permanenti
Un’applicazione datata può non supportare subito la misura prevista. La deroga deve identificare sistema, motivazione, rischio, misure compensative, responsabile e data di riesame. «Il fornitore non lo permette» è il punto di partenza dell’analisi, non la sua conclusione. Potrebbero essere disponibili un accesso attraverso un intermediario, una restrizione di rete o una riduzione dei dati trattati.
L’approvazione deve provenire da chi può assumere la decisione per il servizio. Alla scadenza si verifica se la limitazione è ancora reale, se l’esposizione è cambiata e se il piano di sostituzione procede. Registrate anche il rifiuto di una deroga: senza una traccia, la stessa richiesta può ricomparire con un altro referente e ottenere un trattamento incoerente.
Per esempio, una società ipotetica registra la deroga D-04 per il gestionale di magazzino che non supporta ancora MFA. La responsabile logistica approva soltanto l’accesso dalla rete interna attraverso postazioni gestite; il referente IT disabilita l’accesso diretto da Internet e verifica la configurazione. Il riesame è fissato al 30 ottobre, data interna legata al collaudo della versione sostitutiva. Se il collaudo fallisce, la deroga non si rinnova da sola: occorre rivalutare esposizione e alternative. La scheda contiene richiesta, decisione, prova del blocco esterno e referente della migrazione, senza riportare credenziali.
Integrare incidenti e continuità
La politica deve spiegare come segnalare un’anomalia senza chiedere al dipendente di qualificarla giuridicamente. Un allegato può indicare contatto ordinario, canale alternativo e informazioni iniziali utili. Non pretendete una prova completa prima della segnalazione: il triage serve proprio a distinguere un falso allarme da un evento che richiede contenimento.
Collegate il processo al piano di continuità operativa. Durante un’interruzione, le regole su condivisione, accessi e registrazione non possono essere improvvisate. Prevedete modalità degradate autorizzate e modalità di riconciliazione dei dati raccolti temporaneamente. Una soluzione di emergenza che conserva fascicoli personali su account privati può creare un secondo incidente.
Adottare, spiegare e verificare
Prima dell’approvazione fate leggere il testo a persone che dovranno applicarlo. Chiedete loro come gestirebbero tre situazioni: richiesta urgente di accesso, invio di un documento al destinatario sbagliato, indisponibilità dell’applicazione principale. Se le risposte divergono, chiarite istruzioni e punti di contatto. Questa prova editoriale aiuta a scoprire passaggi ambigui senza attendere una crisi.
La diffusione può essere differenziata per ruolo. Gli amministratori devono conoscere procedure privilegiate; il personale commerciale deve sapere come condividere documenti; gli acquisti devono riconoscere i servizi che richiedono una valutazione. Conservate versione distribuita, destinatari e attività formative, usando un livello di dettaglio proporzionato e rispettoso dei dati dei lavoratori.
Il riesame deve considerare incidenti, modifiche dei servizi, nuove dipendenze e risultati delle verifiche. Misurate indicatori legati alle regole: account rimasti attivi dopo una cessazione, deroghe scadute, ripristini non riusciti, segnalazioni senza presa in carico. Un numero di pagine aggiornate non dimostra una migliore protezione.
Come supporto tecnico, il percorso CNIL sulla sicurezza dei dati personali organizza i controlli per temi. Utilizzatelo per interrogare le procedure esistenti e registrate le scelte effettivamente adottate. Il fascicolo finale dovrebbe riunire politica approvata, elenco delle procedure, responsabilità, registro delle deroghe e programma di verifica: documenti diversi, collegati a un unico modo di governare la sicurezza.