La NIS2 ha introdotto un modello europeo di cybersecurity risk management fondato su obblighi ampi, proporzionati e basati su un approccio multirischio.
L’articolo 21 della Direttiva (UE) 2022/2555 individua dieci ambiti minimi di misure tecniche, operative e organizzative, ma mantiene volutamente un livello di formulazione compatibile con la pluralità dei settori coinvolti, dalle infrastrutture digitali alla sanità, dall’energia ai trasporti, dai servizi finanziari ai fornitori ICT.
Indice degli argomenti
Regolamento UE 2024/2690 come laboratorio tecnico della NIS2
Il Regolamento di esecuzione (UE) 2024/2690 compie un’operazione diversa: prende quella cornice generale e la traduce in requisiti molto più analitici per un gruppo di soggetti digitali caratterizzati da natura transfrontaliera, elevata scalabilità tecnica e forte impatto sistemico.
L’elemento più rilevante è la natura dell’atto. Non si tratta di una linea guida, di un documento di soft law o di un catalogo volontario di buone pratiche, ma di un regolamento di esecuzione direttamente applicabile nei confronti dei soggetti rientranti nel suo ambito. La Commissione europea, sulla base dell’articolo 21, paragrafo 5, della NIS2, era chiamata ad adottare atti di esecuzione per specificare i requisiti tecnici e metodologici delle misure di gestione del rischio per alcune categorie di operatori digitali. Il risultato è un testo che produce un effetto di armonizzazione particolarmente intenso: per questi soggetti, la declinazione tecnica delle misure non è rimessa esclusivamente alla trasposizione nazionale o alla successiva prassi amministrativa, ma è fissata a livello unionale.
Questa scelta risponde a una logica precisa. Cloud provider, data centre provider, CDN, DNS provider, registri TLD, MSP, MSSP, marketplace online, motori di ricerca, piattaforme di social networking e prestatori di servizi fiduciari operano normalmente oltre i confini di un singolo Stato membro. La frammentazione dei requisiti tecnici avrebbe potuto generare asimmetrie regolatorie, moltiplicazione degli adempimenti e incertezza per operatori che erogano servizi a clienti distribuiti in più giurisdizioni. Il regolamento riduce tale rischio fissando una grammatica tecnica comune.
La tesi che merita attenzione è che tale grammatica non resterà confinata ai soggetti formalmente destinatari del regolamento. Proprio perché il testo offre la prima concretizzazione normativa delle misure dell’articolo 21 NIS2, esso sarà inevitabilmente utilizzato come parametro di lettura anche da autorità, auditor, consulenti, imprese clienti e funzioni di procurement per valutare la maturità cyber di soggetti non espressamente compresi nell’ambito del regolamento. In questo senso, il Regolamento (UE) 2024/2690 è il laboratorio tecnico della NIS2: il luogo nel quale una disciplina generale della resilienza diventa un insieme verificabile di policy, ruoli, processi, controlli, evidenze e criteri di valutazione.
Il perimetro digitale del Regolamento UE 2024/2690
Il regolamento si applica a un insieme selezionato di operatori che rappresentano il tessuto connettivo del mercato digitale europeo. Vi rientrano, in particolare, 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 centre, 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.
L’elenco non è casuale. Esso comprende soggetti che, pur svolgendo attività diverse, condividono una caratteristica strutturale: abilitano servizi di terzi, concentrano dipendenze tecnologiche e possono amplificare gli effetti di un incidente ben oltre il proprio perimetro societario. Un cloud provider compromesso può incidere sulla disponibilità dei servizi di centinaia o migliaia di clienti. Un MSP vulnerabile può diventare un vettore di attacco verso l’intera clientela gestita. Un MSSP che perde integrità nei propri strumenti di monitoraggio può trasformare un presidio difensivo in un punto di esposizione sistemica. Un prestatore di servizi fiduciari compromesso può incidere sulla fiducia in identità, firme, sigilli o certificati che sostengono transazioni giuridicamente rilevanti.
La scelta della Commissione mostra quindi una linea di politica regolatoria molto chiara: quando un operatore digitale diventa infrastruttura per altri operatori, la sua sicurezza non è più soltanto un interesse aziendale interno, ma un requisito di stabilità dell’ecosistema. Il regolamento interviene precisamente su questo piano, trasformando la nozione generale di gestione del rischio in un set di aspettative tecniche e metodologiche adeguate a soggetti che operano come nodi di interdipendenza.
Destinatari NIS2 e centralità sistemica degli operatori digitali
La tabella seguente sintetizza le principali categorie di operatori richiamate dal regolamento e la ragione per cui esse assumono un rilievo specifico nella logica NIS2. L’obiettivo non è descrivere esaustivamente l’intero ambito applicativo, ma mostrare il filo conduttore che collega soggetti apparentemente differenti: la capacità di sostenere, abilitare o rendere affidabili servizi digitali altrui.
Categorie di operatori e implicazioni NIS2
| Categoria di operatori | Rilevanza tecnica | Implicazione NIS2 |
|---|---|---|
| Cloud computing, data centre, CDN | Concentrazione di workload, dati, risorse elaborative, connettività e capacità di distribuzione. | Le misure di continuità, ridondanza, logging, segregazione, gestione delle configurazioni e supply chain assumono valore sistemico. |
| MSP e MSSP | Accesso privilegiato agli ambienti dei clienti, strumenti di gestione remota, monitoraggio e risposta agli incidenti. | Il rischio del fornitore diventa rischio diretto per la resilienza del cliente; audit, contratti, incident notification e vulnerability handling diventano centrali. |
| DNS provider e registri TLD | Funzioni di risoluzione e registrazione essenziali per la raggiungibilità dei servizi online. | Disponibilità, integrità e autenticità dei servizi incidono direttamente sulla continuità digitale di interi ecosistemi. |
| Marketplace, motori di ricerca, social network | Piattaforme ad ampia scala, fortemente interconnesse e rilevanti per accesso, ricerca, comunicazione e transazioni. | Incidenti e compromissioni possono avere effetti su utenti, imprese, reputazione e funzionamento dei mercati digitali. |
| Trust service provider | Servizi fiduciari connessi a identità, firme, sigilli, certificati e validazioni elettroniche. | La compromissione tecnica produce una crisi di fiducia giuridica, oltre che informatica. |
Proporzionalità e requisiti tecnici nel Regolamento UE 2024/2690
Il regolamento mantiene la logica risk-based della NIS2, ma la rende più operativa. I considerando richiamano la necessità di tenere conto dell’esposizione al rischio, della criticità dell’entità, delle sue dimensioni e struttura, nonché della probabilità e gravità degli incidenti, incluso il loro impatto sociale ed economico. Questa impostazione evita che i requisiti tecnici siano letti come un catalogo meccanico di controlli da applicare in modo indistinto; al tempo stesso, impedisce che il principio di proporzionalità diventi una formula generica utilizzata per giustificare l’assenza di presidi effettivi.
Il punto di equilibrio è costituito dalla documentazione del rischio. Il regolamento richiede che i soggetti pertinenti stabiliscano e mantengano un framework di gestione del rischio, eseguano e documentino valutazioni dei rischi, definiscano un piano di trattamento e monitorino l’attuazione delle misure. I rischi residui devono essere accettati dagli organi di gestione oppure da soggetti dotati di responsabilità e autorità adeguate, purché sia garantito un flusso informativo verso gli organi di gestione. La proporzionalità, dunque, non vive nell’astrazione: deve essere dimostrata attraverso valutazioni, criteri, priorità, responsabilità e accettazione consapevole del rischio residuo.
Questa impostazione offre una lezione utile anche per le organizzazioni non direttamente destinatarie del regolamento. Nel linguaggio della NIS2, invocare l’adeguatezza o la proporzionalità delle misure richiede una catena probatoria: identificazione degli asset, classificazione della loro criticità, analisi dell’impatto, valutazione di minacce e vulnerabilità, scelta delle misure, verifica dell’efficacia, riesame periodico. Il regolamento fornisce una sequenza pratica di tale ragionamento e, proprio per questo, diventa un riferimento interpretativo per qualsiasi soggetto che voglia dimostrare di aver tradotto l’articolo 21 in un sistema operativo.
L’allegato tecnico della NIS2 e i tredici titoli di controllo
L’allegato al regolamento è il cuore dell’intervento. La guida tecnica ENISA pubblicata nel 2025 evidenzia che l’allegato si articola in tredici titoli, ciascuno dedicato a un insieme di requisiti tecnici e metodologici. La struttura è significativa, perché mostra come la gestione del rischio NIS2 non possa essere ricondotta a una sola funzione aziendale o a un solo dominio tecnologico. Governance, risk management, incident handling, continuità operativa, supply chain, sviluppo sicuro, monitoraggio dell’efficacia, formazione, crittografia, sicurezza del personale, controllo degli accessi, asset management e sicurezza fisica diventano componenti coordinate di un unico sistema.
Il primo titolo riguarda la policy sulla sicurezza delle reti e dei sistemi informativi, che deve esprimere l’approccio complessivo dell’organizzazione, essere coerente con la strategia aziendale, fissare obiettivi di sicurezza, prevedere l’impegno al miglioramento continuo, individuare risorse, ruoli, responsabilità, documentazione e indicatori di monitoraggio. La policy deve inoltre essere approvata dagli organi di gestione e riesaminata almeno annualmente o in occasione di incidenti significativi o cambiamenti rilevanti. Si coglie qui un tratto centrale della NIS2: la sicurezza informatica diventa materia di governo, non semplice procedura tecnica.
Il secondo titolo riguarda la gestione del rischio e contiene uno dei passaggi più rilevanti dell’intero regolamento. I soggetti pertinenti devono identificare, analizzare, valutare e trattare i rischi secondo una metodologia definita, stabilire il livello di tolleranza al rischio, mantenere criteri di rischio, considerare un approccio multirischio, includere i rischi relativi ai terzi e ai single point of failure, utilizzare threat intelligence e vulnerabilità, individuare opzioni di trattamento e documentare le ragioni dell’accettazione dei rischi residui. Quando selezionano e prioritizzano le misure, devono considerare i risultati del risk assessment, le valutazioni di efficacia, il rapporto costi-benefici, la classificazione degli asset e la business impact analysis.
Il riferimento alla business impact analysis è particolarmente importante. Il regolamento chiarisce che la continuità operativa non può essere progettata senza comprendere l’impatto delle interruzioni gravi sulle attività dell’organizzazione. Ne deriva che, anche nel quadro NIS2, la BIA non è un esercizio meramente metodologico, ma uno strumento che consente di collegare servizi, asset, obiettivi di ripristino, requisiti di disponibilità e priorità di trattamento del rischio. Per cloud provider, MSP e MSSP, tale analisi assume un rilievo ulteriore, poiché l’impatto della propria indisponibilità si trasferisce sui clienti e sui servizi che questi erogano a valle.
Incidenti significativi e gestione operativa nella NIS2
Il regolamento dedica particolare attenzione alla gestione degli incidenti, prevedendo una policy che definisca ruoli, responsabilità e procedure per rilevazione, analisi, contenimento, risposta, ripristino, documentazione e reporting. La policy deve essere coerente con il piano di continuità operativa e disaster recovery, includere un sistema di categorizzazione degli incidenti, piani di comunicazione, meccanismi di escalation, assegnazione di ruoli e documenti operativi quali manuali di risposta, contatti e template.
L’atto mostra una progressione molto concreta. Prima vengono definiti monitoraggio e logging, con procedure e strumenti per rilevare eventi potenzialmente rilevanti; poi viene previsto un meccanismo semplice per consentire a dipendenti, fornitori e clienti di segnalare eventi sospetti; successivamente viene disciplinata la valutazione e classificazione degli eventi; infine vengono regolati response, contenimento, eradicazione, recovery e post-incident review. Tale sequenza consente di superare una criticità ricorrente nei modelli di compliance: la separazione tra procedure di notifica e capacità effettiva di rilevare, qualificare e documentare l’evento.
Il regolamento interviene anche sulla nozione di incidente significativo. In termini generali, un incidente è significativo quando, ad esempio, ha causato o può causare una perdita finanziaria diretta superiore a 500.000 euro o al 5% del fatturato annuo totale dell’esercizio precedente, se inferiore; quando ha causato o può causare l’esfiltrazione di segreti commerciali; quando ha causato o può causare il decesso di una persona fisica o danni considerevoli alla salute; quando si verifica un accesso non autorizzato, riuscito e presumibilmente malevolo, capace di causare una grave interruzione operativa; o quando ricorrono i criteri relativi agli incidenti ricorrenti o quelli specificamente previsti per le diverse categorie di soggetti.
Questo profilo è rilevante perché il regolamento non si limita a descrivere le misure preventive, ma collega la gestione del rischio alla qualificazione regolatoria dell’evento. Le organizzazioni devono quindi costruire procedure in grado di integrare dati tecnici, impatti economici, impatti operativi, effetti su clienti, disponibilità dei servizi, segreti commerciali e potenziali conseguenze su salute e sicurezza. Per gli operatori digitali, l’incidente significativo non è più soltanto un fatto tecnico da gestire in SOC, ma un evento da qualificare giuridicamente attraverso criteri predefiniti e documentabili.
Business continuity e BIA nel Regolamento UE 2024/2690
Uno degli aspetti più maturi del regolamento è il collegamento tra gestione del rischio, business continuity e business impact analysis. I soggetti pertinenti devono predisporre e mantenere un piano di continuità operativa e disaster recovery applicabile in caso di incidente. Il piano deve comprendere, tra gli altri elementi, scopo, ruoli, responsabilità, contatti, canali di comunicazione, condizioni di attivazione e disattivazione, ordine di ripristino delle operazioni, piani di recupero per attività specifiche, obiettivi di recupero, risorse necessarie, backup, ridondanze e misure temporanee per il ripristino.
La richiesta di effettuare una BIA per valutare l’impatto potenziale di gravi interruzioni sulle operazioni aziendali consente di ancorare la continuità a parametri concreti. In assenza di tale analisi, gli obiettivi di recovery rischiano di essere scelti per approssimazione, per prassi tecnica o per disponibilità di mercato, anziché in funzione dell’impatto reale sui servizi. Il regolamento costringe quindi l’organizzazione a stabilire un rapporto esplicito tra attività, asset, impatto, tempi di ripristino, requisiti di disponibilità e misure tecniche.
Per cloud provider, data centre, CDN, MSP e MSSP, questo passaggio ha conseguenze particolarmente rilevanti. Le loro scelte di ridondanza, backup, disponibilità delle risorse, personale critico, comunicazioni di crisi e test di recovery incidono direttamente sulla resilienza dei clienti. Il regolamento richiede inoltre test regolari del ripristino dei backup e delle ridondanze, con documentazione dei risultati e azioni correttive ove necessario. La continuità operativa, in questa prospettiva, cessa di essere un documento separato dal sistema di sicurezza e diventa una misura di gestione del rischio cyber pienamente integrata.
Supply chain e procurement cyber nella logica NIS2
Il capitolo dedicato alla supply chain è tra i più importanti dell’intero allegato. I soggetti pertinenti devono stabilire, implementare e applicare una policy di sicurezza della catena di fornitura che governi i rapporti con fornitori diretti e prestatori di servizi, con l’obiettivo di mitigare i rischi identificati per la sicurezza delle reti e dei sistemi informativi. La policy deve individuare il ruolo dell’organizzazione nella catena di fornitura e comunicarlo ai fornitori e service provider diretti.
Il regolamento richiede criteri di selezione e contrattualizzazione dei fornitori che considerino le pratiche di cybersecurity, incluse le procedure di sviluppo sicuro, la capacità di soddisfare specifiche di sicurezza, la qualità complessiva e la resilienza di prodotti e servizi ICT, le misure di gestione del rischio incorporate in tali prodotti e servizi, i rischi e la classificazione degli stessi, nonché la capacità di diversificare le fonti di approvvigionamento e limitare il vendor lock-in, ove applicabile.
Il contratto diventa il luogo operativo della NIS2. Il regolamento prevede che, sulla base della policy di supply chain e del risk assessment, i contratti con fornitori e service provider specifichino, ove appropriato anche tramite SLA, requisiti di cybersecurity, requisiti di consapevolezza, competenze e formazione, verifiche sul personale, obblighi di notifica senza indebito ritardo degli incidenti che presentano un rischio per i sistemi dell’entità, diritti di audit o ricezione di audit report, obblighi di gestione delle vulnerabilità, requisiti sul subappalto e obblighi alla cessazione del contratto, inclusi recupero e cancellazione delle informazioni.
Per le imprese clienti di cloud provider, MSP e MSSP, tale disciplina offre un riferimento molto concreto. La verifica del fornitore non può limitarsi a un questionario generico o a una certificazione non contestualizzata. Occorre comprendere quali servizi sono supportati, quali asset sono coinvolti, quale livello di accesso possiede il fornitore, quali subfornitori intervengono, quali procedure di notifica sono previste, quali audit sono disponibili, come vengono gestite le vulnerabilità e quali clausole regolano la fine del rapporto. Il regolamento fornisce un elenco di contenuti contrattuali che diventerà verosimilmente uno standard di mercato anche oltre il suo ambito formale.
Sviluppo sicuro e vulnerability handling nel quadro NIS2
Il titolo dedicato alla sicurezza nell’acquisizione, sviluppo e manutenzione dei sistemi informativi è il punto di maggiore contatto tra NIS2, supply chain e regolazione del prodotto digitale. Il regolamento richiede processi relativi all’acquisizione di prodotti e servizi ICT, secure development life cycle, configurazioni sicure, change management, riparazioni e manutenzione, security testing, gestione delle patch, network segmentation, protezione contro software malevolo o non autorizzato e vulnerability handling.
Questi requisiti assumono una rilevanza particolare nel contesto dell’evoluzione normativa europea. Da un lato, la NIS2 impone agli operatori di considerare la qualità dei prodotti e delle pratiche di cybersecurity dei fornitori, incluse le procedure di sviluppo sicuro. Dall’altro, il Cyber Resilience Act introduce requisiti orizzontali di cybersicurezza per i prodotti con elementi digitali, imponendo obblighi di gestione delle vulnerabilità e sicurezza by design ai fabbricanti. Il regolamento 2024/2690 si colloca tra questi due piani: mostra come l’organizzazione utilizzatrice o erogatrice di servizi debba incorporare la sicurezza del prodotto e del ciclo di vita software nei propri processi di risk management.
La parte relativa al vulnerability handling è particolarmente significativa. Il regolamento richiede canali per monitorare informazioni sulle vulnerabilità, procedure per divulgarle secondo la policy nazionale di coordinated vulnerability disclosure applicabile e, quando l’impatto potenziale lo giustifica, piani di mitigazione; negli altri casi, l’organizzazione deve documentare e motivare perché una vulnerabilità non richieda remediation. Questa impostazione sposta il focus dalla mera conoscenza della vulnerabilità alla tracciabilità della decisione. Anche decidere di non intervenire diventa una scelta da giustificare.
Asset management e access control come prova di conformità
Nella logica del regolamento, l’asset management non è un inventario tecnico privo di funzione regolatoria. I soggetti pertinenti devono definire livelli di classificazione degli asset, associare ogni asset a un livello in base ai requisiti di riservatezza, integrità, autenticità e disponibilità, e allineare i requisiti di disponibilità agli obiettivi di erogazione e ripristino contenuti nei piani di continuità operativa e disaster recovery. Devono inoltre mantenere un inventario completo, accurato, aggiornato e coerente, tracciando le modifiche e includendo almeno l’elenco delle operazioni e dei servizi e quello dei sistemi informativi e degli asset associati che li supportano.
Questo passaggio merita particolare attenzione perché consente di leggere l’intero regolamento come un sistema di collegamento tra servizi, asset, rischio, continuità e controlli. Senza un inventario aggiornato e senza classificazione degli asset, non è possibile stabilire la forza dell’autenticazione richiesta, il livello di crittografia appropriato, la priorità di ripristino, la necessità di logging, la segmentazione della rete o l’ambito del security testing. L’asset inventory diventa quindi la base probatoria della conformità: dimostra quali sistemi sostengono quali servizi, quale criticità presentano e quali misure sono state associate a tale criticità.
Lo stesso vale per il controllo degli accessi. Il regolamento richiede policy di access control, gestione dei diritti, privilegi amministrativi, sistemi di amministrazione separati, lifecycle delle identità, autenticazione sicura e multi-factor authentication o meccanismi di autenticazione continua ove appropriati. La forza dell’autenticazione deve essere coerente con la classificazione dell’asset. Anche qui emerge la struttura sistemica del regolamento: non esiste un controllo isolato, poiché la misura di accesso dipende dalla classificazione, la classificazione dipende da rischio e impatto, e rischio e impatto dipendono dai servizi supportati.
Il Regolamento UE 2024/2690 come benchmark oltre l’ambito formale
Il regolamento è giuridicamente vincolante per le categorie di soggetti che rientrano nel suo ambito. Tuttavia, la sua influenza sarà più ampia per almeno quattro ragioni.
La prima ragione è interpretativa. Il regolamento specifica requisiti tecnici e metodologici dell’articolo 21 NIS2. Ogni volta che un’organizzazione, un’autorità o un auditor dovranno comprendere cosa significhi adottare misure adeguate e proporzionate, il regolamento costituirà un riferimento naturale, anche quando non applicabile in via diretta. Esso rappresenta la prima concretizzazione unionale della norma generale.
La seconda ragione è contrattuale. Le organizzazioni soggette a NIS2 tenderanno a trasferire ai propri fornitori requisiti ispirati al regolamento, soprattutto quando acquistano servizi cloud, managed services, servizi di sicurezza gestita, piattaforme digitali o servizi fiduciari. Le clausole su incident notification, audit, vulnerability handling, subappalto, security testing, backup, continuità e termination saranno sempre più spesso modellate sui requisiti dell’allegato.
La terza ragione è probatoria. ENISA, nella propria guida tecnica, chiarisce che le indicazioni possono risultare utili anche per altri attori pubblici o privati interessati a migliorare la propria cybersecurity. Tale affermazione non trasforma il regolamento in un obbligo generalizzato, ma rafforza il suo valore come riferimento di buona attuazione. Le organizzazioni potranno utilizzarlo per costruire evidenze, gap analysis e piani di trattamento coerenti con un modello riconosciuto a livello europeo.
La quarta ragione è di mercato. Cloud provider, MSP, MSSP e trust service provider sono spesso fornitori di soggetti essenziali e importanti. Anche quando il cliente non sia formalmente destinatario del regolamento, la sua capacità di dimostrare controllo sui fornitori dipenderà sempre più dalla qualità delle misure adottate da tali operatori. Il benchmark tenderà quindi a diffondersi lungo la supply chain, trasformandosi in standard di fatto nelle due diligence e negli audit di secondo livello.
Evidenze operative per applicare il Regolamento UE 2024/2690
La seguente mappa sintetica evidenzia come alcuni blocchi del regolamento possano essere tradotti in evidenze operative. La tabella non sostituisce l’analisi puntuale dell’allegato, ma mostra la direzione applicativa del regolamento: ogni requisito deve lasciare traccia in un documento, in un processo, in un controllo tecnico o in una decisione di governance.
Dalla norma europea alle evidenze aziendali
| Blocco regolatorio | Domanda operativa | Evidenze tipiche |
|---|---|---|
| Policy e governance | Chi approva la strategia di sicurezza e come viene monitorata? | Policy NIS, verbali di approvazione, reporting al management, RACI, indicatori di maturità. |
| Risk management | Quali rischi sono stati identificati, trattati o accettati? | Metodologia, risk assessment, risk treatment plan, accettazione del rischio residuo, criteri di rischio. |
| Business continuity e BIA | Quali servizi devono essere ripristinati prima e con quali obiettivi? | BIA, BCP, DRP, RTO/RPO, test di recovery, evidenze sui backup e sulle ridondanze. |
| Supply chain | Quali garanzie impongono i contratti ai fornitori e subfornitori? | Vendor assessment, clausole di sicurezza, SLA, audit report, obblighi di notifica, gestione vulnerabilità. |
| Incident handling | Come vengono rilevati, classificati e notificati gli incidenti? | Procedure IR, logging, playbook, escalation matrix, template di notifica, post-incident review. |
| Asset management e access control | Quali asset supportano quali servizi e con quali diritti di accesso? | CMDB, inventario asset-servizi, asset classification, IAM review, MFA, privileged access management. |
Modello italiano NIS2 e confronto con il Regolamento UE 2024/2690
Nell’ordinamento italiano, il D.Lgs. 138/2024 recepisce la NIS2 e attribuisce all’Agenzia per la Cybersicurezza Nazionale un ruolo centrale nell’attuazione, supervisione e specificazione operativa degli obblighi. L’articolo 24 del decreto riprende la logica delle misure tecniche, operative e organizzative adeguate e proporzionate, fondate su un approccio multirischio, e individua ambiti coerenti con l’articolo 21 della direttiva. Il regolamento 2024/2690, pur non sostituendo le determinazioni nazionali applicabili ai soggetti italiani, offre un termine di confronto particolarmente utile per interpretare la qualità delle misure richieste.
Per i soggetti italiani che operano come cloud provider, MSP, MSSP, data centre provider, CDN o prestatori di servizi fiduciari, il regolamento deve essere letto come parte integrante del quadro applicabile. Per le altre organizzazioni soggette al D.Lgs. 138/2024, esso può svolgere una funzione diversa ma non meno importante: rappresentare un modello di maturità tecnica rispetto al quale valutare la propria implementazione, soprattutto nei rapporti con fornitori digitali critici. In un audit NIS2, in una due diligence su un fornitore cloud o in una verifica su un managed service provider, il contenuto del regolamento potrà essere utilizzato come griglia per formulare domande più precise e richiedere evidenze meno generiche.
Il raccordo con il contesto italiano diventa particolarmente rilevante nei progetti di mappatura dei servizi, classificazione degli asset, definizione delle misure di sicurezza, gestione dei fornitori e costruzione del registro delle evidenze. Il regolamento mostra che la conformità non può ridursi a un elenco statico di controlli, ma richiede la capacità di dimostrare il collegamento tra servizio, rischio, asset, misura, responsabilità, evidenza e riesame.
Cloud, MSP, MSSP e trust service provider davanti alla NIS2
Cloud provider
Per i cloud provider, il regolamento impone una lettura integrata di sicurezza, continuità, gestione delle configurazioni, backup, logging, incident handling, crittografia, asset management e sicurezza fisica. La dimensione cloud accentua la rilevanza della segregazione, della disponibilità delle risorse, della protezione dei dati in transito e a riposo, della gestione degli accessi privilegiati e della trasparenza verso i clienti in caso di incidente o vulnerabilità.
MSP
Per gli MSP, il punto decisivo è il privilegio operativo. Un managed service provider spesso dispone di credenziali, strumenti di amministrazione, accessi remoti e capacità di intervento sugli ambienti dei clienti. I requisiti su access control, amministrazione dei sistemi, logging, autenticazione, segregazione degli ambienti, personale, formazione e contratti diventano quindi essenziali. La sicurezza dell’MSP è parte della sicurezza del cliente, anche quando il cliente non lo percepisce immediatamente.
MSSP
Per gli MSSP, la questione assume un ulteriore livello di delicatezza. Il fornitore di sicurezza gestita opera con strumenti che monitorano, raccolgono log, identificano eventi, gestiscono allarmi e, in alcuni casi, intervengono nella risposta agli incidenti. Una carenza di integrità nei sistemi dell’MSSP può compromettere la capacità stessa del cliente di rilevare o rispondere agli incidenti. Il regolamento impone quindi di governare con particolare attenzione segregazione, logging, privilegi, incident communication, continuità e sicurezza del personale.
Trust service provider
Per i prestatori di servizi fiduciari, il regolamento si inserisce in un ecosistema già caratterizzato da un forte contenuto regolatorio, connesso al regolamento eIDAS e alla funzione di fiducia giuridica dei servizi erogati. La sicurezza tecnica incide qui direttamente sulla validità, affidabilità e riconoscibilità di processi che sostengono transazioni elettroniche, firme, sigilli, certificati e identità. L’atto di esecuzione rafforza quindi il collegamento tra fiducia digitale e gestione documentata del rischio cyber.
Il Regolamento UE 2024/2690 come manuale normativo della NIS2
Il Regolamento di esecuzione (UE) 2024/2690 segna un passaggio decisivo nell’evoluzione della NIS2. La direttiva aveva definito il perimetro politico e giuridico della resilienza cyber europea, individuando soggetti, obblighi, governance, misure e incident reporting. Il regolamento mostra come tali obblighi possano essere trasformati in requisiti tecnici e metodologici verificabili. In questo senso, rappresenta il primo manuale normativo della NIS2.
La sua importanza supera il perimetro formale dei destinatari. Per gli operatori digitali direttamente soggetti, costituisce un obbligo da implementare. Per le organizzazioni clienti, diventa una base per la due diligence e la contrattualistica. Per le autorità e gli auditor, offre un riferimento concreto per valutare maturità ed effettività. Per le imprese non ricomprese nel suo ambito, rappresenta un benchmark per comprendere come la cybersecurity risk management della NIS2 possa essere tradotta in processi, controlli ed evidenze.
Il messaggio regolatorio è molto chiaro: la cybersecurity non si dimostra con dichiarazioni generiche di adeguatezza, ma attraverso un sistema integrato di governance, rischio, continuità, supply chain, sviluppo sicuro, vulnerabilità, asset management, accessi, formazione, logging, test e riesame. Il regolamento 2024/2690 non esaurisce la NIS2, ma ne rende visibile la traiettoria. La compliance cyber europea si sta spostando verso una dimensione sempre più tecnica, documentata e auditabile, nella quale la domanda centrale non sarà soltanto se un’organizzazione abbia adottato misure di sicurezza, ma se sia in grado di spiegare perché quelle misure siano proporzionate, come siano state implementate, chi le governi, come vengano misurate e quali evidenze ne dimostrino l’effettività.
Riferimenti normativi e tecnici sul Regolamento UE 2024/2690
- Regolamento di esecuzione (UE) 2024/2690 della Commissione, del 17 ottobre 2024, recante norme per l’applicazione della Direttiva (UE) 2022/2555 per quanto riguarda i requisiti tecnici e metodologici delle misure di gestione dei rischi di cibersicurezza e la specificazione dei casi in cui un incidente è considerato significativo per talune categorie di soggetti pertinenti.
- Direttiva (UE) 2022/2555 del Parlamento europeo e del Consiglio, del 14 dicembre 2022, relativa a misure per un livello comune elevato di cybersicurezza nell’Unione, in particolare articoli 21 e 23.
- D.Lgs. 4 settembre 2024, n. 138, di recepimento della Direttiva (UE) 2022/2555 nell’ordinamento italiano, con particolare riferimento agli obblighi in materia di misure di gestione dei rischi per la sicurezza informatica.
- ENISA, Technical implementation guidance on cybersecurity risk-management measures, June 2025, version 1.0, documento di supporto all’attuazione del Regolamento di esecuzione (UE) 2024/2690.
- Standard e specifiche richiamati nel contesto del regolamento: ISO/IEC 27001, ISO/IEC 27002, ETSI EN 319 401, CEN/TS 18026:2024, quali riferimenti europei e internazionali pertinenti per la sicurezza delle reti e dei sistemi informativi.
Fonti online consultate: EUR-Lex – Regolamento di esecuzione (UE) 2024/2690; EUR-Lex – Direttiva (UE) 2022/2555; ENISA – NIS2 Technical Implementation Guidance
Partecipa alla community