
Un audit interno offre all'organizzazione l'occasione di scoprire dove il proprio sistema di gestione della sicurezza delle informazioni (SGSI) si discosta dalle intenzioni. Il risultato utile è una valutazione motivata e un percorso di miglioramento chiaro per ogni rilievo significativo, non semplicemente una cartella di screenshot preparata per la certificazione.
Per un responsabile tecnico, la domanda centrale è se il sistema funzioni attraverso servizi, persone e passaggi di consegne reali. Una policy può essere approvata mentre la sua attuazione fallisce. Un audit dovrebbe far emergere questa differenza senza trasformare ogni imperfezione operativa in un rilievo di conformità privo di fondamento.
Il punto 9.2 della ISO/IEC 27001 richiede audit interni a intervalli pianificati per valutare la conformità ai requisiti del SGSI dell'organizzazione e della norma, nonché se il SGSI sia efficacemente attuato e mantenuto. Il programma di audit deve tenere conto dell'importanza dei processi e dei risultati degli audit precedenti, con auditor selezionati in modo da garantire obiettività e imparzialità.
Un audit interno può essere svolto da dipendenti o da uno specialista esterno incaricato a tale scopo. Non rilascia un certificato: la certificazione è una valutazione distinta, condotta da un organismo di certificazione indipendente. Gli audit interni restano parte della gestione del SGSI anche dopo la certificazione, non solo della preparazione alla valutazione iniziale.
La ISO 27001 non prescrive una frequenza annuale universale per gli audit interni. Come raccomandazione pratica, utilizzate un calendario documentato che rifletta rischio, cambiamenti e rilievi precedenti, con un'attenzione più frequente ai processi instabili o critici.
Un singolo audit non deve esaminare tutto contemporaneamente. Il programma dovrebbe garantire la copertura del SGSI nel suo perimetro lungo il ciclo pianificato, invece di ispezionare ripetutamente solo i controlli più familiari.
Documentate queste decisioni prima di richiedere evidenze:
| Decisione | Che cosa registrare |
|---|---|
| Criteri | Requisiti pertinenti della ISO 27001, procedure interne e obblighi applicabili |
| Campo | Servizi, team, sedi, sistemi e periodo operativo esaminati |
| Copertura | Requisiti del sistema di gestione dei punti da 4 a 10 e controlli selezionati attraverso il trattamento del rischio e la Dichiarazione di Applicabilità |
| Responsabilità | Auditor, responsabili dei processi, referenti specialistici e destinatari del rapporto |
| Metodi | Interviste, esame dei registri, osservazione e approccio al campionamento |
L'Annex A non impone di attuare ogni controllo in modo identico. Verificate se le decisioni di applicabilità e le esclusioni sono giustificate, poi testate gli impegni che l'organizzazione ha effettivamente assunto.
Scegliete auditor competenti che comprendano sia i requisiti del sistema di gestione sia i controlli esaminati. Evitate che le persone verifichino il proprio lavoro. In un piccolo team di sviluppo, un auditor esterno o un revisore di un'altra funzione può risolvere i conflitti, purché disponga di competenze sufficienti e di accesso alle evidenze.
Partite dal perimetro, dalla valutazione del rischio, dal piano di trattamento, dalla Dichiarazione di Applicabilità, dalle policy, dai rilievi precedenti e dai registri operativi pertinenti. Questi documenti spiegano che cosa dovrebbe accadere e dove i fallimenti avrebbero maggiore rilevanza.
Formulate poi domande verificabili. Per gli accessi privilegiati, chiedetevi se le approvazioni precedono l'accesso, se le revisioni coprono la popolazione di account pertinente e se le autorizzazioni revocate scompaiono davvero. Una policy sugli accessi firmata stabilisce un'intenzione; esportazioni degli account, registri delle approvazioni e log delle rimozioni ne dimostrano il funzionamento.
Create un piano di campionamento che includa modifiche recenti, servizi critici, debolezze precedenti ed eccezioni. Registrate la popolazione, il metodo di selezione, il periodo e la motivazione. Un campionamento pratico non deve necessariamente utilizzare un'unica dimensione fissa del campione, ma deve essere spiegabile. Una manciata di screenshot di comodo raramente rappresenta un intero periodo di funzionamento.
Incrociate i registri con interviste e osservazione. Se i responsabili descrivono un passaggio di consegne manuale, esaminate passaggi di consegne effettivamente completati. Se le evidenze contraddicono un'intervista, indagate invece di scegliere la versione più rassicurante. Registrate i limiti quando un sistema non è in grado di fornire evidenze storiche; non deducete silenziosamente il funzionamento passato dalla configurazione attuale.
Ipotesi illustrative: un'azienda SaaS sottopone ad audit le uscite dei dipendenti in un periodo di tre mesi. La sua procedura richiede la rimozione degli accessi entro il momento dell'uscita del dipendente. I registri delle risorse umane mostrano 12 uscite; l'auditor esamina tutti e tre gli utenti privilegiati e altre quattro uscite in team diversi.
L'auditor confronta le marcature temporali delle uscite registrate dalle risorse umane con gli eventi del provider di identità, lo stato degli account applicativi e i ticket di offboarding. L'account di un ex ingegnere presso il provider di identità è stato disattivato in tempo, ma un account del repository gestito separatamente è rimasto attivo per due giorni.
Prima di classificare il rilievo, stabilite se l'account poteva autenticarsi, quali autorizzazioni restavano e se esisteva un'eccezione approvata. Intervistate le risorse umane e il responsabile dell'applicazione per comprendere il passaggio di consegne. Estendete il test ad altre uscite che coinvolgono applicazioni gestite separatamente, se l'omissione appare sistemica.
Un rilievo difendibile identifica la procedura violata, la condizione osservata, i registri a supporto, l'ambito interessato e la potenziale conseguenza. Non dovrebbe affermare che si sia verificato un accesso non autorizzato, a meno che le evidenze supportino tale conclusione.
Una non conformità richiede evidenze del mancato soddisfacimento di un requisito. Un'opportunità di miglioramento individua un perfezionamento utile senza dimostrare una violazione. Una questione aperta resta tale finché evidenze sufficienti non supportano una conclusione.
Utilizzate classificazioni coerenti e date priorità ai rilievi in base a esposizione, ricorrenza e ampiezza. Non lasciate che un'etichetta di gravità sostituisca il ragionamento. Date ai responsabili dei processi la possibilità di correggere errori di fatto, mantenendo in capo all'auditor la responsabilità della conclusione.
Il rapporto dovrebbe indicare campo, criteri, metodi, limiti, rilievi e la valutazione complessiva supportata dal lavoro svolto.
Un piano d'azione dovrebbe indicare un responsabile, una scadenza, la correzione immediata, la causa principale e la modifica volta a prevenire il ripetersi del problema. Rimuovere l'account del repository corregge quel singolo caso. Sistemare l'inventario incompleto delle applicazioni e il passaggio di consegne tra risorse umane e IT interviene sul processo.
Evitate di accettare l'"errore umano" come causa principale completa quando il flusso di lavoro si basa sulla memoria o manca di un responsabile. Definite i criteri di efficacia prima di chiudere l'azione: ad esempio, le uscite successive devono includere verifiche riconciliate con l'inventario delle applicazioni pertinente.
Un ticket completato dimostra l'esecuzione, non necessariamente l'efficacia. Dopo l'attuazione, esaminate un altro campione e conservate il risultato della verifica. Riaprite l'azione se lo stesso errore si ripresenta.
Riferite alla direzione competente le debolezze ricorrenti, le azioni scadute, i fabbisogni di risorse e le decisioni significative sul rischio. Ai sensi della ISO 27001, i risultati dell'audit interno sono un input del riesame della direzione; il riesame è un'attività distinta con altri input obbligatori, non semplicemente una riunione per approvare il rapporto di audit.
Secani collega requisiti, evidenze, responsabili, attività e decisioni di riesame, in modo che valutazione e follow-up restino nel loro contesto. Mantenete i registri a supporto associati ai controlli pertinenti e preservate l'approvazione umana delle conclusioni sulle evidenze. Utilizzate la nostra guida alla preparazione all'audit per organizzare questi registri prima delle attività sul campo.
Un passo successivo concreto è scegliere un processo critico, nominare un auditor imparziale e redigerne i criteri e il piano di campionamento. Pianificate la verifica dell'efficacia nel momento in cui assegnate le azioni correttive, non dopo che tutti le considerano concluse.
Secani collega gli ambiti, le prove, i compiti e gli agenti AI in uno spazio di lavoro condiviso.
Comprendere perimetro del C5, tipi di report, responsabilità dei clienti e le evidenze che i cloud provider devono mantenere collegate.
Ponete domande concrete su qualifiche, esperienza di settore, aspettative sulle evidenze, tempistiche, indipendenza e costo complessivo della valutazione.
Leggere certificati ISO e report SOC 2 nel loro contesto: perimetro, periodo, eccezioni, responsabilità del cliente ed evidenze della remediation.