Un'organizzazione complessa e articolata che lavora su più sedi
Avevamo davanti a noi una sfida importante: mappare tutti i processi aziendali di un gruppo industriale italiano attivo nell’automazione industriale e nell’impiantistica elettrica, qualificato come soggetto importante ai sensi del D.lgs. 138/2024, con più sedi operative e alcune centinaia di dipendenti, per comprenderne le dipendenze e definire, servizio per servizio, i tempi di ripristino richiesti dal business.
Il gruppo progetta, produce, collauda e mette in servizio quadri elettrici e sistemi di automazione per clienti italiani ed esteri. Accanto all’impiantistica, sviluppa piattaforme digitali proprietarie ospitate su cloud pubblico: tra queste, una piattaforma di monitoraggio remoto che rappresenta l’unico presidio di allarme per impianti dei clienti privi di supervisione umana.
Il team di BSD si è concentrato inizialmente su alcune domande, rivolte a ciascun responsabile di servizio e di funzione
Fin da subito ci siamo orientato verso un approccio service-driven. Volevamo evitare a tutti i costi che la Business Impact Analysis (BIA) fornisse solo una fotografia della tecnologia esistente, senza parlare la lingua del business. Chiedere al reparto IT in quanto tempo si ripristina un sistema produce una stima della attuale capacità dei sistemi; chiedere a ciascuna funzione per quanto tempo può lavorare senza quel sistema produce invece un requisito, radicato nelle prassi aziendali e nelle interdipendenze tra le varie funzioni.
-
01Quali servizi eroga davvero l'organizzazione, e quali sono legati al suo core business, quali li abilitano, quali li supportano?
-
02Per quanto tempo il servizio può proseguire in modalità alternativa, senza sistemi tecnologici attivi, e con quale degrado?
-
03Quale servizio ne alimenta un altro, con quali tipologia di dipendenza?
-
04Quanti dati può permettersi di perdere ciascuna funzione, e da quali fonti è in grado di riscostruirli?
-
05Oltre quale soglia il danno sfocia in scenari gravi quali penali, perdita della commessa, impianti dei clienti senza presidio, rischi per le persone?
-
06Chi garantisce, e sulla base di quale contratto o documento tecnico, i tempi di ripristino dei sistemi che sostengono ciascun servizio?
Le sfide
Il progetto presentava tre rischi principali.
-
01Le reali esigenze del businessIl primo era quello di affidarsi a quello che la tecnologia era in grado di sostenere in termini di ripristino, senza verificare le reali esigenze di business. L’organizzazione disponeva di due centri di elaborazione dati ridondati, cioè in grado di subentrare l’uno all’altro in caso di guasto. Il reparto IT stimava di poter ripristinare i sistemi più critici in una o due ore. Quella stima, però, non era mai stata verificata con una prova di ripristino documentata (il cosiddetto test di disaster recovery). Né era stato valutato alcuni impatto su un possibile disservizio, ragionando per singoli servizi.
-
02Le priorità di ripristinoIl secondo era quello di stabilire le priorità di ripristino in base all’importanza apparente dei servizo, in relazione al core business aziendale. In realtà il servizio meno tollerante all’interruzione non era la produzione, ma la piattaforma di monitoraggio remoto degli impianti dei clienti. Il suo MTD (Maximum Tolerable Downtime, la durata massima dell’interruzione oltre la quale il danno diventa inaccettabile) era di 12 ore, contro, ad esempio, gli 8 giorni lavorativi della produzione.
-
03I requisiti del businessIl terzo era quello di confondere i requisiti del business con gli impegni contrattuali dei fornitori. I tempi di ripristino indicati nella BIA esprimono un’esigenza dell’organizzazione. I tempi garantiti dai fornitori, invece, sono fissati nei contratti attraverso gli SLA (Service Level Agreement, gli accordi sui livelli di servizio). Prima vanno definiti i requisiti di business, poi va compreso se i fornitori presentano dei parametri compatibili con le esigenze di ripristino aziendali.
La soluzione
La prima scelta è stata partire dai servizi, non dai sistemi.
-
01Il catalogoAbbiamo costruito con il cliente il catalogo dei servizi, classificandoli in CORE (legati direttamente alla missione aziendale), CRITICI (che abilitano i servizi CORE) e di SUPPORTO, e per ciascuno abbiamo predisposto una scheda servizio con oltre 30 campi, per comprendere: utenti, processi, applicativi, dati trattati, dipendenze umane, infrastrutturali, logiche ed esterne, impatti, modalità alternative, presidi esistenti.
-
02Schede pre-compilateAl fine non appesantire le sessioni con il cliente, abbiamo precompilato le schede con ipotesi motivate, fondate sulle prime rilevazioni, sulle buone prassi del settore e sulle fonti pubbliche, astenendoci dal fornire presunzioni laddove mancavano basi sufficienti. Le ipotesi sono state poi verificate e corrette in oltre 30 ore di audit con ciascun responsabile di servizio e di funzione: è in quella sede che sono emerse le dipendenze tecnologiche, umane e fra funzioni, e le prassi effettive con cui l'organizzazione già assorbiva determinati interruzioni di servizio
-
03Ricavare ogni parametro da driver espliciti e verificabiliRTO, RPO e MTD non sono stati stimati per analogia, ma derivati da quattro driver: la sostenibilità del workaround non tecnologico orienta l'RTO; la posizione del servizio nella catena della commessa rende più stringente il requisito dei servizi che alimentano un punto di blocco; la ricostruibilità del dato determina l'RPO; il punto di non ritorno del danno fissa l'MTD. Ogni valore è riconducibile a specifici driver ed è accompagnato dalla motivazione dei punteggi d'impatto su cinque dimensioni, così da poter essere discusso, difeso e riesaminato, anche per fini di accountability. I valori della BIA sono stati qualificati come requisiti del business, non come livelli di servizio né come capacità dei sistemi.
-
04Il ruolo di ONITAbbiamo poi condiviso la metodologia con Onit Sistemi, il nostro partner tecnologico; ne abbiamo recepito i rilievi in un confronto congiunto: in questo modo abbiamo verificato che l'RTO richiesto dal business fosse superiore a quello garantito dalle soluzioni tecnologiche, così da preservare un margine prima dell'MTD.
La continuità operativa si progetta a partire dalle esigenze di ripristino del business e dalla capacità inerente di assorbire un disservizio.Separare l’RTO richiesto dal business da quello garantito con le soluzioni tecniche, prevedendo che il secondo resti inferiore al primo, trasforma quel margine in un vero parametro di resilienza dell’organizzazione.
Il nostro intervento
+ 30 ore di audit, + 10 funzioni coinvolte
-
01AUDIT SERVICE-DRIVENCatalogo dei servizi e schede servizio validateAbbiamo censito 16 servizi (5 CORE, 7 CRITICI, 4 di supporto) e definito per ciascuno un responsabile. Le schede sono state compilate con profondità proporzionata alla categoria: integrale per i servizi CORE, quasi integrale per i CRITICI, semplificata per quelli di supporto, con attenzione a dati, impatti e tolleranze. Le ipotesi preliminari sono state verificate in audit e integrate con le risposte del responsabile IT. L'audit ha portato alla luce quelle prassi che nessun inventario tecnico avrebbe mostrato. Dove i profili di ripristino non erano omogenei, abbiamo scomposto il servizio: i 16 servizi iniziali si sono tramutati in 18 unità di analisi.
-
02PARAMETRI DI BUSINESSRTO, RPO e MTD derivati da quattro driverPer ogni unità abbiamo definito RTO (tempo entro cui il business richiede il ripristino), RPO (massima perdita di dati tollerabile) e MTD (tolleranza massima all'interruzione, oltre la quale il danno cambia natura), con valori espressi in ore e giorni lavorativi. Gli impatti sono stati valutati su cinque dimensioni (operativa, economica, normativa, reputazionale, persone) con una scala da 1 a 4 e una motivazione esplicita per rafforzare l’accountability. Le unità sono state raggruppate in quattro classi di RTO (fino a 8 ore, a 24 ore, a 72 ore, oltre 72), che orientano l'ordine di ripristino. Per ciascuna abbiamo calcolato la curva degli impatti nel tempo, da 4 ore a 15 giorni, in assenza di misure di continuità, secondo il metodo della ISO/TS 22317.
-
03ALLINEAMENTO CON IL PARTNER TECNICOL’importanza di una sinergia effettiva con il partnerAbbiamo condiviso la metodologia con Onit Sistemi S.r.l., partner tecnico del percorso, e ne abbiamo discusso i rilievi in un incontro dedicato. Le decisioni assunte hanno reso il modello più solido: l'MTD resta nella BIA come parametro di documentazione del sistema di continuità, e accanto a RPO e RTO indicati dal business abbiamo identificato delle SLA compatibili. Il margine fra RTO e SLA garantito dai servizi gestiti da Onit Sistemi, diventa così un parametro di progetto: quando il secondo è inferiore al primo, l'organizzazione dispone del tempo necessario per gestire l'imprevisto senza avvicinarsi al punto di non ritorno.
-
04DALLA BIA ALLA REMEDIATIONGap, direttive e avanzamento condivisoL'analisi ha documentato 20 gap, in parte emersi dal confronto fra requisiti e presidi esistenti, in parte corroborati dalla Gap Analysis NIS2 già svolta: dai backup del magazzino automatizzato, eseguiti con cadenza giornaliera a fronte di un RPO richiesto di 12 ore, alla necessità di una prova di disaster recovery che verifichi i tempi di ripristino stimati. Le direttive derivate dalla BIA sono state integrate con le azioni della Gap Analysis NIS2 in un piano di remediation unificato di 57 azioni, ricondotte alle misure di sicurezza dell'art. 24 del D.lgs. 138/2024 o ai requisiti della BIA, che BSD e il reparto IT aggiornano a ogni stato di avanzamento. La BIA sarà inoltre la base su cui saranno redatti le politiche NIS2 e i piani di continuità operativa, disaster recovery e gestione delle crisi.
Le sfide
Cosa abbiamo prodotto concretamente
-
Deliveralbe 01Catalogo dei servizi16 servizi classificati in CORE, CRITICI e di supporto secondo criteri condivisi, ciascuno con il proprio responsabile e le prime informazioni su applicativi e dipendenze.
-
Deliveralbe 02Schede servizio BIAUna scheda per ciascun servizio, con oltre trenta campi (in versione semplificata per i servizi di supporto) verificati in audit con i responsabili di funzione: processi, applicativi, dati, dipendenze umane, tecnologiche ed esterne, impatti, workaround, presidi esistenti e logica di derivazione di RTO, RPO e MTD per motivare tali parametri.
-
Deliveralbe 03Business Impact AnalysisDocumento operativo per il reparto IT e il partner tecnico: requisiti di protezione per 10 sistemi con RTO e RPO e le colonne predisposte per le SLA garantite contrattualmente, così da avere un rapido raffronto e valutare il margine esistente tra i valori.
-
Deliveralbe 04Metodo BIA condivisoProcedura, checklist di audit e definizioni condivise con il partner tecnico: driver dei parametri, natura dei valori, ripartizione delle responsabilità e terminologia, che saranno la nostra metodologia per tutti i futuri progetti NIS2.
-
Deliveralbe 05Piano di remediation unificato57 azioni dalla Gap Analysis NIS2 e dalla BIA, con priorità, responsabile, riferimento alla misura e stato di attuazione, utilizzato come strumento di avanzamento fra BSD e reparto IT.
Quanto tempo può fermarsi la tua azienda prima che l'interruzione diventi un danno?
La continuità operativa non si costruisce partendo dalla tecnologia, ma dalle esigenze del business. Con una Business Impact Analysis puoi individuare i servizi critici, definire le priorità di ripristino e trasformare i requisiti NIS2 in un piano concreto di resilienza.