Direttiva NIS2: obblighi e framework per la conformità aziendale

Ormai la registrazione e l’auto-valutazione dei soggetti nel perimetro della Direttiva NIS2 è alle spalle.

Nel mentre, si attendono i riscontri formali che ACN si impegna a fornire entro Aprile 2025, come da (FAQ 3.3):

La registrazione di un soggetto sulla piattaforma di ACN è successivamente sottoposta ad una fase di analisi. Entro il 31 marzo 2025, l’Agenzia, in qualità di Autorità nazionale competente NIS, comunicherà al soggetto l’eventuale inserimento nell’elenco dei soggetti essenziali o importanti.

Il tempo non abbonda mai, pertanto ci permettiamo di anticipare le prossime mosse.

Quali sono gli obblighi per i soggetti della Direttiva NIS2?

Anche qui, accorre in aiuto la FAQ 1.9:

1.9 Cosa sono gli obblighi di base in materia di misure di sicurezza e di notifica di incidente?

In ossequio ai principi di proporzionalità e gradualità previsti dal decreto NIS, gli obblighi (articolo 23, 24 e 25) in materia di misure di sicurezza e notifica di incidente sono definiti mediante delle determinazioni del Direttore generale dell’Agenzia per la cybersicurezza nazionale che dovranno essere adottate entro aprile 2025.

Gli allegati tecnici di queste determinazioni andranno a stabilire i requisiti minimi in termini di misure di sicurezza che i soggetti dovranno realizzare entro ottobre 2026. declinate impiegando il Framework Nazionale per la Cyber Security e la Data Protection (FNCS). Il FNCS è l’adattamento nazionale del Cyber Security Framework (CSF) del NIST (National Institute of Standards and Technology), sviluppato e arricchito dal CIS Sapienza.

Per ognuno dei 10 ambiti indicati dall’articolo 24 del decreto NIS verranno indicati dei requisiti minimi, organizzati sulla base del citato FNCS.

Con riferimento, invece, alle notifiche di incidente, nei medesimi allegati tecnici saranno indicate le fattispecie considerate “incidenti significativi” e, pertanto, soggette all’obbligo di notifica di cui all’articolo 25.

Nelle more dell’adozione delle citate determinazioni (aprile 2025), si segnalano le “Linee guida per il rafforzamento della resilienza” che possono fornire utili indicazioni a quelle organizzazioni che intendono anticipare l’avvio del processo di rafforzamento della loro postura di sicurezza informatica.

Nell’ottica collaborativa declinata dal decreto NIS, tramite i tavoli settoriali, previsti dall’articolo 11, verranno raccolti riscontri circa le bozze di allegati tecnici in parola nel corso del mese di febbraio 2025.

Il riferimento normativo è dato dagli articoli 23, 24 e 25 del D. Lgs 138/2024 di recepimento della Direttiva NIS 2.

Per pianificare le prossime azioni, analizziamo questi articoli uno per uno.

L’articolo 23 – Le responsabilità dei vertici delle organizzazioni

Il testo dell’articolo è il seguente:

Art. 23

Organi di amministrazione e direttivi

1. Gli organi di amministrazione e gli organi direttivi dei soggetti essenziali e dei soggetti importanti:
   a) approvano le modalita’ di implementazione delle misure di gestione dei rischi per la sicurezza informatica adottate da tali soggetti ai sensi dell’articolo 24;
   b) sovrintendono all’implementazione degli obblighi di cui al presente capo e di cui all’articolo 7;
   c) sono responsabili delle violazioni di cui al presente decreto.
   
2. Gli organi di amministrazione e gli organi direttivi dei soggetti essenziali e dei soggetti importanti:
   a) sono tenuti a seguire una formazione in materia di sicurezza informatica;
   b) promuovono l’offerta periodica di una formazione coerente a quella di cui alla lettera a) ai loro dipendenti, per favorire l’acquisizione di conoscenze e competenze sufficienti al fine di
   individuare i rischi e valutare le pratiche di gestione dei rischi per la sicurezza informatica e il loro impatto sulle attivita’ del soggetto e sui servizi offerti.
   
3. Gli organi di amministrazione e gli organi direttivi dei soggetti essenziali e dei soggetti importanti sono informati su base periodica o, se opportuno, tempestivamente, degli incidenti e delle
   notifiche di cui agli articoli 25 e 26.

In sostanza, l’articolo chiarisce che attiene alle figure apicali

Gli organi di amministrazione e gli organi direttivi dei soggetti essenziali e dei soggetti importanti

attuare la seguente azione di governance

• approvare le modalita’ di implementazione delle misure di gestione dei rischi per la sicurezza informatica adottate da tali soggetti ai sensi dell’articolo 24
• sono tenuti a seguire una formazione in materia di sicurezza informatica
• sono informati su base periodica o, se opportuno, tempestivamente, degli incidenti e delle
  notifiche di cui agli articoli 25 e 26

e garantire adeguata formazione

promuovono l’offerta periodica di una formazione coerente a quella di cui alla lettera a) ai loro dipendenti, per favorire l’acquisizione di conoscenze e competenze sufficienti al fine di individuare i rischi e valutare le pratiche di gestione dei rischi per la sicurezza informatica e il loro impatto sulle attivita’ del soggetto e sui servizi offerti.

Sulla responsabilità, il testo della norma è chiaro:

Gli organi di amministrazione e gli organi direttivi dei soggetti essenziali e dei soggetti importanti sono responsabili delle violazioni di cui al presente decreto

Dunque, le figure apicali sono:

• responsabili delle violazioni di cui al presente decreto

e devono:

• approvare le modalita’ di implementazione delle misure di gestione dei rischi per la sicurezza informatica
• seguire una formazione in materia di sicurezza informatica
• promuovere l’offerta periodica di una formazione ai loro dipendenti
• essere informati su base periodica o, se opportuno, tempestivamente, degli incidenti e delle notifiche

L’articolo 24 – Gli obblighi da implementare

Il testo dell’articolo è il seguente:

Art. 24

Obblighi in materia di misure di gestione dei rischi per la sicurezza informatica

1. I soggetti essenziali e i soggetti importanti adottano misure tecniche, operative e organizzative adeguate e proporzionate, secondo le modalita’ e i termini di cui agli articoli 30, 31 e 32, alla gestione dei rischi posti alla sicurezza dei sistemi informativi e di rete che tali soggetti utilizzano nelle loro attivita’ o nella fornitura dei loro servizi, nonche’ per prevenire o ridurre al minimo l’impatto degli incidenti per i destinatari dei loro servizi e per altri servizi.
   Tali misure:
   • a) assicurano un livello di sicurezza dei sistemi informativi e di rete adeguato ai rischi esistenti, tenuto conto delle conoscenze piu’ aggiornate e dello stato dell’arte in materia e, ove applicabile, delle pertinenti norme nazionali, europee e internazionali, nonche’ dei costi di attuazione;
   • b) sono proporzionate al grado di esposizione a rischi del soggetto, alle dimensioni del soggetto e alla probabilita’ che si verifichino incidenti, nonche’ alla loro gravita’, compreso il loro impatto sociale ed economico.
     
2. Le misure di cui al comma 1 sono basate su un approccio multi-rischio, volto a proteggere i sistemi informativi e di rete nonche’ il loro ambiente fisico da incidenti, e comprendono almeno i seguenti elementi:
   • a) politiche di analisi dei rischi e di sicurezza dei sistemi informativi e di rete;
   • b) gestione degli incidenti, ivi incluse le procedure e gli strumenti per eseguire le notifiche di cui agli articoli 25 e 26;
   • c) continuita’ operativa, ivi inclusa la gestione di backup, il ripristino in caso di disastro, ove applicabile, e gestione delle crisi;
   • d) sicurezza della catena di approvvigionamento, ivi compresi gli aspetti relativi alla sicurezza riguardanti i rapporti tra ciascun soggetto e i suoi diretti fornitori o fornitori di servizi;
   • e) sicurezza dell’acquisizione, dello sviluppo e della manutenzione dei sistemi informativi e di rete, ivi comprese la gestione e la divulgazione delle vulnerabilita’;
   • f) politiche e procedure per valutare l’efficacia delle misure di gestione dei rischi per la sicurezza informatica;
   • g) pratiche di igiene di base e di formazione in materia di sicurezza informatica;
   • h) politiche e procedure relative all’uso della crittografia e, ove opportuno, della cifratura;
   • i) sicurezza e affidabilita’ del personale, politiche di controllo dell’accesso e gestione dei beni e degli assetti;
   • l) uso di soluzioni di autenticazione a piu’ 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, ove opportuno.
     
3. Nel valutare quali misure di cui al comma 2, lettera d), siano adeguate, i soggetti tengono conto delle vulnerabilita’ specifiche per ogni diretto fornitore e fornitore di servizi e della qualita’ complessiva dei prodotti e delle pratiche di sicurezza informatica dei propri fornitori e fornitori di servizi, comprese le loro procedure di sviluppo sicuro.
   Per la medesima finalita’ i soggetti tengono altresi’ conto dei risultati delle valutazioni coordinate dei rischi per la sicurezza delle catene di approvvigionamento critiche effettuate dal Gruppo di cooperazione NIS.
   
4. Qualora un soggetto rilevi di non essere conforme alle misure di cui al comma 2, esso adotta, senza indebito ritardo, tutte le misure appropriate e proporzionate correttive necessarie.

Identifichiamo gli ambiti di intervento:

• politiche di analisi dei rischi e di sicurezza dei sistemi informativi e di rete;
• gestione degli incidenti, ivi incluse le procedure e gli strumenti per eseguire le notifiche di cui agli articoli 25 e 26;
• continuita’ operativa, ivi inclusa la gestione di backup, il ripristino in caso di disastro, ove applicabile, e gestione delle crisi;
• sicurezza della catena di approvvigionamento, ivi compresi gli aspetti relativi alla sicurezza riguardanti i rapporti tra ciascun soggetto e i suoi diretti fornitori o fornitori di servizi;
• sicurezza dell’acquisizione, dello sviluppo e della manutenzione dei sistemi informativi e di rete, ivi comprese la gestione e la divulgazione delle vulnerabilita’;
• politiche e procedure per valutare l’efficacia delle misure di gestione dei rischi per la sicurezza informatica;
• pratiche di igiene di base e di formazione in materia di sicurezza informatica;
• politiche e procedure relative all’uso della crittografia e, ove opportuno, della cifratura;
• sicurezza e affidabilita’ del personale, politiche di controllo dell’accesso e gestione dei beni e degli assetti;
• uso di soluzioni di autenticazione a piu’ 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, ove opportuno.

Unito alle scadenze esplicitate dalla FAQ 1.7:

• [SOGGETTI] Entro gennaio 2026 (entro 9 mesi dalla ricezione della notifica di inserimento nell’elenco dei soggetti NIS), adempimento agli obblighi di base in materia di notifica di incidente.
• [SOGGETTI] Entro ottobre 2026 (entro 18 mesi dalla ricezione della notifica di inserimento nell’elenco dei soggetti NIS), adempimento agli obblighi di base in materia di sicurezza informatica.

significa che gli adempimenti urgenti risultano i seguenti:

• Entro 9 mesi: adempimento degli obblighi in materia di notifica degli incidenti
• Entro 18 mesi: adempimento degli obblighi di base in materia di sicurezza informatica (analisi dei rischi, continuità operativa, pratiche di base e formazione, crittografia, autenticazione a due fattori)

L’articolo 25 – Le notifiche degli incidenti

Il testo dell’articolo è il seguente:

Art. 25

Obblighi in materia di notifica di incidente

• 1. I soggetti essenziali e i soggetti importanti notificano, senza ingiustificato ritardo, al CSIRT Italia ogni incidente che, ai sensi del comma 4, ha un impatto significativo sulla fornitura dei loro servizi, secondo le modalita’ e i termini di cui agli articoli 30, 31 e 32.
  
• 2. Le notifiche includono le informazioni che consentono al CSIRT Italia di determinare un eventuale impatto transfrontaliero dell’incidente.
  
• 3. La notifica non espone il soggetto che la effettua a una maggiore responsabilita’ rispetto a quella derivante dall’incidente.
  
• 4. Un incidente e’ considerato significativo se:
  • a) ha causato o e’ in grado di causare una grave perturbazione operativa dei servizi o perdite finanziarie per il soggetto interessato;
  • b) ha avuto ripercussioni o e’ idoneo a provocare ripercussioni su altre persone fisiche o giuridiche causando perdite materiali o immateriali considerevoli.
    
• 5. Ai fini della notifica di cui al comma 1, i soggetti interessati trasmettono al CSIRT Italia:
  • a) senza ingiustificato ritardo, e comunque entro 24 ore da quando sono venuti a conoscenza dell’incidente significativo, una pre-notifica che, ove possibile, indichi se l’incidente significativo possa ritenersi il risultato di atti illegittimi o malevoli o puo’ avere un impatto transfrontaliero;
  • b) senza ingiustificato ritardo, e comunque entro 72 ore da quando sono venuti a conoscenza dell’incidente significativo, una notifica dell’incidente che, ove possibile, aggiorni le informazioni di cui alla lettera a) e indichi una valutazione iniziale dell’incidente significativo, comprensiva della sua gravita’ e del suo impatto, nonche’, ove disponibili, gli indicatori di compromissione;
  • c) su richiesta del CSIRT Italia, una relazione intermedia sui pertinenti aggiornamenti della situazione;
  • d) una relazione finale entro un mese dalla trasmissione della notifica dell’incidente di cui alla lettera b), che comprenda:
    • una descrizione dettagliata dell’incidente, ivi inclusi la sua gravita’ e il suo impatto;
    • il tipo di minaccia o la causa originale (root cause) che ha probabilmente innescato l’incidente;
    • le misure di attenuazione adottate e in corso;
    • ove noto, l’impatto transfrontaliero dell’incidente;
  • e) in caso di incidente in corso al momento della trasmissione della relazione finale di cui alla lettera d), una relazione mensile sui progressi e una relazione finale entro un mese dalla conclusione della gestione dell’incidente.
    
• 6. In deroga a quanto previsto dal comma 5, lettera b), un prestatore di servizi fiduciari, in relazione a incidenti significativi che abbiano un impatto sulla fornitura dei suoi servizi fiduciari, provvede alla notifica di cui alla medesima lettera, senza indebito ritardo e comunque entro 24 ore da quando sono venuti a conoscenza dell’incidente significativo.
  
• 7. Fermo restando quanto previsto dall’articolo 15, comma 4, senza ingiustificato ritardo e ove possibile entro 24 ore dal ricevimento della pre-notifica di cui al comma 5, lettera a), il CSIRT Italia fornisce una risposta al soggetto notificante, comprensiva di un riscontro iniziale sull’incidente significativo e, su richiesta del soggetto, orientamenti o consulenza sull’attuazione di possibili misure tecniche di mitigazione. Su richiesta del soggetto notificante, il CSIRT Italia fornisce ulteriore supporto tecnico.
  
• 8. Qualora si sospetti che l’incidente significativo abbia carattere criminale, il CSIRT Italia fornisce al soggetto notificante anche orientamenti sulla segnalazione dell’incidente significativo, all’organo centrale del Ministero dell’interno per la sicurezza e per la regolarita’ dei servizi di telecomunicazione, di cui all’articolo 7-bis del decreto-legge 27 luglio 2005, n. 144, convertito, con modificazioni, dalla legge 31 luglio 2005, n. 155 (Autorita’ di contrasto).
  
• 9. Sentito il CSIRT Italia, se ritenuto opportuno e qualora possibile, i soggetti essenziali e i soggetti importanti comunicano, senza ingiustificato ritardo, ai destinatari dei loro servizi gli incidenti significativi che possono ripercuotersi negativamente sulla fornitura di tali servizi.
  
• 10. I soggetti essenziali e i soggetti importanti, se ritenuto opportuno e qualora possibile, sentito il CSIRT Italia, comunicano senza ingiustificato ritardo, ai destinatari dei loro servizi che sono potenzialmente interessati da una minaccia informatica significativa, misure o azioni correttive o di mitigazione che tali destinatari possono adottare in risposta a tale minaccia. Inoltre, sentito il CSIRT Italia, se ritenuto opportuno, i soggetti essenziali e i soggetti importanti comunicano ai medesimi destinatari anche la natura di tale minaccia informatica significativa.
  
• 11. L’Agenzia per la cybersicurezza nazionale, nello svolgimento delle funzioni di Autorita’ nazionale competente NIS e di CSIRT Italia, anche sentendo, se del caso, le autorita’ competenti e gli CSIRT nazionali degli altri Stati membri interessati, puo’ informare il pubblico riguardo all’incidente significativo per evitare ulteriori incidenti significativi o per gestire un incidente significativo in corso, o qualora ritenga che la divulgazione dell’incidente significativo sia altrimenti nell’interesse pubblico.
  
• 12. L’Agenzia per la cybersicurezza nazionale adotta mezzi tecnici e relative procedure per semplificare le notifiche di cui al presente articolo e le notifiche volontarie di cui all’articolo 26, informando i soggetti essenziali e i soggetti importanti.

Il testo è lungo: sintetizziamo gli aspetti principali.

a) senza ingiustificato ritardo, e comunque entro 24 ore da quando sono venuti a conoscenza dell’incidente significativo, una pre-notifica che, ove possibile, indichi se l’incidente significativo
possa ritenersi il risultato di atti illegittimi o malevoli o puo’ avere un impatto transfrontaliero;
b) senza ingiustificato ritardo, e comunque entro 72 ore da quando sono venuti a conoscenza dell’incidente significativo, una notifica dell’incidente che, ove possibile, aggiorni le informazioni
di cui alla lettera a) e indichi una valutazione iniziale dell’incidente significativo, comprensiva della sua gravita’ e del suo impatto, nonche’, ove disponibili, gli indicatori di compromissione;
c) su richiesta del CSIRT Italia, una relazione intermedia sui pertinenti aggiornamenti della situazione;
d) una relazione finale entro un mese dalla trasmissione della notifica dell’incidente di cui alla lettera b), che comprenda:
1) una descrizione dettagliata dell’incidente, ivi inclusi la sua gravita’ e il suo impatto;
2) il tipo di minaccia o la causa originale (root cause) che ha probabilmente innescato l’incidente;
3) le misure di attenuazione adottate e in corso;

Dunque, è necessario prepararsi per notificare:

• pre-allarme entro 24h
• notifica entro 72h
• relazione intermedia su richiesta
• relazione finale entro 1 mese

E quindi?

Responsabilità (art. 23), compiti (art. 24) e adempimenti (art. 25) adesso dovrebbero essere chiari.

Come affrontarli ? In aiuto una possibile soluzione.

Il framework

La FAQ 1.9 anticipa la metodologia suggerita: il Framework Nazionale per la Cyber Security e la Data Protection (FNCS):

Gli allegati tecnici di queste determinazioni andranno a stabilire i requisiti minimi in termini di misure di sicurezza che i soggetti dovranno realizzare entro ottobre 2026. declinate impiegando il Framework Nazionale per la Cyber Security e la Data Protection (FNCS). Il FNCS è l’adattamento nazionale del Cyber Security Framework (CSF) del NIST (National Institute of Standards and Technology), sviluppato e arricchito dal CIS Sapienza.

Come funziona il framework ?

Il Framework è ispirato al Cybersecurity Framework ideato dal NIST (National Institute of Standards and Technology) e fornisce uno strumento operativo per organizzare i processi di cybersecurity adatto alle organizzazioni pubbliche e private, di qualunque dimensione.

In sostanza, è lo strumento di supporto alle organizzazioni che necessitano di strategie e processi volti alla protezione dei dati personali e alla sicurezza cyber. Possiamo intenderlo come una guida organizzativa volta alla cybersecurity e alla protezione dei dati coerente con i regolamenti vigenti in materia.

Entriamo nel merito

All’interno del Framework sono definiti 3 concetti fondamentali:

• Framework Core
• Profile
• Implementation Tier

Vediamo in cosa consistono.

FRAMEWORK CORE

Il Framework Core rappresenta la struttura del ciclo di vita del processo di gestione della cybersecurity ed è strutturato gerarchicamente in:

• function
• category
• subcategory

In sostanza, per ogni function, category e subcategory, sono definite le attività abilitanti, quali processi e tecnologie, da realizzare per gestire la singola function.

Andiamo a descrivere in breve le Function e le Category ad esse associate:

IDENTIFY: funzione necessaria alla comprensione del contesto aziendale, degli asset che supportano i processi critici di business e dei relativi rischi associati. Le category all’interno di questa function sono:

• Asset Management
• Business Environment
• Governance
• Risk Assessment
• Risk Management Strategy
• Supply Chain Risk Management
• Data Management

PROTECT: La function PROTECT è associata all’implementazione di quelle misure volte alla protezione dei processi di business e degli asset aziendali, indipendentemente dalla loro natura informatica.

Le category all’interno di questa function sono:

• Identity Management
• Authentication and Access Control
• Awareness and Training
• Data Security
• Information Protection Processes and Procedures
• Maintenance
• Protective Technology.

DETECT: associata alle attività appropriate per identificare gli incidenti di sicurezza informatica.

Le category all’interno di questa function sono:

• Anomalies and Events
• Security Continuous Monitoring
• Detection Processes

RESPOND: La function RESPOND entra in gioco quando un incidente di sicurezza informatica è stato rilevato. Il suo obiettivo è contenere l’impatto determinato da un potenziale incidente di sicurezza informatica.

Le category all’interno di questa function sono:

• Response Planning
• Communications
• Analysis
• Mitigation
• Improvements

RECOVER: come descritto dal nome stesso, la funzione serve per la gestione dei piani e delle attività per il ripristino dei processi e dei servizi impattati da un incidente. L’ottica è quella di garantire la resilienza dei sistemi e delle infrastrutture.

Le category all’interno di questa function sono:

• Recovery Planning
• Improvements
• Communications

L’elenco completo è disponibile qui.

PROFILI

I profili sono il risultato della selezione di specifiche subcategory in base al contesto della propria organizzazione.

Sono utilizzati anche come opportunità di miglioramento dello stato di sicurezza mettendo a confronto un profilo attuale (profilo corrente), con il profilo desiderato (profilo target).

IMPLEMENTATION TIER

Gli Implementation Tier forniscono contesto sul livello di avanzamento e integrazione dei processi di gestione del rischio cyber.

I livelli di implementazione del framework (“tiers”) descrivono, infatti, il grado delle pratiche di gestione del rischio di cybersecurity di un’organizzazione. I Tier caratterizzano le pratiche di un’organizzazione su un intervallo, da Partial (Tier 1) ad Adaptive (Tier 4).

Durante il processo di selezione del Tier, un’organizzazione deve considerare le sue attuali pratiche di gestione del rischio, l’ambiente delle minacce, i requisiti legali e normativi, gli obiettivi di business/missione e i vincoli organizzativi. In questo modo completa la sua configurazione (attuale o desiderata).

In sintesi

Ogni organizzazione può applicare il framework FNCS selezionando le Subcategory di interesse (all’interno di function/category) e costruendo così il proprio Profile.

A questo punto, associando i livelli di Implementation è possibile definire la postura di cybersecurity attuale e quella che si intende raggiungere (target).

Completata l’applicazione, non resta che avviare le procedure operative.

Pronto per partire?

La tua organizzazione è pronta? Continua a seguirci perché nei prossimi articoli continueremo ad approfondire l’argomento ed entreremo nel dettaglio di ciascuna procedura !

Interessato ? Dubbi ? Contattaci !