ISO 27001 implementation per PMI: roadmap pratica 2026
Implementare ISO 27001 significa costruire un Sistema di Gestione della Sicurezza delle Informazioni (SGSI) operativo, non semplicemente raccogliere documenti. Il primo passo è ottenere il mandato formale del top management, nominare un responsabile ISMS (tipicamente un CISO o un referente dedicato), condurre una gap analysis e redigere il Statement of Applicability (SoA) insieme al piano di trattamento del rischio. Per una PMI, il percorso dalla decisione iniziale al rilascio del certificato richiede generalmente alcuni mesi; organizzazioni più complesse, con infrastrutture legacy o sedi multiple, devono prevedere tempi più lunghi.
Le fasi si articolano in nove passi: mandate della direzione, pianificazione, avvio ISMS, gap analysis e definizione dello scope, risk assessment, redazione del SoA e della documentazione, implementazione dei controlli, audit interno e riesame della direzione, audit di certificazione (Stage 1 e Stage 2). Ogni fase produce deliverable concreti che il management può verificare e approvare.

Un consiglio: Predisporre il SoA come documento guida fin dalle prime settimane, prima ancora di completare l’implementazione tecnica. Gli auditor lo considerano la bussola dell’intero ISMS: un SoA incompleto o non motivato è la causa più frequente di non conformità in Stage 1.
Indice
- Cosa richiede davvero la ISO 27001:2026 e cosa non è
- Come si implementa ISO 27001 passo dopo passo: la roadmap in 9 fasi
- Perché il SoA è l’artefatto centrale dell’ISMS
- Quali documenti e prove servono per superare l’audit
- Come funziona l’audit di certificazione con organismi accreditati Accredia
- Quanto tempo e quanto costa implementare ISO 27001 per una PMI
- Errori frequenti e checklist di readiness prima dell’audit
- ISO 27001 in Italia nel 2026: diffusione, NIS2 e valore competitivo
- Punti chiave
- Governance e SoA contano più degli strumenti
- Securityhub per l’implementazione ISO 27001: un percorso assistito
- Fonti utili e riferimenti normativi
Cosa richiede davvero la ISO 27001:2026 e cosa non è
ISO 27001 non è uno standard tecnologico. È un modello di gestione del rischio informativo che integra persone, processi e sistemi IT attraverso un ciclo Plan-Do-Check-Act. La versione 2022, recepita in Italia come norma internazionale di riferimento per il SGSI, ha riorganizzato l’Annex A riducendo i controlli a 93, raggruppati in quattro temi: controlli organizzativi, controlli sulle persone, controlli fisici e controlli tecnologici.
Le clausole da 4 a 10 definiscono i requisiti del sistema di gestione: contesto dell’organizzazione, leadership, pianificazione, supporto, operatività, valutazione delle prestazioni e miglioramento continuo. L’aggiornamento del 2022 ha introdotto controlli specifici per cloud, threat intelligence e data masking, riflettendo l’evoluzione degli ambienti IT aziendali.
Il SoA è il documento che elenca tutti i 93 controlli dell’Annex A, indica per ciascuno se è applicabile o escluso, ne giustifica la scelta e rimanda alle evidenze di implementazione. Non è un adempimento burocratico: è la mappa che collega il risk assessment alle misure concrete adottate.
I deliverable minimi richiesti dallo standard sono:
- Scope dell’ISMS: perimetro organizzativo, geografico e tecnologico del sistema
- Policy della sicurezza delle informazioni: impegno della direzione e obiettivi di sicurezza
- Statement of Applicability (SoA): selezione e giustificazione dei controlli Annex A
- Risk assessment e piano di trattamento del rischio: metodologia, risultati e azioni pianificate
- Obiettivi di sicurezza misurabili e piani per raggiungerli
- Registrazioni delle attività operative (log, report, verbali, evidenze di formazione)
In Italia, gli organismi di certificazione devono essere accreditati da Accredia, l’ente unico nazionale di accreditamento. Scegliere un organismo non accreditato Accredia significa ottenere un certificato privo di valore legale e commerciale nel mercato europeo.
Come si implementa ISO 27001 passo dopo passo: la roadmap in 9 fasi
La guida completa alle fasi di certificazione di Securityhub articola il progetto in nove fasi sequenziali, ciascuna con obiettivi, deliverable e responsabilità definiti.
Mandate della direzione (Mese 0): Il top management approva formalmente il progetto, definisce budget e risorse, nomina il responsabile ISMS. Deliverable: lettera di incarico, budget approvato, composizione del comitato di sicurezza.
Pianificazione del progetto (Mese 1): Il responsabile ISMS redige il piano di progetto con milestone, risorse e dipendenze. Deliverable: project plan, matrice RACI, calendario delle attività.
Avvio ISMS e definizione dello scope (Mese 1–2): Si definisce il perimetro del SGSI: quali processi, sedi, sistemi e dati rientrano nella certificazione. Uno scope troppo ampio aumenta costi e tempi; uno troppo ristretto riduce il valore commerciale del certificato.
Gap analysis (Mesi 1–2): Mappatura degli asset, confronto con i requisiti dell’Annex A e valutazione iniziale dei controlli esistenti. Deliverable: report di gap analysis, inventario asset preliminare, lista delle aree di miglioramento prioritarie.
Risk assessment (Mesi 2–4): Identificazione delle minacce e vulnerabilità per ogni asset, stima di impatto e probabilità, calcolo del livello di rischio. Deliverable: registro dei rischi, metodologia documentata, soglie di accettabilità approvate dalla direzione.
Redazione del SoA e della documentazione (Mesi 3–5): Selezione dei controlli applicabili, giustificazione delle esclusioni, redazione delle procedure operative. Deliverable: SoA firmato, policy di sicurezza, procedure critiche (gestione incidenti, backup, accessi, change management).
Implementazione dei controlli (Mesi 4–8): Attivazione delle misure tecniche (MFA, SIEM, backup cifrato) e organizzative (formazione, sensibilizzazione, revisione dei contratti con fornitori). Deliverable: evidenze tecniche, registrazioni di formazione, verbali del comitato di sicurezza.
Audit interno e riesame della direzione (Mese 9): Verifica interna dell’efficacia del SGSI, identificazione delle non conformità e avvio delle azioni correttive. Il riesame della direzione valuta i risultati degli audit, le metriche di performance e le decisioni sulle risorse. Deliverable: report di audit interno, verbale di riesame, piano di azioni correttive.
Audit di certificazione Stage 1 e Stage 2 (Mesi 10–12): L’organismo accreditato verifica prima la documentazione (Stage 1) e poi l’implementazione operativa on site (Stage 2). Deliverable: certificato ISO 27001 con validità triennale.
Un consiglio: Parallelizzare la redazione della documentazione con l’implementazione tecnica riduce i tempi complessivi senza compromettere la qualità. Scrivere le procedure mentre si configurano i controlli tecnici evita il rischio di documentare a posteriori pratiche già consolidate in modo diverso.
Deliverable per fase: tabella di riferimento
| Fase | Deliverable principali | Ruoli responsabili |
|---|---|---|
| Mandate | Lettera di incarico, budget | Top management, CDA |
| Pianificazione | Project plan, RACI | Responsabile ISMS |
| Scope | Documento di perimetro ISMS | Responsabile ISMS, IT manager |
| Gap analysis | Report gap, inventario asset | Responsabile ISMS, team IT |
| Risk assessment | Registro rischi, metodologia | Responsabile ISMS, process owner |
| SoA e documentazione | SoA, policy, procedure | Responsabile ISMS, legale, HR |
| Implementazione controlli | Evidenze tecniche, log formazione | IT, HR, procurement |
| Audit interno | Report audit, azioni correttive | Auditor interno, responsabile ISMS |
| Certificazione | Certificato ISO 27001 | Organismo accreditato Accredia |

Se l’organizzazione dispone già di un sistema di gestione ISO 9001, è possibile integrare i processi esistenti per ridurre le duplicazioni documentali: mappare i process owner comuni e usare riferimenti incrociati nelle procedure abbatte il carico documentale in modo significativo.
Perché il SoA è l’artefatto centrale dell’ISMS
Il Statement of Applicability non è un modulo da compilare: è il documento che dimostra che l’organizzazione ha ragionato sui propri rischi e ha scelto consapevolmente quali controlli adottare e perché. Un SoA ben costruito permette anche di evitare acquisti tecnologici sovradimensionati: le esclusioni motivate su base di rischio reale giustificano la non adozione di controlli non pertinenti al contesto aziendale.
La struttura raccomandata prevede almeno sei colonne per ogni controllo dell’Annex A:
- Controllo: codice e titolo del controllo (es. A.8.8 Gestione delle vulnerabilità tecniche)
- Applicabilità: sì / no / parzialmente
- Motivazione: perché il controllo è incluso o escluso (riferimento al risk assessment o alla natura del business)
- Stato di implementazione: pianificato / in corso / implementato
- Evidenze di implementazione: riferimento ai documenti o log che provano l’adozione
- Riferimenti documentali: procedure, policy o registrazioni collegate
Le esclusioni devono essere giustificate con ragionamenti basati sugli asset e sui rischi, non su considerazioni di costo o convenienza. Un auditor accetterà l’esclusione del controllo sulla sicurezza fisica degli uffici remoti se l’organizzazione non ha dipendenti in smart working con accesso a dati classificati; non la accetterà se quella stessa organizzazione gestisce dati sensibili da postazioni non presidiate.
Un consiglio: Collegare ogni controllo del SoA a uno o più rischi del registro dei rischi. Questo collegamento bidirezionale è ciò che rende il SoA difendibile in sede di audit e trasforma il documento da adempimento a strumento di governance.
Gli errori più frequenti nella redazione del SoA sono:
- Esclusioni senza motivazione o con motivazioni generiche («non applicabile al nostro settore»)
- Stato «implementato» per controlli ancora in fase di pianificazione
- Disallineamento tra SoA e procedure operative effettivamente in uso
- Mancanza di riferimenti alle evidenze di implementazione
- SoA non aggiornato dopo modifiche al perimetro o al risk assessment
Quali documenti e prove servono per superare l’audit
La guida pratica agli step di implementazione di Securityhub distingue tra documenti obbligatori e registrazioni operative. I primi definiscono il sistema; le seconde dimostrano che il sistema funziona.
Documenti obbligatori minimi:
- Scope dell’ISMS
- Policy della sicurezza delle informazioni
- Statement of Applicability
- Metodologia di risk assessment
- Registro dei rischi e piano di trattamento
- Obiettivi di sicurezza e piani di raggiungimento
- Procedure per i processi critici (gestione incidenti, continuità operativa, accessi, change management)
Evidenze operative richieste dagli auditor:
- Log di sistema e report di monitoraggio della sicurezza
- Report di vulnerability assessment e penetration test
- Registrazioni delle sessioni di formazione e sensibilizzazione (firme di presenza, quiz di verifica)
- Prove di backup e test di ripristino (con date e risultati)
- Verbali del comitato di sicurezza e del riesame della direzione
- Ticket di gestione degli incidenti e delle azioni correttive
- Contratti e valutazioni di sicurezza dei fornitori critici
Struttura dei pacchetti di evidenza per Stage 1 e Stage 2
| Tipo di verifica | Cosa inviare | Formato |
|---|---|---|
| Stage 1 (documentale) | SoA, policy, procedure, risk assessment, scope | PDF firmati, versione controllata |
| Stage 1 (documentale) | Obiettivi di sicurezza, piano di trattamento | Documento con date e responsabili |
| Stage 2 (on site) | Log di sistema, report audit interno, verbali | File di log, PDF, screenshot |
| Stage 2 (on site) | Evidenze di formazione, test di backup | Registri presenze, report tecnici |
| Stage 2 (on site) | Ticket incidenti, azioni correttive chiuse | Export da sistema di ticketing |
Per il controllo documentale, adottare un sistema di versioning con data, numero di versione e responsabile dell’approvazione per ogni documento. Un repository centralizzato (SharePoint, Confluence o equivalente) con accessi controllati riduce il rischio di versioni non aggiornate in circolazione.
Come funziona l’audit di certificazione con organismi accreditati Accredia
L’audit interno precede sempre l’audit certificativo e serve a identificare le non conformità prima che lo faccia l’auditor esterno. La frequenza minima è annuale, ma molte organizzazioni ne pianificano uno aggiuntivo nei 60 giorni precedenti l’audit di Stage 2.
La metodologia dell’audit interno prevede: definizione del piano di audit (scope, criteri, auditor), raccolta delle evidenze tramite interviste e campionamento dei log, redazione del report con classificazione delle non conformità (maggiori e minori) e avvio delle azioni correttive. Un auditor interno non deve essere il responsabile ISMS: serve indipendenza dal processo auditato.
Il riesame della direzione è un requisito esplicito della clausola 9.3. Gli input tipici includono i risultati degli audit interni, le metriche di performance del SGSI, lo stato delle azioni correttive, i feedback degli stakeholder e le modifiche al contesto organizzativo. La direzione deve produrre decisioni documentate su risorse, obiettivi e miglioramenti.
Processo di certificazione con organismo accreditato Accredia:
- Stage 1: l’auditor esamina la documentazione del SGSI (SoA, policy, risk assessment, procedure). L’esito può essere positivo, con osservazioni o con non conformità che richiedono correzione prima dello Stage 2. Durata tipica: 1–2 giorni.
- Stage 2: verifica on site dell’implementazione operativa. L’auditor intervista il personale, campiona i log, verifica le evidenze e testa la coerenza tra documentazione e pratiche reali. Durata: 2–5 giorni in base alla dimensione dell’organizzazione.
- Rilascio del certificato: dopo la chiusura delle non conformità, l’organismo emette il certificato con validità triennale. Audit di sorveglianza annuali nel primo e secondo anno; audit di rinnovo al terzo anno.
Per scegliere l’organismo di certificazione, verificare:
- Accreditamento Accredia per lo schema ISO 27001
- Esperienza nel settore specifico dell’organizzazione (es. finanza, sanità, PA)
- Capacità di coprire sedi multiple con un unico contratto
- Trasparenza sui costi (giorni-uomo di audit, tariffe giornaliere, spese di trasferta)
- Disponibilità di auditor con competenze tecniche IT, non solo gestionali
Un consiglio: Richiedere almeno tre preventivi da organismi accreditati Accredia e confrontarli non solo sul prezzo, ma sul numero di giorni-uomo previsti per Stage 1 e Stage 2. Un preventivo con meno giorni-uomo del necessario produce un audit superficiale che non aggiunge valore.
Quanto tempo e quanto costa implementare ISO 27001 per una PMI
Le stime di durata dipendono dalla complessità organizzativa, dall’estensione dello scope e dalla maturità iniziale dei controlli di sicurezza.
| Tipo di organizzazione | Durata stimata | Note |
|---|---|---|
| PMI 20–50 dipendenti, scope limitato | 6–12 mesi | Gap analysis 1–2 mesi; implementazione 4–6 mesi |
| Organizzazione media, multisede | alcuni mesi | Complessità IT, più process owner, più sedi da auditare |
| Grande organizzazione, infrastrutture legacy | — | Integrazione sistemi legacy, requisiti NIS2, supply chain estesa |
Per una PMI, il costo complessivo della prima certificazione può variare considerevolmente in base a consulenza, audit, tecnologia e formazione.
| Voce di costo | Range indicativo |
|---|---|
| Ore interne dedicate (stima costo opportunità) | variabile |
I fattori che aumentano tempi e costi in modo rilevante sono: la presenza di più sedi fisiche, infrastrutture IT obsolete che richiedono aggiornamenti prima dell’audit, uno scope che include la supply chain, e i requisiti aggiuntivi derivanti dalla NIS2 per i settori critici.
Prevedere un margine del 15–20% sul budget per azioni correttive post-audit e per i costi degli audit di sorveglianza annuali è una pratica prudente che evita sorprese nel secondo e terzo anno di certificazione.
Errori frequenti e checklist di readiness prima dell’audit
Le non conformità più ricorrenti negli audit di certificazione ISO 27001 derivano da tre cause principali: documentazione scollegata dalle pratiche operative, formazione insufficiente del personale e scarso coinvolgimento del management dopo la fase iniziale.
Errori da evitare:
- SoA con esclusioni non motivate o motivazioni generiche
- Procedure scritte che nessuno conosce o applica
- Risk assessment eseguito una sola volta e mai aggiornato
- Assenza di test documentati per backup, ripristino e incident response
- Formazione limitata al personale IT, senza coinvolgere HR, legale e management
- Audit interno condotto dal responsabile ISMS sulle proprie attività (mancanza di indipendenza)
- Azioni correttive aperte ma non chiuse entro i termini previsti
Checklist di readiness (30–60 giorni prima dell’audit)
- Il SoA è aggiornato, firmato dalla direzione e allineato al risk assessment corrente
- Tutte le procedure critiche sono in versione controllata e accessibili al personale
- Il registro dei rischi è stato rivisto negli ultimi 6 mesi
- L’audit interno è stato completato e il report è disponibile
- Le non conformità dell’audit interno hanno azioni correttive chiuse o in corso con scadenza definita
- Il riesame della direzione è documentato con verbale firmato
- Le evidenze di formazione coprono tutto il personale nello scope
- I log di sistema sono conservati per il periodo previsto dalla policy di retention
- I test di backup e ripristino sono documentati con data e risultato
- I contratti con i fornitori critici includono clausole di sicurezza verificabili
- Il piano di gestione degli incidenti è stato testato (anche con un esercizio tabletop)
- Gli obiettivi di sicurezza hanno metriche misurabili e dati di monitoraggio disponibili
- La documentazione è in un repository centralizzato con controllo degli accessi
- Il personale chiave sa rispondere alle domande base di un auditor sul proprio ruolo nel SGSI
- Il responsabile ISMS ha verificato la coerenza tra SoA e pratiche operative reali
Per i mock audit, condurre interviste strutturate con campionamento dei log rivela spesso gap che una semplice revisione delle checklist non individua. Programmare almeno un mock audit 60 giorni prima dell’audit certificativo è una pratica che riduce significativamente il rischio di non conformità maggiori.
ISO 27001 in Italia nel 2026: diffusione, NIS2 e valore competitivo
In Italia, un numero crescente di aziende ha ottenuto la certificazione ISO 27001, spinto soprattutto dalla Direttiva NIS2 e dalle richieste di sicurezza nella supply chain da parte delle grandi organizzazioni. Questo dato posiziona l’Italia tra i mercati europei con la crescita più rapida nell’adozione dello standard.
La certificazione produce vantaggi concreti e misurabili per le PMI italiane:
- Accesso a bandi pubblici e contratti con grandi aziende: molte gare d’appalto e capitolati di fornitura richiedono esplicitamente la certificazione ISO 27001 come requisito di qualificazione
- Riduzione del rischio assicurativo: alcune polizze cyber riconoscono la certificazione come fattore di riduzione del premio
- Risposta strutturata alla NIS2: per i soggetti essenziali e importanti identificati dalla direttiva, ISO 27001 fornisce il framework operativo su cui innestare i requisiti specifici (notifiche entro 24 ore, valutazione della supply chain, misure di continuità operativa)
Per le aziende soggette a NIS2, la strategia più efficiente è avviare la ISO 27001 come framework di base, che copre buona parte dei requisiti della direttiva, e integrare successivamente i requisiti specifici come le procedure di notifica e la gestione del rischio nella catena di fornitura.
Un consiglio: Prima di avviare un progetto NIS2 separato, verificare quali requisiti della direttiva sono già coperti dall’ISMS ISO 27001 in corso di implementazione. Nella maggior parte dei casi, il gap residuo è gestibile con integrazioni documentali mirate, senza duplicare l’intero sistema di gestione.
Punti chiave
Implementare ISO 27001 richiede un mandato formale della direzione, una gap analysis strutturata, un SoA motivato e un piano di trattamento del rischio: senza questi quattro elementi, il progetto non parte su basi solide.
| Punto | Dettagli |
|---|---|
| Tempi realistici per PMI | 6–12 mesi dalla decisione iniziale al certificato; alcuni mesi per organizzazioni complesse |
| SoA come artefatto centrale | Va redatto nelle prime settimane e aggiornato a ogni modifica del risk assessment |
| NIS2 e ISO 27001 | ISO 27001 copre la maggior parte dei requisiti NIS2; le integrazioni puntuali sono gestibili |
| Securityhub | Supporta PMI e organizzazioni complesse in tutte le fasi, dalla gap analysis all’audit di certificazione |
Governance e SoA contano più degli strumenti
La questione che vedo ripetersi in quasi ogni progetto di certificazione è questa: le organizzazioni investono in tecnologia e trascurano la governance. Acquistano un SIEM, configurano l’MFA, attivano il backup cifrato, e poi arrivano all’audit con un SoA che non riflette nulla di tutto questo, procedure che nessuno ha mai letto e un management che considera la certificazione un problema del reparto IT.
ISO 27001 non certifica la tecnologia. Certifica il sistema di gestione. Un’organizzazione con strumenti modesti ma con un risk assessment solido, un SoA motivato e una direzione che partecipa attivamente al riesame supera l’audit. Un’organizzazione con un’infrastruttura eccellente ma con documentazione scollegata dalle pratiche operative accumula non conformità già in Stage 1.
Il punto che molti responsabili IT sottovalutano è che l’ownership interna dell’ISMS non si delega interamente al consulente esterno. Il consulente porta metodo, template e competenza certificativa; ma il responsabile ISMS interno deve capire il sistema, saperlo spiegare agli auditor e mantenerlo vivo dopo il rilascio del certificato. Le certificazioni che decadono o che producono audit di sorveglianza problematici sono quasi sempre quelle in cui l’organizzazione ha esternalizzato tutto senza costruire competenza interna.
Il SoA, in questo senso, è il test più immediato della maturità di un’organizzazione: se il responsabile ISMS non sa spiegare perché un controllo è stato escluso, l’auditor lo rileva in pochi minuti. La solidità di quel documento riflette la solidità dell’intero sistema.
Securityhub per l’implementazione ISO 27001: un percorso assistito
Chi ha già letto questa guida sa che implementare ISO 27001 richiede competenze trasversali: gestione del rischio, redazione documentale, conoscenza tecnica dei controlli e familiarità con i processi di audit Accredia. Securityhub affianca le PMI e le organizzazioni italiane in ogni fase di questo percorso, dalla gap analysis iniziale fino al supporto durante l’audit di Stage 2.

I servizi disponibili coprono l’intero ciclo: redazione del SoA e delle procedure operative, implementazione dei controlli tecnici e organizzativi, formazione del personale e del management, conduzione di mock audit interni e supporto alla selezione dell’organismo di certificazione accreditato Accredia. Per le organizzazioni già soggette a NIS2, Securityhub integra i requisiti della direttiva nel progetto ISO 27001 senza duplicare il sistema di gestione.
Il vantaggio concreto è la riduzione dei tempi grazie a template già validati in contesti di audit reali e a un team con esperienza diretta nei processi di certificazione. Per richiedere una sessione di valutazione iniziale o un preventivo personalizzato, è possibile consultare la guida completa alla certificazione ISO 27001 oppure accedere direttamente alla pagina dei servizi di certificazione per avviare il contatto con il team.
Fonti utili e riferimenti normativi
Per approfondire i temi trattati in questa guida, le risorse più autorevoli disponibili sono:
- Certificazione ISO 27001 — Regione Lombardia OPR: riferimento istituzionale italiano per la definizione dello standard e del SGSI
- Certificazione ISO 27001: requisiti, tempi e costi — Webmanager: analisi dell’Annex A 2022 e dei 93 controlli per temi
- Guida alla certificazione ISO 27001 — Cyber Security 360: panoramica su passi, preparazione e valore della certificazione
- Step implementazione ISO 27001 — Securityhub: roadmap operativa con template e dettagli sulle fasi per le PMI italiane
- Checklist certificazione ISO 27001 — Securityhub: strumento di readiness check da usare nei 30–60 giorni prima dell’audit






