L'Art. 21 del D.Lgs. 138/2024 elenca le misure tecniche e organizzative minime che ogni soggetto NIS2 deve adottare per gestire i rischi di sicurezza dei sistemi informatici. Questa checklist operativa, pensata per il CISO e per chi ha responsabilità sull'implementazione, traduce le 10 famiglie di misure dell'Art. 21 in evidenze concrete: cosa serve, dove documentarlo, come dimostrarlo a un'ispezione ACN.
Il principio: misure proporzionate al rischio, evidenze obbligatorie
L'Art. 21 introduce un principio chiave: le misure devono essere proporzionate al livello di rischio dell'organizzazione, considerando le dimensioni, la criticità dei servizi erogati, le minacce specifiche del settore e lo stato dell'arte. Non esiste una "lista chiusa" di prodotti o di configurazioni: esiste un risultato di sicurezza atteso, da raggiungere con le tecnologie e i processi più adeguati al contesto.
Quello che è invariabile, invece, è il requisito di evidenza. Per ogni famiglia di misure deve esistere documentazione ricostruibile: policy approvata, processo eseguito, log conservato, report periodico. La conformità sostanziale senza evidenze documentali, in caso di ispezione, equivale a non conformità.
La checklist Art. 21: 10 famiglie di misure, evidenza per evidenza
1. Politiche di analisi del rischio e di sicurezza dei sistemi
Cosa serve: una metodologia di risk assessment formalizzata (ISO/IEC 27005, NIST SP 800-30 o equivalenti), un risk register aggiornato almeno annualmente, una Information Security Policy approvata dall'organo di gestione.
Evidenze: documento di metodologia, risk register datato e versionato, verbale di approvazione della policy.
2. Gestione degli incidenti
Cosa serve: procedura di incident response (rilevamento, classificazione, contenimento, eradicazione, ripristino, lessons learned), runbook per le tipologie di incidente più probabili, integrazione con la procedura di notifica Art. 25.
Evidenze: procedura formalizzata, log di eventuali incidenti gestiti con cronologia delle azioni, esercitazioni periodiche (tabletop o full-scale).
3. Continuità operativa: backup, disaster recovery, gestione delle crisi
Cosa serve: Business Impact Analysis (BIA), Business Continuity Plan (BCP), Disaster Recovery Plan (DRP) con RPO e RTO definiti per i processi critici, piano di crisis management per gli scenari peggiori.
Evidenze: BIA aggiornata, BCP/DRP testati con cadenza almeno annuale, registrazione dei test e dei relativi risultati, log di backup verificati periodicamente per la ripristinabilità.
4. Sicurezza della catena di approvvigionamento
Cosa serve: mappatura dei fornitori critici, processo di vendor risk assessment, clausole contrattuali di sicurezza (incluse SLA su incident response e diritto di audit), monitoraggio continuo della postura dei fornitori critici.
Evidenze: registro fornitori, questionari di due diligence compilati, contratti con clausole NIS2-compliant, eventuali certificazioni dei fornitori (ISO/IEC 27001, SOC 2 Type II).
5. Sicurezza nell'acquisizione, sviluppo e manutenzione dei sistemi
Cosa serve: Secure SDLC con gate di sicurezza (threat modeling, SAST, DAST, SCA), gestione delle vulnerabilità (vulnerability management e patch management con SLA per criticità), processo di responsible disclosure.
Evidenze: policy SDLC, report di SAST/DAST/SCA per le release, vulnerability dashboard con metriche di MTTR per criticità, registro delle patch applicate.
6. Politiche di valutazione dell'efficacia delle misure
Cosa serve: programma di audit interno periodico, vulnerability assessment e penetration test annuali (più frequenti per i sistemi più critici), red teaming per scenari avanzati.
Evidenze: piano di audit annuale, report di VA/PT con piano di remediation associato, evidenza delle remediation chiuse.
7. Igiene informatica di base e formazione
Cosa serve: piano formativo NIS2 stratificato (Management, CISO, IT, personale operativo), security awareness continuativa, simulazioni di phishing periodiche.
Evidenze: piano formativo annuale, registro delle ore erogate per ciascun profilo, certificati di partecipazione, report delle simulazioni di phishing con metriche di click rate e reporting rate.
8. Politiche di crittografia
Cosa serve: cryptography policy che definisca algoritmi accettati e vietati (in linea con linee guida ENISA e NIST), Key Management System per la gestione del ciclo di vita delle chiavi, cifratura at rest e in transit per i dati critici.
Evidenze: policy approvata, registro delle chiavi, configurazioni TLS/SSL conformi, eventuali HSM o servizi di key management cloud documentati.
9. Sicurezza delle risorse umane, controllo degli accessi e gestione degli asset
Cosa serve: processi di onboarding/offboarding con revoca tempestiva degli accessi, principio del least privilege, IAM e PAM per gli accessi privilegiati, asset inventory aggiornato con classificazione.
Evidenze: procedure HR-IT integrate, log degli accessi privilegiati conservati, asset inventory con owner e classificazione, periodico access review.
10. Autenticazione a più fattori e comunicazioni protette
Cosa serve: MFA obbligatoria per gli accessi privilegiati, per gli accessi remoti e per le applicazioni critiche; canali di comunicazione protetti per la gestione degli incidenti e per le comunicazioni di emergenza.
Evidenze: policy MFA, configurazioni IdP, log degli accessi MFA-protected, piano di comunicazione di emergenza testato.
Come si trasforma la checklist in roadmap
Una checklist non è un piano. Per trasformarla in una roadmap di adeguamento concreta servono tre passaggi: gap analysis (qual è lo stato attuale per ogni famiglia di misure), scoring del rischio residuo (quale gap espone l'organizzazione a un rischio inaccettabile) e priorizzazione (quali interventi vanno fatti subito, quali nei 6-12 mesi, quali oltre).
Il CISO che riesce a portare la roadmap in CdA in queste tre dimensioni — stato, rischio, priorità — ottiene approvazione del budget e copertura politica per gli interventi. È esattamente la collaborazione che l'Art. 20 chiede tra organo di gestione e management tecnico.
Risorse correlate
Per il quadro normativo completo: NIS2: la guida completa al D.Lgs. 138/2024. Per la procedura di notifica incidenti: Notifica incidenti NIS2: la procedura 24h / 72h / 1 mese. Per la gestione del rischio sui fornitori: NIS2 e supply chain. Per il regime sanzionatorio: Sanzioni NIS2 Art. 38. Per la formazione del CISO: Corso NIS2 per il CISO.