L’approvazione della sicurezza di un sistema è una decisione documentata sulle condizioni alle quali il servizio può essere utilizzato. Riunisce perimetro, rischi, misure, verifiche e limitazioni ancora presenti. Il suo valore consiste nel rendere esplicito chi accetta il rischio residuo e quali condizioni devono rimanere vere durante l’esercizio.
Questa guida descrive il percorso metodologico del dossier di omologazione: descrizione del sistema, analisi dei rischi, prove, decisione e riesame. Non presenta l’omologazione francese come un obbligo generale italiano. Per i dati personali, gli articoli 24, 25 e 32 GDPR costituiscono riferimenti pertinenti alla responsabilizzazione e alle misure; eventuali regimi settoriali devono essere identificati separatamente.
Chiarire quale decisione viene richiesta
Indicate se si tratta dell’avvio di un nuovo servizio, di una modifica rilevante o del riesame di un sistema esistente. Descrivete utenti, dati, funzioni e ambienti compresi. Un’approvazione relativa a una configurazione limitata non deve essere riutilizzata per giustificare funzionalità o popolazioni aggiunte successivamente.
Definite chi ha il potere di assumere la decisione e chi fornisce le valutazioni. Il responsabile tecnico descrive configurazioni e limiti; il referente del servizio chiarisce esigenze e conseguenze; le funzioni competenti esaminano obblighi e rischi. Il DPO, quando presente, mantiene il proprio ruolo di consulenza e sorveglianza.
La politica di sicurezza informatica può stabilire quali cambiamenti richiedano questa approvazione. Il criterio dovrebbe considerare dati, esposizione, dipendenze e conseguenze, evitando sia una formalità obbligatoria per ogni dettaglio sia l’assenza di controllo sulle trasformazioni più importanti.
Costruire una descrizione del sistema verificabile
Allegate una mappa di applicazioni e flussi con identificativi stabili. Indicate fornitori, accessi amministrativi, interfacce e luoghi di trattamento. Distinguete architettura prevista e configurazione effettiva: il dossier deve dichiarare se una componente è ancora in progetto e quali prove non sono ancora possibili.
Descrivete il modello delle autorizzazioni e le modalità di assistenza. Un sistema può essere protetto nell’uso ordinario e risultare molto più aperto durante la manutenzione. Identificate chi può concedere un accesso temporaneo, come ne viene verificata la necessità e come viene chiuso al termine dell’intervento.
Registrate anche le dipendenze indispensabili alla disponibilità: identità, rete, chiavi, backup e persone con competenze specifiche. Un’approvazione che considera soltanto l’applicazione centrale può trascurare componenti capaci di interrompere o compromettere l’intero servizio.
Collegare scenari, misure ed evidenze
Per ogni rischio descrivete evento, condizioni che lo rendono plausibile e conseguenze. Considerate riservatezza, integrità e disponibilità, insieme agli effetti sulle persone. Non confondete un punteggio economico aziendale con la valutazione di danni che possono riguardare utenti, lavoratori o altri interessati.
Associate le misure agli scenari che dovrebbero ridurre. La cifratura del supporto può rispondere al furto di un dispositivo, ma non necessariamente a un account applicativo compromesso. Una misura genericamente elencata nell’allegato non dimostra la sua pertinenza al rischio esaminato.
Usate il modello delle misure tecniche e organizzative per precisare perimetro, responsabilità e prova. Distinguete controlli applicati, pianificati e dipendenti da un fornitore. Il rischio residuo deve essere valutato sulla base di ciò che esiste, non di interventi futuri trattati come già completati.
Selezionare verifiche proporzionate
Il programma di verifica può comprendere esame documentale, controllo delle configurazioni, prova di accesso, ripristino e attività tecniche specialistiche. Scegliete le prove in funzione delle domande aperte. Un penetration test non sostituisce la valutazione della conservazione o la verifica del percorso di revoca degli utenti.
Un audit di sicurezza deve chiarire perimetro, metodo e limiti. Conservate versione del sistema esaminato, campioni e prerequisiti. Se l’architettura cambia dopo la prova, valutate quali risultati restino pertinenti e quali debbano essere aggiornati.
| Domanda della decisione | Prova possibile | Limite da dichiarare |
|---|---|---|
| Gli accessi rispettano i ruoli? | Campione di autorizzazioni e revoche | Popolazioni non esaminate |
| Il servizio può ripartire? | Ripristino controllato | Componenti escluse e tempi osservati |
| Le interfacce sono limitate? | Verifica dei flussi e della configurazione | Percorsi non raggiungibili nella prova |
| Gli eventi sono ricostruibili? | Generazione e ricerca di un evento | Sorgenti o periodi non coperti |
| Il fornitore sostiene le garanzie? | Esame del contratto e delle evidenze | Documenti mancanti o perimetri diversi |
Esplicitare il rischio residuo
Dopo le misure rimangono incertezze e possibili conseguenze. Descrivetele in modo comprensibile al decisore: quale evento resta possibile, quale servizio o persona può essere colpita e quali condizioni ne influenzano la probabilità. Evitate formule come «rischio accettabile» prive di ragionamento.
Separate rischio residuo e non conformità a un obbligo applicabile. Una decisione interna di accettazione del rischio non elimina un requisito legale né trasforma un trattamento illecito in lecito. Se emerge un vincolo non rispettato, il dossier deve indicare come viene affrontato e se ciò impedisce l’avvio nelle condizioni previste.
Per le lacune temporanee definite compensazioni, referente e scadenza di riesame. Un sistema può essere autorizzato a un uso limitato soltanto se tale limite viene effettivamente applicato. La decisione deve descrivere come impedire l’estensione involontaria del perimetro durante il periodo transitorio.
Scrivere il verbale di approvazione
Il verbale dovrebbe identificare sistema, versione, perimetro e documenti esaminati. Riportate decisione, motivazione, condizioni, azioni aperte, responsabili e circostanze che richiedono un nuovo esame. Non serve ricopiare l’intero dossier: riferimenti stabili permettono di mantenere leggibile il documento finale.
Le possibili conclusioni devono rispecchiare il processo dell’organizzazione: avvio alle condizioni verificate, avvio limitato con prescrizioni, rinvio in attesa di prove o mancata approvazione. Non trattate ogni esito come una semplice firma finale; alcune condizioni possono dover essere soddisfatte prima dell’utilizzo con dati reali.
Collegate il verbale al registro delle decisioni di accountability. Una persona che subentra deve poter ricostruire quali informazioni erano disponibili e quali responsabilità erano state assegnate. Conservate eventuali pareri divergenti e il motivo per cui la decisione finale ha seguito una determinata opzione.
Tradurre le condizioni in esercizio
Le prescrizioni devono raggiungere chi configura e utilizza il sistema. Se il dossier limita categorie di dati, accessi o funzionalità, verificate che applicazione e procedure riflettano tali limiti. Un allegato approvato ma non comunicato al team operativo non controlla il comportamento del servizio.
Il piano di continuità operativa deve conoscere gli obiettivi e le dipendenze esaminate. Le procedure di incidente devono sapere quali evidenze raccogliere e chi contattare. Integrate questi collegamenti prima dell’avvio, quando correggere una responsabilità mancante è più semplice.
Riesaminare quando cambia ciò che era stato approvato
Definite eventi di riapertura: nuove finalità, dati più delicati, accessi aggiuntivi, cambiamento del fornitore, incidente o scadenza di un’eccezione. Una revisione periodica integra questi eventi, ma non dovrebbe essere l’unico meccanismo di aggiornamento.
Il quadro CNIL sulla sicurezza dei dati offre un supporto metodologico per verificare la coerenza dei controlli. Il fascicolo deve comunque descrivere il sistema concreto e le decisioni dell’organizzazione. La sua utilità si misura quando una modifica arriva: se è possibile capire subito quali ipotesi non sono più valide e chi deve riesaminarle, l’approvazione accompagna davvero la gestione del rischio.
Una verifica pratica consiste nel prendere una condizione del verbale e seguirla fino al sistema. Se l’approvazione ammette soltanto un gruppo ristretto di utenti, confrontate quel gruppo con le autorizzazioni osservate e con il processo per aggiungere nuove persone. Se prevede una prova di ripristino, cercate l’esito e il referente che lo ha accettato. Documentate eventuali differenze come azioni aperte. Questa lettura inversa, dalla decisione all’evidenza, permette di distinguere un’approvazione realmente attuata da un documento che non ha modificato il funzionamento del servizio.