L’evoluzione della sicurezza informatica in ambito europeo ha trovato una sua declinazione operativa estremamente concreta nel lavoro di analisi presentato durante il Security Summit Milano 2026. In un momento di forte pressione normativa, la collaborazione tra associazioni di settore come Clusit e AIEA (Associazione Italiana Information Systems Auditors) ha permesso di delineare un percorso guidato per le imprese che devono affrontare le scadenze imminenti e le complessità strutturali introdotte dal nuovo quadro regolatorio.

Attraverso il contributo tecnico di Claudio Telmon e Luca Savoia, emerge con chiarezza che la Direttiva NIS2 non rappresenta semplicemente un adeguamento tecnico, ma una trasformazione profonda del modello di governance aziendale.

La centralità della responsabilità degli organi amministrativi

Uno dei punti di maggiore rottura rispetto al passato riguarda la natura della responsabilità legale. Come evidenziato da Luca Savoia, Partner di Forvis Mazars e membro del comitato esecutivo di AIEA, esiste un equivoco frequente circa la possibilità di delegare gli obblighi previsti dalla norma a figure tecniche o dirigenziali. Su questo aspetto, Savoia è categorico: «La responsabilità rimane in capo ai membri del CdA».

Questa impostazione implica che, anche qualora la gestione operativa venga affidata a un punto di contatto o a dirigenti specifici, la responsabilità ultima non si trasferisce.

Il sistema sanzionatorio riflette questa severità, traendo ispirazione da modelli già consolidati, come quello del settore bancario. Le conseguenze per il mancato adeguamento o per la negligenza nella gestione del piano di remediation possono essere pesanti: le sanzioni amministrative non colpiscono esclusivamente l’ente giuridico, ma possono estendersi alle persone fisiche dei componenti del Consiglio di Amministrazione, arrivando fino alla diffida.

Si tratta di un meccanismo volto a garantire che la cyber sicurezza diventi un tema prioritario nelle agende dei decisori aziendali e non resti confinato nei dipartimenti IT.

Il Management Model e la governance dei flussi informativi

L’approccio operativo suggerito dai gruppi di lavoro si articola su quello che viene definito un “Management Model” o Modello di Gestione. Questo pilastro comprende l’intera architettura organizzativa, spaziando dalle policy interne ai flussi informativi necessari per un reporting sostanziale.

L’obiettivo è superare il vecchio schema delle misure minime di sicurezza, intese come una lista di requisiti da spuntare una tantum. La Direttiva NIS2 impone invece un setup organizzativo destinato a perdurare e a evolversi nel tempo.

Un aspetto fondamentale di questo modello è la trasparenza verso i vertici. All’interno del paper presentato dalle associazioni vengono analizzati 11 documenti fondamentali, che spaziano dalla policy generale di sicurezza alla gestione dei rischi.

Secondo Savoia, non è sufficiente redigere questi testi; è indispensabile che il piano di trattamento dei rischi sia esposto e ratificato formalmente dal CdA. In questo modo, i membri del consiglio sono chiamati a comprendere e validare le scelte strategiche in materia di protezione dei dati e dei sistemi.

Anche il tema della formazione viene reinterpretato. Non è più accettabile limitarsi a programmi di base standardizzati; la normativa richiede percorsi continuativi e, soprattutto, personalizzati in base alle criticità del ruolo e agli eventi rilevati.

Savoia cita l’esempio di un dipendente che cade vittima di un attacco di phishing: in questo scenario, il modello prevede un follow-up specifico con un approccio che deve essere «costruttivo e non punitivo, nel rispetto dell’etica aziendale».

Gestione dei rischi della supply chain e dipendenze esterne

Il secondo grande pilastro operativo riguarda la Supply Chain, un ambito che richiede una mappatura meticolosa dei fornitori per identificare quelli definiti “critici”. Non tutte le realtà che collaborano con un’azienda rientrano automaticamente nel perimetro della Direttiva NIS2, pertanto è necessario applicare criteri di selezione rigorosi basati sulla Business Impact Analysis (BIA).

La criticità di un fornitore deve essere valutata attraverso domande precise: il fornitore tratta dati sensibili o critici? Ha accesso diretto ai sistemi informativi aziendali? Quanto è vitale il suo servizio per la continuità operativa?

I risultati di questa analisi devono tradursi in azioni concrete, quali:

• Lo svolgimento di due diligence approfondite sui potenziali partner.
• L’inserimento di clausole contrattuali specifiche che definiscano gli obblighi di sicurezza relativi alla quota di servizio erogato.
• La garanzia del diritto di audit, che consenta all’azienda di verificare periodicamente la postura di sicurezza del fornitore.
• La gestione della trasparenza sui sub-fornitori per avere visibilità sull’intera filiera.

Il monitoraggio non deve essere inteso come una fotografia statica scattata all’inizio del rapporto contrattuale, ma come un processo dinamico e costante, la cui intensità deve essere proporzionale al livello di rischio assegnato al fornitore.

Incident Management e il dialogo con l’Agenzia per la Cybersicurezza Nazionale

Il terzo pilastro è dedicato alla gestione degli incidenti, un processo che copre l’intera catena dalla rilevazione iniziale fino al triage e alla risoluzione. La Direttiva NIS2 introduce obblighi di notifica stringenti e differenziati in base alla natura del soggetto (essenziale o importante) e al settore di appartenenza.

Definire la “significatività” di un incidente non è sempre immediato: se per un fornitore di servizi IT i criteri possono basarsi sugli SLA (Service Level Agreement), per un’azienda del settore chimico i parametri di riferimento saranno radicalmente differenti.

In questa fase, il rapporto con l’Agenzia per la Cybersicurezza Nazionale (ACN) gioca un ruolo determinante. Luca Savoia riporta un’esperienza diretta di notifica, evidenziando come l’approccio dell’Autorità sia stato orientato alla cooperazione: «Sono stati estremamente collaborativi, agendo quasi più come consulenti che come ispettori».

L’Agenzia ha operato richiedendo dettagli tecnici e payload per classificare correttamente l’evento, fornendo un supporto che Savoia definisce «un grande punto di forza» del sistema attuale.

L’integrazione tra la gestione dell’incidente, la continuità operativa e il disaster recovery deve essere supportata da test regolari e flussi di comunicazione chiari sia verso il top management che verso l’esterno.

L’IT Auditor come advisor proattivo

Un cambiamento rilevante si osserva anche nel ruolo dell’IT Auditor. Tradizionalmente vista come una figura che interviene a valle per certificare la conformità, nell’ottica della Direttiva NIS2 questa professionalità assume una funzione di advisor già nelle fasi iniziali dei progetti.

L’IT Auditor può infatti fornire assurance sulla correttezza della BIA o sulla metodologia scelta per la gestione dei rischi IT e OT (Operational Technology). Questo ruolo proattivo si è dimostrato vincente per garantire che il modello costruito sia non solo conforme al decreto, ma realmente efficace nel contrastare le minacce.

Tuttavia, mentre nel settore bancario questa figura è consolidata, nel mondo industriale la competenza specifica deve spesso essere costruita internamente o acquisita tramite consulenze esterne.

La verifica finale deve comunque accertare sia la compliance normativa sia l’efficacia delle misure attraverso test specifici.