NIS2: Chi è coinvolto? Direttamente, indirettamente – e tramite la catena di fornitura

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

1. 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.
2. 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.
3. 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