NIS2 infrastrutture digitali: la regola dei 30 minuti che nessuno ha configurato

Una piattaforma RMM si guasta alle 09:14 di un martedì. Il fornitore la ripristina alle 09:48. Trentaquattro minuti, qualche cliente irritato, una nota di credito, chiuso.

Solo che non è chiuso. Ai sensi del Regolamento di esecuzione (UE) 2024/2690, quel disservizio è un incidente significativo, e l'orologio delle 24 ore per il preallarme è partito nel momento in cui il fornitore ne è venuto a conoscenza.

Questa è la parte della compliance NIS2 per le infrastrutture digitali che i consulenti continuano a sottovalutare. Per i tipi di soggetti coperti dal Regolamento 2024/2690, il linguaggio vago dell'articolo 21 è già stato sostituito da numeri. Minuti. Percentuali. Il vostro cliente non può discutere su cosa significhi "adeguate e proporzionate" quando il regolamento gli ha detto esattamente cosa significa.

Le infrastrutture digitali sono l'unico settore NIS2 che non negozia l'articolo 21

NIS2 è una direttiva. Ha richiesto 27 leggi nazionali di recepimento, arrivate in ritardo, in modo disomogeneo e in alcuni casi ancora assenti.

Il Regolamento 2024/2690 è un regolamento. È stato pubblicato in Gazzetta Ufficiale il 18 ottobre 2024 e si applica direttamente in ogni Stato membro. Nessun recepimento. Nessuno strato interpretativo nazionale. Dove fissa un requisito, quel requisito si applica — indipendentemente da ciò che la legge NIS2 locale dice o non dice.

Il suo allegato scompone l'articolo 21(2) in 13 gruppi di requisiti con sotto-requisiti numerati. Il solo punto 11 divide il controllo degli accessi in gestione dei diritti di accesso, account privilegiati, sistemi di amministrazione, identificazione univoca, autenticazione e autenticazione a più fattori. I redattori si sono appoggiati a ISO/IEC 27001, ISO/IEC 27002, ETSI EN 319 401 e CEN/TS 18026:2024, quindi un SGSI esistente vi porta a metà strada — ma la mappatura non è uno a uno, ed è nelle lacune che atterrano gli audit.

Articolo 21 — 10 Misure di Cybersicurezza NIS2
🛡️
Articolo 21
10 Misure di Cybersicurezza
📊
Governance & Strategia
1Analisi dei rischi & politiche di sicurezza delle informazioni
6Valutazione dell'efficacia delle misure di sicurezza
🚨
Incidenti & Continuità
2Gestione degli incidenti & notifica
3Continuità operativa & ripristino di emergenza
🔗
Catena di Fornitura & Sistemi
4Sicurezza della catena di fornitura
5Sicurezza nello sviluppo di sistemi di rete e informativi
🔐
Controlli Tecnici
8Crittografia & cifratura
10Autenticazione a più fattori & comunicazioni sicure
👥
Persone & Risorse
7Igiene informatica & formazione
9Sicurezza HR & controllo degli accessi

Se il vostro cliente non rientra tra i tipi di soggetti coperti, la cosa conta comunque. Il Regolamento 2024/2690 è la dichiarazione ufficiale più granulare di cosa la Commissione intenda per conformità all'articolo 21. Le autorità di vigilanza che valutano un cliente dell'energia o della sanità lo leggeranno. Dovreste farlo anche voi. Vedi la nostra analisi delle dieci misure dell'articolo 21 per la visione a livello di direttiva.

Undici tipi di soggetti sono coperti, e le soglie dimensionali non ne salvano la maggior parte

Il regolamento nomina i suoi destinatari all'articolo 1:

• Fornitori di servizi DNS
• Registri dei nomi di dominio di primo livello
• Fornitori di servizi di cloud computing
• Fornitori di servizi di data center
• Fornitori di reti di distribuzione dei contenuti
• Fornitori di servizi gestiti
• Fornitori di servizi di sicurezza gestiti
• Fornitori di mercati online
• Fornitori di motori di ricerca online
• Fornitori di piattaforme di servizi di social network
• Prestatori di servizi fiduciari

Qui i consulenti sbagliano due cose.

Primo, i fornitori di servizi DNS, i registri dei nomi di dominio di primo livello e i prestatori di servizi fiduciari rientrano nell'ambito ai sensi dell'articolo 2(2) NIS2 a prescindere da organico o fatturato. Un operatore DNS di quattro persone è dentro. La regola dimensionale che salva le piccole imprese nella maggior parte dei settori non si applica a loro.

Secondo, "fornitore di servizi gestiti" è definito in modo ampio all'articolo 6(39) della direttiva: un soggetto che fornisce servizi relativi all'installazione, alla gestione, al funzionamento o alla manutenzione di prodotti TIC, reti, infrastrutture, applicazioni o altri sistemi informatici e di rete, presso la sede del cliente o da remoto. È gran parte del mercato MSP, più un buon numero di aziende che si presentano come "supporto IT" o "partner di sviluppo" senza mai usare la parola gestito. Se leggete questo come consulenti, verificate se descrive voi prima di verificare se descrive i vostri clienti — la nostra guida NIS2 per gli MSP tratta il doppio obbligo in dettaglio.

La giurisdizione è la trappola successiva. I soggetti delle infrastrutture digitali sono generalmente vigilati dove si trova il loro stabilimento principale, non dove si trovano i loro clienti. Se non siete certi di quale autorità vigili sul vostro cliente, leggete il nostro articolo sull'articolo 26 prima di dare qualcosa per scontato.

Le soglie di significatività sono orologi, non valutazioni discrezionali

È qui che il Regolamento 2024/2690 si discosta di più da come la maggior parte delle organizzazioni gestisce oggi il triage degli incidenti.

L'articolo 3 fissa criteri orizzontali validi per ogni soggetto coperto. Un incidente è significativo se ha causato o può causare una perdita finanziaria diretta superiore a 500.000 EUR o al 5% del fatturato annuo totale del soggetto nell'esercizio precedente, a seconda di quale importo sia inferiore. Anche se può causare l'esfiltrazione di segreti commerciali. Anche se si è verificato un accesso riuscito, presumibilmente malevolo e non autorizzato, in grado di causare una grave perturbazione operativa — e il considerando 39 chiarisce che un attaccante che si posiziona per una perturbazione futura conta, anche senza perturbazione in atto.

Poi arrivano i criteri specifici per soggetto:

Fornitori cloud (articolo 7) — indisponibilità totale per più di 30 minuti. Disponibilità limitata per più di un'ora che riguardi oltre il 5% degli utenti nell'Unione o oltre un milione di utenti nell'Unione, a seconda di quale numero sia inferiore. Qualsiasi compromissione di integrità, riservatezza o autenticità dei dati derivante da un'azione presumibilmente malevola, senza alcuna soglia minima di utenti.

Fornitori di data center (articolo 8) — indisponibilità totale di un servizio di data center, punto, senza qualificazione temporale. Disponibilità limitata per più di un'ora. Compromissione dei dati da azione presumibilmente malevola. E accesso fisico compromesso alla struttura: un episodio di tailgating al varco diventa quindi un evento da notificare.

MSP e MSSP (articolo 10) — indisponibilità totale per più di 30 minuti. Disponibilità limitata per più di un'ora che riguardi oltre il 5% o un milione di utenti nell'Unione, a seconda di quale numero sia inferiore. Compromissione dei dati da azione presumibilmente malevola.

Attenzione a come si contano gli utenti. Ai sensi dell'articolo 3(3), si contano i clienti sotto contratto e le persone fisiche e giuridiche associate ai clienti business che utilizzano il servizio. Un MSP con 60 aziende clienti non conta 60 utenti. Conta ogni dipendente di quelle 60 aziende che tocca il servizio gestito.

L'articolo 4 chiude l'ultima falla: gli incidenti ricorrenti che singolarmente restano sotto soglia vengono aggregati e trattati come un unico incidente significativo quando complessivamente soddisfano i criteri in una finestra di sei mesi. Tre disservizi distinti di 20 minuti con la stessa causa radice non sono tre non-eventi.

Cronologia delle Notifiche di Incidenti NIS2
24h
⚡
Allerta Precoce
Notificare all'autorità competente (CSIRT/ANC) entro 24 ore dalla conoscenza di un incidente significativo.
Fase 1
72h
📋
Notifica dell'Incidente
Presentare una notifica dettagliata entro 72 ore con una valutazione iniziale della gravità, dell'impatto e degli indicatori di compromissione.
Fase 2
1mo
📊
Rapporto Finale
Consegnare un rapporto finale completo entro un mese che copra la causa principale, le misure adottate e l'impatto transfrontaliero.
Fase 3
24h
⚡
Allerta Precoce
Notificare all'autorità competente (CSIRT/ANC) entro 24 ore dalla conoscenza di un incidente significativo.
72h
📋
Notifica dell'Incidente
Presentare una notifica dettagliata entro 72 ore con una valutazione iniziale della gravità, dell'impatto e degli indicatori di compromissione.
1mo
📊
Rapporto Finale
Consegnare un rapporto finale completo entro un mese che copra la causa principale, le misure adottate e l'impatto transfrontaliero.

I termini di notifica in sé non sono cambiati — 24 ore per il preallarme, 72 ore per la notifica dell'incidente, un mese per la relazione finale. Ciò che è cambiato è quanto spesso l'orologio parte. Trattiamo la meccanica in termini di notifica degli incidenti NIS2.

La manutenzione programmata è esente, ma solo se potete provare che era programmata

L'articolo 3(2) esclude le interruzioni programmate e le conseguenze previste delle operazioni di manutenzione programmata. Il considerando 33 estende l'esclusione all'indisponibilità basata su accordi contrattuali predefiniti.

Quell'esenzione vale quanto valgono i vostri registri. Il considerando 34 stabilisce che la durata di un incidente di disponibilità decorre dalla perturbazione della corretta erogazione del servizio fino al ripristino — e quando il soggetto non riesce a determinare quando è iniziata la perturbazione, la durata si misura dal momento in cui è stata rilevata, o dal momento in cui è stata registrata nei log, quale dei due sia precedente.

Rileggetelo dalla sedia di un auditor. Un logging scadente non vi concede il beneficio del dubbio. Produce l'orario di inizio difendibile più precoce. Un soggetto con monitoraggio debole dichiarerà sistematicamente incidenti più lunghi di uno con buon monitoraggio, a parità esatta di disservizio.

Il controllo pratico qui non è quindi un documento di policy. È un calendario di manutenzione con marca temporale, approvato in anticipo e conservato — più un monitoraggio in grado di stabilire l'orario di inizio al minuto.

"Non applicabile" è ammesso, ma va messo per iscritto

Il considerando 6 lascia ai soggetti la possibilità di concludere che uno specifico requisito dell'allegato non è adeguato, non è applicabile o non è fattibile per loro. Il considerando 5 consente misure compensative dove la dimensione rende un requisito impraticabile — una micro-entità che non può separare compiti in conflitto può sostituirla con una vigilanza mirata del management o con monitoraggio e logging rafforzati.

Entrambi portano una condizione: il soggetto deve documentare il proprio ragionamento in modo comprensibile.

Questo è il deliverable di maggior valore che un consulente possa produrre questo trimestre per un cliente delle infrastrutture digitali. Non l'ennesimo template di policy. Una dichiarazione di applicabilità scritta, datata e approvata dal management che percorra i 13 punti dell'allegato e registri quali sotto-requisiti sono implementati, quali no e perché — con la misura compensativa indicata dove ne viene usata una.

Le autorità non si aspettano che un MSSP di dodici persone assomigli a un hyperscaler. Si aspettano però che il soggetto ci abbia pensato su carta prima dell'audit, non durante. La nostra checklist delle evidenze per gli audit di vigilanza copre cos'altro chiedono i regolatori.

Cosa fare nei prossimi 30 giorni

1. Classificare. Stabilite se ogni cliente — e il vostro stesso studio — rientra in uno degli undici tipi di soggetti dell'articolo 1. Applicate le esenzioni dell'articolo 2(2) prima delle soglie di organico.
2. Ricalcolare il numero di utenti. Ricostruite la cifra degli utenti nell'Unione per ogni servizio coperto, inclusi gli utenti finali presso i clienti business. La maggior parte dei soggetti lavora con un numero inferiore di un ordine di grandezza.
3. Reimpostare le regole di triage. Portate le soglie dei 30 minuti e dell'ora nella piattaforma di monitoraggio come condizioni di allerta, non come criteri di revisione a posteriori. Se deve essere una persona ad accorgersi del superamento, se ne accorgerà tardi.
4. Sistemare il registro della manutenzione. Finestre programmate approvate e marcate temporalmente in anticipo, conservate almeno per il periodo di vigilanza.
5. Scrivere la dichiarazione di applicabilità. Tredici punti dell'allegato, sotto-requisito per sotto-requisito, con motivazione per ogni esclusione.

I soggetti coperti dal Regolamento 2024/2690 stanno a monte della compliance di tutti gli altri. Quando un MSP o un fornitore cloud non supera un audit, il rilievo scende lungo la catena di fornitura fino a ogni contratto cliente che lo ha indicato come fornitore critico — l'altra ragione per sistemare la cosa ora e non dopo la prima decisione sanzionatoria.

Se volete un quadro strutturato di dove si trova un cliente rispetto all'articolo 21 e al regolamento di esecuzione prima di impegnarvi su un piano di rimedio, eseguite un quick scan NIS2. Richiede pochi minuti e vi dà un punto di partenza difendibile per la conversazione.