Molte organizzazioni valutano in modo errato il proprio rischio ai sensi della NIS-2. Non perché siano disinformate, ma perché si concentrano solo su soglie formali: settore, dimensioni, definizioni legali. Nella realtà, il coinvolgimento nasce in tre modi – e due di essi funzionano senza una notifica formale. Chi lo ignora, in caso di crisi si ritrova senza prove , senza tutela contrattuale della catena di fornitura e senza procedure di segnalazione collaudate.
I tre percorsi di coinvolgimento
-
Direttamente coinvolti : aziende classificate formalmente come “essenziali” o “importanti”. Hanno obblighi espliciti in materia di governance , gestione del rischio, misure tecniche/organizzative e segnalazione degli incidenti.
-
Indirettamente coinvolti : fornitori di servizi e subfornitori che lavorano per clienti direttamente coinvolti. I requisiti vengono trasferiti per via contrattuale: controlli minimi (ad es. MFA resistente al phishing, patch-SLO), diritti di audit e di prova, termini di segnalazione, contatti di emergenza.
-
Fattualmente coinvolti : aziende senza classificazione formale il cui guasto bloccherebbe processi critici dei clienti. Al più tardi durante l’onboarding o la ricertificazione, vengono obbligate ad adottare gli stessi controlli – oppure perdono i contratti.
La differenza è giuridicamente rilevante, ma operativamente secondaria: in tutti e tre i casi occorre dimostrare che la propria sicurezza IT è adeguata, documentata ed efficace.
Perché la dimensione non è il criterio decisivo
Il coinvolgimento reale nasce dalle catene di impatto: se il vostro sistema si ferma e di conseguenza si interrompono produzione, logistica o servizi pubblici di un cliente, non conta il numero di dipendenti, ma il grado di dipendenza. I trigger tipici sono interfacce esposte a Internet, accessi amministrativi ai sistemi dei clienti, trattamento di dati sensibili o responsabilità operativa per piattaforme centrali. In breve: chi abilita o influenza una funzione critica viene valutato – formalmente o contrattualmente.
Pressione indiretta: compliance “dall’alto verso il basso”
I committenti direttamente coinvolti trasferiscono gli obblighi lungo la propria catena di fornitura. Non è un “nice to have”, ma una strategia di sopravvivenza: un punto debole presso il fornitore è un punto debole nel proprio audit. Sono quindi attesi standard minimi chiari – senza nomi di vendor, ma con effetti verificabili:
-
Identità prima di tutto : MFA resistente al phishing per ruoli privilegiati, disattivazione dei protocolli legacy deboli.
-
Disciplina nelle patch : scadenze vincolanti in base all’esposizione (Internet vs. interno), eccezioni documentate con misure compensative.
-
Backup con prova : verifica di integrità e ripristino con tempi misurati.
-
Canale di segnalazione & referenti: contatto 24/7, soglie definite, verbale della prima notifica.
-
Logging : registri tracciabili degli accessi e delle modifiche critiche – a prova di audit, finalizzati.
Chi è in grado di fornirli supera l’onboarding; chi no, viene escluso dalle shortlist – indipendentemente dalla classificazione formale NIS-2.
Falsi presupposti frequenti – confutati con realismo
-
“Siamo troppo piccoli.” – Finché un grande cliente non classifica la vostra piattaforma come critica. Da quel momento valgono subito le sue regole.
-
“Un certificato basta.” – No. I certificati aiutano, ma non sostituiscono processi concreti, audit e prove.
-
“Segnaliamo più tardi, quando tutto è chiaro.” – Gli obblighi di segnalazione richiedono notifiche iniziali tempestive e strutturate, con aggiornamenti.
-
“Se ne occupa l’IT.” – La NIS-2 riguarda le responsabilità della direzione. Budget, rischi ed escalation sono temi di governance.
Cosa è sensato fare ora (senza attivismo)
Iniziate dove il fallimento è più costoso e create prove invece di dichiarazioni d’intento:
-
Mappa dei rischi & responsabilità: quali servizi sono critici per i clienti? Chi decide in caso di incidente? Per iscritto, approvato, reperibile.
-
Runbook dei controlli : una pagina per misura: obiettivo, trigger, passaggi, responsabile, prova (screenshot, log, ticket).
-
Modello a livelli della catena di fornitura : desk review per tutti, prove remote per “alto”, test mirati per “critico”. Scadenze ed escalation regolati contrattualmente.
-
Comunicazione degli incidenti : modelli e matrici di contatto (interno/esterno), soglie, canali out-of-band – provati una volta, non solo descritti.
-
Disciplina della prova : “Non documentato” in audit equivale a “non avvenuto”. Raccogliere, versionare, archiviare centralmente.
KPI che reggono in caso di verifica
-
Copertura MFA (resistente al phishing) per ruoli privilegiati.
-
Conformità Patch-SLO separata per esposto a Internet/interno.
-
Tempo di ripristino & verifica di integrità per due processi aziendali critici.
-
Tempo fino alla prima notifica e completezza delle prime informazioni sull’ incidente.
-
Fitness della catena di fornitura : quota di partner critici con prove aggiornate e contatto 24/7 funzionante.
Questi KPI non sono un fine in sé; ogni deviazione richiede una conseguenza definita (escalation, change-freeze, verifica aggiuntiva). Solo così la governance diventa efficace.
Conclusione
La domanda “Siamo formalmente NIS-2?” è importante – ma non decisiva. Ciò che conta è poter dimostrare che i vostri controlli sono adeguati, funzionano e sono comprovabili in modo solido in caso di emergenza. Direttamente, indirettamente o fattualmente coinvolti: conta il risultato. Chi oggi chiarisce le responsabilità, redige runbook, tutela contrattualmente la catena di fornitura e raccoglie prove non solo supera il prossimo audit – ma riduce concretamente il rischio reale di interruzioni e costi conseguenti.
FAQ sul post del blog
Chi è coinvolto dalla NIS-2 – solo le aziende direttamente elencate?
No. Oltre alle imprese classificate formalmente, anche fornitori e subfornitori sono coinvolti indirettamente tramite obblighi contrattuali e requisiti della catena di fornitura.
Cosa attiva il coinvolgimento ai sensi della NIS-2?
Accessi amministrativi ai sistemi dei clienti, trattamento di dati sensibili e dipendenze operative critiche sono i trigger più comuni.
Come può un’azienda dimostrare l’adeguatezza della sicurezza IT?
Attraverso KPI misurabili come copertura MFA, rispetto dei Patch-SLO, test di ripristino documentati e metriche strutturate sugli incidenti.
Cosa richiedono i clienti in ambito NIS-2?
Prove verificabili, diritti di audit contrattuali, scadenze di segnalazione definite e contatti operativi 24/7.
Qual è l’errore più comune riguardo alla NIS-2?
“Siamo troppo piccoli.” Questa convinzione cade quando un’interruzione blocca processi critici di un cliente.
