Asset trasversali nella NIS2: il ruolo strategico della BIA

La prima stagione attuativa della NIS2 italiana ha obbligato molte organizzazioni a compiere un esercizio che, almeno in apparenza, sembrava amministrativo: elencare le attività e i servizi rilevanti e attribuire loro una categoria di impatto. In realtà, quell’adempimento è solo la parte visibile di un lavoro molto più profondo.

Sistemi condivisi nella NIS2: oltre la categorizzazione

La categoria assegnata a un servizio non vive infatti in astratto, ma dipende dalla capacità dell’organizzazione di comprenderne le dipendenze operative, tecnologiche, informative e contrattuali.

Il punto più delicato emerge quando si passa dal servizio all’asset. Un servizio può essere classificato come a impatto alto, medio, basso o minimo; ma il sistema che lo abilita raramente è dedicato a quel solo servizio. Nella pratica aziendale, soprattutto nei gruppi societari, nelle organizzazioni multi-sito e nelle infrastrutture informatiche centralizzate, i sistemi sono condivisi: lo stesso ERP può sostenere contabilità, logistica, acquisti, ciclo attivo e funzioni operative essenziali; lo stesso Identity and Access Management può abilitare applicazioni critiche e non critiche; lo stesso SOC può monitorare perimetri diversi; la stessa piattaforma cloud può ospitare ambienti produttivi, applicazioni documentali e servizi di supporto.

Da qui nasce il problema degli asset trasversali. Un sistema informativo apparentemente comune, perché utilizzato da molte funzioni e non riconducibile a un solo servizio, può assumere una rilevanza regolatoria elevata proprio per effetto del servizio più critico che sostiene. La NIS2 italiana, letta insieme alle determinazioni ACN sulle misure di sicurezza e sulla categorizzazione, spinge le organizzazioni verso questa conclusione: non basta sapere che un asset è condiviso; bisogna sapere quali servizi abilita e quale sarebbe l’impatto della sua compromissione sulla riservatezza, integrità e disponibilità di quei servizi.

Impatto maggiore e sistemi condivisi: il perimetro da dimostrare

Il criterio dell’impatto maggiore può essere sintetizzato in modo semplice: se un sistema abilita più attività o servizi con categorie di rilevanza diverse, la sua criticità non dovrebbe essere determinata dalla funzione più ordinaria che svolge, ma dal servizio di maggiore impatto che sarebbe compromesso in caso di indisponibilità, alterazione o accesso non autorizzato. Non si tratta di trasformare ogni sistema condiviso in un asset massimo per definizione, ma di evitare l’errore opposto: considerare un sistema “generale” o “di supporto” e quindi sottostimarne il peso regolatorio.

La regola non deve essere applicata in modo meccanico. Una piattaforma comune può contenere segregazioni tecniche, domini separati, tenant distinti, controlli di accesso differenziati, ambienti con livelli di resilienza non omogenei. Questi elementi possono incidere sulla valutazione. Tuttavia devono essere dimostrati, documentati e ricondotti a una valutazione del rischio credibile. In assenza di evidenze, l’approccio coerente con la proporzionalità del rischio è considerare il sistema in base al maggiore impatto ragionevolmente derivante dalla sua compromissione.

Questo aspetto è particolarmente importante perché le misure di sicurezza di base ACN usano spesso l’espressione “per almeno i sistemi informativi e di rete rilevanti”. La conseguenza pratica è evidente: prima ancora di chiedersi se un controllo sia implementato, l’organizzazione deve essere in grado di spiegare su quali sistemi esso si applica. E questa perimetrazione non può essere decisa solo dall’IT sulla base dell’inventario tecnico; deve discendere dal rapporto tra servizi NIS, processi aziendali, dipendenze tecnologiche, dati trattati e impatti di business.

ERP, IAM, SOC e cloud tra gli asset comuni della NIS2

Gli esempi sono numerosi. L’ERP è il caso più evidente. In molte imprese, lo stesso sistema governa processi amministrativi ordinari e processi che incidono sulla continuità di servizi NIS: pianificazione della produzione, gestione degli ordini, approvvigionamenti, magazzino, fatturazione, manutenzione, disponibilità di materiali o componenti essenziali. Se un processo a impatto alto dipende dall’ERP, non è sufficiente affermare che l’ERP è un sistema corporate general purpose. Occorre verificare quali moduli siano coinvolti, quali dati siano necessari, quali interfacce siano critiche, quali tempi di indisponibilità siano tollerabili e quali controlli debbano essere rafforzati.

Identità, monitoraggio e infrastrutture cloud

Lo stesso vale per i sistemi IAM. Un servizio digitale può essere resiliente dal punto di vista applicativo, ma diventare indisponibile se gli utenti, gli amministratori o i sistemi integrati non riescono ad autenticarsi. L’IAM è spesso la vera porta di ingresso dell’ecosistema applicativo. Se abilita l’accesso a servizi classificati con categorie differenti, il suo livello di criticità deve essere letto alla luce del servizio più esposto. La MFA, la gestione delle utenze privilegiate, la segregazione dei ruoli, il logging degli accessi amministrativi e il monitoraggio degli eventi di autenticazione non sono semplici controlli tecnici: sono misure che proteggono la capacità dell’organizzazione di continuare a erogare i propri servizi NIS.

Il SOC, il SIEM, le piattaforme EDR/XDR e gli strumenti di monitoraggio rappresentano un ulteriore caso di asset trasversale. Possono non essere, di per sé, il servizio finale dell’organizzazione, ma sono funzionali alla rilevazione tempestiva degli eventi, alla gestione degli incidenti, alla capacità di escalation e alla continuità della risposta. Se monitorano sistemi che abilitano servizi ad alto impatto, non possono essere trattati come strumenti accessori. La loro indisponibilità o cattiva configurazione può incidere direttamente sulla capacità di rispettare gli obblighi di detection, incident management e notifica.

Ancora più complesso è il caso degli ambienti cloud e delle infrastrutture comuni: landing zone, networking, backup, repository documentali, sistemi di orchestrazione, piattaforme di integrazione, API gateway, strumenti di secrets management, servizi DNS, firewall centralizzati, proxy, sistemi di posta e collaborazione. In molte organizzazioni questi componenti sono invisibili alla funzione di business, ma decisivi per la continuità operativa. La loro qualifica non può essere lasciata alla percezione di chi li considera “servizi generali”; deve derivare da una mappatura delle dipendenze.

BIA e sistemi condivisi dopo la scadenza del 30 giugno

La scadenza del 30 giugno 2026 per la categorizzazione non chiude il tema: lo apre sul piano dell’attuazione. Una volta comunicato l’elenco categorizzato, l’organizzazione deve essere in grado di dimostrare che la categoria assegnata ai servizi si traduce in un perimetro coerente di sistemi, applicazioni, infrastrutture, fornitori e misure. È qui che la Business Impact Analysis assume una funzione diversa da quella tradizionalmente associata alla sola continuità operativa.

La BIA non deve essere vista soltanto come uno strumento per definire RTO, RPO e priorità di ripristino in vista di un percorso ISO 22301. Nel contesto NIS2, essa diventa il metodo con cui collegare servizi, processi e asset, trasformando una classificazione formale in una base decisionale per la sicurezza informatica. Serve a capire quali processi sostengono un servizio NIS, quali dati sono indispensabili, quali applicazioni li trattano, quali infrastrutture li ospitano, quali fornitori li supportano, quali persone li governano e quali impatti deriverebbero da una compromissione.

Senza BIA, l’individuazione dei sistemi informativi e di rete rilevanti rischia di diventare arbitraria. Da un lato si può cadere nella sovraestensione, classificando come rilevante ogni asset per timore di errore, con conseguente aumento dei costi e perdita di priorità. Dall’altro si può cadere nella sottovalutazione, escludendo asset comuni che, in realtà, sono abilitanti per servizi critici. Entrambi gli errori compromettono il principio di proporzionalità: il primo per eccesso, il secondo per difetto.

Gruppi societari e BIA: responsabilità sui sistemi comuni

Nei gruppi societari il tema è ancora più rilevante. La società italiana soggetta alla NIS2 può dipendere da sistemi gestiti dalla capogruppo, da una service company interna, da un provider cloud, da un MSP o da un centro servizi estero. In questi casi, la BIA non può essere svolta solo dalla funzione IT centrale e non può essere svolta solo dalla società operativa. Deve essere condotta per tutte le aziende interessate, con prospettive differenti ma integrate.

La società che eroga il servizio NIS deve descrivere il proprio impatto di business: quali attività sono essenziali, quali tempi di indisponibilità sono accettabili, quali obblighi regolatori o contrattuali sarebbero violati, quali effetti si produrrebbero su clienti, utenti, pazienti, cittadini, filiere o controparti. La società o funzione che gestisce l’asset condiviso deve invece descrivere l’architettura, le dipendenze, i controlli, le segregazioni, le responsabilità operative, le finestre di manutenzione, le procedure di incident response e le modalità di ripristino. Il punto di incontro tra queste due prospettive è la matrice servizio-asset-impatto.

Questa matrice consente di evitare che la responsabilità si perda nella distanza tra chi usa il sistema e chi lo gestisce. Il soggetto NIS resta responsabile della propria conformità, ma per dimostrarla deve poter ottenere dal gestore dell’asset condiviso evidenze sufficienti: inventari, architetture, logiche di segregazione, livelli di servizio, piani di continuità, test di backup, controlli di accesso, monitoraggio, vulnerability management, procedure di change management e documentazione sui fornitori ulteriormente coinvolti.

Dai servizi NIS ai controlli sugli asset condivisi

L’utilità della BIA emerge soprattutto quando l’organizzazione deve applicare controlli concreti. Se una misura ACN richiede backup, logging, monitoraggio, MFA, hardening, gestione delle configurazioni, piani di continuità o procedure di ripristino per almeno i sistemi informativi e di rete rilevanti, la domanda preliminare diventa: quali sono questi sistemi? La risposta non può essere un semplice elenco CMDB, perché la CMDB descrive gli asset ma non sempre ne esprime l’impatto regolatorio. Serve una lettura per servizio.

Un database può essere tecnicamente identico ad altri, ma contenere dati indispensabili alla prosecuzione di un servizio a impatto alto. Un firewall può essere uno dei tanti apparati di rete, ma rappresentare il punto di transito obbligato per un servizio essenziale. Una piattaforma documentale può apparire amministrativa, ma contenere istruzioni operative, evidenze regolatorie, procedure di emergenza o documentazione indispensabile per il ripristino. Un sistema di ticketing può essere percepito come supporto interno, ma diventare essenziale se governa escalation, incident response e comunicazioni con fornitori critici.

Il passaggio dal servizio al controllo richiede quindi una tassonomia diversa da quella puramente tecnica. Per ogni asset occorre indicare almeno: i servizi NIS supportati, la categoria più elevata tra quelli supportati, il tipo di dipendenza, il livello di sostituibilità, l’impatto su riservatezza, integrità e disponibilità, il fornitore o owner operativo, i controlli già presenti, le lacune rispetto alle misure ACN e le eventuali ragioni per cui un asset comune non deve essere trattato come rilevante. Queste ragioni, se esistono, devono essere motivate: isolamento, segregazione, ridondanza effettiva, indipendenza funzionale, assenza di dati critici, possibilità di bypass operativo, oppure tempi di ripristino compatibili con l’impatto del servizio.

Classificare i sistemi condivisi senza sovraestendere i controlli

Il criterio dell’impatto maggiore non deve trasformarsi in una scorciatoia per classificare tutto al livello più elevato. Una simile scelta, apparentemente prudente, può produrre effetti indesiderati: aumento incontrollato del perimetro dei controlli, dispersione degli investimenti, roadmap non sostenibili, perdita di attenzione sugli asset davvero critici e difficoltà a dimostrare proporzionalità. La NIS2 non chiede di proteggere tutto allo stesso modo; chiede di proteggere in modo adeguato e proporzionato ciò che sostiene attività e servizi rilevanti.

Allo stesso tempo, è ancora più rischioso mantenere al livello minimo o basso gli asset condivisi solo perché non sono intestati a un servizio specifico. Nei gruppi, questa sottovalutazione può derivare da una separazione organizzativa: la società operativa conosce l’impatto del servizio ma non conosce l’architettura; la funzione IT centrale conosce l’architettura ma non sempre conosce la categoria regolatoria del servizio; il fornitore conosce il componente tecnico ma non l’impatto di business. La BIA serve precisamente a chiudere questa distanza.

La soluzione corretta sta nel mezzo: adottare il criterio dell’impatto maggiore come regola di default per gli asset realmente abilitanti, ma consentire riduzioni motivate quando l’analisi dimostra che il rischio è segregato, il servizio non dipende in modo sostanziale dall’asset oppure esistono soluzioni alternative realistiche e testate. Questa impostazione consente di trasformare la categorizzazione da esercizio dichiarativo a strumento di governance.

Governance cyber e sistemi condivisi nella NIS2

Il tema degli asset trasversali obbliga le organizzazioni a rivedere anche la governance. Non è sufficiente nominare un referente NIS, aggiornare un inventario o approvare una policy. Occorre definire chi decide la rilevanza di un sistema, chi valida le dipendenze, chi accetta le assunzioni, chi approva le eccezioni e chi aggiorna la matrice quando cambiano servizi, architetture o fornitori. In assenza di un processo stabile, la fotografia prodotta per la categorizzazione rischia di diventare rapidamente obsoleta.

La governance dovrebbe prevedere almeno tre livelli. Il primo è il livello business, che identifica servizi, processi, impatti e priorità. Il secondo è il livello tecnologico, che traduce quei servizi in asset, dipendenze e controlli. Il terzo è il livello di rischio e compliance, che verifica la coerenza con il decreto NIS, con le determinazioni ACN, con le misure di sicurezza di base e con gli obblighi verso fornitori e stakeholder. Solo l’integrazione di questi tre livelli consente di stabilire se un ERP, un IAM, un SOC o un ambiente cloud siano sistemi rilevanti e con quale priorità debbano essere oggetto di adeguamento.

In questa prospettiva, la BIA diventa un documento vivo. Deve essere aggiornata quando cambia il catalogo dei servizi, quando viene introdotto un nuovo applicativo, quando un servizio viene migrato in cloud, quando si centralizza una funzione, quando cambia un fornitore, quando un sistema prima locale diventa condiviso o quando una società del gruppo entra o esce dal perimetro NIS. La BIA non è un allegato statico alla business continuity: è la base informativa che rende difendibile il perimetro dei sistemi rilevanti.

Categorizzare le dipendenze per proteggere i servizi NIS

La NIS2 italiana ha introdotto un passaggio essenziale: non limitarsi a identificare i soggetti obbligati, ma comprendere quali attività e servizi abbiano un impatto rilevante per la sicurezza e la resilienza del Paese. Tuttavia, la categorizzazione dei servizi è solo il primo livello. Il secondo, più difficile e più operativo, è la categorizzazione delle dipendenze.

Nei sistemi informativi moderni, la criticità non coincide sempre con ciò che è visibile all’utente finale. Spesso si trova negli asset condivisi: identità digitali, reti, piattaforme cloud, strumenti di monitoraggio, sistemi documentali, applicazioni gestionali, servizi di integrazione, backup, logging e sicurezza. Sono questi asset a determinare se un servizio NIS possa continuare a funzionare, essere protetto e ripristinato.

Per questo, anche oltre la scadenza del 30 giugno 2026, le organizzazioni dovrebbero continuare a lavorare sulla BIA. Non come esercizio formale, ma come metodologia per individuare i sistemi informativi e di rete rilevanti, calibrare le misure ACN, motivare le priorità di investimento e documentare le scelte. Il criterio dell’impatto maggiore, applicato con rigore e supportato da evidenze, consente di evitare sia la sottovalutazione degli asset comuni sia l’estensione indiscriminata dei controlli. In definitiva, consente di fare ciò che la NIS2 richiede davvero: collegare la sicurezza informatica alla continuità dei servizi e alla responsabilità degli organi di governo.