ISO 27001: Ho Letto lo Standard Cinque Volte. Poi Ho Cercato di Implementarlo.

Storia vera.

Un professionista che ho formato lo scorso autunno era security manager in un'azienda di medie dimensioni nei Paesi Bassi. Competente. Rigoroso. Aveva la certificazione Foundation. Aveva letto ISO 27001 dall'inizio alla fine. Più volte. Sapeva spiegare cosa richiedeva la Clausola 6. Elencava a memoria le quattro categorie di controlli dell'Annex A. Disegnava il ciclo Plan-Do-Check-Act su una lavagna a occhi chiusi.

L'azienda ha deciso di certificarsi. Il suo responsabile gli ha detto: "Conosci lo standard. Guidalo tu."

E poi si è seduto alla scrivania un lunedì mattina e ha realizzato di non avere assolutamente idea da dove cominciare.

Non perché fosse incompetente. Perché lo standard non glielo aveva mai detto. Gli aveva detto cosa doveva esistere. Non gli aveva mai detto come costruirlo.

Tre mesi dopo, non era ancora sicuro che il suo scoping fosse corretto. La metodologia di risk assessment era stata riscritta due volte perché nessuno riusciva a concordare sul significato di "probabile". La SoA era compilata a metà e lui non si fidava di nessuna di quelle voci. Aveva fatto progressi, ma del tipo in cui si avanza senza sapere se si stia andando nella direzione giusta.

Quando è arrivato al mio corso, ci lavorava da quasi un anno. Non perché il lavoro fosse troppo difficile. Perché lo stava facendo senza una metodologia.

Se qualcosa di tutto ciò vi suona familiare, questo articolo fa per voi.

Lo standard non è un manuale operativo. Non lo è mai stato.

Ecco la cosa che nessuno dice apertamente: ISO 27001 è deliberatamente incompleto.

Non è una critica. È il progetto. Lo standard deve funzionare per una startup di cinque persone e per una banca con cinquantamila dipendenti. Deve funzionare in ogni settore, ogni giurisdizione, ogni stack tecnologico. L'unico modo per farlo è specificare cosa deve esistere senza specificare come costruirlo. Quella generalità è ciò che lo rende potente. È anche ciò che lo rende inutile come guida passo dopo passo.

"L'organizzazione deve determinare le questioni esterne e interne rilevanti per i propri scopi." Come? Workshop? PESTLE? Interviste? Appunti su un foglietto davanti a un caffè? Lo standard non lo dice, perché la risposta dipende dal fatto che si tratti di un ospedale, una SaaS company o uno studio legale.

"L'organizzazione deve definire e applicare un processo di risk assessment per la sicurezza delle informazioni." Bene. Ma come si presenta quel processo? Quale metodologia? Quali scale? Come si calibra affinché la parola "alto" significhi la stessa cosa per il reparto legale e per il team SOC? Lo standard non lo dice.

"L'organizzazione deve produrre una Statement of Applicability." D'accordo. Ma cosa rende una SoA efficace? Quanto devono essere dettagliate le giustificazioni? Cosa costituisce evidenza di implementazione? È sufficiente una policy, oppure l'auditor vuole i log? Lo standard non lo dice affatto.

Chi conosce lo standard ma non riesce a implementarlo non manca di competenza. Manca di metodologia. E questo non è un fallimento della persona. È una lacuna che lo standard non è mai stato progettato per colmare.

Cinque decisioni che lo standard lascia interamente a voi

Ho implementato ISO 27001 in oltre cento organizzazioni. Queste cinque decisioni sono il punto in cui ogni implementazione trova la propria rotta o perde mesi.

Come definire lo scope. La maggior parte delle persone pensa che lo scoping sia semplice. Si definisce cosa è dentro, cosa è fuori, e si va avanti. Poi ci si passa tre mesi a discuterne. L'ambiente di sviluppo deve essere in scope? E quella controllata che condivide lo stesso Active Directory? E il team di supporto offshore che accede ai dati di produzione? Ogni decisione di scoping ha conseguenze a cascata su rischi, controlli e audit. Lo standard dice "determinare il perimetro". Non dice come navigare questi compromessi, né come scrivere una dichiarazione di scope che un auditor accetti in trenta secondi invece di smontare pezzo per pezzo per due ore.

Come valutare i rischi. È qui che si spreca più tempo. Non nell'eseguire la valutazione, ma nel progettare la metodologia. Ho esaminato risk register in cui l'intera colonna della probabilità riportava "medio". Dove la colonna dell'impatto aveva cinque livelli ma nessuno sapeva spiegare la differenza tra un tre e un quattro. Dove lo stesso rischio veniva valutato diversamente da due team seduti in stanze adiacenti perché nessuno aveva calibrato le scale. Lo standard dice "applicare un processo di risk assessment". Non dice come costruire una metodologia ripetibile, difendibile, che non collassi al primo momento in cui l'auditor chiede "perché questo è un tre e non un quattro?"

Come scrivere la SoA. La Statement of Applicability è il documento più importante del vostro ISMS e il più frequentemente sbagliato. Ho esaminato SoA in cui ogni controllo era contrassegnato come "implementato" senza alcuna evidenza. Dove la colonna delle giustificazioni riportava "vedere la policy" per novantatré righe. Dove le proprietà del documento mostravano che l'ultima modifica era stata fatta da qualcuno di un'altra azienda completamente diversa, perché il file era stato scaricato da internet e i nomi non erano mai stati cambiati. L'auditor legge prima la SoA. Se cade a pezzi, nient'altro vi salva.

Come coinvolgere il management. La Clausola 5 stabilisce che il top management deve dimostrare leadership e impegno. In pratica, significa che occorre far sì che il board stanzi il budget, partecipi ai management review e approvi le decisioni di accettazione del rischio. Lo standard dice "il management deve". Non dice come presentarsi a una riunione del consiglio e spiegare perché l'azienda deve spendere denaro in qualcosa che non ha un ROI visibile fino al giorno in cui qualcosa va storto. È un problema di comunicazione, non di sicurezza, e la maggior parte delle implementazioni fallisce qui, non a livello tecnico.

Come prepararsi per l'audit. Lo Stage 1 è la revisione della documentazione. Lo Stage 2 è l'evidenza operativa. La maggior parte delle persone si prepara per uno e va nel panico durante l'altro. Costruiscono documenti eccellenti e poi non riescono a dimostrare che i controlli siano effettivamente in funzione. Oppure hanno controlli operativi ma non riescono a produrre la catena di evidenze. Lo standard dice "prepararsi per l'audit di certificazione". Non dice cosa apre prima l'auditor, quali domande arrivano nella prima ora, né cosa fa inciampare le persone ogni singola volta. Lo so, perché sono stato su entrambi i lati di quel tavolo.

Cosa significa davvero metodologia

Quando dico che questo corso insegna la metodologia, non intendo che si riceve una checklist. Intendo che si impara il sistema operativo che sta dietro allo standard.

Una metodologia dice cosa fare prima, e perché. Dice come condurre il workshop di scoping in modo che richieda un giorno, non un trimestre. Fornisce un framework di risk assessment che si può difendere, non solo compilare. Mostra come appare una buona SoA e cosa rende evidente una cattiva. Insegna come presentare la sicurezza a un board che non si interessa alla sicurezza, in un linguaggio che lo faccia interessare. E dice cosa farà l'auditor, in quale ordine, così ci si può preparare invece di limitarsi a sopravvivere.

Questa è la differenza tra conoscere lo standard e saper implementarlo. Ed è la differenza tra un progetto di sei mesi che ha successo e uno di dodici mesi che produce un archivio pieno di documenti che nessuno usa.

A questo servono i 5 giorni

Dal 17 al 21 agosto. Da lunedì a venerdì. Live online, in inglese. Un gruppo limitato a sei partecipanti, perché al settimo la conversazione muore e gli esercizi diventano una formalità.

Ogni riga di quella tabella inizia con "come". È intenzionale. Il "cosa" è nello standard. Lo si può leggere gratuitamente. Il "come" è ciò per cui si paga.

Chi insegna questo corso

Io. Christophe. CISO attivo, fondatore di Cyber Academy, PECB Gold Trainer.

Non insegno l'implementazione da un libro di testo. La insegno dal lavoro sul campo. Quando spiego la metodologia di risk assessment, è perché ho costruito framework di rischio e poi mi sono seduto di fronte a un auditor che ha cercato di smontarli. Quando spiego come ottenere il buy-in del management, è perché mi sono presentato davanti a board che non volevano sentirlo e ho trovato il modo di farli ascoltare. Quando qualcuno nel corso dice "la mia SoA è un disastro", non fornisco la risposta da esame. Dico cosa farei se fossi seduto alla loro scrivania il lunedì, perché ci sono stato a quella scrivania.

Duecento audit. Cento implementazioni. I casi reali in questo corso sono miei. Conta, perché il divario tra lo standard e la realtà non è teorico. È operativo. E lo si impara a colmare da chi lo fa di mestiere.

La garanzia

Completate il corso. Sostenete l'esame. Se non lo superate, rimborsamo la quota di formazione.

Nessuna clausola nascosta oltre al completamento del programma e al sostenimento dell'esame. La chiamiamo Certified or Refunded, e la intendiamo sul serio. La metodologia funziona. Il tasso di superamento lo dimostra. E se si investe una settimana del proprio tempo e il denaro dell'azienda, si merita un fornitore che scommette sullo stesso risultato.

I dettagli

• Corso: ISO/IEC 27001:2022 Lead Implementer, PECB Certified
• Date: 17–21 agosto 2026
• Formato: Live online. Interattivo. Non registrato.
• Lingua: Inglese
• Dimensione del gruppo: da 3 a 6 partecipanti
• Esame: Esame PECB di 3 ore al Giorno 5, open-book
• Materiali: Oltre 450 pagine incluse
• CPD: 31 crediti
• Ripetizione gratuita: Entro 12 mesi
• Prezzo: €2.499
• Garanzia: Certified or Refunded

La vostra mossa

Se avete letto lo standard e non sapete ancora cosa fare il lunedì mattina, questo è il corso che colma quella lacuna.

Se vi è stato assegnato un progetto di implementazione e cercate su Google "ISO 27001 risk assessment template" a mezzanotte, questo vi fornisce la metodologia così da non doverlo cercare mai più.

Se siete un consulente e i vostri clienti si aspettano che guidiate questo processo dall'inizio alla fine, è qui che smettete di improvvisare e iniziate a sapere.

Se siete a otto mesi di un progetto che avrebbe dovuto richiederne quattro, questo è il vostro reset di cinque giorni.

Riservate il vostro posto qui sotto.

Domande? Scrivetemi direttamente. Nessun team di vendita. Nessun chatbot. Solo io.

Christophe Fondatore e Formatore, Cyber Academy | Become the Code Father cyberacademy.net