NIS2 articolo 21(2)(a): i due documenti che ogni auditor chiede per primi
Il 15 agosto 2026 è entrata in vigore la Cyberbeveiligingswet olandese. Oltre 8.000 organizzazioni hanno ora un dovere di diligenza, l'obbligo di registrazione presso l'NCSC e un termine di notifica di 24 ore.
A nessuna di esse verrà chiesto per prima cosa della console EDR.
L'articolo 21(2)(a) di NIS2 è il punto da cui parte ogni colloquio con l'autorità di vigilanza: la vostra politica di sicurezza delle reti e dei sistemi informativi e il vostro quadro di gestione del rischio. Due documenti. Entrambi approvati dall'organo di gestione. Entrambi datati.
La maggior parte delle organizzazioni non possiede nessuno dei due nella forma effettivamente richiesta dalla normativa. Ecco cosa richiede l'articolo 21(2)(a), misura per misura, e cosa significa per i consulenti che devono realizzarlo.
L'articolo 21(2)(a) contiene due obblighi, non uno
Il testo della Direttiva è breve: «politiche di analisi dei rischi e di sicurezza dei sistemi informativi». Letto in fretta, sembra un unico documento.
Il Regolamento di esecuzione (UE) 2024/2690 la vede diversamente. Il suo allegato divide l'articolo 21(2)(a) in due sezioni principali distinte:
- Sezione 1 — Politica di sicurezza delle reti e dei sistemi informativi, oltre a ruoli, responsabilità e autorità.
- Sezione 2 — Politica di gestione del rischio: il quadro, il monitoraggio della conformità e il riesame indipendente.
Il Regolamento è direttamente vincolante per fornitori DNS, registri di TLD, fornitori cloud, operatori di data center, CDN, managed service provider, managed security service provider, mercati online, motori di ricerca, piattaforme social e prestatori di servizi fiduciari. Per tutti gli altri è il parametro di riferimento di fatto, perché le autorità nazionali non hanno nulla di più specifico con cui misurare.
Se consegnate un'unica «politica di sicurezza delle informazioni» combinata e considerate chiuso l'articolo 21(2)(a), ne avete soddisfatto circa la metà.
La vostra politica di sicurezza ha undici contenuti obbligatori
Il punto 1.1.1 dell'allegato elenca cosa deve contenere la politica di livello più alto. Non «dovrebbe considerare» — deve stabilire:
- L'approccio del soggetto alla gestione della sicurezza delle proprie reti e sistemi informativi
- La coerenza con la strategia e gli obiettivi aziendali
- Obiettivi di sicurezza dichiarati
- Un impegno al miglioramento continuo
- Un impegno a fornire risorse — personale, budget, processi, strumenti, tecnologie
- Comunicazione ai dipendenti e alle parti esterne rilevanti e loro presa d'atto
- Ruoli e responsabilità di cui al punto 1.2
- La documentazione da conservare e la relativa durata di conservazione
- L'elenco delle politiche tematiche
- Indicatori e misure per monitorare l'attuazione e il livello di maturità attuale
- La data di approvazione formale da parte degli organi di gestione
Il punto 5 è quello su cui fallisce il maggior numero di audit. Una politica che si impegna sulla sicurezza ma mai su budget o organico non è conforme a 1.1.1(e). Nemmeno il punto 10: se non potete mostrare gli indicatori con cui misurate la vostra stessa politica, avete una dichiarazione d'intenti, non una politica.
Il punto 11 è il più economico da correggere e il più spesso assente. Una politica priva di approvazione datata dell'organo di gestione è, ai fini della vigilanza, una bozza.
Dove si colloca 21(2)(a) tra le dieci misure
L'articolo 21(2)(a) è la prima delle dieci misure di gestione del rischio — e quella da cui tutte le altre derivano. Il controllo degli accessi ai sensi di 21(2)(i) deve essere una politica tematica sotto la vostra politica di alto livello. I requisiti di backup ai sensi di 21(2)(c) devono discendere da un'analisi di impatto sul business che alimenta il vostro piano di trattamento del rischio. Se (a) è sbagliato, le altre nove non hanno fondamenta.
Articolo 21 — 10 Misure di Cybersicurezza NIS2
Articolo 21
10 Misure di Cybersicurezza
Governance & Strategia
1Analisi dei rischi & politiche di sicurezza delle informazioni6Valutazione dell'efficacia delle misure di sicurezzaIncidenti & Continuità
2Gestione degli incidenti & notifica3Continuità operativa & ripristino di emergenzaCatena di Fornitura & Sistemi
4Sicurezza della catena di fornitura5Sicurezza nello sviluppo di sistemi di rete e informativiControlli Tecnici
8Crittografia & cifratura10Autenticazione a più fattori & comunicazioni sicurePersone & Risorse
7Igiene informatica & formazione9Sicurezza HR & controllo degli accessi
L'organo di gestione deve firmare — e firmare di nuovo
Il punto 1.1.2 richiede che la politica sia riesaminata e, se opportuno, aggiornata dagli organi di gestione almeno annualmente e, in aggiunta, ogni volta che si verificano incidenti significativi o cambiamenti significativi delle operazioni o dei rischi. L'esito di ciascun riesame deve essere documentato.
Due conseguenze pratiche.
Primo: «annualmente» è una soglia minima, non un calendario. Una fusione, una nuova piattaforma cloud, un incidente ransomware presso un fornitore chiave — ognuno di questi attiva un riesame fuori ciclo. Se il vostro cliente ha introdotto un nuovo ERP a marzo e la politica è stata riesaminata l'ultima volta a gennaio, è una lacuna che un'autorità trova con una sola domanda.
Secondo: il riesame è un'attività dell'organo di gestione, non dell'IT. Il CISO può prepararlo. L'organo di gestione deve eseguirlo. È l'espressione operativa della responsabilità personale prevista dall'articolo 20 — ed è il motivo per cui i verbali del consiglio sono diventati evidenza di audit.
Almeno una persona deve riferire direttamente all'organo di gestione
Il punto 1.2.3 è una frase con conseguenze sproporzionate: almeno una persona riferisce direttamente agli organi di gestione in materia di sicurezza delle reti e dei sistemi informativi.
Per un MSP questa è la linea che non potete varcare per conto del cliente. Potete gestire il SOC, scrivere la politica, mantenere il registro dei rischi e preparare il dossier per il consiglio. Non potete essere la persona che riferisce al consiglio per loro conto, perché la responsabilità risiede all'interno del soggetto.
Il punto 1.2.5 aggiunge la separazione dei compiti in conflitto, ove applicabile. Il punto 1.2.4 riconosce la realtà dei soggetti più piccoli: la sicurezza può essere un compito svolto in aggiunta a un ruolo esistente anziché una funzione dedicata. Ciò che non ammette è l'assenza del compito.
Il quadro di gestione del rischio è un processo, non un foglio di calcolo
Il punto 2.1.2 dell'allegato definisce il processo di gestione del rischio cyber in dieci passaggi. I soggetti devono:
- Seguire una metodologia di gestione del rischio
- Stabilire un livello di tolleranza al rischio coerente con la propensione al rischio
- Stabilire e mantenere criteri di rischio
- Identificare e documentare i rischi con un approccio multirischio, includendo esplicitamente terze parti e single point of failure
- Analizzare minaccia, probabilità, impatto e livello di rischio, utilizzando intelligence sulle minacce e dati sulle vulnerabilità
- Valutare i rischi rispetto ai criteri
- Identificare e dare priorità alle opzioni di trattamento
- Monitorare continuamente l'attuazione delle misure di trattamento
- Indicare chi è responsabile di ciascuna misura di trattamento ed entro quando
- Documentare le misure in un piano di trattamento del rischio, con giustificazione comprensibile di ogni rischio residuo accettato
Confrontate quell'elenco con il registro dei rischi di un cliente medio. La maggior parte ha un elenco di rischi con valutazione rosso-ambra-verde. Pochissimi hanno metodologia documentata, livello di tolleranza dichiarato, responsabili nominati con scadenze e giustificazione scritta del rischio residuo.
Il requisito multirischio è anche più ampio di quanto la maggior parte dei team supponga. Copre minacce fisiche e ambientali, guasto di fornitori e indisponibilità del personale — non solo attacchi informatici. Se il vostro registro contiene solo scenari di attacco, non soddisfa 2.1.2(d). Il rischio di terze parti in particolare deve essere identificabile nel registro stesso, ed è lì che si collega agli obblighi di catena di fornitura ai sensi dell'articolo 21(2)(d).
Il punto 2.1.3 aggiunge un vincolo che i consulenti dovrebbero accogliere con favore: nel dare priorità al trattamento, i soggetti devono ponderare il costo di attuazione rispetto al beneficio atteso. La proporzionalità è scritta nel Regolamento. Non siete tenuti a raccomandare tutto — siete tenuti a giustificare ciò che avete fatto e ciò che non avete fatto.
Il rischio residuo deve avere un nome
Il punto 2.1.1 è la frase che cambia la governance: i risultati della valutazione del rischio e i rischi residui devono essere accettati dagli organi di gestione, o da persone responsabili e con autorità di gestire i rischi, con adeguata rendicontazione agli organi di gestione.
È un requisito di firma. «Il consiglio è stato informato» non è accettazione. Deve esserci una decisione, di una persona responsabile identificata, verbalizzata.
Il punto 2.1.4 richiede poi di riesaminare la valutazione del rischio e il piano di trattamento a intervalli pianificati e almeno annualmente, nonché dopo incidenti significativi o cambiamenti significativi. Stessa logica di attivazione del riesame della politica, applicata al registro.
Monitoraggio della conformità e riesame indipendente sono due cose diverse
Il punto 2.2 richiede un riesame periodico della conformità alle vostre politiche, norme e regole, con rendicontazione regolare agli organi di gestione tramite un efficace sistema di reporting sulla conformità.
Il punto 2.3 richiede tutt'altro: un riesame indipendente dell'approccio del soggetto alla gestione della sicurezza — persone, processi e tecnologie — svolto da individui con adeguata competenza di audit che non siano nella linea gerarchica dell'area riesaminata.
Dove la separazione è impossibile per dimensione, il soggetto deve adottare misure alternative che garantiscano l'imparzialità. Non può semplicemente saltare il riesame.
È l'apertura commerciale più chiara dell'articolo 21(2)(a) per consulenti e vCISO. Un soggetto importante di dieci persone non può produrre un revisore indipendente internamente. Uno esterno è la misura alternativa. Notate che 2.3 si affianca, non sostituisce, la valutazione di efficacia di cui all'articolo 21(2)(f) — le autorità si aspetteranno entrambe.
Le autorità non aspettano più
La pressione arriva da due direzioni contemporaneamente.
Sul piano nazionale: i Paesi Bassi sono entrati in vigore il 15 agosto 2026 con la Cyberbeveiligingswet, che copre 18 settori e oltre 8.000 soggetti. La finestra di registrazione tedesca si è chiusa mesi fa con una quota rilevante di soggetti in ambito ancora non registrata. Austria, Svezia, Polonia e Portogallo sono tutte in vigore.
Da Bruxelles: l'8 luglio 2026 la Commissione europea ha deferito Irlanda, Spagna, Francia e Paesi Bassi alla Corte di giustizia dell'UE per recepimento incompleto, chiedendo sanzioni pecuniarie. Gli Stati membri lenti nel recepimento sono spinti con forza — il che storicamente si traduce in autorità nazionali desiderose di dimostrare attività di enforcement non appena la loro legge entra in vigore.
Stato di Attuazione NIS2 per Paese (2025–2026)
Pienamente in vigore
BelgioCroaziaUngheriaLituaniaLettoniaItalia6 paesiAdottata — fine 2025
GermaniaRepubblica CecaFinlandia3 paesiIn corso — previsto 2026
Paesi BassiFranciaSpagnaPoloniaAustriaSveziaIrlanda7 paesi
Cosa succede quando manca 21(2)(a)
Una politica assente o non datata raramente è il rilievo che chiude un'ispezione. È il rilievo che ne apre una. Se la politica di alto livello non è approvata, le politiche tematiche sottostanti non hanno mandato. Se il registro dei rischi non ha metodologia, ogni decisione di controllo a valle diventa ingiustificabile.
Da lì l'armamentario di vigilanza sale di livello: istruzioni vincolanti, audit obbligatori a spese del soggetto, pubblicazione della non conformità, sanzioni amministrative fino a 10 milioni di euro o al 2 % del fatturato annuo mondiale per i soggetti essenziali e — per i soggetti essenziali — sospensione temporanea delle funzioni dirigenziali.
Escalation delle sanzioni NIS2 — Oltre la multa
!Evento scatenante
Non conformità rilevata o incidente verificatosi
Un'autorità di vigilanza identifica una lacuna di conformità o un'organizzazione non soddisfa i requisiti NIS2
Le autorità possono imporre▼Sanzioni non finanziarie1Ordini di conformità con scadenze vincolanti
2Audit di sicurezza obbligatori a vostre spese
3Divulgazione pubblica delle violazioni
4Istruzioni vincolanti su misure di sicurezza specifiche
Scala verso▼Conseguenze operative e personali1Sospensione di certificazioni o licenze operative
2Divieto temporaneo di funzioni dirigenziali per individui
3Denominazione pubblica delle persone fisiche responsabili
Evento scatenanteNon finanziarioOperativo / personale
Un piano di 30 giorni per i consulenti
Se supportate clienti in ambito, questa sequenza produce le prove difendibili più rapidamente:
Giorni 1–5. Recuperate l'attuale politica di sicurezza del cliente. Verificatela rispetto agli undici contenuti del punto 1.1.1. La maggior parte fallisce su risorse, indicatori e data di approvazione.
Giorni 6–10. Accertate se qualcuno riferisce direttamente all'organo di gestione in materia di sicurezza. In caso contrario, nominate quella persona e mettetelo a verbale.
Giorni 11–20. Ricostruite il registro dei rischi attorno a 2.1.2: metodologia documentata, tolleranza dichiarata, ambito multirischio inclusi fornitori e single point of failure, responsabili nominati, scadenze e giustificazione scritta del rischio residuo.
Giorni 21–25. Portate la politica e il piano di trattamento del rischio davanti all'organo di gestione. Ottenete l'approvazione formale, datata e verbalizzata.
Giorni 26–30. Definite la cadenza del monitoraggio della conformità ai sensi di 2.2 e programmate il primo riesame indipendente ai sensi di 2.3, con una nota esplicita su come è garantita l'imparzialità.
Questo produce i due artefatti che un'autorità chiede per prima — con la tracciabilità di governance che dimostra che sono reali.
Se volete una lettura rapida della posizione di un cliente rispetto all'articolo 21 prima di impegnarvi su uno scope di progetto, eseguite il quick scan NIS2. Mappa le lacune in pochi minuti, così potete quotare il lavoro invece di stimarlo a occhio.
La versione breve
L'articolo 21(2)(a) non è sovraccarico documentale. È il controllo che rende difendibile ogni altro controllo. Una politica con undici contenuti definiti e un'approvazione datata del consiglio. Un quadro di rischio con metodologia, responsabili nominati e rischio residuo accettato. Monitoraggio della conformità e un riesame indipendente da parte di qualcuno fuori dalla linea gerarchica.
Tutto il resto dell'articolo 21 poggia su questo. Costruitelo per primo.