NIS2 comunicazioni sicure: la metà dell'articolo 21(2)(j) che la maggior parte dei programmi salta

Tra febbraio e giugno 2026, Sophos ha seguito una campagna che chiama STAC4749. Gli attaccanti hanno creato account Microsoft Teams su domini dall'aria IT, hanno chiamato i dipendenti fingendosi l'helpdesk e li hanno convinti ad aprire una sessione Quick Assist. Almeno tre di quelle intrusioni sono finite con il ransomware Chaos. Una è passata dalla prima chiamata Teams ai file cifrati in meno di 17 ore.

Ora chiedetevi cosa hanno usato quelle organizzazioni per coordinare la risposta. Teams. Outlook. Lo stesso tenant in cui l'attaccante era già entrato.

È questo il problema che i requisiti NIS2 sulle comunicazioni sicure esistono per risolvere. L'articolo 21(2)(j) è la misura che lo copre, ed è la metà di quell'articolo che la maggior parte dei programmi di conformità non implementa mai.

L'articolo 21(2)(j) ha due metà, e la maggior parte dei programmi ne costruisce una sola

La formulazione della direttiva è breve: «l'uso di soluzioni di autenticazione a più fattori o di autenticazione continua, di comunicazioni vocali, video e testuali protette e di sistemi di comunicazione di emergenza protetti da parte del soggetto al proprio interno, se del caso».

Tutti leggono la prima parte. La MFA ottiene budget, un progetto e una riga nel report al consiglio. A inizio anno abbiamo spiegato perché la MFA da sola non supera più un audit.

La seconda parte viene ignorata. Contiene due obblighi distinti: proteggere i canali voce, video e testo di tutti i giorni, e avere un sistema di comunicazione di emergenza che funzioni ancora quando quelli di tutti i giorni non funzionano più.

«Se del caso» non è una clausola di uscita. È un qualificatore basato sul rischio. Se decidete che un controllo non è appropriato, la decisione deve essere scritta nella valutazione del rischio con la motivazione. Un auditor tratta il silenzio come una lacuna, non come una decisione.

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

Il regolamento di esecuzione sparpaglia il requisito in cinque sezioni

Il Regolamento di esecuzione (UE) 2024/2690 della Commissione è il manuale dettagliato per infrastrutture digitali, gestione dei servizi TIC e fornitori digitali. Significa che MSP e MSSP vi rientrano direttamente. Le autorità nazionali degli altri settori lo usano come riferimento per definire cosa sia «appropriato».

Non contiene alcuna sezione intitolata «comunicazioni sicure». Cercatela e concluderete che l'obbligo è sottile. Non lo è. È distribuito:

Il punto 3.5.3 richiede piani e procedure di comunicazione per la risposta agli incidenti: con il CSIRT o l'autorità competente, tra il proprio personale e con le parti interessate esterne.

Il punto 4.1.2(c) richiede che il piano di continuità operativa e disaster recovery elenchi i contatti chiave e i canali di comunicazione interni ed esterni.

Il punto 4.2.4(d) richiede una ridondanza almeno parziale dei «canali di comunicazione appropriati», accanto alla ridondanza di sistemi, strutture e personale.

Il punto 4.3.2(b) richiede che il processo di gestione delle crisi definisca i mezzi di comunicazione con le autorità competenti, sia per le notifiche obbligatorie sia per gli scambi non obbligatori.

I punti 6.7.2(i) e (k) richiedono canali fidati e isolati tra i sistemi e un piano di attuazione degli standard moderni di comunicazione via e-mail.

Il punto 11.7 copre la metà MFA.

La conseguenza pratica: un auditor non chiederà «avete comunicazioni sicure?». Chiederà la procedura di risposta agli incidenti, il piano BC/DR e il processo di gestione delle crisi, e cercherà il canale di comunicazione in ciascuno. Se la risposta in tutti e tre è «e-mail e Teams», il rilievo si scrive da solo.

La vostra risposta agli incidenti gira sul sistema in cui si trova l'attaccante

Presumete la compromissione. Non è paranoia, è comportamento documentato.

Microsoft e CISA descrivono entrambe come Octo Tempest, più noto come Scattered Spider, cerchi in Slack, Teams ed Exchange Online della vittima le conversazioni sulla propria intrusione e si unisca alle call di risposta agli incidenti per capire come i difensori gli danno la caccia. A giugno 2026, affiliati di DragonForce sono stati osservati instradare traffico di comando e controllo attraverso relay Microsoft Teams legittimi per confondersi con il normale traffico di collaborazione.

Se l'attaccante ha un account Entra ID privilegiato, ogni canale che si autentica su Entra ID è leggibile per lui. Incluso il canale Teams «di riserva» che avete creato per il team di crisi.

Un sistema di comunicazione di emergenza supera tre test:

Identità separata. Non si autentica tramite il vostro identity provider principale. Se il SSO vi fa entrare, un SSO compromesso fa entrare l'attaccante.

Infrastruttura separata. Non è ospitato nello stesso tenant, sullo stesso dominio o dietro lo stesso DNS che potreste dover spegnere.

Predisposto in anticipo e provato. L'elenco dei contatti esiste offline, gli account esistono prima dell'incidente e il canale è stato usato in un test. Il punto 4.1.4 richiede che i piani BC/DR siano testati a intervalli pianificati. Il canale di emergenza fa parte di quel piano, quindi di quel test.

In pratica non è costoso. Un gruppo Signal o Threema su dispositivi gestiti via MDM con account non legati al SSO aziendale. Una scheda contatti stampata nel raccoglitore di crisi. Una casella di posta di emergenza presso un altro provider. Il costo non sta nello strumento. Il costo sta nella disciplina di tenerlo aggiornato.

Un altro dettaglio che sfugge: il preallarme entro 24 ore dell'articolo 23 deve raggiungere il vostro CSIRT anche quando è proprio il vostro server di posta a essere fuori uso. I recapiti che avete fornito al registro nazionale dei soggetti al momento della registrazione sono quelli che il CSIRT userà per richiamarvi. Se si tratta di una casella nel tenant compromesso, avete un problema di notifica oltre a un problema di sicurezza. La procedura di gestione degli incidenti deve indicare esplicitamente il percorso alternativo verso il CSIRT.

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.

NIS2 comunicazioni sicure è uno standard di configurazione, non un acquisto di prodotto

Teams, Google Meet e Zoom cifrano tutti in transito. Nessuno fallisce un audit perché le sue videochiamate non sono cifrate. La domanda che il regolamento pone davvero è: chi può raggiungere le vostre persone, attraverso quali canali e sotto quali controlli?

Traducete questo in impostazioni concrete e il quadro diventa chiaro.

Accesso esterno. STAC4749 e la campagna Black Basta prima di essa dipendevano entrambe dalla possibilità per account Teams esterni di scrivere e chiamare i dipendenti. Limitare la federazione esterna a una allow-list di domini partner, o bloccare chat e chiamate esterne per la maggior parte degli utenti, elimina il punto di ingresso. Il punto 6.7.2(c) richiede già di impedire le comunicazioni di rete non necessarie all'operatività. Questa è la versione a livello di collaborazione di quella regola.

Autenticazione e-mail. Il punto 6.7.2(k) chiede un piano di attuazione degli «standard moderni di comunicazione via e-mail concordati a livello internazionale e interoperabili». La guida tecnica di attuazione ENISA di giugno 2025 rimanda a SPF, DKIM e DMARC per l'autenticazione del mittente e a MTA-STS o DANE per la cifratura del trasporto. Un record DMARC a p=none è monitoraggio, non protezione. Gli auditor hanno imparato la differenza.

Strumenti approvati per classificazione. La vostra policy di crittografia ai sensi dell'articolo 21(2)(h) dovrebbe indicare quali strumenti di messaggistica e videoconferenza sono approvati per quale livello di classificazione degli asset. Un consiglio che discute un incidente su WhatsApp da telefoni personali è un rilievo, perché nessuna policy lo consente e nessun controllo lo governa.

Igiene delle riunioni. Sala d'attesa attiva, accesso autenticato alle riunioni interne, condivisione schermo e registrazione riservate all'host, e la regola che nessuno in una call di crisi è anonimo.

Voce. Trunk SIP e VoIP su TLS e SRTP e, nelle sedi in cui conta, capacità di chiamata di emergenza che non dipenda dal funzionamento della rete aziendale.

Niente di tutto questo richiede l'acquisto di un nuovo prodotto. Tutto richiede qualcuno che possieda la configurazione e sappia esportarne l'evidenza.

Cosa chiederà davvero un auditor

Le autorità di vigilanza hanno iniziato a chiedere pacchetti di evidenze invece di dichiarazioni di policy. Abbiamo trattato la checklist generale delle evidenze due settimane fa. Per l'articolo 21(2)(j), aspettatevi questi otto elementi:

La sezione comunicazione della procedura di risposta agli incidenti, con canali primari e alternativi e relativi responsabili.
La sezione contatti chiave e canali del piano BC/DR, datata entro il ciclo di revisione corrente.
Una dichiarazione di ridondanza dei canali di comunicazione ai sensi del punto 4.2.4(d).
Un verbale di test che dimostri l'uso del canale di emergenza durante un'esercitazione.
Un'esportazione della configurazione di accesso esterno di Teams o Google Workspace.
I record DNS per DMARC, MTA-STS e, dove usato, DANE.
L'elenco degli strumenti di comunicazione approvati, collegato ai livelli di classificazione degli asset.
Le voci della valutazione del rischio che giustificano eventuali decisioni di «non appropriato».

Se riuscite a produrre tutti e otto in un giorno, avete finito con questa misura. Se riuscite a produrne tre, sapete da dove parte la gap analysis.

Per gli MSP questa misura si applica due volte

Un MSP è un soggetto di gestione dei servizi TIC ai sensi dell'allegato I della NIS2. Il Regolamento 2024/2690 gli si applica direttamente. Questo è il vostro obbligo.

Poi c'è il lato cliente. La policy di sicurezza della catena di approvvigionamento di ogni cliente, al punto 5.1, dovrebbe valutare le pratiche di cybersicurezza dei suoi fornitori di servizi. La vostra capacità di comunicare con un cliente durante un incidente, su un canale che non sia il tenant compromesso del cliente né il vostro tenant compromesso, è una di quelle pratiche.

Simulate questo scenario: il vostro RMM o il vostro tenant M365 è compromesso. Quaranta clienti devono saperlo entro poche ore. La vostra e-mail è proprio ciò che è compromesso. Qual è l'elenco, dove si trova, e chi ce l'ha su un telefono che non si sincronizza con il SSO aziendale?

Se non c'è risposta, quello è il primo punto del vostro piano di rimedio. Il Cyberbeveiligingswet olandese è in vigore dal 15 agosto 2026, e la RDI vigila direttamente sulla gestione dei servizi TIC. Il BSI tedesco e il CCB belga lo fanno da più tempo. Il doppio obbligo per gli MSP non è più teorico in nessuno di quei mercati.

Escalation delle sanzioni NIS2 — Oltre la multa
!
Evento scatenante
Non conformità rilevata o incidente verificatosi
Un'autorità di vigilanza identifica una lacuna di conformità o un'organizzazione non soddisfa i requisiti NIS2
Le autorità possono imporre▼
Sanzioni non finanziarie
1
Ordini di conformità con scadenze vincolanti
2
Audit di sicurezza obbligatori a vostre spese
3
Divulgazione pubblica delle violazioni
4
Istruzioni vincolanti su misure di sicurezza specifiche
Scala verso▼
Conseguenze operative e personali
1
Sospensione di certificazioni o licenze operative
2
Divieto temporaneo di funzioni dirigenziali per individui
3
Denominazione pubblica delle persone fisiche responsabili
Evento scatenante
Non finanziario
Operativo / personale

Da dove iniziare questo mese

Non è un progetto con un comitato guida. Sono quattro attività.

Scegliete il canale di emergenza e predisponetelo. Identità separata, infrastruttura separata, elenco contatti conservato offline.

Mettetelo per iscritto. Aggiungete il canale alla procedura di risposta agli incidenti al punto 3.5.3 e alla sezione contatti chiave del piano BC/DR al punto 4.1.2(c).

Chiudete la porta d'ingresso. Limitate la federazione esterna in Teams. Portate DMARC a p=reject quando i report confermano i vostri mittenti legittimi.

Testatelo. Il primo messaggio della vostra prossima esercitazione tabletop parte solo sul canale di emergenza. Se nessuno lo vede, avete imparato qualcosa di importante in un momento comodo.

Se volete sapere dove si colloca l'articolo 21(2)(j) rispetto alle altre nove misure per un cliente specifico, il quick scan NIS2Certify copre tutte e dieci in circa dieci minuti e vi consegna un elenco prioritizzato di lacune da cui partire.