Quando un’azienda inizia a valutare la ISO 27001, la prima domanda riguarda quasi sempre come ottenere la certificazione. Prima di quell’audit, però, ci sono mesi di lavoro interno di cui nessuno parla in fase commerciale. Prima che un auditor esterno metta piede in azienda, qualcuno del team ha già dovuto decidere cosa proteggere, quali rischi esistono e quali controlli applicare.
Questo lavoro preliminare è l’implementazione. In questo articolo spieghiamo cosa occorre costruire e in quale ordine per arrivare all’audit con un sistema che funzioni davvero e non solo sulla carta.
Cosa significa implementare la ISO 27001?
Implementare la ISO 27001 significa mettere in piedi un Sistema di Gestione della Sicurezza delle Informazioni, più noto con la sigla SGSI. Si tratta di costruire un meccanismo che permetta all’organizzazione di individuare quali informazioni sono critiche, cosa può andare storto, quali misure adottare per evitarlo e come dimostrare che queste misure funzionano.
La norma non indica quale tecnologia usare né quale fornitore scegliere. Richiede di saper giustificare le proprie decisioni con un metodo coerente e di poterle dimostrare con delle evidenze. Per questo due aziende dello stesso settore possono essere certificate con sistemi molto diversi tra loro.
La differenza tra implementare la norma e certificarsi
Sono due cose distinte ed è bene chiarirlo fin da subito, perché corrispondono a due progetti con tempistiche e responsabili diversi.
- Implementare: è il lavoro interno. Definire il perimetro, analizzare i rischi, scegliere i controlli, documentare il sistema e renderlo operativo. Se ne occupa il team, con o senza supporto esterno, e occupa la maggior parte del tempo complessivo.
- Certificarsi: è la validazione esterna. Un organismo di certificazione accreditato da ACCREDIA verifica il SGSI e conferma che è conforme alla norma. È un processo più breve e molto strutturato, che è possibile approfondire nella nostra guida su come ottenere la certificazione ISO 27001.
Un’organizzazione può implementare la norma senza certificarsi mai. Ciò che non può fare è certificarsi senza averla prima implementata.
Cosa serve prima di implementare la ISO 27001?
Prima ancora di toccare il primo documento, tre condizioni determinano se il progetto va avanti o si arena dopo due mesi.
- Un impegno reale della direzione: la norma richiede il coinvolgimento del vertice aziendale, ma al di là del requisito formale, senza un budget dedicato e senza tempo liberato per le persone coinvolte, il progetto entra in competizione con l’attività quotidiana e perde sempre. Il supporto deve tradursi in risorse, non in una firma.
- Un responsabile chiaramente individuato: qualcuno deve guidare il SGSI e avere potere decisionale su processi che non riguardano solo l’IT. Uno degli errori più frequenti è affidare l’intero progetto al team tecnico, quando la norma tocca risorse umane, ufficio legale, operations e fornitori.
- Una gap analysis iniziale: prima di pianificare qualsiasi cosa conviene confrontare ciò di cui si dispone già con ciò che la norma richiede. Quasi tutte le aziende partono con una parte del percorso già fatta, tra politiche di accesso, backup, gestione degli incidenti o inventario dei dispositivi. Sapere da dove si parte è ciò che consente di stimare l’impegno reale e di stabilire le priorità.
Le 10 fasi per implementare la ISO 27001
Nella norma non esiste un elenco ufficiale di fasi, ma tutti i progetti finiscono per attraversare più o meno questi dieci passaggi. I primi definiscono il terreno, gli ultimi sono quelli che un auditor esamina con maggiore attenzione.
1. Definire il perimetro del SGSI
Il perimetro delimita quali processi, servizi, sedi, dispositivi e persone rientrano nel sistema. È la decisione che pesa di più sull’intero progetto, perché condiziona il lavoro delle nove fasi successive.
Un perimetro troppo ampio rende il progetto ingestibile. Uno troppo ristretto produce un certificato che non risponde all’esigenza di partenza, di solito soddisfare un cliente o partecipare a una gara d’appalto.
2. Identificare gli asset informativi
All’interno di questo perimetro occorre sapere cosa c’è. Gli asset sono i database, le applicazioni, i server, i servizi cloud, i portatili e i telefoni aziendali, la documentazione cartacea se presente, e anche i fornitori che trattano informazioni per conto dell’azienda.
L’inventario è il punto di partenza dell’analisi dei rischi ed è uno dei primi documenti che un auditor controlla. Se viene aggiornato a mano su un foglio di calcolo, diventa obsoleto nel giro di poche settimane.
3. Valutare i rischi
Per ogni asset rilevante si individuano le minacce che lo riguardano e le vulnerabilità che presenta, e si stimano la probabilità e l’impatto che qualcosa accada. Il risultato è un elenco di priorità che indica dove conviene investire.
Ciò che conta qui è la metodologia. Deve essere esplicita, ripetibile e proporzionata alle dimensioni dell’organizzazione. Un’analisi troppo teorica e scollegata dall’operatività reale è problematica quanto la sua assenza, perché non orienta alcuna decisione.
4. Decidere come trattare ogni rischio
Una volta stabilite le priorità dei rischi, l’organizzazione decide cosa fare di ciascuno. Le opzioni sono quattro. Ridurlo applicando controlli, trasferirlo tramite un’assicurazione o un terzo, evitarlo eliminando l’attività che lo genera, oppure accettarlo in modo consapevole e documentato.
Accettare i rischi è del tutto legittimo e molte aziende non lo sanno. Ciò che non è legittimo è accettarli senza lasciare traccia di chi ha deciso e con quale criterio.
5. Selezionare i controlli dell’Allegato A
L’Allegato A della norma raccoglie 93 controlli suddivisi in quattro gruppi, ovvero organizzativi, relativi alle persone, fisici e tecnologici. Non è necessario applicarli tutti. Vanno applicati quelli che rispondono ai rischi individuati.
Tra quelli che finiscono quasi sempre nell’elenco ci sono il controllo degli accessi, l’autenticazione multifattore, la gestione dei privilegi, i backup, la gestione delle vulnerabilità, la sicurezza dei fornitori e la gestione degli incidenti.
6. Redigere la Dichiarazione di Applicabilità
La Dichiarazione di Applicabilità, o SoA secondo la sigla inglese, è il documento che riporta i 93 controlli e indica quali si applicano, quali no e perché. È l’elemento che collega l’analisi dei rischi alle decisioni prese, ed è il primo documento che un auditor richiede nella Fase 1.
Un SoA che si limita a spuntare caselle senza motivazione è una delle cause più frequenti di non conformità.
7. Documentare il sistema
La norma richiede un insieme minimo di documentazione. Il perimetro, la politica di sicurezza delle informazioni, la metodologia di analisi dei rischi, il piano di trattamento, il SoA, le procedure legate ai controlli applicati e le registrazioni dell’audit interno e del riesame della direzione.
Questa documentazione deve servire a gestire il sistema nel quotidiano. Se nessuno la apre mai, è scritta per l’auditor e non per l’azienda.
8. Applicare i controlli e generare evidenze
È qui che si vede se il SGSI funziona davvero. Non basta avere una politica degli accessi, bisogna poter mostrare come vengono concessi, rivisti e revocati i permessi. E non basta una procedura di backup, occorre dimostrare che viene eseguita e che qualcuno ne verifica i risultati.
Le evidenze si generano strada facendo, oppure non si generano affatto. Se cominciano a comparire due settimane prima dell’audit, l’auditor se ne accorge.
9. Formare il team
La norma richiede competenza e consapevolezza. In pratica questo significa che le persone dell’organizzazione devono conoscere le politiche che le riguardano e sapere cosa fare in caso di incidente.
Conta più di quanto sembri, perché nell’audit di certificazione l’auditor intervista dipendenti di aree diverse, non solo il team tecnico. La distanza tra ciò che dicono i documenti e ciò che sanno davvero le persone emerge proprio in quelle conversazioni.
10. Svolgere l’audit interno e il riesame della direzione
Prima di rivolgersi a un organismo di certificazione, la norma obbliga a svolgere un audit su sé stessi. L’audit interno cerca le non conformità prima che le trovi un terzo, e ha valore solo se condotto con onestà. Trattarlo come un adempimento formale significa arrivare all’audit esterno senza sapere dove sono le proprie lacune.
Segue poi il riesame della direzione, in cui il vertice aziendale valuta formalmente le prestazioni del SGSI, gli incidenti verificatisi, i risultati dell’audit interno e le opportunità di miglioramento.
Quanto tempo serve per implementare la ISO 27001?
Non esiste una tempistica standard. La durata dipende soprattutto dalle dimensioni dell’organizzazione, dalla maturità in materia di sicurezza al punto di partenza e dall’ampiezza del perimetro scelto. Gli intervalli qui sotto sono indicativi e riflettono progetti tipici, non un requisito della norma.
| Dimensione dell’organizzazione | Tempo stimato di implementazione |
| Fino a 20 dipendenti | Da 3 a 4 mesi |
| Da 21 a 50 dipendenti | Da 5 a 8 mesi |
| Da 51 a 200 dipendenti | Da 8 a 12 mesi |
| Oltre 200 dipendenti | 12 mesi o più |
Tre fattori spostano parecchio queste tempistiche. Il primo è quanta sicurezza è già strutturata prima di iniziare. Il secondo è l’impegno reale del team, perché un progetto portato avanti nei ritagli di tempo si dilata senza fine. Il terzo è il grado di automazione, perché buona parte del tempo se ne va nel raccogliere evidenze che in molte aziende sono sparse tra fogli di calcolo, e-mail e strumenti non collegati tra loro.
Gli errori più frequenti nell'implementazione della ISO 27001
L’implementazione della ISO 27001 raramente fallisce per carenza di competenze tecniche. I progetti che accumulano ritardi o che arrivano all’audit a metà strada tendono a ripetere gli stessi errori, e quasi tutti riguardano il modo in cui è organizzato il lavoro.
- Trattare il progetto come un esercizio documentale: la documentazione è necessaria, ma l’audit valuta processi ed evidenze, non la qualità redazionale delle politiche.
- Copiare politiche e modelli generici: fanno risparmiare tempo all’inizio e ne fanno perdere molto di più dopo, perché descrivono un’organizzazione diversa dalla propria e non si adattano ai rischi reali.
- Definire il perimetro all’ultimo momento: cambiare il perimetro a progetto avviato costringe a rifare l’inventario, l’analisi dei rischi e buona parte della documentazione.
- Rimandare le evidenze alla fine: i log degli accessi, degli incidenti e della formazione si generano in modo continuo, oppure non si generano. Non ci sono scorciatoie.
- Lasciare tutto in mano all’IT: la ISO 27001 tocca assunzioni, uscite dei dipendenti, fornitori, formazione e decisioni della direzione. Senza il coinvolgimento di queste aree, il sistema presenta lacune fin dal primo giorno.
E dopo aver implementato la ISO 27001?
Con il SGSI operativo si aprono due strade. Si può rimanere qui, usando la norma come quadro interno di gestione della sicurezza senza puntare al certificato. Oppure si può compiere il passo verso la certificazione, come fa la maggior parte delle organizzazioni che arrivano fino a questo punto, di solito perché un cliente, una gara d’appalto o un mercato lo richiedono.
Chi punta alla certificazione, come passo successivo, sceglie un organismo accreditato da ACCREDIA e prepara l’audit in due fasi. Lo spieghiamo nel dettaglio nella guida su come ottenere la certificazione ISO 27001.
In entrambi i casi, il sistema non può restare cristallizzato. Ogni nuovo strumento, ogni incidente e ogni cambiamento organizzativo dovrebbe tradursi in una revisione di rischi e controlli. Un SGSI che non viene aggiornato smette di rispecchiare la realtà dell’azienda nel giro di pochi mesi.
Come Factorial IT aiuta a implementare la ISO 27001
La parte più impegnativa dell’implementazione della norma di solito non è decidere quali controlli applicare. È mantenere l’evidenza che vengono applicati, mese dopo mese, senza che questo assorba il tempo del team.

Factorial IT centralizza la gestione di dispositivi, accessi e sicurezza dell’organizzazione e trasforma questa gestione in evidenze pronte per l’audit.
- Un inventario che si aggiorna da solo: ogni dispositivo aziendale entra nel registro nel momento in cui viene assegnato, così la fase 2 di questo articolo non dipende più dal fatto che qualcuno si ricordi di aggiornare un foglio di calcolo.
- Attivazione e revoca degli accessi da un unico pannello: quando una persona entra nel team o lo lascia, i permessi su tutti gli strumenti si aggiornano nello stesso momento e resta traccia di chi ha fatto la modifica e quando.
- Controlli dell’Allegato A che si applicano senza intervento: blocco dei dispositivi, cifratura e protezione degli endpoint si configurano una volta e si distribuiscono all’intera flotta aziendale, invece di dipendere dal singolo.
- Uno storico fin dal primo mese: le registrazioni iniziano ad accumularsi non appena la piattaforma viene attivata, ed è esattamente ciò che verrà richiesto una volta arrivati alla fase 10.
- Meno ore del team dedicate al progetto: ciò che l’auditor richiede si esporta sul momento, senza doverlo ricostruire a partire da e-mail e file sparsi.

