Come eseguire una Gap analysis tra framework (passo dopo passo)

Una Gap analysis risponde a una domanda: se già rispettiamo il framework A, cosa ci manca ancora per il framework B? Ecco un metodo che trasforma la risposta in un piano anziché in un foglio di calcolo che nessuno apre.

Ogni secondo framework parte dalla stessa domanda: quanto di questo abbiamo già? Una Gap analysis risponde proprio a questo. Fatta male, produce un foglio di calcolo che assegna "parzialmente conforme" a tutto e non viene mai più aperto. Fatta bene, produce un elenco di attività con costi e responsabili. Ecco il metodo che useremmo.

Passo 1: definire lo scope e la direzione

Una Gap analysis ha una direzione: avere un framework (o i controlli attuali) e dover soddisfare un altro. Scrivete entrambi, con le relative versioni, e lo scope organizzativo: quale entità, servizi e sedi. Le Gap analysis falliscono più spesso perché i due scope non coincidono, ad esempio quando un certificato ISO copre una sola linea di prodotto ma viene confrontato con un obbligo NIS2 riferito all'intera entità.

Passo 2: generare il confronto requisito per requisito

Partite da una mappatura, non da un foglio bianco. La Gap analysis di ControlMapping elenca ogni requisito del framework che vi serve, ciascuno con la sua corrispondenza in quello che avete:

mappato: un crosswalk pubblicato o il giudizio della Redazione lo collega a qualcosa che avete già.
correlazione debole: condivide solo un risultato con qualcosa che avete già. Consideratelo probabilmente un lavoro nuovo.
nessuna mappatura nei nostri dati: probabilmente lavoro nuovo, a meno che la copertura di quel framework non sia parziale.

Per esempio, passando da ISO 27001 a NIS2:

Dei 49 punti di requisito di NIS2, 49 (100%) corrispondono a qualcosa in ISO 27001, 0 sono solo debolmente correlati e 0 non hanno mappature nei nostri dati. Apri il report sui gap →

Passo 3: validare le corrispondenze con la realtà

Una mappatura indica che due requisiti sono correlati. Non dice che la vostra implementazione soddisfa entrambi. Per ogni riga mappata, chiedetevi:

Facciamo davvero ciò a cui abbiamo mappato? Una mappatura verso ISO A.8.8 serve solo se la gestione delle vulnerabilità funziona davvero.
Il nuovo requisito è più specifico? Scadenze, frequenze, tecniche specifiche e ambito spesso differiscono.
Il collegamento è una valutazione della Redazione? Verificate la motivazione mostrata e decidete se siete d'accordo.

Contrassegnate ogni riga come soddisfatto, parzialmente soddisfatto o non soddisfatto. Siate onesti: una Gap analysis troppo generosa sposta solo la scoperta dei problemi all'audit.

Fotografia di una lavagna bianca da ufficio coperta di colonne di post-it colorati vuoti, con un pennarello sul vassoio — Una Gap analysis è utile solo quando diventa un elenco di attività con responsabili.

Passo 4: esportarla come tracker

Premete e nella vista della Gap analysis (o il pulsante Esporta CSV) per scaricare il risultato. Ogni riga riporta requisito, sezione, corrispondenza, base e motivazione, più quattro colonne vuote pronte per il lavoro: responsabile, stato di implementazione, riferimento alle evidenze e note. Apritelo nel vostro foglio di calcolo o importatelo nel vostro strumento GRC.

Passo 5: trasformare le righe in lavoro

Raggruppate per responsabile e tema, non per numero di requisito: "contratti con i fornitori" è un'unica attività che può chiudere sei righe.
Stimate ogni gruppo e pianificatelo in sequenza: le modifiche a governance e policy di solito sbloccano il lavoro tecnico.
Compilate la colonna delle evidenze man mano, così il tracker diventa il vostro fascicolo per l'audit.
Ripetete l'analisi quando cambia uno dei due framework; la nostra si aggiorna quando cambiano i dati.

Punti chiave

Definite prima lo scope e la direzione: avere A, dover soddisfare B, con le versioni.
Partite da una mappatura, poi validate ogni corrispondenza su ciò che fate realmente.
Esportate il risultato come tracker con colonne di responsabili, stato ed evidenze, e trasformate le righe in lavoro raggruppato.

Errori comuni

Confrontare con una versione superata (CSF 1.1, ISO 27001:2013, PCI DSS v3.2.1).
Considerare "correlazione debole" come coperto.
Ignorare del tutto i requisiti fuori dalla mappatura: gli obblighi di legge, come le scadenze di notifica degli incidenti, spesso non compaiono in alcun catalogo di controlli.

Per esempi svolti, vedete ISO 27001 vs NIS2 punto per punto e i confronti, ciascuno dei quali è una Gap analysis bidirezionale già pronta.

Domande

Che cos'è una Gap analysis di conformità?

Un confronto requisito per requisito tra ciò che già fate (o il framework che già soddisfate) e i requisiti di un framework che vi serve, che identifica ciò che è coperto, parzialmente coperto e mancante.

Quanto tempo richiede una Gap analysis?

La mappatura può essere prodotta in pochi minuti con uno strumento come la Gap analysis di ControlMapping. Validarla rispetto ai vostri controlli e alle evidenze effettive è il lavoro vero, in genere da qualche giorno a un paio di settimane a seconda dello scope.

Cosa significa 'correlazione debole' in una Gap analysis?

I due requisiti condividono solo un risultato del NIST CSF 2.0; nessuno li ha mappati tra loro. Trattateli come una pista da verificare e, di solito, come lavoro nuovo, non come copertura.

Dati aggiornati al 2026-10-27: i numeri di questo articolo sono calcolati dal crosswalk attuale e si aggiornano quando questo cambia. Crosswalk una tabella di corrispondenza pubblicata (NIST, ENISA, CIS, PCI SSC) stabilisce il collegamento · Redazione Giudizio di ControlMapping dove non esiste una tabella di corrispondenza; la motivazione è indicata · condivide solo un esito di CSF 2.0: da verificare, non è una mappatura · Nessuna mappatura nei nostri dati nessuna mappatura nei nostri dati; spesso si tratta di lavoro nuovo, ma verifica le note sulla copertura. Non è una consulenza di conformità.

Come eseguire una Gap analysis tra due framework e ricavarne un tracker