Vai al contenuto

PR28.1 - Procedura di gestione della continuità operativa

Procedura di Gestione della Continuità Operativa

Revisioni
Rev. Data Descrizione Redatto Approvato
0.0 24/04/2026 Prima emissione CISO Amministratore Unico

Revisioni 1

Indice 2

1 Introduzione 3

1.1 Riferimenti e Allegati 3

1.2 Definizioni, Acronimi, Abbreviazioni 3

2 Continuità Operativa 4

2.1 Procedura Operatività Aziendale 4

2.2 Pianificazione 4

2.2.1 Identificazione scenari 4

2.2.2 Tipologie di eventi 5

2.2.3 Soluzioni a supporto degli eventi 6

2.3 Piani di Continuità Operativa 7

2.3.1 Implementazione 7

2.3.2 Monitoraggio 11

2.3.3 Manutenzione e miglioramento continuo 12

2.3.4 Esecuzione 12

Introduzione

Al fine di garantire la continuità della sicurezza delle informazioni, vengono definiti dei Piani di Continuità Operativa che identificano gli scenari maggiormente critici di interruzione dei processi e dei servizi ICT fondamentali all’attività dell’Azienda e dei suoi Clienti, nell’operatività giornaliera, e stabilisce le azioni che le funzioni aziendali coinvolte devono intraprendere al fine garantire la continuità delle attività operative critiche.

Una volta individuati i servizi ICT a supporto dell'erogazione dei processi di business ed analizzati, con l’aiuto dei vari Responsabili di Area, dal punto di vista degli impatti di eventi critici sull’operatività degli stessi, è possibile pianificare e preparare piani e soluzioni di Continuità Operativa al fine di stabilire a priori le principali azioni necessarie per far fronte ad una interruzione di tali servizi con possibili conseguenze economiche/finanziarie, normative e di immagine sui processi aziendali di business.

Le attività connesse con l’individuazione, l’implementazione e l’attivazione di un Piano di Continuità Operativa si svolgono con modalità e responsabilità definite, in modo da assicurare l’adeguatezza delle contromisure da attuare per impedire o comunque contenere interruzioni di servizio.

Il presente documento descrive la procedura per la definizione, descrizione e test di un nuovo Piano di Continuità Operativa o la dismissione di uno superato.

Riferimenti e Allegati

ALPR28.1.B – Disaster Recovery Plan

MDPR28.1.A – BIA_Business Impact Analysis

ALPR28.1.A – Piani di Continuità Operativa

MDPR28.1.B - Piano dei Test di Continuità Operativa

MDPR28.1.C – Report Test di Continuità Operativa

PO28 – Gestione della Continuità Operativa.

Definizioni, Acronimi, Abbreviazioni

BIA – Business Impact Analysis

ICT – Information and Communication Technology

RPO – Recovery Point Objective

RTO – Recovery Time Objective.

Continuità Operativa

La procedura identifica le risorse e i processi/servizi aziendali, in particolare i servizi ICT a supporto del business, che sono fondamentali per il funzionamento dell’Azienda stessa, valuta l'impatto che un'improvvisa interruzione di tali servizi di base potrebbe avere sul business operativo giornaliero e stabilisce il momento giusto per il loro ripristino a seguito dell’emergenza.

Procedura Operatività Aziendale

L’Azienda definisce l’organizzazione delle attività e le relative responsabilità al fine di garantire sempre l’operatività aziendale. Tutto questo può essere suddiviso in due ambiti e momenti diversi:

  • responsabilità durante le normali attività di gestione – normal state;

  • organizzazione a seguito di uno stato di crisi dichiarato – crisis state.

Durante il “normale state”, l’Azienda opera secondo i ruoli, le responsabilità ed in base alle competenze del personale, come definito dall’organigramma aziendale e dal mansionario.

Durante il “crisis state”, l’Azienda definisce l’operatività con le seguenti modalità:

  • il personale addetto, formato sulle procedure da mettere in atto per affrontare la condizione di disastro e/o emergenza, ha il compito di rilevare le condizioni di emergenza e di comunicarle a CISO;

  • CISO si attiva nei tempi e nelle modalità definite nel presente documento, convocando il Comitato di Crisi;

  • il gruppo di lavoro così costituito procede con le decisioni sui ruoli e le responsabilità valide solo nel presente;

  • in base alle decisioni prese, e comunque in maniera coordinata, vengono eseguite le attività definite nella presente procedura;

  • in base alle decisioni prese, e comunque in maniera coordinata, vengono mantenuti i rapporti con le terze parti interessate e si gestiscono tecnici ed eventuali fornitori da coinvolgere.

Pianificazione

Identificazione scenari

I servizi ICT a supporto dell'erogazione dei processi di business identificati per Vectorlab sono quelli determinati nel documento “MDPR28.1.A – BIA_Business Impact Analysis”. Gli stessi sono presi in considerazione nell’Analisi del Rischio, dalla quale si evince l’esistenza di processi primari e processi a supporto. Di conseguenza, gli asset sono quelli che sono a supporto dei servizi e dei processi sopra indicati e le informazioni sono quelle gestite dai singoli processi: sia informazioni che asset possono essere condivisi tra più processi.

La BIA permette a Vectorlab di identificare le attività di business prioritarie e determinare quali servizi ICT e relative risorse sono necessari a supportare tali attività, stabilendone i requisiti di continuità (prestazioni, capacità dei sistemi, valori di RTO e RPO).

In base a queste informazioni, gli scenari di emergenza / critici per i quali viene predisposto un Piano di Continuità Operativa, saranno:

  1. Indisponibilità della sede per eventi avversi esterni quali terremoto, alluvione, collasso, atmosferici, sociali o sanitari

  2. Indisponibilità della sede per eventi avversi interni quali incendio o allagamento

  3. Mancanza elettricità nella sede

  4. Connessione dati non disponibile

  5. Infrastruttura locale non disponibile

  6. Servizi cloud non disponibili: strumenti per la gestione delle richieste dei clienti, gestione della documentazione, repository di codice sorgente, servizi di posta elettronica, ecc.

  7. Indisponibilità del personale: mancanza di personale o di competenze temporanee o permanenti

  8. Fermo sistema di condizionamento sala CED

  9. Indisponibilità dei fornitori

  10. Indisponibilità archivi cartacei

  11. Impossibilità di lavorare in modalità “smart working” da parte di un membro del personale abilitato a lavorare da remoto.

Una volta identificati gli scenari su cui è necessario intervenire, si identificano quali sono gli eventi che potrebbero danneggiarli.

Tipologie di eventi

Gli eventi possono essere divisi in due classi:

  • eventi ICT

  • eventi NON ICT.

Per eventi ICT si intende tutto ciò che concerne gli aspetti tecnologici, applicativi e operativi per l’erogazione dei servizi ICT. Fanno parte di questa tipologia di eventi:

  • problemi relativi ai laptop;

  • problemi relativi all’accesso logico ai sistemi;

  • problemi relativi all’accesso alle e-mail;

  • problemi relativi alla connettività (per accesso all’esterno e VPN, connettività dedicata al servizio erogato);

  • problemi di natura elettrica;

  • ecc.

Per eventi NON ICT si intende tutto ciò che concerne gli aspetti legati alla sicurezza fisica, a problematiche relative al personale, all’amministrazione, ai clienti; a titolo di esempio sono riportati:

  • problematiche di accesso fisico ai locali;

  • gestione errata delle informazioni (distruzione accidentale, comunicazioni non autorizzate, ecc.);

  • assenza di personale;

  • mancanza di competenze;

  • ecc.

Soluzioni a supporto degli eventi

Le soluzioni a supporto degli eventi critici sono di diversa natura in relazione al tipo di evento accaduto e al processo sul quale ogni evento può causare un potenziale danno (considerato che ogni processo ha delle componenti ICT); queste possono essere, quindi, raggruppate in soluzioni di tipo tecnologico e di tipo organizzativo. Il piano di continuità derivante terrà conto quindi di aspetti sia di natura tecnica che organizzativa.

Soluzioni di tipo tecnologico

La soluzione tecnologica è impostata per garantire, a fronte di un evento dannoso, la gestione della fase di contenimento e di ritorno alla normalità dell’infrastruttura ICT e, quindi, viene attuata a fronte del verificarsi di un evento ICT (es. backup). La soluzione tecnologica può offrire un supporto tale da mantenere la normale operatività in termini di infrastruttura, seppure con possibili riduzioni a livello di prestazioni.

IT è responsabile di dare supporto a CISO nell’attuare la soluzione a fronte dello scatenarsi di un evento dannoso sulla base dei piani di continuità definiti.

Soluzioni di tipo organizzativo

La soluzione organizzativa è impostata al fine di gestire la valutazione e la dichiarazione di emergenza e quindi l’attivazione delle fasi operative di ripristino/contenimento sia per ovviare a eventi ICT che non ICT; in particolare, tale soluzione si adotta sia assieme alla soluzione tecnologica, sia qualora non sia possibile attuare una soluzione tecnologica o dove quest’ultima risulti troppo onerosa rispetto ai rischi ai quali l’Azienda può andare incontro.

Piani di Continuità Operativa

I piani di continuità operativa sono definiti e implementati al fine di diffonderne la cultura e la conoscenza e quindi garantire un rapido recupero dei servizi in caso di emergenza.

I piani mostrano l'insieme delle possibili soluzioni, nonché l'elenco delle procedure organizzative e delle istruzioni e comunicazioni necessarie per associare, nel tempo, ruoli e responsabilità a specifici riferimenti operativi (nomi, attività, posizioni, e-mail, numeri di telefono, canali alternativi di comunicazione, ecc.).

I piani di continuità operativa seguono un ciclo di vita di seguito descritto.

Implementazione

Identificati i processi e servizi critici, si procede con la realizzazione dei piani di continuità operativa avvalendosi del documento “ALPR28.1.A - Piani di Continuità Operativa”, composto da 5 sezioni da compilare:

I - SEZIONE

Si definiscono le informazioni generali come ID identificativo del piano, il creatore del piano, la data di creazione/aggiornamento, il referente per la sua esecuzione e la frequenza definita per testare periodicamente il piano.
Informazioni generali
ID
Creato da
Data emissione piano
Referente piano
Frequenza test

II -SEZIONE

Si definiscono le informazioni di dettaglio dello scenario, quali:

  • scenario critico/di disastro considerato: breve descrizione dello scenario oggetto del piano;

  • processi impattati: lista dei processi primari e a supporto su cui impatta lo scenario;

  • tipo di soluzione: tecnologica e/o organizzativa (indicare con una X) che viene applicata allo scenario;

  • RTO ipotizzato;

  • RPO ipotizzato;

  • funzioni interessate dall’applicazione del piano: lista delle funzioni che possono essere coinvolte nella stesura del piano o semplicemente consultate o impattate nell’esecuzione del piano stesso.
Informazioni Scenario
Scenario critico/di disastro considerato
Processi Impattati
Tipo di soluzione Tecnologica Organizzativa
RTO ipotizzato
RPO ipotizzato
Funzioni interessate dall'applicazione del piano

III – SEZIONE

Si fornisce una descrizione dettagliata del piano che verrà attuato.
Descrizione del Piano

IV – SEZIONE

Si definisce l’evento scatenante, fornendo una descrizione di cosa ha dato origine al piano; può derivare dalla BIA, dall’analisi dei rischi o da un incidente occorso.
Evento scatenante

V – SEZIONE

Si riporta una sequenza di passi e azioni da compiere in modo dettagliato, indicando chi deve compiere l’azione (Responsabile) e i risultati attesi.
Passi e azioni da compiere
Azioni Definite Responsabile Risultati attesi
FASE \<#> 1
FASE \<#> …

Per ogni azione indicare:

  • la FASE a cui appartiene l’azione, con opportuna semaforica:
FASE 1 - Prima risposta e valutazione
Intraprendere ogni azione immediata a seguito di un incidente, valutare l’impatto dell’incidente sulle attività
FASE 2 - Misure di emergenza provvisorie
Attuare misure a breve termine per limitare l’impatto dell’incidente (come, ad esempio, trasferire le attività dello staff in un altro luogo o fare in modo che il personale chiave lavori da casa)
FASE 3 – Approvvigionamento di risorse

Fornire le risorse minime necessarie per riprendere le operazioni in una località alternativa (come scrivanie, telefoni, PC’s, stampanti, server, connettività, electronic data, ecc.)
FASE 4 - Ripresa delle operazioni
Riprendere ad un livello accettabile l’operatività nella località alternativa; può richiedere il trasferimento del personale, la ricreazione di dati perduti, l’elaborazione degli arretrati, ecc.
FASE 5 - Rientro
Completare tutte le azioni necessario per risolvere l’incidente, trasferimento del personale nella sede originale e ripresa della normale attività

  • un numero progressivo, al fine di comprendere la sequenza corretta delle azioni in caso di possibili differenti casistiche da seguire;

  • le attività da eseguire con elevato livello di dettaglio; tra le attività va indicato come gestire le applicazioni, i fornitori, l’eventuale documentazione necessaria e le dotazioni specifiche da usare;

  • il Responsabile di ogni azione, in modo che sia chiaro di quale attività deve farsi carico e che deve verificarne il completamento;

  • i risultati attesi da quella azione per renderla misurabile.

La procedura di Disaster Recovery è invece definita secondo il documento “ALPR28.1.B – Disaster Recovery Plan”.

Ogni piano è distribuito nei seguenti formati/repository, ridondanti fra loro per garanzia di disponibilità ed integrità:

  • documenti raggiungibili dalla rete esterna (repository su cloud primario aziendale) ed interna (cartella su NAS);

  • copia sul PC;

  • documenti cartacei diffusi e loro modalità di accesso (in raccoglitore).

La diffusione della documentazione viene mantenuta controllata anche per garantire la diffusione di aggiornamenti coerentemente con la distruzione di tutte le versioni obsolete.

La formazione programmata su come attuare un piano di continuità operativa è parte del processo di consapevolezza e può includere anche la partecipazione ai test dei piani di continuità operativa.

Monitoraggio

La pianificazione e l'esecuzione dei test dei piani sono fasi importanti e obbligatorie, poiché garantiscono la coerenza dei piani di continuità operativa nel tempo, creano cultura e consapevolezza nel personale. In particolare, la validità del piano viene verificata e mantenuta aggiornata laddove devono essere pianificate azioni correttive organizzative e tecnologiche.

I test sono programmati secondo il “MDPR28.1.B - Piano dei Test di Continuità Operativa” , sotto la supervisione del CISO, e possono essere effettuati a vari livelli di profondità, dall’analisi della sequenza di istruzioni documentate fino alla simulazione comunicata e controllata in tempo reale di un disservizio.

Le possibili modalità di test sono:

  • evento reale,

  • simulazione di evento con personale preavvertito,

  • simulazione di evento con personale non preavvertito,

  • test a tavolino.

L’Azienda potrebbe eseguire a campione i test a sorpresa o, nel caso di modifiche sostanziali all’organizzazione o ai sistemi informatici, si impegna a eseguire test sul piano che è maggiormente coinvolto nelle modifiche avvenute. In base al tipo di test, le azioni da eseguire sono:

  • Simulazione di evento con personale preavvertito: pianificare con il personale coinvolto nell’attuazione del piano l’attività di test e osservare come il relativo piano adottato si attua, annotando i comportamenti del personale e i tempi di attuazione e il risultato di ogni sequenza del piano nel relativo “MDPR28.1.C - Report Test di Continuità Operativa”;

  • Simulazione di evento con personale non preavvertito: simulare o dichiarare solo l’evento di disastro in modo da osservare come il relativo piano adottato si attua e, di conseguenza, annotare i comportamenti del personale e i tempi di attuazione e il risultato di ogni sequenza del piano nel relativo “MDPR28.1.C - Report Test di Continuità Operativa”;

  • Test a tavolino: il personale coinvolto viene riunito intorno ad un tavolo alla presenza di un elemento estraneo all’applicazione del piano e viene dichiarato uno degli scenari avversi; di conseguenza, si verifica e si annota, nel relativo “MDPR28.1.C - Report Test di Continuità Operativa”, il comportamento e le azioni dei presenti e le eventuali anomalie/scostamenti dal piano stesso.

Nel caso di eventi reali per cui si attiva un piano di continuità operativa, una volta concluse le attività, si compilerà il “MDPR28.1.C - Report Test di Continuità Operativa” e si registrerà il test “reale” nel “MDPR28.1.B - Piano dei Test di Continuità Operativa” per essere conteggiato per le finalità di monitoraggio.

Le evidenze dell’esito dei test dei piani di continuità sono conservate su XXX

Manutenzione e miglioramento continuo

Nel momento in cui viene eseguito/testato un piano di continuità, una revisione/analisi formale del piano deve essere eseguita a valle del ripristino, al fine di determinare se ulteriori miglioramenti devono essere applicati. Questa revisione/analisi dovrebbe includere tutte le funzioni aziendali coinvolte.

Tutte le azioni di miglioramento definite devono essere documentate, testate e monitorate formalmente.

Nel momento in cui sia necessaria una modifica di un piano di continuità, questo deve essere sempre testato prima della sua approvazione.

Esecuzione

Al presentarsi di un evento avverso, sarà cura di CISO, una volta ricevuta la notizia da parte di chi segnala per primo l’evento, avviare le attività previste nel piano di continuità operativa legato all’evento avverso individuato.

Durante la gestione del piano, o immediatamente a valle del ripristino del processo/servizio impattato, si procederà con la registrazione di quanto avvenuto in INDICARE COME E DOVE SI TIENE TRACCIA DELL’EVENTO OCCORSO.