L’implementazione della NIS2 in Italia ha costretto molte organizzazioni a rivedere in profondità i loro modelli operativi, soprattutto in relazione alla mappatura degli asset. Tra queste, i sistemi informativi trasversali, come ERP, IAM, SOC, cloud e piattaforme comuni, assumono un ruolo cruciale se abilitano servizi a impatto elevato.

La sfida della categorizzazione

La prima fase dell’applicazione della NIS2 ha obbligato le organizzazioni a identificare e categorizzare i servizi in base all’impatto. Questo processo sembrava essere un esercizio puramente amministrativo, ma in realtà ha aperto una riflessione molto più complessa. La categoria assegnata ai servizi non è isolata, ma dipende dall’apprezzamento operativo, tecnologico, informativo e contrattuale.

Il problema cruciale sorse quando si passò dal servizio all’asset. Molti servizi rilevanti dipendono da sistemi condivisi che svolgono molteplici funzioni. Questo ha portato a un dibattito: può un sistema comune, utilizzato per funzioni meno rilevanti, essere ritenuto critico se abilita un servizio a impatto alto?

Il concetto di asset trasversali

Un asset trasversale è un sistema che non può essere associato in modo diretto a un unico servizio, ma è condiviso da funzioni diverse. Se quel sistema abilita un servizio critico, automaticamente assume una rilevanza regolatoria elevata. La NIS2 insieme alle disposizioni ACN spinge a considerare le dipendenze operative e il potenziale impatto su riservatezza, integrità e disponibilità.

Criteri e valutazioni di impatto

I sistemi informativi critici non devono essere definiti per definizione, ma devono essere giustificati in base all’esposizione ad un servizio ad alto impatto. Non si tratta, quindi, di elevare a un livello massimo ogni sistema condiviso, ma di evitare di sottovalutare sistemi apparentemente secondari in base alla loro funzione meno critica.

Il criterio dell’impatto maggiore richiede quindi di considerare il servizio più sensibile che un determinato asset abilita. Se un sistema è condiviso, con diverse configurazioni o ambienti interni a diversi livelli di resilienza, le sue proprietà devono essere documentate per supportare una valutazione del rischio coerente.

La Business Impact Analysis al centro della NIS2

La Business Impact Analysis (BIA) diventa un’analisi fondamentale. Si tratta di mappare non solo la capacità operativa di ripresa (RTO) e la quantità massima di dati che possono essere persi (RPO), ma di capire chi governa un servizio, quali applicazioni lo abilitano, che infrastrutture lo sostengono, e che processi ne dipendono.

I sistemi critici: esempi concreti

L’ERP

Nei contesti aziendali, lo stesso sistema ERP è usato per molti processi: contabilità, logistica, gestione ordini, acquisti. Tuttavia, se uno di questi processi sostiene un servizio a impatto alto, l’ERP non può essere classificato solo come un sistema “corporate general purpose”.

Identity and Access Management (IAM)

Gli IAM sono la porta d’ingresso dell’intero ecosistema applicativo. Se abilitano l’accesso a applicazioni a impatto diverso, il loro livello di sicurezza deve essere valutato in base al servizio più esposto.

I SOC, le piattaforme di monitoraggio e gli ambienti cloud

Il SOC, le piattaforme SIEM, EDR/XDR, gli strumenti di log e di monitoraggio, non sono solo strumenti di controllo. Se monitorano sistemi che abilitano servizi critici, la loro indisponibilità o malfunzionamento metterà a rischio l’adempimento obbligatorio in tema di detection e gestione degli incidenti.

Gli ambienti cloud e le infrastrutture comuni (landing zone, API gateway, secrets management, firewall centralizzati, ecc.) sono anch’essi asset trasversali. Nonostante siano percepiti come servizi generali, sono fondamentali per la continuità operativa e devono essere mappati in base alle loro dipendenze.

La scadenza e la prospettiva futura

Il 30 giugno 2026 è la scadenza per la categorizzazione definitiva. Ma quella data non chiude l’argomento; anzi lo apre sul piano dell’attuazione concreta. L’organizzazione dovrà dimostrare che i servizi categorizzati corrispondono ad un perimetro coerente di sistemi, infrastrutture, fornitori e controlli di sicurezza.

Da qui emerge il significativo ruolo evolutivo della Business Impact Analysis, che non va limitata alle tradizionali logiche ISO 22301. Essa diventa uno strumento fondamentale per trasformare una mera classificazione formale in una base decisionale per la gestione del rischio informatico.

Qualità vs. arbitrio: il rischio senza BIA

Senza una BIA ben documentata, la classificazione degli asset informativi può diventare arbitraria. Da una parte si potrebbe sovrastimare la rilevanza di asset non critici, aumentando i costi e disorientando le priorità di sicurezza.

Dall’altra si rischia di sottovalutare asset apparentemente secondari, che in realtà sono fondamentali per mantenere operativi servizi NIS. L’assenza di una mappatura chiara e documentabile rende quindi l’organizzazione vulnerabile alle richieste di conformità e all’adempimento regolatorio.

Verso una cultura di conformità basata sul rischio

La NIS2 non è una semplice checklist di controlli da attivare. Essa richiama una cultura di conformità che va ben oltre la mera adozione tecnica di misure. Chiara, coerente, basata sul rischio e supportata da documentazione, essa è l’unico modo per garantire un’implementazione sostenibile e rispettosa dei principi di proporzionalità e di effettività.