Direttiva NIS 2 e cloud: i requisiti di conformità per le infrastrutture digitali

La direttiva NIS2 (Network and Information Security Directive), rispetto alla precedente NIS1 del 2016, è una riscrittura sostanziale del quadro europeo per la sicurezza delle reti e dei sistemi informativi che riflette una trasformazione fondamentale avvenuta nel decennio precedente: la migrazione massiva delle infrastrutture critiche verso ambienti cloud, l’espansione della superficie di attacco attraverso la supply chain digitale e la crescita esponenziale degli incidenti di sicurezza con impatto sistemico.

Il cloud non è, in questo contesto, un dettaglio tecnico: è il teatro principale in cui si giocano i requisiti di resilienza che la direttiva impone.

NIS2 e cloud: perché le infrastrutture digitali esterne sono al centro della direttiva

Per le organizzazioni che operano nei settori critici identificati dalla direttiva, l’adozione del cloud ha creato una dipendenza strutturale da infrastrutture digitali esterne che NIS2 intende presidiare con obblighi precisi.

I workload critici (sistemi di controllo industriale, piattaforme di gestione clinica, infrastrutture energetiche, sistemi finanziari) che un tempo risiedevano in data center interni sotto il diretto controllo dell’organizzazione, oggi girano su infrastrutture di provider terzi, con catene di sub-processor che si estendono attraverso più livelli e più giurisdizioni.

NIS2 risponde a questa realtà imponendo che la responsabilità della sicurezza rimanga in capo all’organizzazione cliente, indipendentemente da dove fisicamente risiedono i sistemi.

Il recepimento italiano della direttiva, avvenuto con il D.lgs. 138/2024 (in vigore dal 16 ottobre 2024), ha introdotto specificità nazionali significative rispetto al testo europeo, in particolare per quanto riguarda il perimetro dei soggetti obbligati, il ruolo dell’Agenzia per la Cybersicurezza Nazionale (ACN) come autorità competente e il calendario di adeguamento progressivo che ha già visto scadere le prime date e che proseguirà fino a tutto il 2026.

Per i consulenti e i CISO che supportano le organizzazioni nell’adeguamento, conoscere queste specificità non è un’opzione: è il prerequisito per un lavoro efficace.

Soggetti essenziali, importanti e provider cloud sotto NIS2

Di seguito, una breve analisi che aiuta a comprendere chi è soggetto all’adeguamento alla direttiva NIS2.

I settori critici e le soglie di applicabilità

NIS2 identifica due categorie di soggetti obbligati, distinte per livello di criticità e intensità degli obblighi.

• I soggetti essenziali operano nei settori ad altissima criticità elencati nell’Allegato I della direttiva: energia (elettricità, gas, petrolio, teleriscaldamento, idrogeno), trasporti (aerei, ferroviari, via acqua, su strada), settore bancario, infrastrutture dei mercati finanziari, settore sanitario, acqua potabile, acque reflue, infrastrutture digitali (IXP, DNS, TLD, CSP, CDN, data center, reti di comunicazione elettronica), gestione dei servizi ICT, pubblica amministrazione, spazio.
• I soggetti importanti operano nei settori di altra criticità dell’Allegato II: servizi postali, gestione dei rifiuti, produzione e distribuzione di sostanze chimiche, produzione e distribuzione di alimenti, manifatturiero in settori specifici, fornitori di servizi digitali (marketplace, motori di ricerca, social network), organizzazioni di ricerca.

Le soglie dimensionali si applicano in modo differenziato: in linea generale, le medie imprese (50-249 dipendenti, fatturato o totale di bilancio tra 10 e 50 milioni di euro) e le grandi imprese (oltre 250 dipendenti o fatturato superiore a 50 milioni) sono incluse nel perimetro.

Le microimprese e le piccole imprese (sotto i 50 dipendenti e sotto i 10 milioni di euro) sono escluse, salvo che non svolgano funzioni critiche specifiche o siano l’unico fornitore di un servizio essenziale in uno Stato membro.

Il D.lgs. 138/2024 ha introdotto la possibilità per ACN di includere anche soggetti sottosoglia che rivestano un ruolo critico per l’economia o la sicurezza nazionale.

I CSP come soggetti NIS2 in proprio

Una delle innovazioni più significative di NIS2 rispetto alla versione precedente è l’inclusione esplicita dei fornitori di servizi cloud (CSP) tra i soggetti obbligati, nella categoria delle infrastrutture digitali.

AWS, Microsoft Azure, Google Cloud, ma anche i provider cloud di dimensioni medie che operano nel mercato europeo, sono soggetti diretti degli obblighi NIS2, non solo come provider di infrastruttura per altri soggetti obbligati, ma in quanto gestori di infrastrutture digitali critiche in proprio.

Questo cambia significativamente la dinamica della relazione tra un’organizzazione cliente NIS2 e il proprio CSP: entrambi sono soggetti alla direttiva, entrambi hanno obblighi di sicurezza da rispettare, e la loro relazione è disciplinata anche dal quadro NIS2 oltre che dal contratto commerciale.

Per le organizzazioni che utilizzano servizi cloud, questo significa che il loro CSP è tenuto a rispettare requisiti di sicurezza analoghi ai propri e che possono legittimamente richiedere evidenza di questo rispetto come parte della propria due diligence sulla supply chain.

La certificazione EUCS (European Union Cybersecurity Certification Scheme for Cloud Services), sviluppata da ENISA e in fase di adozione progressiva, sarà lo strumento di riferimento per dimostrare la conformità dei CSP ai requisiti NIS2, offrendo tre livelli di assurance (Basic, Substantial, High) corrispondenti a diversi livelli di rischio e criticità dei servizi erogati.

I requisiti tecnici NIS2 per il cloud: l’articolo 21 in dettaglio

L’articolo 21 della direttiva NIS2, recepito nell’articolo 24 del D.lgs. 138/2024, è il cuore tecnico degli obblighi di sicurezza. Elenca le misure tecniche, operative e organizzative che i soggetti obbligati devono adottare, proporzionalmente al rischio e alla criticità delle funzioni svolte.

Non è un elenco di controlli specifici, anche perché NIS2 è una direttiva basata sul principio di proporzionalità, non un framework di controlli prescrittivi, ma definisce le aree tematiche obbligatorie, lasciando agli standard tecnici (in primis, il Framework Nazionale di Cybersecurity e Data Protection e poi NIST, ISO, CIS, framework ENISA) la specificazione dei controlli concreti.

Gestione del rischio e governance della sicurezza

Il primo requisito dell’art. 21 è l’adozione di politiche di analisi dei rischi e di sicurezza dei sistemi informativi.

Per le organizzazioni con infrastrutture cloud, questo si traduce nella necessità di un processo formale di risk assessment che copra esplicitamente i rischi derivanti dall’utilizzo di servizi cloud:

• concentrazione verso singoli provider;
• dipendenza da infrastrutture fuori dal proprio controllo diretto;
• rischi di disponibilità e integrità dei dati in ambienti multi-tenant.

Il risk assessment non è un documento da produrre una volta: NIS2 richiede che sia un processo continuo, aggiornato almeno annualmente e ogni volta che cambiano in modo significativo le condizioni del rischio.

La governance della sicurezza richiesta da NIS2 implica il coinvolgimento diretto del management: i dirigenti responsabili sono personalmente tenuti a supervisionare l’implementazione delle misure di sicurezza e possono essere ritenuti responsabili in caso di inadempimento.

Il D.lgs. 138/2024 ha reso esplicita questa responsabilità del management, prevedendo che gli organi di amministrazione e direttivi approvino le misure di gestione del rischio e seguano formazione periodica sulla cyber security.

Per le organizzazioni con infrastrutture cloud, il CdA deve essere informato e consapevole dei rischi associati all’utilizzo dei servizi cloud critici.

Crittografia, autenticazione e controllo degli accessi

L’art. 21, comma 2, lettera h) richiede esplicitamente l’uso della crittografia e, se del caso, della cifratura end-to-end.

Nel contesto cloud, questo requisito si traduce in obblighi concreti: crittografia dei dati a riposo e in transito, gestione sicura delle chiavi crittografiche (con preferenza per soluzioni BYOK o HYOK per i dati più sensibili) e utilizzo di protocolli crittografici aggiornati (TLS 1.3, eliminazione di SSL e TLS 1.0/1.1).

Per i dati classificati come critici (dati sanitari, dati finanziari, dati relativi a infrastrutture critiche) la crittografia end-to-end con chiavi gestite dall’organizzazione cliente è il requisito minimo accettabile.

L’autenticazione a più fattori (MFA) e i sistemi di autenticazione continua sono citati esplicitamente dall’art. 21, comma 2, lettera j). Per gli ambienti cloud, questo significa MFA obbligatoria per tutti gli accessi amministrativi e per tutti gli accessi a dati classificati come sensibili, senza eccezioni.

Le linee guida ENISA per l’implementazione di NIS2 raccomandano l’adozione di soluzioni di Identity and Access Management (IAM) integrate con i provider di identità aziendali tramite protocolli federati (SAML, OIDC), l’eliminazione delle credenziali statiche per gli account di servizio a favore di credenziali dinamiche o certificate-based authentication e la revisione periodica dei permessi con analisi dei diritti effettivi versus concessi (permission gap analysis).

Business continuity e gestione delle crisi

I requisiti di continuità operativa dell’art. 21, comma 2, lettere c) e d) sono particolarmente rilevanti per le organizzazioni con infrastrutture cloud.

La direttiva richiede la gestione della continuità operativa, inclusa la gestione dei backup e il ripristino in caso di disastro, e la gestione delle crisi.

Per il cloud, questo si traduce nella necessità di definire e testare RTO e RPO per tutti i sistemi critici, di mantenere backup in location geograficamente separate e sotto il controllo dell’organizzazione cliente (non solo del CSP), e di avere piani di continuità che contemplino scenari di indisponibilità del CSP principale, incluso il fallback su provider alternativi.

La gestione delle crisi richiede strutture organizzative dedicate: un team di incident response con ruoli e responsabilità definiti, procedure di escalation documentate, canali di comunicazione di emergenza e accordi di mutual aid con altri soggetti del settore.

Per le organizzazioni nei settori più critici (energia, sanità, infrastrutture digitali), NIS2 richiede la partecipazione a esercitazioni periodiche di gestione delle crisi a livello nazionale ed europeo, coordinate da ACN e da ENISA.

La supply chain cloud sotto NIS2: obblighi verso i fornitori

Tra i requisiti dell’art. 21, la sicurezza della catena di approvvigionamento – lettera d) – è quella con le implicazioni più ampie per le organizzazioni con infrastrutture cloud.

L’obbligo non si limita alla verifica del CSP principale: si estende a tutti i soggetti della catena di fornitura che hanno accesso ai sistemi informativi dell’organizzazione o che forniscono componenti critici per l’erogazione dei servizi. Sub-processor, fornitori di software, integratori, provider di connettività: ogni anello della catena deve essere valutato e presidiato.

L’adeguamento ai nuovi obblighi europei impone alle imprese di verificare l’affidabilità cyber di tutti i soggetti interconnessi.

L’applicazione delle linee guida di gestione del rischio fornitori consente di mappare i requisiti obbligatori richiesti e di strutturare il programma di valutazione della supply chain in modo coerente con le aspettative di ACN e delle autorità di vigilanza europee.

Il D.lgs. 138/2024 ha recepito questo requisito con particolare attenzione al contesto italiano, dove la catena di fornitura IT delle organizzazioni nei settori critici è spesso caratterizzata da una forte dipendenza da fornitori di medie dimensioni (system integrator, MSP, fornitori di software verticali) che non sono essi stessi soggetti NIS2 ma che hanno accesso privilegiato alle infrastrutture dei soggetti obbligati.

ACN ha chiarito che la responsabilità di verificare la postura di sicurezza di questi fornitori ricade sul soggetto NIS2 cliente, indipendentemente dalle dimensioni del fornitore. Non è sufficiente richiedere una dichiarazione di conformità: è necessario un processo strutturato di valutazione, contrattualizzazione e monitoraggio.

Notifica degli incidenti: obblighi, tempi e procedure sotto NIS2

Il regime di notifica degli incidenti è uno degli elementi di maggiore discontinuità rispetto alla NIS1 e uno degli aspetti più operativamente impegnativi per le organizzazioni.

NIS2 introduce un sistema a tre livelli:

1. l’early warning, da inviare ad ACN entro 24 ore dall’identificazione dell’incidente significativo;
2. la notifica, da inviare entro 72 ore con una valutazione iniziale dell’incidente, della sua gravità e del suo impatto;
3. la relazione finale, da trasmettere entro un mese con l’analisi completa delle cause, delle misure adottate e delle lezioni apprese.

Per gli incidenti in corso, è previsto un aggiornamento intermedio su richiesta di ACN.

La definizione di «incidente significativo» è cruciale: NIS2 considera significativo un incidente che causa o può causare interruzioni gravi della prestazione dei servizi, o perdite finanziarie considerevoli per l’entità interessata, o danni materiali o immateriali significativi ad altre persone fisiche o giuridiche.

Le linee guida ENISA per la notifica degli incidenti specificano soglie quantitative orientative (percentuale di utenti colpiti, durata dell’interruzione, volume di dati compromessi) che le autorità nazionali possono adottare come riferimento.

ACN ha già pubblicato indicazioni operative sulla soglia di significatività degli incidenti per il contesto italiano.

Per le organizzazioni con infrastrutture cloud, la notifica degli incidenti pone una sfida specifica: spesso l’incidente si verifica a livello del CSP, non direttamente nell’ambiente del cliente.

Un’interruzione del servizio del CSP, una violazione dei dati nell’infrastruttura del provider, una vulnerabilità nel software del cloud: in questi casi, il soggetto NIS2 cliente deve essere in grado di ricevere le informazioni necessarie dal CSP in tempi compatibili con gli obblighi di notifica.

Questo rende le clausole contrattuali di notifica degli incidenti, con obbligo del CSP di notificare al cliente entro 4 ore, non solo buone pratiche, ma prerequisiti operativi per il rispetto degli obblighi NIS2.

Il ruolo di ACN: vigilanza, ispezioni e sanzioni

L’Agenzia per la Cybersicurezza Nazionale (ACN) è l’autorità competente NIS2 per l’Italia, designata dal D.lgs. 138/2024 con poteri di vigilanza, ispezione e sanzione che vanno significativamente oltre quelli previsti dalla NIS1.

ACN può condurre ispezioni in loco e da remoto, richiedere evidenza documentale delle misure di sicurezza implementate, ordinare audit di sicurezza da parte di revisori qualificati indipendenti, e imporre misure correttive con termini vincolanti.

Per i soggetti essenziali, ACN esercita una vigilanza ex ante, ossia verifica la conformità prima che si verifichino incidenti; per i soggetti importanti, la vigilanza è prevalentemente ex post, attivata da incidenti o segnalazioni.

Il regime sanzionatorio introdotto dal D.lgs. 138/2024 è significativamente più severo rispetto alla NIS1. Per i soggetti essenziali, le sanzioni amministrative possono arrivare fino a 10 milioni di euro o al 2% del fatturato mondiale annuo totale (se superiore). Per i soggetti importanti, il massimale è di 7 milioni di euro o l’1,4% del fatturato mondiale.

Le sanzioni si applicano per l’inosservanza delle misure di sicurezza obbligatorie, per la mancata notifica degli incidenti nei termini previsti, per l’ostruzione alle attività di ispezione e audit, e per la mancata implementazione delle misure correttive ordinate da ACN.

È importante notare che la responsabilità personale dei dirigenti è esplicitamente prevista: il D.lgs. 138/2024 consente ad ACN di dichiarare la responsabilità delle persone fisiche che ricoprono funzioni dirigenziali e di imporre temporaneamente il divieto di esercitare funzioni direttive nei casi più gravi.

NIS2 e DORA: coordinamento per il settore finanziario cloud

Le organizzazioni del settore finanziario (banche, assicurazioni, gestori di fondi, infrastrutture di mercato, istituti di pagamento) si trovano nella peculiare condizione di essere soggette contemporaneamente a NIS2 e a DORA (Digital Operational Resilience Act, applicabile dal 17 gennaio 2025).

I due framework condividono obiettivi comuni (resilienza operativa e sicurezza della supply chain ICT) ma hanno requisiti specifici distinti e autorità di supervisione diverse: ACN per NIS2, autorità finanziarie (Banca d’Italia, IVASS, Consob) per DORA.

Il D.lgs. 138/2024 ha previsto un meccanismo di coordinamento tra i due regimi, stabilendo che le entità finanziarie che rispettano i requisiti DORA sono considerate conformi agli obblighi NIS2 equivalenti, il cosiddetto principio di lex specialis.

In pratica, questo significa che per le entità finanziarie DORA è il framework primario di riferimento per la gestione del rischio ICT e della supply chain, mentre NIS2 si applica alle aree non coperte da DORA. Per i consulenti che assistono entità finanziarie, la raccomandazione è di strutturare il programma di adeguamento partendo da DORA, più prescrittivo e dettagliato, e verificare poi la copertura residuale NIS2.

Un’area di particolare rilevanza per il coordinamento NIS2-DORA riguarda i provider cloud. Un CSP che eroga servizi a entità finanziarie soggette a DORA può essere designato come provider ICT critico dalle autorità europee (EBA, ESMA, EIOPA), con conseguente assoggettamento a un regime di sorveglianza diretta.

Questa designazione aggiunge un livello di requisiti al di sopra di quelli NIS2: accesso diretto delle autorità europee ai sistemi del CSP, test di resilienza operativa coordinati, e obblighi di cooperazione rafforzati.

Per le entità finanziarie, verificare lo status DORA del proprio CSP è un elemento essenziale della due diligence sulla supply chain cloud.

Roadmap di adeguamento NIS2 per le infrastrutture cloud

Il calendario di adeguamento NIS2 in Italia è articolato su più scadenze progressive, alcune già decorse e alcune ancora aperte.

La tabella che segue sintetizza le scadenze operative principali per i soggetti NIS2, con particolare riferimento agli adempimenti rilevanti per le infrastrutture cloud. Per ogni scadenza, la mancata conformità espone il soggetto a sanzioni amministrative e all’obbligo di implementare misure correttive ordinate da ACN.

Per le organizzazioni che stanno avviando il percorso di adeguamento in ritardo rispetto alle prime scadenze, la priorità deve essere data agli adempimenti con maggiore impatto sulla riduzione del rischio reale e su quelli più visibili nelle ispezioni ACN: la registrazione sulla piattaforma ACN, la documentazione del processo di gestione del rischio, e l’implementazione delle misure di sicurezza più critiche (MFA, crittografia, gestione della supply chain).

Un adeguamento parziale documentato e in progresso è una posizione molto più difendibile, in caso di ispezione, di un’assenza totale di azione.