Quasi tutte le organizzazioni hanno i backup. Pochissime sanno quanto tempo impiegherebbero davvero a riprendere l'operatività dopo un'interruzione grave, o quali processi ripristinare per primi. Quel divario, tra avere i backup e avere la continuità, è esattamente ciò che la ISO 22301 mette in ordine. In questo articolo spiego che cosa richiede la norma, come condurre un'analisi d'impatto davvero utile per decidere, che cosa significano RTO e RPO quando in gioco c'è denaro, perché un piano mai testato non conta e come tutto questo si integra con ciò che ISO 27001, NIS 2 e DORA già Le chiedono.

Che cos'è la ISO 22301 e quale problema risolve

La ISO 22301:2019 è la norma internazionale per i sistemi di gestione della continuità operativa. Non è un manuale di ripristino IT: è un quadro con cui un'organizzazione identifica quali attività non può permettersi di perdere, per quanto tempo, e che cosa ha pronto per sostenerle quando qualcosa si guasta.

La differenza rispetto a un piano di disaster recovery è di perimetro e di finalità. Il ripristino guarda ai sistemi; la continuità guarda al business: persone, sedi, fornitori, processi e dati. Un data center replicato non vale nulla se il team che gestisce il processo critico non può lavorare e nessuno ha deciso chi dichiara la crisi.

Come le altre norme sui sistemi di gestione, segue la struttura di alto livello dell'Annex SL, con i capitoli su contesto, leadership, pianificazione, supporto, attività operative, valutazione delle prestazioni e miglioramento. Se la Sua organizzazione lavora già con la ISO 27001, lo scheletro Le risulterà familiare e gran parte del sistema potrà essere riutilizzata.

La BIA: dove si decide tutto il resto

L'analisi d'impatto sul business, o BIA, è il pezzo che regge il resto della norma. È lì che si risponde a una domanda scomoda: se questa attività si ferma, che cosa succede e da quando comincia a fare male.

Una BIA utile per decidere misura l'impatto nel tempo, non in un solo istante. La stessa interruzione di un servizio di fatturazione può essere irrilevante per due ore, fastidiosa a otto e grave dopo tre giorni, quando arrivano le scadenze di pagamento. Quel profilo temporale è ciò che poi fissa priorità e budget.

Una BIA ben condotta produce tre cose che userà ovunque: le attività prioritarie, il periodo massimo tollerabile di interruzione per ciascuna e le risorse minime necessarie per sostenerle, compresi i fornitori da cui dipende senza averlo mai messo per iscritto.

L'errore più comune che vedo nei progetti è condurre la BIA per reparto invece che per attività. Un reparto non si interrompe: si interrompe un processo, e quasi sempre attraversa più reparti e un fornitore esterno.

RTO e RPO, spiegati con un caso

Sono i due numeri che governano l'investimento, e vengono confusi di continuo. Conviene fissarli con un esempio.

Immagini uno studio che elabora le buste paga. L'RTO, recovery time objective, è per quanto tempo il servizio può restare fermo prima che il danno diventi inaccettabile: diciamo otto ore lavorative. L'RPO, recovery point objective, è quanti dati ci si può permettere di perdere, misurati in tempo: se il backup viene eseguito di notte, l'RPO è di ventiquattro ore, e questo significa che un guasto alle sei di sera cancella un'intera giornata di lavoro che dovrà essere rifatta a mano.

La conseguenza pratica è diretta: abbassare l'RPO costa tecnologia (replica, backup più frequenti) e abbassare l'RTO costa preparazione (ambienti di riserva, procedure provate, persone formate). Portarli entrambi a zero è una fantasia costosa, e fissarli senza una BIA è tirare a indovinare.

C'è un terzo numero che viene dimenticato e che decide se gli altri due sono credibili: il periodo massimo tollerabile di interruzione. Se l'RTO che ha fissato lo supera, il piano non protegge nulla: documenta soltanto quando fallirà.

Dalla strategia a un piano che qualcuno esegue davvero

Fissati gli obiettivi, la norma Le chiede di scegliere le strategie di continuità e di tradurle in procedure concrete. Le opzioni abituali sono sostenere l'attività altrove, degradarla a una modalità manuale concordata, trasferirla a un terzo o accettare il rischio in modo esplicito e per iscritto.

Accettare il rischio è una risposta legittima, e vale la pena dirlo, perché la paura di metterlo per iscritto porta a inventare piani che nessuno eseguirà mai. Ciò che non è legittimo è non aver deciso.

Sul fronte del piano, ciò che separa un piano utile da uno decorativo è che risponde a quattro domande senza che nessuno debba interpretare nulla: chi decide di attivarlo, chi viene avvisato e attraverso quale canale quando la posta aziendale è proprio ciò che non funziona, che cosa succede nelle prime due ore e come si torna alla normalità, che è la parte che manca quasi sempre.

Desidera certificarsi come ISO 22301 Lead Implementer?
Formazione ufficiale PECB con un consulente in attività, al Suo ritmo o con accompagnamento individuale, che si svolge in inglese.

Vedere il corso →Parlare con Ricardo

Un piano mai testato non è un piano

È qui che i sistemi di gestione che funzionano si separano da quelli che esistono solo in una cartella. La norma richiede un programma di esercitazioni e test, e non come formalità: un piano mai eseguito contiene, senza eccezioni, ipotesi false.

Le esercitazioni vanno dal leggero al pesante e non occorre cominciare dalla più costosa: revisione a tavolino, esercitazione tabletop con i veri responsabili, simulazione di un componente specifico e, infine, un test con failover reale. Ogni livello fa emergere cose diverse.

Ciò che emerge quasi sempre nella prima esercitazione tabletop: il numero di telefono che non appartiene più a nessuno, il backup che si ripristina ma impiega il triplo del tempo previsto e il fornitore critico il cui contratto non prevede alcun impegno di ripristino. Nessuna delle tre cose si scopre leggendo il piano.

Il valore dell'esercitazione non è superarla. È l'elenco di ciò che è andato storto, con un responsabile e una data dietro ogni riga.

La continuità non si dimostra il giorno dell'incidente: si dimostra il giorno dell'esercitazione. Chi ha solo il documento scopre le proprie ipotesi false nel momento peggiore, e con i clienti che guardano.

Come si integra con ISO 27001, NIS 2 e DORA

È la parte che conta di più per chi è già dentro un programma di conformità, perché evita di pagare due volte lo stesso lavoro.

Con la ISO/IEC 27001 la sovrapposizione è sostanziale: struttura di alto livello condivisa, analisi del contesto, informazioni documentate, audit interno e riesame della direzione. Ciò che la ISO 27001 tratta come un singolo controllo, la continuità, la ISO 22301 lo sviluppa come un sistema completo.

La NIS 2 la richiede esplicitamente: tra le misure del suo articolo 21 c'è la continuità operativa, compresa la gestione dei backup, il ripristino in caso di disastro e la gestione delle crisi. Un sistema conforme alla ISO 22301 è il modo più ordinato per dare evidenza di quel blocco a un'autorità.

E per le entità finanziarie, DORA va ancora oltre: richiede una politica di continuità operativa ICT, piani di risposta e ripristino e test periodici con risultati documentati. I concetti sono gli stessi e il lavoro è quasi interamente riutilizzabile.

In un progetto reale questo significa che la BIA condotta per la ISO 22301 sosterrà le decisioni negli altri tre quadri. Vale la pena farla bene una volta sola.

Formazione e certificazione

Se desidera passare alla certificazione ufficiale PECB, ci sono tre livelli a seconda di ciò di cui ha bisogno. ISO 22301 Foundation per padroneggiare il quadro e il vocabolario. Lead Implementer se costruirà il sistema di gestione. Lead Auditor se lo verificherà, per conto proprio o per un organismo di certificazione.

Tutti e tre possono essere seguiti in autoapprendimento, con il materiale ufficiale PECB e al Suo ritmo, oppure con accompagnamento in sessioni individuali con me, che si svolgono in inglese, se preferisce lavorare sul Suo caso anziché su un esempio da manuale.