Chiunque legga la Determinazione ACN sulle misure NIS2 trova codici come GV.RR-02, ID.RA-01, PR.AA-03.
Si tratta di le sottocategorie del NIST Cybersecurity Framework, lo schema americano che l’Italia ha adottato dieci anni fa come Framework Nazionale e che oggi è la struttura che ha ispirato gli obblighi di ACN.

Capire il framework serve quindi a due cose: leggere le misure che vi riguardano sapendo da dove vengono e usare uno strumento che il resto del mondo usa per parlare di sicurezza con un linguaggio comune.

  1. Che cos’è il NIST Cybersecurity Framework
  2. Le sei funzioni
  3. Core, livelli e profili: come si usa
  4. Il Framework Nazionale e la Determinazione ACN
  5. NIST o ISO 27001?
  6. Dove il framework si verifica e dove no
NIST Cybersecurity Framework e Framework Nazionale italiano: le sei funzioni adottate dall'ACN per la NIS2

Che cos’è il NIST Cybersecurity Framework

Il NIST o National Institute of Standards and Technology è l’ente di standardizzazione del governo americano.
Nel 2013 un ordine esecutivo presidenziale gli affida il compito di scrivere uno schema volontario per la sicurezza delle infrastrutture critiche.
A febbraio 2014 esce la versione 1.0 del Cybersecurity Framework.
La 1.1 arriva nel 2018. La versione 2.0, pubblicata nel febbraio 2024 come documento NIST CSWP 29, estende l’ambito a qualsiasi organizzazione, di qualunque settore e dimensione.

Tre cose lo distinguono dagli standard che si incontrano di solito.

Non è una norma e non è certificabile.
Nessun ente rilascia un certificato “NIST CSF“. Tuttavia, si tratta di un elenco di risultati da raggiungere, scritto perché un’organizzazione possa descrivere dove sta, decidere dove vuole arrivare e che quest’ultima possa spiegarlo a terzi.

Il documenti è orientato ai risultati, non alle modalità di controllo.
Ad esempio, il documento non contiene l’indicazione “installate un firewall”, al contratio dice “le reti sono protette dall’accesso non autorizzato”.
Come arrivare al raggiungimento di questo obiettivo viene lasciato a chi lo applica. Per questo le indicazioni si adattano a qualunque soggetto: da una banca a un’azienda meccanica.

Il framework è una risorsa gratuita e pubblica: il documento si scarica dal sito del NIST senza registrazione.
La maggior parte degli altri standard tra cui anche ISO 27001, pubblica tabelle di corrispondenza verso di esso. È diventato la lingua comune con cui si confrontano schemi diversi.

Le sei funzioni del framework

Il cuore del framework si chiama Core ed è organizzato su tre livelli:

  • funzioni
  • categorie
  • sottocategorie.

Nella versione 2.0 le funzioni sono sei, le categorie 22 e le sottocategorie 106.
Ogni sottocategoria ha un codice: due lettere per la funzione, due per la categoria e un numero.

nist csf sei funzioni acn

Le sei funzioni del NIST CSF 2.0: in grigio le sottocategorie del framework, in rosso quelle che l’ACN ha reso misure di base per i soggetti NIS2.

Ad esempio PR.AA-03 è la terza sottocategoria della categoria “Autenticazione e controllo degli accessi” della funzione Protect.

  1. Govern, GV, è la funzione nuova della versione 2.0.
    Riguarda chi decide: la strategia di gestione del rischio, i ruoli e le responsabilità, le politiche, la supervisione, la catena di fornitura.
    Non è stata inventata da zero. Nella versione 1.1 queste cose stavano dentro Identify. Trentasei sottocategorie sono state spostate sotto un nome che gli amministratori leggono. Per questo Govern parte con 31 sottocategorie, più di qualunque altra funzione.
  2. Identify, ID, è sapere cosa si ha e cosa rischia.
    Comprende l’inventario degli asset, la valutazione del rischio, l’identificazione delle vulnerabilità e il miglioramento continuo.
  3. Protect, PR, raccoglie le misure che riducono la probabilità o l’impatto di un incidente.
    Gestione delle identità e degli accessi, formazione, sicurezza dei dati, sicurezza delle piattaforme, resilienza dell’infrastruttura.
  4. Detect, DE, è accorgersi che qualcosa sta succedendo: monitoraggio continuo e analisi degli eventi anomali.
  5. Respond, RS, è cosa si fa quando è successo: gestione dell’incidente, analisi, comunicazione, contenimento.
  6. Recover, RC, è il ritorno all’operatività: esecuzione del piano di ripristino e comunicazione.

Prima, durante e dopo l’incidente

Le prime tre funzioni riguardano il prima dell’incidente, la quarta il durante, le ultime due il dopo.
È una divisione utile anche per capire cosa si compra quando si compra un servizio di sicurezza. Un vulnerability assessment lavora in Identify. Un penetration test lavora in Identify e Protect. Un centro operativo lavora in Detect e Respond.

Come si usa: profili e livelli di implementazione

Il Core è l’elenco dei risultati. Da solo non dice niente di un’organizzazione specifica.
Per usarlo servono gli altri due componenti.

I profili sono il meccanismo centrale.
Un profilo corrente descrive quali risultati del Core l’organizzazione raggiunge oggi, sottocategoria per sottocategoria. Un profilo obiettivo descrive quali vuole raggiungere, in base al proprio rischio, ai requisiti normativi e alle aspettative dei clienti.
La differenza fra i due profili è il piano di lavoro, con le priorità già scritte.

I livelli di implementazione sono quattro, da parziale ad adattivo.
Descrivono quanto il processo di gestione del rischio è maturo: se le decisioni sono episodiche o integrate, se l’organizzazione impara dagli incidenti, se coinvolge la catena di fornitura.
Non sono un voto. Il NIST stesso sconsiglia di usarli come tale. Servono a capire se la gestione della sicurezza è un processo o una serie di reazioni.

In pratica un’azienda usa il framework così.
Prende le sottocategorie e per ciascuna si chiede: lo facciamo? Come lo dimostriamo?
Segna le risposte. La colonna delle risposte negative diventa il programma di lavoro.
È lo stesso esercizio che la Determinazione ACN chiede ai soggetti NIS2, con una differenza: lì le sottocategorie le ha già scelte l’Agenzia.

Il Framework Nazionale italiano e la Determinazione ACN

Nel febbraio 2016 il Centro di ricerca CIS della Sapienza e il Cybersecurity National Lab del CINI pubblicano il Framework Nazionale per la Cybersecurity.
È costruito sul NIST CSF 1.0, con adattamenti al contesto italiano.
Nel 2019 esce la versione 2.0, che aggiunge “Data Protection” al nome e sottocategorie dedicate al GDPR: 117 contro le 108 del NIST 1.1.

L’edizione 2025, realizzata con la collaborazione dell’ACN, è quella che la Determinazione 379907/2025 cita come riferimento.
Le misure di sicurezza di base per i soggetti NIS2 sono, testualmente, “sviluppate in accordo al Framework nazionale e organizzate in funzioni, categorie, sottocategorie e requisiti”.

I 43 codici della Determinazione sono sottocategorie NIST

I codici che compaiono negli allegati ACN sono le sottocategorie del framework.
Tutti i 43 corrispondono a sottocategorie del NIST 2.0. Si verifica sulla tabella di transizione dal 1.1 al 2.0 che il NIST pubblica insieme al documento.
Di questi, 42 esistevano già nella versione 1.1 con un codice diverso. Uno solo è nuovo del 2.0: ID.IM-01, sui miglioramenti identificati dalle valutazioni.
Quello che l’ACN ha aggiunto sono i requisiti numerati sotto ciascuna sottocategoria, che dicono cosa fare in concreto.

La tabella mostra quante sottocategorie ha ciascuna funzione nel NIST e quante ne ha selezionate l’ACN. L’abbiamo contata sul documento NIST e sugli allegati della Determinazione.

FunzioneSottocategorie nel NIST 2.0Misure ACN, importantiMisure ACN, essenziali
Govern311111
Identify21910
Protect221216
Detect1122
Respond1322
Recover812
Totale1063743

L’ACN ha preso circa un terzo delle sottocategorie e non in modo uniforme.
In Protect, per gli essenziali, quasi tre quarti. In Detect e Respond meno di un quinto.
Gli obblighi di base si concentrano su chi decide e su cosa protegge. Il rilevamento e la risposta restano a poche misure.
È una scelta coerente con la logica del framework: prima si sa cosa si ha e si decide chi ne risponde, poi si protegge, poi si rileva.

L’analisi delle singole misure e di quali richiedano una verifica esterna l’abbiamo fatta nell’articolo su quali misure ACN si dimostrano solo con una verifica.

La funzione Identify, verificata dall’esterno

Un vulnerability assessment copre le sottocategorie di Identify che non si dimostrano con un documento: l’inventario di ciò che è esposto, le vulnerabilità presenti, le priorità di intervento. Il report è l’evidenza che riempie quella colonna del profilo.

Scoprite il servizio di Vulnerability Assessment

Meglio NIST o ISO 27001?

È la domanda che si fa chi deve scegliere da dove cominciare.
La risposta è che non sono alternative.

La ISO 27001 è uno standard certificabile.
Definisce un sistema di gestione, con un ciclo di pianificazione, attuazione, verifica e miglioramento, più un elenco di controlli nell’allegato A.
Un ente terzo verifica che il sistema esista e funzioni. Rilascia un certificato che vale tre anni.
È quello che un cliente chiede quando vuole una garanzia formale.

Il NIST CSF è uno schema di risultati.
Non ha un ciclo di gestione proprio, non ha un ente che certifica, non ha un allegato di controlli.
Ha una struttura che permette di descrivere la propria situazione in modo confrontabile, più tabelle di corrispondenza che mappano ogni sottocategoria sui controlli della ISO 27001 e di altri standard.

In pratica si usano insieme.
Un’organizzazione certificata ISO 27001 ha già gran parte dei risultati del framework. Lo scopre compilando il profilo.
Un’organizzazione che parte dal framework ha una mappa di cosa le manca prima di affrontare una certificazione.
Il confronto fra i principali standard l’abbiamo fatto nell’analisi degli standard di sicurezza.

Per chi è in Italia la domanda ha oggi una risposta in più.
La strada della conformità NIS2 passa dal Framework Nazionale, quindi dal NIST, con i requisiti dell’ACN.
Chi parte dalla ISO 27001 trova gran parte delle misure già coperte ma deve comunque produrre le evidenze nella forma che la Determinazione chiede.

Quali risultati si possono verificare e quali no

Un profilo compilato a tavolino vale quanto chi lo compila.
Il framework stesso, nella sezione sull’uso, insiste sul fatto che i risultati vanno verificati e non dichiarati.

Le sottocategorie di Govern si verificano sui documenti.
Le politiche esistono, sono approvate, hanno una data, sono state riesaminate. Chi le legge può dire se ci sono. Non può dire se vengono applicate.

Quelle di Identify e di buona parte di Protect si verificano sui sistemi.
L’inventario è completo solo se un confronto con quello che è davvero esposto non trova differenze.
Le vulnerabilità sono identificate solo se qualcuno le ha cercate.
L’autenticazione a più fattori è attiva solo dove un test lo conferma.
I privilegi sono minimi solo se un accesso ordinario non porta oltre quello che dovrebbe.
È il lavoro di un penetration test, ed è l’unica parte del profilo che non si può compilare senza guardare.

Quelle di Detect, Respond e Recover si verificano con esercitazioni e con gli incidenti reali.
Richiedono strumenti in esercizio permanente e procedure provate. Sono attività che non eroghiamo.

Il framework, usato bene, dice a un’azienda una cosa sola e la dice in modo ordinato: cosa sa di sé, cosa ha deciso, cosa ha verificato e cosa ha solo scritto.
Le ultime due colonne sono quelle che un’ispezione guarda.

Protect, con prove

Un penetration test parte da un accesso realistico e verifica le sottocategorie di Protect sul campo: quali accessi richiedono il secondo fattore, fin dove porta un’utenza ordinaria, quali sistemi un segmento raggiunge. Il risultato è il profilo corrente scritto da chi ha provato, non da chi ha dichiarato.

Scoprite il servizio di Penetration Test


    Dichiaro di aver letto e compreso l'Informativa sul trattamento dei dati