Regolamento (UE) 2024/2690

Regolamento di esecuzione (UE) 2024/2690: requisiti tecnici e incidenti significativi in materia di cibersicurezza

Il regolamento attua la direttiva (UE) 2022/2555 (NIS 2) per un insieme di soggetti essenziali e importanti operanti in ambiti digitali e fiduciari. La sua funzione è duplice: da un lato dettaglia le misure tecniche e metodologiche di gestione dei rischi di cibersicurezza; dall’altro individua con maggiore precisione quando un incidente debba essere considerato significativo ai fini della notifica.

Ambito soggettivo e finalità

Il provvedimento riguarda i fornitori di servizi DNS, i registri dei nomi di dominio di primo livello, i fornitori di servizi di cloud computing, i fornitori di servizi di data center, i fornitori di reti di distribuzione dei contenuti, i fornitori di servizi gestiti, i fornitori di servizi di sicurezza gestiti, i fornitori di mercati online, di motori di ricerca online e di piattaforme di servizi di social network, nonché i prestatori di servizi fiduciari. Tali soggetti sono qualificati come "soggetti pertinenti" ai sensi della direttiva NIS 2.

Quadro normativo di riferimento

Il regolamento si fonda in particolare sull’articolo 21, paragrafo 5, primo comma, e sull’articolo 23, paragrafo 11, secondo comma, della direttiva (UE) 2022/2555. Nei considerando la Commissione chiarisce che i requisiti tecnici e metodologici dell’allegato si ispirano a standard europei e internazionali, tra cui ISO/IEC 27001, ISO/IEC 27002, ETSI EN 319401 e CEN/TS 18026:2024. È inoltre richiamato il principio di proporzionalità, con attenzione alle dimensioni del soggetto, alla sua esposizione al rischio, alla probabilità e gravità degli incidenti e al relativo impatto sociale ed economico.

Principi trasversali di attuazione

Il regolamento non impone un modello rigido e uniforme, ma richiede che i soggetti pertinenti adattino le misure al proprio profilo di rischio. Quando un requisito dell’allegato è formulato come applicabile "se opportuno", "se applicabile" o "nella misura del possibile", l’eventuale scelta di non applicarlo deve essere motivata e documentata in modo comprensibile.

Sono previsti anche orientamenti da parte di ENISA o delle autorità nazionali competenti, utili per l’individuazione e la valutazione dei rischi e per l’adozione delle misure, senza però ridurre gli obblighi di individuazione, documentazione e attuazione che restano in capo ai soggetti.

Requisiti di governance e gestione del rischio

L’allegato impone una politica di sicurezza dei sistemi informativi e di rete al livello più alto dell’organizzazione, approvata dagli organi di gestione, coerente con la strategia aziendale e accompagnata da politiche specifiche per tema. La politica deve definire obiettivi, ruoli e responsabilità, risorse, indicatori di monitoraggio e documentazione da conservare, e va riesaminata almeno annualmente o in caso di incidenti significativi o mutamenti rilevanti.

Il quadro di gestione dei rischi deve prevedere una metodologia strutturata per identificare, analizzare, valutare e trattare i rischi, documentando un piano di trattamento e i rischi residui accettati. La valutazione deve considerare anche terzi, single points of failure, intelligence sulle minacce e classificazione delle risorse. È richiesto un monitoraggio della conformità alle politiche, nonché riesami indipendenti da parte di soggetti competenti e imparziali.

Gestione degli incidenti e monitoraggio

Il regolamento richiede una politica di incident management che copra rilevazione, analisi, contenimento, risposta, recupero, documentazione e tempestiva segnalazione. I soggetti devono monitorare e registrare le attività dei sistemi, usare strumenti idonei al rilevamento e mantenere procedure di valutazione e classificazione degli eventi, incluse le verifiche trimestrali di eventuali incidenti ricorrenti.

Sono inoltre richiesti meccanismi semplici per la segnalazione di eventi sospetti da parte di dipendenti, fornitori e clienti, e procedure di risposta articolate in contenimento, eradicazione e recupero, con tracciamento delle attività e delle evidenze. Dopo il ripristino, i soggetti devono svolgere, se opportuno, riesami post-incidente per individuare la causa di fondo e trarre insegnamenti documentati.

Continuità operativa, backup e gestione delle crisi

Il regolamento prescrive un piano di continuità operativa e di ripristino in caso di disastro basato sulla valutazione dei rischi, comprensivo di ruoli, contatti, canali di comunicazione, condizioni di attivazione, priorità di ripristino, risorse necessarie, obiettivi di recupero e ripresa delle attività. È espressamente richiesta un’analisi dell’impatto sulle attività aziendali per definire i requisiti di continuità.

Devono essere predisposti backup sicuri, conservati in luoghi protetti e separati dalla rete principale, con controlli di accesso e test periodici di integrità e ripristino. La ridondanza deve riguardare sistemi, risorse, personale e canali di comunicazione nella misura necessaria. È inoltre richiesto un processo di gestione delle crisi, con flussi di comunicazione verso le autorità competenti e capacità di utilizzare le informazioni ricevute da CSIRT o autorità su incidenti, vulnerabilità e minacce.

Sicurezza della catena di approvvigionamento e acquisizione TIC

Un capitolo centrale riguarda la supply chain. I soggetti devono adottare una politica di sicurezza della catena di approvvigionamento, definire criteri di selezione e appalto dei fornitori, valutare pratiche di cibersicurezza, capacità di soddisfare specifiche di sicurezza, resilienza di prodotti e servizi TIC e possibilità di diversificazione delle fonti.

I contratti con fornitori e fornitori di servizi devono includere, se opportuno, requisiti di cibersicurezza, formazione e competenze del personale del fornitore, verifiche dei precedenti, obblighi di notifica tempestiva degli incidenti, diritto di audit, gestione delle vulnerabilità e regole sul subappalto e sulla cessazione del rapporto. I soggetti devono inoltre mantenere un registro dei fornitori diretti e dei servizi/prodotti TIC forniti.

Sviluppo sicuro, configurazione, patch e vulnerabilità

Il regolamento impone norme di sviluppo sicuro per sistemi e software, applicabili sia allo sviluppo interno sia a quello esternalizzato, che coprano specifiche, progettazione, implementazione e test. Sono richiesti controlli sulla sicurezza degli ambienti di sviluppo, sulla qualità dei dati di test e sulla protezione dei componenti critici per tutto il loro ciclo di vita.

La gestione della configurazione e delle modifiche deve essere documentata, controllata e sottoposta a test prima dell’implementazione. Le patch di sicurezza devono essere applicate entro un termine ragionevole, previa verifica della loro integrità e compatibilità; è tuttavia ammessa una deroga motivata quando i rischi dell’applicazione superano i benefici in termini di cibersicurezza. Il regolamento richiede anche la gestione e divulgazione delle vulnerabilità, con monitoraggio delle fonti informative, scansioni periodiche, interventi tempestivi sulle vulnerabilità critiche e procedura di divulgazione coordinata.

Controllo degli accessi, identità e autenticazione

La disciplina degli accessi è molto dettagliata. I soggetti devono adottare strategie di controllo degli accessi logici e fisici, assegnare e revocare diritti secondo i principi del privilegio minimo e della necessità di sapere, gestire account privilegiati e di amministrazione separatamente, e limitare l’uso dei sistemi di amministrazione alle sole attività di amministrazione.

Deve essere gestito l’intero ciclo di vita delle identità, con identità uniche, tracciabilità e disattivazione tempestiva delle identità non più necessarie. L’autenticazione deve essere adeguata alla classificazione della risorsa e, quando opportuno, deve includere l’autenticazione a più fattori o meccanismi di autenticazione continua, soprattutto per accessi remoti, privilegiati o a dati sensibili.

Gestione delle risorse, crittografia e sicurezza delle persone

L’allegato richiede una classificazione completa delle risorse, un inventario accurato e aggiornato, regole per la gestione corretta delle informazioni e dei supporti rimovibili, nonché procedure per la restituzione o cancellazione delle risorse al termine del rapporto di lavoro. La crittografia deve essere regolata da una politica specifica che disciplini tipo, robustezza, protocolli, algoritmi e gestione delle chiavi, anche con approccio di agilità crittografica.

Sul piano organizzativo, i soggetti devono formare e sensibilizzare dipendenti, membri degli organi di gestione, fornitori e fornitori di servizi, con programmi periodici di awareness e formazione specializzata per i ruoli che richiedono competenze di sicurezza. Sono richiesti anche verifiche dei precedenti personali, regole sulla cessazione del rapporto, processi disciplinari e chiarimento delle responsabilità residue dopo la fine del rapporto di lavoro.

Sicurezza fisica e ambientale

Il regolamento include misure di protezione contro minacce fisiche e ambientali e contro l’accesso fisico non autorizzato. I soggetti devono proteggere i servizi pubblici di sostegno, come energia, telecomunicazioni, acqua, ventilazione e condizionamento, monitorarne il funzionamento e predisporre ridondanze e forniture di emergenza ove necessario.

Sono richiesti perimetri di sicurezza, controlli di ingresso, sicurezza fisica di uffici, sale e impianti, monitoraggio costante dei locali e protezione da eventi naturali o intenzionali. Per i data center e i sistemi sensibili, i considerando richiamano espressamente misure antincendio, rilevamento di allagamenti, protezione da sovratensioni e sistemi continui e ridondanti di raffreddamento.

Criteri di incidente significativo e notifiche

Il regolamento specifica con precisione i casi in cui un incidente è significativo. La soglia generale include una perdita finanziaria diretta superiore a 500.000 EUR o, se inferiore, al 5 % del fatturato annuo precedente; la sottrazione di segreti commerciali; il decesso; danni considerevoli alla salute; accessi malevoli non autorizzati idonei a causare gravi perturbazioni; incidenti ricorrenti; e i casi specifici per categoria di soggetto.

Per i servizi DNS, ad esempio, sono significative la completa indisponibilità oltre 30 minuti, tempi medi di risposta superiori a 10 secondi per oltre un’ora e compromissioni dell’integrità, riservatezza o autenticità dei dati; per i prestatori fiduciari la soglia temporale è più stringente, con indisponibilità totale oltre 20 minuti o indisponibilità superiore a un’ora settimanale, oltre a specifiche soglie di impatto su utenti e parti facenti affidamento sulla certificazione.

La nozione di indisponibilità limitata è definita in modo operativo, includendo anche rallentamenti significativi rispetto ai tempi medi o la perdita di funzionalità. Per gli incidenti finanziari devono essere considerate le perdite dirette effettive o stimate, con esclusione di sanzioni amministrative e costi ordinari di esercizio. Per i servizi fiduciari, inoltre, rileva non solo il numero di utenti ma anche quello delle parti che fanno affidamento sulla certificazione.

Entrata in vigore, abrogazione e applicazione

Il regolamento abroga il regolamento di esecuzione (UE) 2018/151. Entra in vigore il ventesimo giorno successivo alla pubblicazione nella Gazzetta ufficiale dell’Unione europea ed è direttamente applicabile in tutti gli Stati membri, con efficacia obbligatoria in tutti i suoi elementi.