Un’implementazione di ISMS viene spesso sottovalutata come progetto di documentazione. In pratica, però, non è la quantità di direttive a determinare la futura certificazione ISO-27001, bensì se si stabilisce il controllo della sicurezza come sistema operativo per le decisioni: responsabilità chiare, rischi tracciabili, controlli efficaci (Controls) e prove ripetibili. Proprio su questi punti molte organizzazioni falliscono – non per crittografia o firewall, ma per ambiti di applicazione poco chiari, processi non attuati e mancanza di evidenze.
Questo contributo fornisce una roadmap passo dopo passo orientata alla prospettiva di audit. È volutamente formulata in modo che la direzione IT, la compliance, la security e la direzione aziendale acquisiscano una comprensione comune: cosa deve essere deciso e quando? Quali artefatti sono obbligatori? Quali attività devono essere assegnate al funzionamento IT? E quali driver di costo e capacità è realistico prevedere?
Da chiarire in anticipo: ISO 27001, ISMS e Annex A in una frase
ISO/IEC 27001 descrive i requisiti per un sistema di gestione della sicurezza delle informazioni (ISMS): ossia per governance, gestione del rischio, processi e rendicontazione con cui la sicurezza delle informazioni viene gestita e migliorata. I Annex-A-Controls (misure di controllo da ISO/IEC 27001 ovvero richiamate da ISO/IEC 27002) sono una sorta di catalogo dei controlli: si selezionano misure adeguate in base ai rischi, si giustificano le deroga e si documenta il tutto nella Statement of Applicability (SoA, dichiarazione di applicabilità).
Importante per le aspettative: una certificazione non conferma „siamo al sicuro“, ma „gestiamo la sicurezza delle informazioni in modo sistematico, basato sul rischio e verificabile“.
Roadmap in 10 passaggi: dall’ambito alla certificazione
I passaggi sono intenzionalmente sequenziali. Possono essere parallelizzati, ma non arbitrariamente: senza ambito (Scope) non è possibile una valutazione dei rischi sensata, senza trattamento dei rischi non c’è una SoA affidabile, senza processi applicati non ci sono evidenze per l’audit.
1) Sponsorship, obiettivo e governance minima
Non cominciate con le policy, ma con una decisione di management: perché ISO 27001? I driver frequenti sono requisiti dei clienti, requisiti della supply chain, riduzione di responsabilità e rischio o consolidamento delle pratiche di sicurezza tra sedi. Da questi driver ricavate quanto „rigido“ deve essere l’ISMS e dove potete restare pragmatici.
Stabilite una governance minimamente funzionante:
- Responsabilità del top management: Chi detiene la responsabilità complessiva (tipicamente la direzione generale o la direzione IT aziendale)?
- ISMS-Owner: gestione funzionale, coordinamento, reporting.
- Risk Owner: responsabili dei rischi per aree/servizi (non solo „l’IT“).
- Asset Owner: responsabili dei valori informativi (dati, sistemi, servizi).
- Process Owner: per change, incident, supplier, backup ecc.
Prospettiva audit: gli auditor verificano presto se i ruoli esistono non solo sulla carta, ma se decisioni, approvazioni ed escalation sono tracciabili (es. verbali, ticket, management review).
2) Definire ambito e contesto: cosa appartiene veramente all’ISMS?
Il Scope (ambito di applicazione) è la variabile più rilevante in termini di costi e complessità. Uno Scope troppo ampio consuma capacità, uno troppo ristretto risulta privo di valore per il business o non soddisfa i requisiti dei clienti. Lo Scope dovrebbe essere tecnicamente preciso: unità organizzative, sedi, flussi informativi, soluzioni aziendali digitali, componenti infrastrutturali, servizi esternalizzati.
Linee guida pratiche per uno Scope valido in sede di audit:
- Definire in termini di servizio: ad es. „Gestione della piattaforma di processo prossima all’ERP incl. l’elaborazione dati associata“ invece di „reparto IT“.
- Interfacce esplicite: cosa è „in“, cosa è „out“ (ad es. Shared Services, IT di gruppo, data center esterni, SaaS).
- Sedi e lavoro remoto: se processi rilevanti vengono eseguiti da remoto, ciò deve essere considerato nello Scope.
- Contesto normativo: requisiti contrattuali, legali e specifici del settore (senza sostenere che ISO 27001 sostituisca altre norme).
Trappola tipica dello Scope: „Certifichiamo solo il data center“. Se però i processi core si basano su Cloud-SaaS, endpoint e fornitori, lo Scope diventa implausibile e l’analisi dei rischi artificiosa.
3) Costruire l’inventario: asset, processi, flussi di dati
Senza un inventario affidabile il risk management resta vago. Non serve un programma CMDB perfetto, ma un coerente inventario degli asset e una rappresentazione comprensibile dei flussi di dati critici.
Cosa gli auditor generalmente vogliono vedere:
- Elenco degli asset (sistemi, applicazioni, database, servizi cloud, segmenti di rete, chiavi/PKI, classi di endpoint).
- Valori informativi: tipologie di dati e loro requisiti di protezione (riservatezza, integrità, disponibilità).
- Mappa dei processi per i processi operativi rilevanti per la sicurezza (Incident, Change, Access, Backup, Supplier).
- Confini di sistema e dipendenze (ad es. IdP, M365, ticketing, monitoring, destinazione backup, logging).
Approccio pragmatico: iniziate con le „Top 20“ dei servizi critici e ampliate in modo iterativo. ISO 27001 richiede efficacia e completezza nello Scope, non una bellezza accademica.
4) Definire la metodologia di rischio: come valutare i rischi senza perdersi
ISO 27001 non prescrive un metodo specifico, ma richiede che la vostra valutazione del rischio sia coerente, ripetibile e documentata. Ciò che conta è il metodo, non lo strumento.
In pratica si è dimostrata efficace una scala contenuta (es. 1–5) per:
- Impatto (business/operativo/legale)
- Probabilità di occorrenza (sulla base di ipotesi su attori della minaccia, esposizione, livello di maturità)
- Criterio di rischio: da quando deve essere trattato (soglia di accettazione)
Importante: definite se valutate i rischi “inerenti” (prima dei controlli) o i rischi “residui” (dopo i controlli) – e come tracciate lo stato nel registro dei rischi.
Come modello copiabile per una policy di rischio sintetica (estratto):
Valutazione del rischio (ISMS) – Standard sintetico
1. Scopo
- Valutazione e trattamento uniformi dei rischi per la sicurezza delle informazioni nell'ambito dell'ISMS.
2. Scale
- Impatto (I): 1 = basso, 5 = minaccia esistenziale
- Probabilità (W): 1 = rara, 5 = frequente
- Rischio = I x W
3. Criteri di rischio
- 1–6: accettabile (giustificazione documentata)
- 8–12: trattamento necessario (piano con scadenza e responsabile)
- 15–25: trattamento immediato / decisione del management
4. Contenuti minimi per ogni rischio
- Asset/Servizio, minaccia, vulnerabilità, controlli esistenti, valutazione, responsabile, opzione di trattamento,
piano d'azione, rischio residuo, accettazione/autorizzazione.
Prospettiva audit: un metodo snello e realmente applicato è meglio di un modello complesso che nessuno usa in modo coerente.
5) Analisi delle lacune rispetto a ISO 27001: maturità e priorità
L’analisi delle lacune risponde a: quali requisiti sono già soddisfatti, dove manca il processo, dove manca la prova? Non è un fine a sé stante, ma uno strumento di prioritizzazione per budget e capacità.
Valutate separatamente:
- Design: processo/policy esiste ed è sensato.
- Implementazione: viene effettivamente eseguita (es. workflow di change, on-/offboarding).
- Evidenza: le prove sono reperibili, complete, coerenti (ticket, log, registrazioni).
Molte organizzazioni sono già avanti nel design, ma falliscono su implementazione ed evidenza. Pianificate quindi tempo per il „collegamento operativo“ (Betriebsverdrahtung): modelli di ticket, campi obbligatori, periodi di conservazione, responsabili.
6) Selezione dei controlli e redazione della SoA: basato sul rischio, non guidato dal catalogo
La Statement of Applicability è uno dei documenti di audit centrali. Elenca quali Annex-A-Controls sono applicabili al vostro scope, se sono implementati e come sono realizzati. „Non applicabile“ è consentito, ma deve essere motivato – e non deve ovviamente contraddire i vostri rischi.
Regole pratiche per una SoA affidabile:
- Mappatura dei rischi: Per i rischi rilevanti deve essere riconoscibile quali controlli li mitigano.
- Fare riferimento all’implementazione: Indicare policy, processi e standard tecnici concreti.
- Stato e roadmap: Se sono previsti controlli, servono scadenze e responsabili.
- Gestire le eccezioni: i processi di eccezione (Exceptions) sono a loro volta controlli: documentati, a termine, approvati.
Esempio di una voce di SoA come struttura testuale (senza riferimenti normativi):
Controllo: controllo degli accessi (Identity & Access)
Applicabile: Sì
Motivazione: accesso ai sistemi produttivi e ai dati dei clienti nel perimetro.
Implementazione: policy IAM, processo Joiner/Mover/Leaver, standard MFA, ricertificazione periodica.
Evidenze: HR-Trigger, ticket, IAM-Logs, registrazioni di ricertificazione.
Stato: Implementato (parzialmente); ricertificazione per Legacy-System X entro Q4.
Responsabile: Operazioni IT / responsabilità applicativa
7) Operationalizzare i processi chiave: dove ISO 27001 „si svolge“ nella pratica quotidiana
La certificazione raramente si gioca su una singola misura. Si decide sui processi operativi ripetibili. Per il management IT questi processi sono le leve più importanti, perché migliorano contemporaneamente sicurezza, stabilità e auditabilità.
Identity & Access Management (IAM): diritti, ruoli, ricertificazione
IAM significa: identità, ruoli, autorizzazioni, autenticazione. Critici non sono solo gli account admin, ma anche i service account, le API-Key e gli accessi di terze parti. Domande tipiche da audit: chi autorizza gli accessi? Quanto velocemente vengono eseguiti gli offboarding? Come verificate regolarmente che i permessi siano ancora necessari?
- Joiner/Mover/Leaver: onboarding, cambi di ruolo, offboarding con trigger chiari.
- MFA (Autenticazione multi-fattore): prioritario per remote, admin, cloud, VPN, applicazioni critiche.
- Ricertificazione: verifica periodica di ruoli e privilegi speciali.
- Privileged Access: identità amministrative separate, registrazione delle attività, elevazione temporanea dei privilegi.
Change- e Patch-Management: modifiche controllate invece di interventi „eroici“
Gli auditor non cercano un’implementazione ITIL perfetta, ma controllo: valutazione del rischio delle change, approvazioni, prove di test, piano di rollback. Per la sicurezza il patch management è centrale, ma a livello operativo spesso è il collo di bottiglia.
Uno standard di change praticabile si può far rispettare tramite campi obbligatori nel sistema di ticketing:
Change-Ticket – Campi obbligatori (minimo)
- servizi/asset interessati
- categoria di rischio (basso/medio/alto) + motivazione
- test/validazione (come e dove)
- piano di rollback
- finestra di manutenzione + lista di comunicazione
- approvazione (ruolo, data)
- prova dell'implementazione (log/screenshot/check di monitoraggio)
Logging & Monitoring: capacità di fornire evidenze e analisi degli incidenti
Il logging è un controllo, ma anche la vostra assicurazione in caso di incidente. Fondamentali sono: raccolta centralizzata, sincronizzazione temporale (NTP), conservazione, protezione degli accessi, e un processo praticabile per la gestione degli allarmi.
- Use-Cases: es. login amministratore, azioni privilegiate, MFA non riuscita, modifiche a policy critiche.
- Retention: adeguata al rischio e ai requisiti contrattuali, con un piano di cancellazione.
- Integrità: protezione dalla manomissione (es. meccanismi write-once, privilegi amministrativi RESTrittivi).
Backup, RESTore und Verfügbarkeit: RTO/RPO als Management-Entscheid
ISO 27001 non richiede che esistano semplicemente dei backup, ma che la disponibilità venga pianificata e testata. RTO (Recovery Time Objective) e RPO (Recovery Point Objective) sono decisioni di business: quanto a lungo un servizio può rimanere non disponibile, quanta perdita di dati è tollerabile? Da queste scelte derivano tecnologia, costi e oneri operativi.
Siete pronti per l’audit se potete dimostrare test di ripristino, non solo job di backup. Pianificate almeno:
- Test di ripristino per sistemi critici (pianificati nel tempo, documentati, con lessons learned)
- Copie immutable/offline contro ransomware (in funzione del rischio)
- Gestione delle chiavi per backup cifrati (chi può ripristinare?)
Incident Response: vie di segnalazione, ruoli, capacità forense minima
Incident Response è il processo con cui gli eventi di sicurezza vengono rilevati, valutati, contenuti e riesaminati. Gli auditor cercano chiarezza: cos’è un incident? Chi decide l’escalation? Come viene documentato? Come nascono le misure di miglioramento?
Un semplice workflow per incident, conforme all’audit, comprende:
- Triage: classificazione in base a impatto/interessamento.
- Contenimento: contromisure tecniche immediate, revoca degli accessi, segmentazione.
- Comunicazione: stakeholder interni, eventualmente clienti/fornitori.
- Revisione post-incidenti: analisi delle cause, misure, verifica di efficacia.
Gestione dei fornitori: contratti, controlli, piano di uscita
Il rischio di terze parti è rilevante in quasi tutti gli ambiti: cloud, managed services, accessi di manutenzione, sviluppatori esterni, hosting. Un processo auditabile non richiede centinaia di questionari, ma requisiti minimi chiari:
- Due Diligence: requisiti di sicurezza e privacy prima dell’affidamento.
- Controlli contrattuali: p.es. subappaltatori, segnalazione di incidenti, diritti di audit/prova, localizzazione dei dati, cancellazione.
- Monitoraggio: verifica periodica dei fornitori critici.
- Uscita: RESTituzione/cancellazione dei dati, transizione, revoca degli accessi.
8) Progettare la documentazione in modo che possa essere gestita operativamente
Il difetto più comune: una raccolta di policy che nessuno trova o che non è utilizzabile nella pratica quotidiana. La documentazione deve servire per l’operatività, l’onboarding e gli audit. Lo si ottiene con gerarchia, versioning, approvazioni e standard brevi e inequivocabili.
Piramide documentale consigliata:
- ISMS-Policy: linee guida e obiettivi, approvazione del management.
- Standard: requisiti minimi vincolanti (p.es. MFA, logging, backup, hardening).
- Processi/Runbook: procedure concrete, ruoli, escalation.
- Records (prove): protocolli, ticket, report, audit-log.
Importante per audit e operatività: controllo documentale chiaro (versione, owner, data di approvazione, ciclo di revisione). Se usate un wiki, serve comunque una logica di approvazione e tracciamento delle modifiche.
9) Audit interno e valutazione della direzione: la prova pratica conta
L’audit interno verifica se il vostro ISMS soddisfa i requisiti e se è efficace. Efficacia significa: i controlli riducono i rischi in modo tracciabile e i processi funzionano in condizioni reali. L’audit interno è inoltre il miglior momento per colmare gap di evidenza prima dell’audit di certificazione.
Consigli pratici per un audit interno utilizzabile:
- Campionamenti da ticket, log, revisioni delle autorizzazioni, fascicoli dei fornitori.
La valutazione della direzione (Management Review) non è un atto formale. È la prova che il Top-Management decide in modo informato: sui rischi, le risorse, il raggiungimento degli obiettivi, le deviazioni e i miglioramenti. Input tipici: KPI/tendenze, incidenti rilevanti, risultati di audit, stato del piano di trattamento dei rischi, cambiamenti del contesto (nuovi Services, M&A, Outsourcing).
10) Pianificare l’audit di certificazione: Stage 1/Stage 2 e pacchetto di evidenze
La maggior parte degli organismi di certificazione lavora su due livelli:
- Stage 1: verifica documentale e di readiness (Scope, struttura ISMS, metodo di rischio, SoA, policy centrali).
- Stage 2: verifica dell’efficacia in esercizio (interviste, campionamenti, evidenze).
Pianificate un «pacchetto di evidenze» che usiate internamente nello stesso modo in cui lo utilizzarete in audit: un deposito strutturato con link/cartelle chiari che renda reperibili SoA, registro dei rischi, evidenze di processo, audit interni, management review e record chiave. L’obiettivo non è sommergere gli auditor di materiale, ma fornire rapidamente evidenze solide.
Checklist: ciò che serve davvero per fase
Le checklist seguenti sono volutamente concise. Potete usarle come punto di partenza per template interni, modelli di ticket o la vostra area ISMS.
Fase A – Setup (2–6 settimane, a seconda della situazione iniziale)
- Scope incl. interfacce, sedi, Services definito e approvato
- Ruoli/RACI (chi decide, chi fornisce input) documentati
- Metodo di rischio incl. criteri e soglie di accettazione stabiliti
- Gestione dei documenti (versione, review, approvazione) definita
- Inventario iniziale degli asset per i servizi critici creato
Fase B – Build (6–16 settimane)
- Registro dei rischi inizialmente popolato e prioritizzato
- Piano di trattamento dei rischi con owner, scadenze, ipotesi sui costi
- SoA redatta e coerente con i rischi
- Processi core operazionalizzati (IAM, Change/Patch, Logging, Backup/RESTore, Supplier, Incident)
- Tracciamento delle evidenze tramite ticket/report/log stabilito
Fase C – Run & Prove (6–12 settimane)
- Audit interni con campionamenti eseguiti, findings tracciati
- Valutazione della direzione effettuata, decisioni documentate
- KPI/reporting (es. stato delle patch, recertificazione, test di ripristino, statistica degli incidenti) stabiliti
- Pacchetto di evidenze e deposito ripuliti, responsabilità chiarite
Costi, sforzo e colli di bottiglia tipici: pianificate realisticamente
Un’introduzione a ISO-27001 raramente fallisce per l’audit di certificazione in sé, ma per la capacità operativa del day-to-day. Considerate che le linee di business e l’IT operativo dovranno fornire tempo ricorrente: per workshop sul rischio, review dei privilegi, verifiche dei fornitori, disciplina delle modifiche e manutenzione delle evidenze.
Tipici driver di costo (senza numeri forfettari):
- Estensione dello Scope: il numero di Services/sedi/fornitori determina il carico di audit e di mantenimento.
- Tooling: logging centrale/SIEM, estensioni IAM, asset management, tooling GRC (opzionale, ma talvolta sensato).
- Indurimento e modernizzazione: i sistemi legacy generano eccezioni, controlli aggiuntivi e rischi operativi.
- Capacità di produrre evidenze: ticket strutturati, protocolli, recertificazioni richiedono tempo ma prevengono discussioni future.
Avvertimento sui colli di bottiglia dal punto di vista operativo: se oggi il vostro processo di change e patch è non strutturato, la ISO 27001 non lo migliorerà „automaticamente“. Dovete investire consapevolmente in disciplina dei processi, finestre di manutenzione, ambienti di test e responsabilità.
Prospettiva di audit: quali domande dovRESTe essere in grado di rispondere in qualsiasi momento
Se potete rispondere a queste domande con sicurezza e fornirne evidenza, di norma siete vicini allo stato „audit-ready“:
- Qual è lo scope dell’ISMS e perché è stato definito così?
- Quali sono i principali rischi, chi è il loro Owner e qual è lo stato del trattamento?
- Come vengono derivati dai rischi i controlli e come ciò si riflette nella SoA?
- Come garantite che solo persone autorizzate abbiano accesso (incl. offboarding, admin, fornitori terzi)?
- Come vengono valutate, approvate, testate e ripristinate le modifiche?
- Quali log sono critici, come vengono protetti, per quanto tempo sono conservati e come vengono analizzati?
- Con quale frequenza testate il ripristino e cosa avete migliorato in seguito?
- Come gestite i rischi dei fornitori e terminate in modo ordinato accessi/contratti?
- Come apprendete da incidenti e audit (azioni correttive, controllo di efficacia)?
- Quali decisioni manageriali sono state prese di recente (risorse, accettazione, priorità)?
Errori comuni nell’implementazione dell’ISMS — e come evitarli
Troppa documentazione, poco esercizio operativo
Se le policy non sono „appese“ a ticketing, IAM e processi operativi, vi manca l’evidenza. Soluzione: pochi standard chiari e collegamento consequenziale con le attività quotidiane (campi obbligatori, date di ricertificazione, template per verbali).
Registro dei rischi trasformato in un cimitero Excel
Un registro senza Owner, scadenze e decisioni di management è critico in sede di audit. Soluzione: nominare un Risk Owner, usare il piano di trattamento come strumento di governo, fissare review periodiche.
Legacy e eccezioni non vengono adeguatamente sottoposte a escalation
Le eccezioni sono normali, ma devono essere a termine, motivate, autorizzate e tracciate. Soluzione: processo per le eccezioni con data di scadenza e organismo decisionale, più un piano per ridurre l’archivio delle eccezioni.
Fornitori solo „coperti“ contrattualmente
Contratti senza monitoraggio e piano di exit sono deboli. Soluzione: classificare la criticità, definire prove minime, review periodiche e checklist di offboarding.
Conclusione: la certificazione è un risultato, non un punto di partenza
Un’implementazione ISMS di successo nasce quando si stabilisce la sicurezza delle informazioni come processo di gestione e operativo ripetibile: definire lo scope in modo preciso, gestire i rischi in modo coerente, derivare i controlli in maniera tracciabile, ancorare i processi alla routine quotidiana e tenere le evidenze in modo strutturato. In tal modo l’audit di certificazione diventa la conferma formale di un sistema che già funziona — e non una frenetica campagna di documentazione poco prima della scadenza.
Anche le certificazioni ISO 27001 sono importanti per questo tema. Il contributo inquadra questi aspetti in modo chiaro e mostra cosa conta nella pratica quotidiana.