Certificazione ISO 27001: costruire un SGSI che duri

Un cliente vi chiede il certificato ISO 27001. La scadenza commerciale è chiara; il lavoro di implementazione potrebbe non esserlo. La prima decisione del vertice aziendale è se costruire un sistema di gestione della sicurezza che l’azienda sia in grado di sostenere nel tempo, oppure organizzare un progetto temporaneo attorno a una data di audit.

Un piano di certificazione utile parte dalla definizione del sistema che dovete gestire e solo dopo organizza le evidenze che lo dimostrano. Ciò significa decidere quali servizi debba coprire il certificato, chi possa autorizzare le decisioni sui rischi, di quali risorse abbiano bisogno i responsabili dei controlli e come la direzione saprà se i controlli funzionano.

Il certificato è un risultato importante. Il patrimonio aziendale duraturo, però, è un sistema di gestione della sicurezza delle informazioni, o SGSI, che resta utile quando i dipendenti se ne vanno, i fornitori cambiano, vengono lanciati nuovi prodotti e i clienti pongono domande più difficili.

Che cosa attesta davvero la certificazione ISO 27001

ISO/IEC 27001 specifica i requisiti per stabilire, attuare, mantenere e migliorare in modo continuo un SGSI. Il suo scopo è gestire i rischi per la riservatezza, l’integrità e la disponibilità delle informazioni nel contesto dell’organizzazione.

La riservatezza riguarda la divulgazione impropria, per esempio quando i dati dei clienti diventano accessibili a utenti non autorizzati. L’integrità riguarda modifiche inesatte o non autorizzate, per esempio quando qualcuno altera le istruzioni di pagamento. La disponibilità riguarda l’accesso quando serve, per esempio il ripristino di un servizio importante dopo un guasto dell’infrastruttura.

La certificazione riguarda quel sistema di gestione entro il perimetro dichiarato. Non garantisce che ogni prodotto sia privo di vulnerabilità, che non possano verificarsi incidenti o che ogni unità di business sia stata valutata. Un certificato che copre un servizio gestito non dovrebbe essere presentato come garanzia per un prodotto non correlato.

ISO e IEC pubblicano la norma; non certificano la vostra organizzazione. È un organismo di certificazione indipendente a svolgere la valutazione e a prendere la decisione di certificazione. Ai fini della fiducia dei clienti, una raccomandazione pratica è scegliere un organismo accreditato per l’attività di certificazione SGSI pertinente e verificare che la sua certificazione soddisfi i requisiti degli acquirenti.

Conta anche la distinzione tra conformità e certificazione. Un’organizzazione può implementare un SGSI conforme alla norma senza richiedere una certificazione esterna. La certificazione aggiunge una valutazione indipendente e un certificato formale. Acquistare un software, assumere un implementatore qualificato o completare un corso di formazione non conferisce la certificazione all’organizzazione.

Valutate se la certificazione risolve il problema aziendale

La certificazione è particolarmente rilevante quando requisiti di procurement, impegni contrattuali, informazioni sensibili o dipendenze operative giustificano una garanzia indipendente. Non è un obbligo di legge universale per ogni impresa.

Prima di impegnarvi, chiedete ai team commerciali e di account management di individuare il requisito effettivo. L’acquirente richiede un certificato prima della firma del contratto, prima dell’accesso alla produzione o al rinnovo? Deve coprire un servizio o una persona giuridica specifici? L’acquirente richiederà comunque un questionario di sicurezza, report di test o controlli contrattuali aggiuntivi?

Queste risposte incidono sulle priorità di investimento. Un certificato può agevolare il procurement, ma non elimina tutta la due diligence. Evitate di prevedere ricavi partendo dal presupposto che la certificazione chiuda automaticamente la revisione di sicurezza di ogni cliente.

Tenete separata la certificazione dall’analisi normativa. Un SGSI può supportare evidenze e governance rilevanti per altri obblighi, ma la certificazione non attesta la conformità al GDPR o alla direttiva NIS2. Questi regimi hanno regole di applicabilità e obblighi propri. La NIS2 viene attuata tramite il diritto nazionale; gli obblighi del GDPR dipendono dalle attività di trattamento e dai ruoli organizzativi.

La motivazione presentata al vertice dovrebbe quindi individuare tre elementi: la garanzia di cui i clienti hanno bisogno, i rischi informativi che l’azienda deve gestire e il costo operativo continuativo. Approvate il programma su questa base, non sulla promessa di un certificato entro una data arbitraria.

Definite un perimetro comprensibile per i clienti

Il perimetro descrive i confini e l’applicabilità del SGSI. Dovrebbe individuare i servizi, le unità organizzative, le sedi, le persone, le informazioni, i sistemi e le dipendenze rilevanti. Deve inoltre tenere conto delle interfacce con le attività al di fuori di tali confini.

Un perimetro ristretto può essere appropriato, soprattutto per una prima implementazione. Deve comunque riflettere ciò che i clienti si aspettano che il certificato copra. Escludere il team che amministra gli accessi alla produzione non ne elimina l’influenza su un servizio per i clienti incluso nel perimetro.

Per un’applicazione in hosting, esaminate l’intera catena del servizio: sviluppo, deployment, gestione della produzione, accessi del supporto, amministrazione delle identità, backup e fornitori esterni significativi. Processi HR o IT condivisi possono incidere sulla sicurezza anche quando il perimetro è incentrato su un prodotto anziché sull’intera azienda.

Una registrazione pratica del perimetro dovrebbe rispondere alle seguenti domande:

• Quale persona giuridica gestisce il servizio?
• Quali servizi e informazioni destinati ai clienti sono coperti?
• Quali sedi e modalità di lavoro da remoto sono rilevanti?
• Quali team e processi condivisi incidono su tali servizi?
• Quali fornitori forniscono infrastruttura o trattano informazioni rilevanti?
• Che cosa resta fuori dal confine e come vengono gestite le relative interfacce?

Mettete alla prova la formulazione proposta con un collega che lavora a contatto con gli acquirenti. Se non riesce a spiegare se il servizio del cliente è coperto, la formulazione va rivista.

Non ottimizzate il perimetro solo per ridurre i costi dell’audit. Un confine più ristretto può creare interfacce complicate e lasciare senza risposta il requisito commerciale. Al contrario, includere subito tutte le società del gruppo può generare un coordinamento superfluo. Il confine giusto è difendibile, comprensibile e gestibile sul piano operativo.

Documentate la motivazione e gli eventi che dovrebbero indurre a riconsiderarlo, come l’acquisizione di un’azienda, lo spostamento dell’infrastruttura o il lancio di un servizio sostanzialmente diverso. Il perimetro deve restare una decisione della direzione, non un paragrafo dimenticato.

Date al programma autorità, non solo un responsabile

Nominate un responsabile dell’implementazione e uno sponsor della direzione che ne risponda. Hanno responsabilità diverse. Il responsabile coordina il lavoro e ne garantisce la visibilità; lo sponsor risolve le priorità, autorizza le risorse e fa sì che gli obiettivi di sicurezza si integrino con le decisioni aziendali.

La titolarità dei controlli dovrebbe seguire l’autorità operativa. L’HR può essere responsabile delle procedure legate al rapporto di lavoro, l’IT della gestione dei dispositivi, l’engineering delle pratiche di sviluppo e il procurement può coordinare la valutazione dei fornitori. Il responsabile della compliance non dovrebbe diventare formalmente responsabile di processi che non può modificare.

Definite chi può accettare il rischio residuo e a quale livello. Il responsabile di un servizio può raccomandare di accettare un’esposizione operativa limitata, mentre un rischio che incide su impegni importanti verso i clienti può richiedere l’approvazione del vertice. Documentate la decisione, la motivazione, le condizioni e la data di riesame.

Il vertice deve anche proteggere la capacità di implementazione. Assegnare lavoro senza fargli spazio produce ritardi prevedibili. Chiedete ai responsabili l’impegno necessario, le dipendenze e i compromessi; poi approvate un piano realistico.

Il riesame della direzione è il momento in cui il vertice valuta il sistema e prende decisioni su miglioramenti, modifiche e risorse. Un verbale firmato privo di decisioni significative ha scarso valore pratico. Il riesame dovrebbe far emergere le scelte ancora aperte, non limitarsi ad avallare una dashboard verde.

Comprendete i requisiti prima di acquistare una checklist

I requisiti dei punti da 4 a 10 della ISO/IEC 27001 costituiscono il nucleo del sistema di gestione. Non possono essere esclusi quando si dichiara la conformità. I loro risultati pratici sono distinti dall’implementazione dei singoli controlli di sicurezza.

L’Annex A dell’edizione 2022 contiene 93 controlli di riferimento: 37 organizzativi, otto relativi alle persone, 14 fisici e 34 tecnologici. L’applicabilità si basa sul rischio; non esiste un numero universale che ogni azienda debba implementare.

Determinate i controlli necessari per il trattamento dei rischi, poi confrontateli con l’Annex A per verificare di non aver trascurato controlli necessari. I controlli possono derivare anche da requisiti contrattuali, da altre fonti o dalla vostra stessa progettazione. L’Annex A non sostituisce la valutazione dei rischi né è un catalogo esaustivo di ogni possibile misura di sicurezza.

La Dichiarazione di applicabilità (Statement of Applicability, SoA) registra i controlli necessari, le ragioni della loro inclusione, il loro stato di implementazione e la giustificazione dell’esclusione dei controlli dell’Annex A. Mantenete una tracciabilità sufficiente per spiegare come queste decisioni si collegano al trattamento dei rischi e agli altri requisiti.

La ISO 27002 fornisce linee guida sui controlli di sicurezza delle informazioni; la ISO 27001 fornisce i requisiti certificabili del sistema di gestione. Usate le linee guida per comprendere le opzioni di implementazione, ma adattate le procedure alla vostra organizzazione anziché importare un modello operativo che non siete in grado di sostenere.

Costruite il trattamento dei rischi prima di raccogliere le evidenze

Partite da un metodo di valutazione dei rischi ripetibile. Definite come vengono identificati i rischi, come vengono valutate probabilità e conseguenze, come vengono confrontati i risultati e quali criteri ne determinano l’accettabilità. Un’interpretazione coerente conta più di una formula di punteggio complicata.

Descrivete i rischi come scenari. «Rischio cloud» è troppo vago per supportare una decisione. «Un account amministratore viene compromesso e utilizzato per esportare i dati dei clienti» identifica un evento, le informazioni coinvolte e una conseguenza per l’azienda.

Coinvolgete le persone che conoscono il servizio. Possono illustrare le misure di protezione esistenti, gli accessi del supporto, le dipendenze dai fornitori, i vincoli di ripristino e le soluzioni di ripiego che una libreria di rischi generica potrebbe non cogliere. Per una struttura pratica delle registrazioni, consultate la nostra guida al registro dei rischi operativo.

Per ogni rischio significativo, registrate il responsabile, la valutazione, i controlli in essere, la decisione di trattamento, il risultato atteso e la valutazione del rischio residuo. Le possibili opzioni di trattamento comprendono la riduzione dell’esposizione, la rinuncia a un’attività, la condivisione di alcuni aspetti del rischio o la sua accettazione secondo criteri definiti. Un’assicurazione o l’esternalizzazione non eliminano ogni conseguenza o responsabilità.

Traducete il trattamento in attività con un responsabile chiaro. «Migliorare la sicurezza degli accessi» non è un piano eseguibile. Specificate i sistemi interessati, la modifica necessaria, il responsabile, i criteri di completamento e il modo in cui verrà valutata l’efficacia.

Mantenete distinte queste registrazioni:

Devono essere coerenti tra loro senza diventare copie l’una dell’altra. Se un trattamento dipende dal monitoraggio dei fornitori ma il relativo controllo è escluso senza spiegazione, risolvete l’incoerenza prima di preparare l’audit.

Riesaminate i rischi a intervalli pianificati e quando si verificano cambiamenti significativi. Un nuovo fornitore di supporto, una raccolta di dati più ampia, un incidente o un importante cambiamento architetturale possono rendere obsoleta una decisione precedente.

Integrate i controlli nell’operatività ordinaria

Una politica enuncia le aspettative; una procedura spiega come si svolge il lavoro; le registrazioni operative dimostrano che cosa è effettivamente accaduto. La preparazione alla certificazione richiede tutti e tre gli elementi, laddove pertinenti.

Per esempio, una politica sugli accessi dovrebbe collegarsi a un processo di ingresso e uscita del personale effettivamente implementato, a modifiche degli accessi verificate a campione e a un riesame delle eccezioni. Il solo documento di politica lascia indimostrata gran parte di questa storia.

Costruite il processo attorno alle responsabilità effettive. Individuate chi richiede l’accesso, chi lo approva, chi lo concede, che cosa succede quando cambia il ruolo di una persona e come vengono rimossi gli account. Includete gli account di servizio e gli utenti esterni laddove incidono sul perimetro.

Applicate lo stesso ragionamento agli altri processi importanti:

• La valutazione dei fornitori dovrebbe collegare criticità del servizio, accesso alle informazioni, aspettative contrattuali, esiti dei riesami e criticità irrisolte.
• La gestione degli incidenti dovrebbe collegare canali di segnalazione, responsabilità di risposta, escalation, ripristino e lezioni apprese.
• Backup e ripristino dovrebbero collegare esigenze aziendali, sistemi protetti, procedure di ripristino, risultati dei test e attività conseguenti.
• La gestione delle modifiche dovrebbe collegare approvazione, test, registrazioni di deployment, modifiche urgenti ed eccezioni.

I controlli fisici e quelli relativi alle persone restano importanti anche in un’organizzazione basata sul cloud. Lavoro da remoto, protezione dei dispositivi, conversazioni riservate, cambiamenti nel rapporto di lavoro e consapevolezza non possono essere liquidati solo perché i server sono esternalizzati.

Stabilite la frequenza dei controlli in base al rischio e alle esigenze operative. Non copiate in una politica l’impegno a un riesame trimestrale se il responsabile non è in grado di svolgerlo e di conservarne le registrazioni. Una politica che descrive un processo che nessuno segue crea un divario evitabile tra intenzione e attuazione.

Progettate le evidenze per la verifica, non per il volume

Una buona evidenza risponde a una domanda definita su un requisito o un controllo. Una cartella piena di screenshot non è di per sé più solida di un insieme più piccolo e ben spiegato di registrazioni attendibili.

Per ogni controllo importante, specificate il sistema di origine, il responsabile, il metodo di raccolta, la copertura, la frequenza prevista e chi lo riesamina. Distinguete le evidenze di progettazione da quelle di funzionamento. Una configurazione delle identità può mostrare che l’autenticazione a più fattori è attiva; le registrazioni delle approvazioni e i riesami degli accessi dimostrano altri aspetti della governance degli accessi.

Un’evidenza dovrebbe rendere chiaro il proprio significato:

• Quale servizio, sistema o popolazione copre?
• Quando è stata prodotta e quale periodo rappresenta?
• È sufficientemente completa per la domanda oggetto di valutazione?
• Chi l’ha riesaminata e quali eccezioni sono state individuate?
• Quali azioni sono seguite a tali eccezioni?

Conservate anche gli esiti negativi. Un test di ripristino fallito, con indagine, rimedio e un nuovo test riuscito documentati, può dimostrare che il monitoraggio e il miglioramento funzionano. Cancellare i risultati scomodi compromette l’utilità della documentazione.

Proteggete le evidenze come informazioni a pieno titolo. Le esportazioni possono contenere dati dei dipendenti, identificativi dei clienti o configurazioni sensibili. Limitate gli accessi, riducete al minimo i contenuti superflui e definite la conservazione in base agli obblighi pertinenti e alle esigenze aziendali. Predisponete un accesso controllato per gli auditor anziché distribuire con leggerezza archivi estesi.

Usate audit interno e riesame della direzione per verificare la prontezza

L’audit interno valuta se il SGSI è conforme ai requisiti applicabili ed è attuato e mantenuto in modo efficace. Dovrebbe riguardare il sistema di gestione, non limitarsi a controllare impostazioni tecniche.

Pianificate perimetro, criteri, metodi e reportistica dell’audit. Selezionate auditor competenti e salvaguardate obiettività e imparzialità. Un’organizzazione piccola può ricorrere a supporto esterno o a idonei accordi tra funzioni diverse, anziché chiedere a una sola persona di valutare tutto il proprio lavoro.

Un audit utile segue una registrazione lungo tutto il processo. Selezionate l’uscita di un dipendente e verificate notifica, rimozione degli account, gestione delle apparecchiature ed eccezioni. Selezionate un fornitore ed esaminate se la sua valutazione dei rischi corrisponde al suo accesso effettivo. Selezionate un’azione di trattamento e verificate se il completamento dichiarato ha un riscontro operativo.

Registrate i rilievi con precisione, indicando il requisito, l’evidenza osservata e la lacuna. Non riducete l’audit a una percentuale di completamento che nasconde processi di gestione mancanti.

Il riesame della direzione prende poi in considerazione gli input richiesti, tra cui prestazioni, risultati degli audit, cambiamenti, stato della valutazione e del trattamento dei rischi e opportunità di miglioramento. Preparate un dossier decisionale sintetico con le registrazioni di supporto a disposizione. Spiegate dove il vertice deve scegliere tra rimedio, risorse aggiuntive, obiettivi modificati o accettazione approvata del rischio.

Per le non conformità, separate la correzione immediata dall’azione correttiva. Disattivare un account trascurato corregge il problema immediato. Riparare il processo di notifica e controllare le uscite successive affronta il rischio che il problema si ripresenti. Registrate la causa, l’azione, il responsabile e la valutazione dell’efficacia.

Comprendete Stage 1, Stage 2 e la decisione di certificazione

La certificazione iniziale prevede normalmente due fasi di audit. Concordate con l’organismo di certificazione modalità, registrazioni attese e aspettative di prontezza con sufficiente anticipo per pianificare correttamente.

Lo Stage 1 esamina la prontezza, il perimetro e la documentazione del sistema di gestione. Aiuta l’organismo a comprendere l’organizzazione e a valutarne la preparazione per lo Stage 2. Aspettatevi un esame attento del rapporto tra perimetro, valutazione dei rischi, trattamento, SoA e processi di gestione. Risolvete le criticità individuate anziché considerare lo Stage 1 un semplice passaggio amministrativo.

Lo Stage 2 valuta attuazione ed efficacia. Gli auditor utilizzano interviste, osservazioni e registrazioni campionate per verificare se il SGSI funziona come descritto. I dipendenti dovrebbero essere in grado di spiegare le proprie responsabilità effettive, non recitare risposte provate in anticipo.

Mantenete ordinate le richieste durante l’audit. Nominate un coordinatore, registrate le richieste, individuate il responsabile giusto e fornite le evidenze pertinenti con il relativo contesto. Se manca qualcosa, spiegate la situazione con precisione. Non create registrazioni retroattive che lascino intendere falsamente che un processo si sia svolto.

Una non conformità significa che un requisito non è stato soddisfatto. Le non conformità maggiori incidono sulla capacità del sistema di gestione di conseguire i risultati attesi; quelle minori non hanno tale effetto. La classificazione dipende dal contesto, per cui a una singola registrazione mancante non si può assegnare in anticipo un’etichetta universale.

L’organismo di certificazione determina in modo indipendente i rilievi, le risposte richieste, le modalità di verifica e la decisione di certificazione. Verificate in anticipo le sue scadenze e i requisiti di follow-up. La raccomandazione di un auditor non equivale a un certificato rilasciato e i rilievi non risolti possono ritardare la decisione.

Dopo la certificazione, un ciclo tipico comprende audit di sorveglianza negli anni intermedi e la ricertificazione prima della scadenza triennale del certificato. Verificate con il vostro organismo il programma di audit specifico e le relative condizioni. La sorveglianza non autorizza a mettere in pausa il SGSI tra una visita e l’altra.

Pianificate tempi e budget in funzione delle dipendenze

La durata dipende da maturità, perimetro, rischi irrisolti, disponibilità delle evidenze, capacità interna e calendario degli auditor. Non esiste un periodo universale di evidenze operative ISO 27001 che renda automaticamente pronta ogni organizzazione.

Chiedete all’organismo di certificazione che cosa debba campionare nel vostro caso specifico. Un processo svolto mensilmente produce registrazioni in modo diverso da un’attività annuale. Non aspettate la prenotazione dell’audit per scoprire che un controllo importante non è mai stato messo in pratica.

Separate le attività che potete accelerare (raccolta, coordinamento, stesura e preparazione dei riesami) da quelle che richiedono implementazione e funzionamento dimostrato. Svolgete in parallelo le attività indipendenti, ma rispettate le dipendenze: una SoA non può essere finalizzata in modo credibile senza la motivazione della selezione dei controlli, e l’efficacia non può essere valutata soltanto sulla base di una politica proposta.

Utilizzate punti di verifica della prontezza anziché un’unica data di fine ottimistica:

Prevedete a budget l’impegno interno, i rimedi, gli strumenti, la formazione, l’eventuale supporto consulenziale e la valutazione esterna. Includete sorveglianza, ricertificazione e manutenzione continuativa, non solo la fattura del primo audit.

Chiedete agli organismi di certificazione di illustrare le loro ipotesi su personale, sedi, attività, complessità e modalità di audit. Confrontate l’intero ciclo e i costi di follow-up. Evitate di considerare un preventivo iniziale basso come il costo complessivo della gestione di un SGSI certificato.

Esempio pratico: un servizio, un piano sostenibile

Si consideri, a titolo illustrativo, un’azienda di 30 persone che gestisce un servizio di condivisione di documenti in hosting. Supponiamo che disponga già di gestione delle identità, approvazioni dei deployment e backup, ma che i riesami dei fornitori e le registrazioni dei riesami degli accessi siano disomogenei. Il potenziale cliente vuole garanzie sul servizio in hosting, compresi gli accessi del supporto.

La direzione include nel perimetro il servizio e i processi di sviluppo, gestione operativa e supporto che lo sostengono. Registra le interfacce con l’HR e l’IT condiviso anziché escluderne gli effetti sulla sicurezza. Il CEO è sponsor del programma; un responsabile dell’implementazione lo coordina; i responsabili operativi sono titolari dei controlli.

Il team individua uno scenario in cui permessi eccessivi del supporto espongono i documenti dei clienti. Il trattamento comprende ruoli di supporto limitati, elevazione temporanea dei privilegi approvata, riesami degli accessi e un monitoraggio adeguato al servizio. La SoA registra i controlli necessari e il loro stato di implementazione.

Il responsabile degli accessi raccoglie quindi una configurazione dei ruoli, registrazioni di approvazione campionate, un riesame completato e l’evidenza che i permessi eccessivi emersi durante quel riesame sono stati rimossi. Queste registrazioni dimostrano più della semplice esistenza di una politica sugli accessi.

Durante l’audit interno si scopre che un collaboratore esterno non più in servizio ha ancora un account attivo. Il team lo disattiva, indaga sulla mancata notifica da HR a IT, aggiunge un passaggio esplicito per la cessazione dei collaboratori esterni e controlla le uscite successive per valutarne l’efficacia. Il riesame della direzione prende in esame il rilievo, i rischi residui e le risorse necessarie per i riesami continuativi.

Solo ai fini della pianificazione del budget, supponiamo che otto persone dedichino ciascuna due ore a settimana per dodici settimane. Si tratta di 192 ore interne, al netto dei rimedi specialistici e della partecipazione all’audit. È un calcolo illustrativo della capacità, non una stima di mercato né una promessa di certificazione.

La lezione è di natura gestionale: assegnate il lavoro a persone che hanno autorità, riservate capacità e fate dipendere la prontezza dalle evidenze. Le misure tecniche esistenti riducono parte del lavoro di implementazione, ma non sostituiscono le decisioni sui rischi, l’audit interno o il riesame della direzione.

Automatizzate il lavoro ripetitivo mantenendo il giudizio umano

L’automazione può supportare l’aggiornamento degli inventari, la raccolta delle evidenze, i promemoria, le verifiche tecniche e la reportistica. Date priorità al lavoro ricorrente con dati di origine affidabili e un revisore chiaro, anziché automatizzare un processo poco definito.

Una verifica automatizzata richiede una copertura definita e una gestione degli errori. Se una connessione smette di raccogliere registrazioni, distinguete tra «nessun problema rilevato» e «nessun dato aggiornato». Verificate che la fonte copra i sistemi, gli account o le sedi pertinenti prima di fare affidamento sul risultato.

Mantenete esplicito il giudizio umano per l’accettazione dei rischi, l’applicabilità dei controlli, le conclusioni sulle evidenze e le decisioni del vertice. Una verifica di configurazione può mostrare che la cifratura è attiva; non dimostra che l’accesso alle chiavi, il ripristino e i percorsi eccezionali dei dati siano gestiti in modo adeguato.

Analogamente, l’automazione dei flussi di lavoro può organizzare le richieste e i rilievi dell’audit interno, ma non fornisce competenza né indipendenza di audit. Sintesi e mappature generate dall’IA dovrebbero restare bozze finché un revisore non ne verifica le fonti e ne approva le conclusioni.

Misurate sia l’efficienza sia l’efficacia: tempo dedicato alla preparazione delle evidenze, azioni correttive scadute, copertura incompleta, errori ricorrenti e tempo necessario per risolvere le eccezioni importanti. La nostra guida alle metriche del SGSI spiega come rendere le misure utili per le decisioni della direzione.

Mantenete viva la titolarità dopo la certificazione

Prima che arrivi il certificato, definite il calendario di manutenzione. Tra le raccomandazioni pratiche rientrano verifiche periodiche da parte dei responsabili, riesami dei rischi avviati da cambiamenti rilevanti, valutazioni pianificate dei controlli, audit interni, riesami della direzione e preparazione alle valutazioni esterne. Scegliete le frequenze in base al processo e al rischio, anziché rendere mensile ogni attività.

Riassegnate le responsabilità quando i dipendenti cambiano ruolo o lasciano l’azienda. Riesaminate il perimetro e l’applicabilità dei controlli quando l’attività cambia. Tenete traccia delle eccezioni ricorrenti: una rimozione degli accessi ripetutamente tardiva indica un problema di processo anche se ogni singolo caso viene alla fine chiuso.

Secani supporta questo flusso di lavoro collegando requisiti, controlli, evidenze, responsabili, attività e decisioni di riesame in uno spazio di lavoro condiviso. Iniziate con un servizio rappresentativo, modellatene sistemi e dipendenze, collegate le evidenze esistenti a ciò che dimostrano e trasformate le lacune in attività assegnate. Verificate i suggerimenti assistiti dall’IA rispetto alle loro fonti e conservate le approvazioni umane e lo storico delle decisioni. Ciò aiuta il team a conservare ciò che apprende durante la certificazione mentre i sistemi cambiano; la certificazione resta una decisione dell’organismo indipendente.

Domande che cambiano il piano di implementazione

La ISO 27001 richiede un penetration test?

Non esiste un punto universale della ISO 27001 che imponga a ogni organizzazione di eseguire un penetration test. I test necessari dipendono dal trattamento dei rischi, dai controlli applicabili, dalle caratteristiche del servizio e dai requisiti contrattuali. Laddove i test siano necessari, definite copertura, rimedi e nuovi test anziché limitarvi a conservare un report.

Dovremmo puntare invece su SOC 2?

Chiedete che cosa richiedono i clienti e quale perimetro si aspettano. SOC 2 produce un report di attestazione; la ISO 27001 produce una certificazione del sistema di gestione. Alcune evidenze operative possono essere riutilizzabili, ma nessuna delle due si converte automaticamente nell’altra. Valutate i requisiti specifici di ciascuna prima di impegnarvi su entrambe.

Ci serve un consulente esterno?

Non necessariamente. Un aiuto esterno può rispondere a esigenze di interpretazione, di capacità o specialistiche. Mantenete la titolarità all’interno e fate in modo che le procedure restino utilizzabili dopo la fine dell’incarico. La qualifica di implementatore o di auditor di una persona non certifica il suo datore di lavoro.

Iniziate con una decisione e una traccia di evidenze

Approvate un breve mandato di implementazione che indichi l’esigenza commerciale, il perimetro previsto, lo sponsor, il responsabile, i titolari dei controlli, la capacità e i punti di verifica della prontezza. Poi prendete un servizio importante e seguite un controllo dal requisito al trattamento dei rischi, all’implementazione, alle evidenze e al riesame.

Questa prima traccia farà emergere responsabilità poco chiare e registrazioni mancanti prima che si moltiplichino. Usate la nostra checklist ISO 27001 per organizzare il lavoro rimanente, mantenendo distinti i requisiti del sistema di gestione e l’applicabilità dei controlli.

Un SGSI duraturo rende le decisioni di sicurezza verificabili e ripetibili. La certificazione riconosce il sistema entro il suo perimetro; il vertice lo mantiene in funzione dopo che il team di audit se n’è andato.