La sicurezza misurabile nasce da un atto di conoscenza: comprendere che cosa è davvero critico per l’organizzazione e quanto tempo può restare fermo senza compromettere la continuità dei servizi essenziali.

La Business Impact Analysis (BIA) è il cuore di questo processo e serve a generare i parametri che alimentano gli obiettivi di servizio, i contratti di continuità e le soglie di allerta che attivano il rilevamento.

Ecco come i parametri/valori della BIA – MTD, RTO, RPO e MBCO – diventano la matrice logica dei livelli di servizio (SL). La loro definizione consente di trasformare la teoria della resilienza in prassi di governo.

Logica della Business Impact Analysis (BIA)

Ogni infrastruttura digitale vive su un equilibrio precario: quello tra tempo e impatto. La domanda vera non è “se” si verificherà un’interruzione, ma “quanto a lungo” l’organizzazione potrà reggere senza subire danni irreversibili interni e/o verso i propri clienti.

È questa la logica della Business Impact Analysis (BIA), che non è un esercizio contabile né una tabella di tempi tecnici, ma un metodo per riconoscere la soglia oltre la quale un evento diventa perdita.

Nel modello organizzativo NIS 2 (Monis), la BIA non è più un requisito opzionale o accessorio ma il punto di partenza di tutto il sistema di misurazione.

Senza una BIA aggiornata e documentata, i livelli di servizio (SL) sono numeri inventati e senza livelli di servizio, non si può rilevare un incidente significativo.

La direttiva NIS 2 lega dunque la prevenzione alla misurazione e la misurazione alla conoscenza dell’impatto.

Business Impact Analysis (BIA) come strumento di governo

La BIA, nella prospettiva della continuità operativa e della sicurezza, è un processo di conoscenza che mette in relazione persone, processi e servizi con la loro funzione sociale o produttiva.

Serve a rispondere a due domande fondamentali:

• quali processi devono essere mantenuti per garantire la missione dell’organizzazione;
• quanto tempo e quante risorse servono per ripristinarli.

In questo senso, la BIA è un atto strategico della politica aziendale, prima ancora che tecnico.

Definire quali servizi sono “critici” significa assumere una responsabilità di priorità mentre attribuire a ciascun servizio un valore di impatto significa prendere coscienza di quanto vale la sua interruzione per la collettività o per il sistema economico.

I parametri della BIA: il linguaggio del tempo e della soglia 1

Ogni BIA ben costruita genera quattro parametri fondamentali, che costituiscono il linguaggio operativo della resilienza:

• MTD (Maximum Tolerable Downtime): il tempo massimo tollerabile di interruzione oltre il quale l’impatto diventa insostenibile;
• RTO (Recovery Time Objective): il tempo massimo entro cui il servizio deve essere ripristinato per evitare di superare l’MTD;
• RPO (Recovery Point Objective): la quantità massima di dati che si può perdere (in termini temporali) senza incorrere in un danno inaccettabile;
• MBCO (Minimum Business Continuity Objective): il livello minimo di prestazione che consente di continuare a operare anche in condizioni degradate.

Non formule astratte, ma decisioni di governo

Questi parametri stabiliscono le soglie di continuità che ogni unità organizzativa deve rispettare e rappresentano la base per la contrattualizzazione con fornitori e partner.
Un elemento di complessità è rappresentato dal fatto che per ogni servizio devono essere definiti valori specifici.

Quindi non esistono necessariamente valori che soddisfano ogni servizio, ma per ogni servizio devono essere definiti i valori di resilienza.

Dalla BIA ai livelli di servizio (SL): la trasformazione della conoscenza in misura

La misura/subcategoria DE.CM-01 richiamata nel capitolo 3 delle Linee guida – Specifiche di base di Acn e tradotta dalla stessa Acn in “requisiti” operativa, chiede di definire (e documentare) i livelli di servizio (SL). Non spiega però come calcolarli ed è un bene.

Se imponesse anche il metodo di calcolo, costringerebbe tutte le organizzazioni a usare lo stesso modello, cancellando le loro specificità e quelle dei servizi che offrono.
È qui che entra in gioco la BIA: serve proprio a fornire i dati concreti che trasformano un requisito generale in un parametro misurabile e adatto alla singola realtà.

Qualche esempio concreto

Se la BIA stabilisce che il processo di erogazione dei pagamenti non può restare fermo oltre 4 ore (RTO), il livello di servizio di disponibilità del sistema contabile dovrà garantire un ripristino entro 3 ore, lasciando margine di sicurezza.

Invece, se la quantità massima di dati che si può perdere è quella accumulata in 15 minuti (RPO), il livello di servizio del backup dovrà assicurare repliche almeno ogni 10 minuti.

Se il livello minimo di prestazione che consente di continuare a operare anche in condizioni degradate è fissato al 70% della capacità operativa (MBCO), i piani di emergenza dovranno prevedere modalità di servizio degradato compatibili con tale valore.

Ovvero configurazioni operative ridotte o semplificate che permettono di mantenere attive le funzioni essenziali del servizio, quando non è possibile garantire la piena capacità operativa.

Così, il dato tecnico diventa una soglia di sicurezza.

Dalla soglia alla governance: SLA, SLI e responsabilità

Una volta ricavati i livelli di servizio (SL) dai valori della BIA, occorre trasformarli in strumenti di governance.

Ecco che qui entrano in gioco:

• gli SLA (Service Level Agreement), che fissano gli obiettivi contrattuali verso clienti e fornitori;
• gli SLI (Service Level Indicator), che misurano effettivamente le prestazioni rispetto agli SLA.

In sostanza, gli SLA traducono le soglie della BIA in impegni formali, mentre gli SLI le rendono misurabili e tracciabili.

Questa architettura è essenziale non solo per gestire la continuità, ma anche per dimostrare la conformità alla NIS 2.

Nel nuovo paradigma normativo, infatti, la resilienza non va dichiarata, deve essere dimostrabile.

Un esempio operativo: la catena della disponibilità

Immaginiamo un fornitore di servizi cloud (che per il tipo di servizio fornito rientra nel perimetro della NIS 2) che opera per un soggetto essenziale NIS.

Il cliente richiede contrattualmente una disponibilità del 99,9% e un RTO di 2 ore.
Il fornitore, per rispettare questi parametri, deve, a sua volta, ottenere dai propri carrier di rete (fornitori), SLA che siano coerenti.

Per esempio, un ripristino delle linee entro un’ora ovvero con un margine di sicurezza adeguato rispetto alle richieste del cliente.

Il monitoraggio continuo di questi valori consente di individuare subito, sia da parte del fornitore sia del cliente, l’eventuale superamento di una soglia, grazie a strumenti di controllo in tempo reale.

Quando il tempo di inattività supera il valore concordato, l’evento non è solo un disservizio, ma può costituire un incidente significativo ai sensi del criterio IS-3 indicato dalle linee guida – specifiche di base dell’ACN.

In questo modo, la BIA del cliente, tradotta in SLA del fornitore, diventa la matrice della rilevazione e della notifica.

Due prospettive della stessa logica

La BIA e i livelli di servizio non sono documenti distinti, ma due prospettive della stessa logica.

La prima conosce l’impatto, i secondi lo misurano nel tempo. Solo integrando questi due strumenti si può costruire un sistema capace di prevenire, rilevare e comunicare con tempestività.

Nel prossimo capitolo di questa tetralogia, vedremo come il monitoraggio dei livelli di servizio si trasforma nel motore operativo della notifica NIS 2 e come la violazione di uno SLA possa costituire la prova oggettiva di un incidente significativo.

Bibliografia

Per approfondimenti su questi temi si rinvia al capitolo 3 della Parte quarta – Integrazione fra la NIS 2 e il D.lgs. 138/2024 con la ISO 22301:2016 – del Manuale “Il Modello organizzativo NIS 2 (MONIS)” di Giuseppe Alverone e Monica Perego – Ed. Simone Professionale.