La nuova edizione della norma ISO 22301:2019 per la certificazione della business continuity

Soprattutto in questo periodo è estremamente attuale essere
in grado di pianificare la continuità operativa delle imprese, almeno per
quanto possibile.

Anche le aziende più preparate a gestire la business
continuity
, forse, non hanno previsto una pandemia come quella del Covid-19,
o forse si erano prefigurati scenari diversi, nei quali le persone non sono in
grado di andare al lavoro a causa di epidemie di influenza o altre cause. In
questa fase che stiamo attraversando l’assenza di personale non è dovuta –
nella maggior parte dei casi – allo stato di malattia delle persone, ma alla
necessità di “isolamento sociale” delle risorse umane di un’intera azienda. Per
certi aspetti, dunque, il panorama è meno catastrofico, in quanto le persone
sono quasi tutte operative ed in grado di lavorare
, ma non possono accedere
ai locali aziendali per un periodo di tempo che potrebbe essere considerevole.

Come potrebbe (o poteva) l’azienda lungimirante e preparata,
affrontare situazioni di emergenza come questa che stiamo attraversando? O
meglio, come potrà pensare di affrontarle in futuro se si verificheranno?



Ci viene in soccorso lo standard UNI EN ISO 22301 (Sicurezza e resilienza – Sistemi di gestione
per la continuità operativa – Requisiti
titolo originale “Security
and resilience – Business continuity management systems – Requirements”
),
recentemente revisionato (edizione 2019) e tradotto in italiano dall’UNI e
pubblicati a febbraio 2020.

Come già visto in un precedente articolo sulla vecchia versione della norma (pubblicata dall’ISO nel 2012) , lo standard specifica i requisiti per progettare, implementare e gestire efficacemente un Sistema di gestione della continuità operativa.

Le modifiche alla norma non hanno aggiunto nuovi
requisiti
, ma solamente chiarito quelli già presenti, allineato la
norma alle altre norme sui sistemi di gestione e riorganizzato il capitolo 8,
vero cuore dello standard.

Il sistema di gestione della continuità operativa (business continuity management system o BCMS)
enfatizza l’importanza di:

  • comprendere le esigenze dell’organizzazione e le necessità per
    stabilire la politica e gli obiettivi per la continuità operativa;
  • gestire e mantenere processi, capacità e
    strutture di risposta per garantire che l’organizzazione sopravviva a
    interruzioni;
  • implementare e rendere operativi controlli e misure per gestire la
    capacità di un’intera organizzazione nella gestione delle interruzioni (discontinuità)
    dell’operatività dovute a cause accidentali;
  • monitorare e riesaminare le
    prestazioni e l’efficacia del sistema di gestione della continuità
    operativa;
  • migliorare in modo continuo
    il BCMS basato su metriche qualitative e quantitative (obiettivi misurabili).

Si ricorda che anche la norma ISO/IEC 27031 “Information technology — Security techniques
— Guidelines for information and communication technology readiness for
business continuity
” tratta la business continuity, ma nel contesto dell’ICT
e delle tecniche di sicurezza strettamente correlata alla ISO 27001 che
contiene i requisiti per la
certificazione dei sistemi di gestione della sicurezza delle informazioni
.

La ISO 22301 evidenzia i componenti chiave del sistema di
gestione della continuità operativa, peraltro presenti anche in altri sistemi
di gestione. Tra essi la politica,
le persone con le loro responsabilità definite, la gestione dei processi correlati a
politica, pianificazione, attuazione e funzionamento del BCMS, valutazione
delle prestazioni
, riesame di
direzione
e miglioramento,
nonché le informazioni documentate in grado di fornire evidenze
verificabili anche tramite audit sul
sistema di gestione della continuità operativa.

Il vantaggio di disporre di un BCMS correttamente
funzionante è quello di far sì che l’organizzazione sia preparata – attraverso
processi, procedure, responsabilità, risorse, controlli, competenze, ecc. – a
mantenere l’operatività a seguito di un’interruzione, ovvero di un evento
destabilizzante (in inglese viene utilizzato il termine “disruption”) che
mina i processi operativi critici.

Anche questa norma recepisce il metodo del “PLAN DO CHECK ACT” già noto da altre
norme dei sistemi di gestione.

Per questa norma il concetto di “parti interessate” o stakeholders è molto importante in
quanto una discontinuità (interruzione) nell’operatività dell’organizzazione,
una indisponibilità dei servizi essenziali per i clienti, un fermo delle
attività produttive per un periodo più o meno lungo, possono causare danni, sia
dal punto di vista commerciale, sia da quello finanziario, ma anche da quello
delle altre parti interessate, quali personale interno, individui della
collettività che subiscono danni anche fisici, fornitori, ecc..

Scopo della norma per la gestione della business continuity
è quello di specificare i requisiti atti proteggere l’organizzazione da interruzioni
quando accadono, ma non solo. Il BCMS ha anche l’obiettivo di ridurre la
probabilità che tali eventi negativi avvengano
, prepararsi ad essi e rispondere
in modo adeguato a ripristinare l’operatività nel più breve tempo possibile
qualora si verifichi un evento che provoca l’interruzione dell’operatività.
Naturalmente non si può pensare che un’azienda metta in atto azioni volte a
prevenire calamità naturali o pandemie, ma – facendo un esempio estremamente
attuale – una volta che sia stata conclamata un’epidemia su larga scala,
potrebbe porre in essere misure volte a prevenire il contagio fra i dipendenti e,
quindi, volte ad evitare che si verifichi un’interruzione totale dell’operatività
aziendale causata da un contagio interno molto diffuso. Questo, naturalmente,
al di là delle decisioni e delle disposizioni governative che hanno limitato l’operatività
di molte attività, ma non di tutte. Addirittura alcune aziende dovevano porsi l’interrogativo
se chiudere anticipatamente in base alla probabilità di contagio nella propria
zona fra personale dipendente.

La norma ISO 22301 definisce alcuni termini specifici sulla
materia tra cui il termine di continuità operativa (business continuity),
piano di continuità operativa (business continuity plan), analisi di
impatto operativo
(business impact
analysis
o BIA).

Oltre ad altri termini consueti delle norme della serie ISO
9000, altro termine significativo mutuato dalle norme della serie ISO 27000 è
quello di incidente che è definito
come “evento che può o potrebbe condurre ad un’interruzione, a una perdita,
a un’emergenza o a una crisi
” Al proposito la norma utilizza spesso il
termine interruzione che
rappresenta “un incidente che causa una deviazione negativa, non pianificata
dell’erogazione prevista dei prodotti e servizi secondo gli obiettivi di un’organizzazione
”;
modificando significativamente la definizione della precedente versione della
norma, forse più concreta e facilmente comprensibile ai più.

Verranno successivamente introdotti dalla norma degli
indicatori specifici per questa tematica come:

  • Maximum
    Tolerable Period of Disruption
    (MTPD) ovvero
    il tempo massimo accetabile che può trascorrere a fronte degli impatti
    negativi conseguenti ad una interruzione come risultato della mancata
    fornitura di un prodotto, erogazione di un servizio o svolgimento di un’attività
    operativa.
  • Recovery Time Objective (RTO):
    periodo di tempo entro il quale – dopo l’interruzione – i servizi erogati,
    la produzione, i servizi di supporto e le funzionalità operative devono
    essere ripristinati ad un livello minimo accettabile.

Il capitolo 4 della norma denominato “Contesto dell’organizzazione” contiene
gli elementi per comprendere il contesto dell’organizzazione, tra cui i fattori
interni ed esterni che influenzano la sua capacità di conseguire i risultati
del BCMS. La norma stabilisce che nell’ambito del Sistema di gestione per la
continuità operativa debbano essere identificati i requisiti dell’organizzazione e delle sue parti interessate, che
dovranno essere tenuti in debito conto nella progettazione del sistema di
gestione dell’organizzazione

Tra i requisiti da prendere in considerazione viene dedicato
un punto specifico ai requisiti legali e regolamentari, ovvero quei
requisiti cogenti che determineranno gli obiettivi di minima del BCMS e dei
piani di continuità operativa. Ciò aiuterà nella definizione dello scopo e campo di applicazione del sistema di gestione
di continuità operativa
. A tale riguardo la norma stabilisce le modalità
attraverso le quali l’organizzazione deve stabilire i confini del BCMS e quali
processi, prodotti e servizi sono compresi nel sistema di gestione e quali
parti dell’organizzazione agiscono all’interno di esso, dettagliando eventuali
esclusioni che, comunque, non possono influenzare negativamente i risultati del
sistema di gestione ed i livelli di operatività stabiliti nell’analisi di
impatto.

Al punto 4.4 la norma stabilisce che l’organizzazione deve
implementare, mantenere attivo e migliorare continuamente un sistema di
gestione della continuità operativa, inclusi i processi necessari e le relative
interazioni fra essi, in accordo con i requisiti di questo standard
internazionale (ISO 22301).

Il capitolo 5 della norma è denominato “Leadership”. In esso la norma
stabilisce che l’alta direzione (ovvero il top
management
) deve possedere leadership e dimostrare un impegno preciso
rispetto al sistema di gestione per la continuità operativa. L’impegno del management
viene poi esplicitato attraverso una serie di responsabilità della direzione
relative al sistema di gestione quali, ad esempio, assicurare che politiche ed obiettivi
siano stabiliti, che le risorse necessarie siano messe a disposizione e che vi
sia un’adeguata comunicazione all’interno dell’organizzazione relativamente ai
requisiti del sistema di gestione della continuità operativa.

Sono poi stabiliti requisiti relativi alla definizione della
politica per la continuità operativa
e la definizione della struttura
organizzativa dell’organizzazione
, quindi la definizione di ruoli
responsabilità ed autorità.

Il capitolo 6, denominato “Pianificazione” stabilisce che:

  • L’organizzazione deve attuare
    azioni rivolte ad affrontare i
    rischi ed alle opportunità
    , in particolare assicurando che il sistema riesca
    a perseguire gli obiettivi ed i risultati stabiliti, prevenire o ridurre
    gli effetti indesiderati sul BCMS e mirare al miglioramento continuo.
  • Vengano definiti obiettivi per la business continuity e soluzioni/piani per raggiungerli;
    tale aspetto, con le dovute modifiche, è del tutto analogo ad altri
    sistemi di gestione: gli obiettivi devono essere misurabili, devono essere
    monitorati, occorre stabilire chi è responsabile, che cosa deve fare,
    quali risorse sono richieste, quando dovranno essere completate le azioni
    finalizzate al perseguimento degli obiettivi e come dovranno essere
    valutati i risultati. Unica differenza rispetto ad altri sistemi di
    gestione è che nella definizione degli obiettivi bisognerà tenere conto di
    un livello minimo di servizio o di prodotto fornito ritenuto accettabile
    dall’organizzazione nel raggiungimento dei suoi obiettivi.

Viene anche chiarito, in una nota, che i rischi di questa
sezione sono quelli che influenzano l’intero BCMS, non i rischi che minacciano
la continuità operativa, trattati al successivo punto 8.2.

Il capitolo 7 della norma denominato “Supporto” stabilisce i requisiti per
alcune attività e processi di supporto, quali – in generale – la gestione delle risorse, le competenze del personale, la consapevolezza dello stesso personale
relativamente al sistema di gestione della continuità operativa e la comunicazione, sia essa interna che
esterna. In particolare, per questo tipo di sistema di gestione, le modalità ed
i mezzi di comunicazione sono molto importanti per garantire la continuità del
servizio anche durante i periodi di indisponibilità delle risorse critiche.

Infine, l’ultima parte di questo capitolo è dedicato alle informazioni documentate, i cui
requisiti relativi riguardano le modalità di gestione di documenti, dei dati e
delle registrazioni richieste dalla norma.

A questo riguardo è opportuno precisare che, nell’ambito
della business continuity, i
documenti – in particolare i piani, le procedure e le istruzioni operative –
necessarie per ripristinare nel più breve tempo possibile i servizi richiesti
durante i periodi di crisi successivi ad un’interruzione, dovrebbero essere
accessibili dai responsabili nominati, dunque occorre prevedere supporti
alternativi per i documenti che potrebbero non essere disponibili nel formato
originario, su supporto elettronico o cartaceo. Pertanto, tali documenti
dovrebbero essere resi disponibili su supporti ed ubicazioni realmente
utilizzabili in funzione del tipo di crisi (scenario) previsto in fase di pianificazione.

Il capitolo 8 della norma, denominato “Attività operative”, è quello che è
stato maggiormente modificato rispetto alla versione precedente della norma e rappresenta
il cuore della ISO 22301 in quanto tratta gli aspetti di pianificazione e controlli
operativi, l’analisi di impatto e la valutazione dei rischi e, infine, la strategia di business continuity e le
relative soluzioni adottate, ovvero tutto ciò che l’organizzazione intende fare
per garantire la continuità operativa, compresa la definizione dei business
continuity plan
o piani di continuità operativa, la loro applicazione e
test/esercizio.

Nei suddetti paragrafi sella sezione 8 vengono specificate,
tra l’altro, le modalità di effettuazione e documentazione della analisi di impatto operativo e della valutazione del dei rischi, per la quale può essere preso come
riferimento quanto indicato nella ISO 31000 (UNI ISO 31000 – Gestione del rischio – Principi e linee guida). Occorre
precisare che sia l’analisi di impatto sia la valutazione dei rischi dovranno
prendere in considerazione i rischi che possono impattare la continuità
operativa, quindi i rischi che si verifichino incidenti distruttivi che portino
a situazioni di crisi o di interruzione dell’operatività e, conseguentemente, a
situazioni insostenibili per i requisiti stabiliti di continuità operativa e
per la propensione al rischio dell’organizzazione. A fronte di tali situazioni,
in base ai risultati della valutazione dei rischi, dovranno essere determinate
e poste in essere le azioni conseguenti per mantenere la continuità operativa.

Le soluzioni per garantire la continuità operativa
devono essere finalizzate a:

  • rispettare i requisiti di continuità e di
    recupero delle attività prioritarie entro le tempistiche prestabilite e
    capacità concordate;
  • proteggere le attività prioritarie dell’organizzazione;
  • ridurre le probabilità di un’interruzione;
  • accorciare la durata di un’interruzione entro
    limiti tollerabili;
  • limitare l’impatto di un’interruzione sui
    prodotti e servizi dell’organizzazione;
  • provvedere alla disponibilità di risorse
    adeguate a poter affrontare le situazioni di crisi.

Le soluzioni identificate devono essere scelte in base ai
requisiti da soddisfare, i rischi ritenuti accettabili, i costi ed i benefici. Per
attuarle dovranno essere stabiliti i requisiti e le necessità di risorse umane,
tecnologiche, infrastrutturali, ecc.

Il punto 8.4 della norma fornisce indicazioni su come progettare
i piani di continuità operativa e le procedure da mettere in atto per
garantire la continuità operativa dell’organizzazione a fronte di un’interruzione.

Il capitolo 9 della norma tratta la “Valutazione delle prestazioni”. Vengono
qui illustrati i requisiti relativi al monitoraggio,
alle misurazioni, all’analisi ed
alla valutazione dei processi che
hanno un impatto sulla continuità operativa; in particolare vengono esplicitati
i requisiti relativi ad indicatori e
metriche finalizzate al monitoraggio
dell’efficacia del BCMS.

Nel capitolo 9 vengono anche trattati i requisiti
standard per i sistemi di gestione riguardanti gli audit interni ed il riesame di
direzione
. Anche qui, rispetto alle altre normative sui sistemi di gestione,
il focus è sui rischi risultanti dall’analisi di impatto e sul risk assessment.

Nel capitolo 10, denominato “Miglioramento”, sono trattati le non conformità, le azioni correttive ed il miglioramento
continuo
. Relativamente a non conformità ed azioni correttive la gestione è
analoga ai sistemi gestionali descritti nelle altre normative sui sistemi di
gestione (ISO 9001 in primis). Sono inoltre introdotte le azioni che vengono
messe in atto al fine di perseguire il miglioramento continuo del sistema e
delle sue prestazioni.

Premesso ciò, le non conformità relative al sistema di
gestione della continuità operative – normalmente incidenti ed altri eventi che hanno generato interruzioni oltre
ad altre situazioni nelle quali si verifica il non soddisfacimento dei
requisiti procedurali – dovranno essere identificate e dovranno essere attuate
prontamente correzioni per eliminare, quando possibile, gli effetti della non
conformità stessa e le relative conseguenze. Inoltre, si deve valutare la
necessità di intraprendere azioni correttive finalizzate ad eliminare le cause
della non conformità.

In conclusione, le organizzazioni che vorranno adeguarsi a tale
normativa e certificarsi secondo le proprie esigenze di business, quasi
certamente avranno già messo in atto e certificato un sistema di gestione per
la qualità ISO 9001, ma probabilmente alcune di queste organizzazioni avranno
anche già implementato il sistema di
gestione della sicurezza delle informazioni ISO 27001
, pertanto lo sforzo
per conformarsi a questa norma sulla business
continuity
non sarà eccessivo. Infatti, molti requisiti sono comuni fra la
norma ISO 22301 e la norma ISO 27001 nella quale esiste già un obiettivo di
controllo riguardante la continuità operativa che impone di predisporre uno o
più business
continuity plan
per garantire la continuità nell’erogazione del
servizio o nella produzione, ma a fronte di interruzioni dovute a
indisponibilità di informazioni.

Al proposito occorre notare che la norma tratta la gestione
di tutti i tipi di discontinuità o interruzioni di servizio, non
necessariamente solo quelli legati all’indisponibilità dei sistemi informatici,
anche se quasi tutte le organizzazioni vedono come principale pericolo per la
propria continuità operativa il blocco dei sistemi informatici che ormai
governano quasi tutte le attività aziendali.

Gli esempi di situazioni nelle quali la continuità operativa
non è minacciata da interruzioni e disastri legati ai sistemi informatici sono
sotto i nostri occhi in questo periodo.




Lo smartworking sicuro al tempo del Coronavirus

In questo periodo molte organizzazioni, sia pubbliche che private, hanno scoperto – per necessità – il lavoro a distanza, formalmente definito “lavoro flessibile”, telelavoro o smartworking.

Fermo restando che il vero smartworking non consiste
nel farsi mandare un documento a casa via e-mail da un collega (o da sé stesso),
lavorarci su fra le mura domestiche e poi rimandarselo in ufficio, cerchiamo di
capire quali sono le modalità efficaci, efficienti e “sicure” per lavorare con
continuità da casa o comunque da un sito che non è l’ufficio o la sede
aziendale in genere.



In questo periodo molte organizzazioni ed i loro dipendenti,
collaboratori e consulenti stanno sperimentando tecnologie che sono disponibili
già da alcuni anni a basso costo o addirittura gratis, ma che necessitano di acquisire
competenze informatiche di base per poterle utilizzare in modo produttivo.

Partendo dagli strumenti più semplici, i colossi dell’informatica
e del web – come Microsoft e Google, ma anche Apple per i suoi utenti – hanno messo
a disposizione, insieme alle relative suite di produttività (es. Office
365), anche alcuni strumenti per lavorare su documenti condivisi tramite
cloud
(ad es. Google Drive, One Drive), per comunicare in modo organizzato
sul medesimo progetto, per organizzare riunioni via web (es. Skype for
Business ora migrato in Teams, Google Meet, Hangout, oppure GoToMeeting, ecc.).
Tali strumenti permettono di lavorare a distanza su documenti informatici, anche
contemporaneamente, di condividere lo schermo e di vedersi in modo estremamente
proficuo, anche per l’ambiente. Infatti, un effetto collaterale benefico di
questa emergenza coronavirus è la riduzione del traffico – e quindi dell’inquinamento
– nelle strade e l’eliminazione della carta, ovvero della stampa di documenti,
quando non necessaria.

Le aziende più strutturate avevano già previsto modalità di “telelavoro”
nelle quali il PC utilizzato dal dipendente fuori sede poteva collegarsi
direttamente ai sistemi informatici aziendali tramite VPN.

Per fare questo passo ulteriore, e collegarsi tramite
internet ai sistemi aziendali, occorrono maggiori competenze del reparto
sistemistico aziendale (troppo spesso ridotto all’osso o demandato all’esterno
a consulenti che magari in questo momento sono molto impegnati) ed altre
tecnologie.

Il mercato degli applicativi gestionali ha favorito questa
trasformazione attraverso il rilascio di applicativi web che non
necessitano di installazione su server in azienda o comunque che non funzionano
in tecnologia client-server, ma possono essere resi accessibili via web da
qualsiasi parte del mondo, dunque anche da casa propria, anche se si è in
quarantena, ma si gode di ottima salute!

Chiaramente l’utilizzo di tutti questi strumenti “innovativi” non può essere realizzato da un giorno all’altro in modo efficace ed efficiente, occorrerebbe un periodo di formazione del personale e di test. Ma l’emergenza non ci concede questo tempo e – come al solito – siamo costretti ad operare in modalità diverse a fronte di un evento destabilizzante. È giocoforza ricordare che proprio in questi giorni è uscita la versione italiana della norma UNI EN ISO 22301:2019 sui sistemi di gestione della continuità operativa (leggi l’articolo), ovvero sulla business continuity. Ma quante aziende avevano un piano di business continuity che considerasse lo scenario della pandemia o comunque dell’assenza forzata dal lavoro di numerose persone?

Dunque molti sono costretti a improvvisare, ma occorre
pensare anche alla sicurezza delle attività lavorative a distanza, ovvero
occorre ragionare in termini di “security”, mentre alla “safety” delle persone
si pensa cercando di evitare il più possibile i contatti fisici.

Se con lo smartworking preveniamo i l corona-virus,
siamo sicuri di prevenire anche i virus informatici, ovvero il malware che
potrebbe far perdere la necessaria riservatezza, integrità e/o disponibilità ai
nostri dati? Riusciamo a garantire il rispetto della normativa sulla protezione
dei dati (GDPR)?

Ci viene in soccorso la UNI EN ISO 27002 (Linea Guida
sui controlli di sicurezza delle informazioni), al punto 6.2.2 Telelavoro, ma
non solo.  Tale norma ci insegna che:

«Dovrebbero essere attuate una politica e delle misure di
sicurezza a suo supporto
(del telelavoro) per proteggere le informazioni
accedute, elaborate o memorizzate presso siti di telelavoro.
»

Perciò le organizzazioni che permettono attività di
telelavoro o smartworking – e in questo momento sono moltissime, anche a
fronte della modifica normativa – dovrebbero emettere una policy che definisca
le condizioni e le limitazioni al telelavoro, ovvero stabilire delle regole
generali per gestire lo smartworking in modo sicuro, nelle diverse
situazioni.

Gli aspetti da considerare dovrebbero essere i seguenti:

  • Il livello di sicurezza fisica del sito
    di telelavoro (es. l’abitazione del dipendente/collaboratore oppure il luogo
    pubblico dove esso può esercitare l’attività lavorativa), considerando gli
    edifici e l’ambiente circostante. In pratica consideriamo il fatto che se la
    postazione di lavoro non è all’interno della sede aziendale devono essere
    garantiti un accesso controllato in modo continuo delle persone estranee a
    documenti e dispositivi elettronici. L’abitazione ha una porta blindata e/o un
    sistema di allarme? La postazione di lavoro è facilmente accessibile da porte o
    finestre aperte?
  • L’ambiente di telelavoro proposto: l’azienda
    può prevedere l’utilizzo di determinati tipi di locali piuttosto che altri (es.
    divieto di lavorare in luoghi pubblici).
  • I requisiti per la sicurezza delle
    comunicazioni
    , tenendo in considerazione la necessità di accesso remoto ai
    sistemi interni dell’organizzazione (ad esempio l’accesso più sicuro è tramite
    VPN crittografata), la criticità delle informazioni che sono accedute e
    trasmesse attraverso il canale di comunicazione (ad es. dati personali
    appartenenti a categorie particolari di dati), nonché la criticità del sistema
    interno. Occorre cambiare il punto di vista: le comunicazioni non avvengono più
    all’interno dell’azienda, ma dall’interno all’esterno e viceversa e necessitano
    di essere protette con comunicazioni crittografate. Anche il semplice invio di
    e-mail dall’ufficio all’abitazione del dipendente dovrebbe comunque garantire
    trasmissioni sicure (es. con crittografia SSL/TLS) su un indirizzo privato
    approvato e l’accesso a siti sFTP dovrebbe essere preferito rispetto ai meno
    sicuri FTP.
  • La fornitura di accesso in modalità desktop
    virtuale
    che prevenga l’elaborazione e la memorizzazione di informazioni su
    dispositivi privati: se il dispositivo usato dal dipendente è il proprio PC
    casalingo – e non un notebook fornito dall’azienda – potrebbe essere opportuno
    non consentire il salvataggio di dati particolarmente riservati in locale, ma
    solo di lavorare in desktop remoto sul PC aziendale.
  • Le minacce di accesso non autorizzato alle
    informazioni o alle risorse
    da parte di altri soggetti che frequentano il
    luogo di lavoro flessibile, per esempio i famigliari e gli amici: evidentemente
    in un contesto privato possono esserci altri soggetti che non sono autorizzati
    ad accedere alle informazioni aziendali che potrebbero accedervi, pertanto
    occorre stabilire regole ferree con i dipendenti (es. divieto di divulgare
    password a conviventi).
  • L’uso di reti casalinghe e i requisiti o le
    limitazioni alla configurazione dì servizi wireless
    di rete: soprattutto se
    il collegamento alla rete aziendale non avviene tramite VPN è importante
    garantire la sicurezza della rete cablata o Wi-Fi dell’abitazione o di altro
    luogo ove si è abilitati a lavorare. Quasi tutti i dispositivi sono in grado di
    valutare se la rete Wi-Fi a cui ci si collega dispone almeno di un livello di
    sicurezza WPA2. In caso negativo occorre configurare adeguatamente il
    router/modem casalingo, se si è in un luogo pubblico meglio astenersi dalla
    connessione. In certi casi è l’azienda stessa a fornire una connessione sicura
    tramite scheda SIM 3G/4G.
  • Le politiche e le procedure per prevenire
    discussioni riguardo i diritti per la proprietà intellettuale sviluppatisi
    su dispositivi privati
    : è opportuno stabilire regole precise per chiarire al
    dipendente che eventuali progetti sviluppati in smartworking casalingo
    rimangono di proprietà dell’azienda.
  • L’accesso a dispositivi privati (per verificare
    la sicurezza del sistema o durante un’indagine), che potrebbero essere proibiti
    dalla legge. Se il dipendente usa un proprio dispositivo privato che contiene
    materiale illegale o viene usato per consultare siti illegali potrebbero
    esserci dei problemi.
  • Gli accordi di licenza del software tali
    per cui le organizzazioni potrebbero diventare responsabili per le licenze di
    software sulle workstation private di proprietà del personale o di utenti di
    terze parti. Chiaramente se il dipendente utilizza il proprio PC occorre che le
    licenze software siano conformi alla legge applicabile. Anche un Office con
    licenza Student o Privata non potrebbe essere usato per scopi aziendali o
    professionali. Eventuali indagini dell’Autorità potrebbero creare problemi al
    dipendente ed all’azienda.
  • Le protezioni dal malware e i requisiti per
    l’uso di firewall
    in caso di utilizzo di PC privati devono essere comunque
    garantiti. Sarebbe bene richiedere la presenza di un anti-malware ed un
    firewall di livello equivalente a quello aziendale (le licenze free degli
    antivirus sono da evitare).

In generale dovrebbero essere stabilite regole fra azienda e
dipendente che definiscano quali dispositivi utilizzare, come utilizzarli, dove
poter lavorare, quali misure di sicurezza occorre mantenere sempre, come
gestire i backup delle informazioni e le stampe, quali informazioni si possono
elaborare, se ci sono particolari restrizioni per il trattamento di dati
personali appartenenti a categorie particolari di dati (art. 9 del GDPR), la
gestione delle procedure di autenticazione e la gestione delle password, le
attività non consentite dai dispositivi utilizzati anche per lavoro e così via.

Anche per attività che richiedono software particolari e
costosi (es. editing grafico e progettazione CAD) i produttori di software
stanno venendo incontro agli utenti con licenze non legate ad un particolare
dispositivo fisico, ma utilizzabili, con il supporto del cloud, su dispositivi
differenti, anche se non contemporaneamente.

Purtroppo sono tutti elementi che non si possono
improvvisare da un giorno all’altro, ma che sarebbe opportuno considerare e
gestire anche nell’emergenza.

Infine occorre considerare un problema di capacità:
se un’azienda normalmente è strutturata per uno smartworking
contemporaneo del 20% dei dipendenti (ad esempio una giornata lavorativa a
settimana) e in questa situazione di emergenza il lavoro a distanza sale al 90%,
probabilmente le reti e le VPN dovranno essere ridimensionati per supportare
tutto il traffico, nella consapevolezza che le connessioni di rete delle
abitazioni dei dipendenti potrebbero non garantire prestazioni sufficienti e
questo problema potrebbe essere difficile da ovviare anche con connessioni
tramite chiavette con SIM 4G se l’abitazione del dipendente si trova in una zona
mal servita dai provider internet.




RPO e RTO: come progettare il disaster recovery

In questo articolo parleremo ancora di business continuity, ovvero di business continuity plan ed in particolare della progettazione delle procedure di disaster recovery.

Molte organizzazioni che non predispongono un vero e proprio piano di continuità operativa (o business continuity plan, BCP), comunque hanno una procedura di disaster recovery, più o meno evoluta. Purtroppo, però, questa attività viene delegata quasi interamente ai responsabili ICT senza coinvolgere il management, i responsabili dei processi primari di business ed in particolare di quelli più critici.

Non che i responsabili ICT non siano in grado di progettare una procedura di disaster recovery adeguata, ma spesso sono loro stessi che stabiliscono i requisiti di base del disaster recovery, ovvero implicitamente definiscono gli obiettivi RTO e RPO che dovrebbero essere alla base della procedura.

Riprendiamo le definizioni di questi indici, già esposte in precedenti articoli, per capire meglio di cosa si tratta.

  • Recovery Point Objective (RPO) ovvero il punto (l’istante nel tempo) al quale le informazioni sono coerenti e possono essere ripristinate per consentire la ripresa delle attività (denominato anche Maximum Data Loss).
  • Recovery Time Objective (RTO): periodo di tempo entro il quale i servizi erogati, la produzione, i servizi di supporto e le funzionalità operative devono essere ripristinati dopo l’incidente che ha generato la discontinuità.

 

Facciamo un esempio per comprendere meglio il significato degli indici sopra esposti.

Supponiamo che una piccola organizzazione che opera nel settore dei servizi, denominata ALFA srl, decida di effettuare un backup incrementale dei propri dati con frequenza giornaliera su un NAS interno, mantenendo le ultime 7 versioni dei dati e che poi, per cautelarsi a fronte di eventuali catastrofi naturali che potrebbero rendere inutilizzabile il sistema informatico aziendale e tutti i backup salvati su NAS, effettui anche un backup completo su nastri DAT con cadenza settimanale. I nastri magnetici dell’ultimo backup settimanale sono conservati a casa del titolare, a 20 km di distanza dalla sede dell’azienda, il quale quando si porta via il backup restituisce quello della settimana precedente.

Qual è il valore di RPO e RTO per questa azienda?

Occorre distinguere fra diversi tipi di problemi (disastro):

  1. Si tratta di un crash del sistema che ha comportato la perdita dei soli dati (eventualmente anche dei supporti di memorizzazione) oppure
  2. Si tratta di un evento catastrofico che ha reso inutilizzabile l’intero server e l’infrastruttura informatica della sede di ALFA?

Evidentemente nel primo caso potrebbero essere sufficienti i backup su supporto NAS da ripristinare su un nuovo hard disk, reperibile in tempi brevi. Dunque il RTO potrebbe essere pari anche ad una sola giornata, dipende dal tempo che si impiega a ripristinare il sistema (tempi di acquisto dei nuovi supporti di memorizzazione, tempi di eventuale reinstallazione del sistema operativo del server e degli applicativi, ecc.). Il RPO invece è pari ad una giornata di lavoro o meno, a seconda dal tempo trascorso dall’ultimo backup giornaliero eseguito. In questo caso per valutare correttamente il RTO occorre capire quanto tempo si impiegherebbe a reinstallare il sistema, partendo dai supporti originali oppure da un’immagine del sistema creata attraverso l’impiego di macchine virtuali. Questa seconda soluzione, certamente più costosa della prima, potrebbe abbassare drasticamente il RPO.

Nel secondo caso il ripristino dell’operatività dipende anche dai danni generati alla sede dell’organizzazione: che si sia verificato un terremoto che ha reso inagibili i locali oppure un’alluvione i cui danni possano essere riparati entro qualche giorno o settimane la situazione può essere sensibilmente differente e il RTO, anche in questo caso può essere di alcuni giorni o settimane, indipendentemente dalla strategia di backup implementata. Il backup settimanale su nastro, conservato in un luogo sicuro (da valutare se la distanza dalla sede è sufficiente per garantire un’alta probabilità di evitare danni), garantirebbe un RPO di al massimo una settimana di dati persi.

Bisogna capire se questi valori, di RPO e RTO, sono accettabili per l’organizzazione oppure le perdite, in termini di dati e di discontinuità operativa, mettono a repentaglio la sopravvivenza dell’azienda.

Ricordiamo che per alcune attività critiche il verificarsi di eventi disastrosi con RTO di settimane e di RPO di una settimana potrebbero portare a danni economici ingenti, non coperti da polizze assicurative (ritardi nella consegna di commesse con addebito di penali da parte del committente, perdita di commesse importanti, ecc.).

In questa seconda situazione occorrerebbe certamente un sito di disaster recovery, ovvero un sito alternativo, geograficamente distante dalla sede principale dell’azienda, in grado di consentire la ripresa dell’attività in pochissimo tempo (ore, al massimo una giornata lavorativa) e la perdita dei dati di al massimo una giornata, dunque ottenendo un RTO = 1 giorno e RPO = 1 giorno. Ciò potrebbe essere ottenuto senza investimenti consistenti in una struttura gemella, ma dotandosi di una infrastruttura tecnologica in cloud.

In conclusione la procedura di disaster recovery dovrebbe essere progettata da personale competente (responsabile IT, consulenti esterni, …) basandosi su precisi input da parte della Direzione aziendale, derivanti da obiettivi di RPO e RTO ritenuti adeguati per l’organizzazione. La procedura di disaster recovery progettata avrà dei costi (che possono variare in base alle soluzioni scelte) che la Direzione dovrà mettere a budget per garantirsi gli obiettivi desiderati. Viceversa bisognerà migrare verso obiettivi meno ambiziosi di RPO e RTO, ma la Direzione deve essere consapevole di ciò. In caso di disastri, infatti, nessuno potrà accusare altri di non aver pensato alle giuste contromisure ed ognuno si assumerà le responsabilità che gli spettano.




La sicurezza delle informazioni in caso di calamità naturali e non naturali

terremotoIn caso di catastrofi e calamità naturali quali terremoti, alluvioni, inondazioni, incendi, eruzioni vulcaniche, uragani oppure atti terroristici, uno dei danni collaterali dopo la perdita di vite umane e i danni materiali ad edifici ed infrastrutture, occorre considerare il blocco dei sistemi informativi che può rallentare notevolmente la ripresa delle normali attività.

Le metodologie da impiegare per prevenire e mitigar i danni che possono compromettere la ripresa delle attività dopo un evento catastrofico riguardano la tematica della business continuity (continuità operativa).

Nell’intervento presentato lo scorso 17/11 al Convegno EVENTI SISMICI: PREVENZIONE, PROTEZIONE, SICUREZZA, EMERGENZA, le cui slide sonono scaricabili in questa pagina, si sono presentate tutte le attività da porre in essere per controllare tali situazioni indesiderate, in particolare sono stati trattati i seguenti argomenti:

  • business continuitymanagement
  • normative ISO 22301, ISO 2001/27002 e ISO 27031 per la gestione della business continuity, con particolare riferimento ai sistemi informatici
  • gestione dei rischi per la continuità operativa
  • disaster recovery
  • obiettivi ed indicatori di business continuity
  • business continuity plan (piano di continuità operativa).

La sicurezza dei dati in caso di terremoto




Cosa hanno in comune privacy, cloud computing e business continuity?

Montagna01In precedenti articoli (Il cloud computing e la PMI, i sistemi di gestione della sicurezza delle informazioni, ISO 22301 e la business continuity, le novità sulla privacy) abbiamo affrontato tutti questi argomenti che, indubbiamente, hanno un unico filo conduttore.

Oggi molte aziende, fra cui anche numerose PMI, hanno dati “nel cloud”, ovvero memorizzati in risorse fisiche non collocate all’interno dell’azienda, bensì su internet, magari senza rendersene conto. Infatti, oltre a veri e propri servizi cloud erogati da fornitori specializzati, molte PMI utilizzano servizi di archiviazione gratuiti quali SkyDrive, Dropbox o Google Drive in maniera non strutturata, in quanto sono propri reparti o uffici o addirittura singoli collaboratori che, per praticità, hanno pensato di sfruttare suddetti tool di archiviazione remota.

In altri casi alcune organizzazioni utilizzano software via web che memorizzano i dati su server remoti, magari presso il fornitore del software (spesso si tratta di Saas, Software as a Service).

Tra i principali aspetti negativi che hanno generato diffidenza sull’archiviazione nel cloud c’è sicuramente la sicurezza dei dati, declinata in termini di riservatezza. Molti imprenditori, infatti, hanno la sensazione che alcuni dati riservati (informazioni commerciali, proprietà intellettuale relativa a progetti, ecc.) debbano rimanere in azienda per paura che qualcuno li possa consultare.

Risk  assessmentNormalmente una PMI, specialmente una piccola impresa, non effettua un’adeguata valutazione dei rischi che corre e, pertanto, valuta questo argomento a sensazione, piuttosto che con fatti concreti. Quali sono infatti i rischi reali?

In una logica di Risk Assessment, naturalmente, ogni impresa fa storia a se; bisogna conoscere quali dati vorrebbe mettere sul cloud, qual è il livello di riservatezza che tali dati devono avere, se si tratta di dati sensibili, quali procedure di backup sono implementate, di che tipo di connessione internet si dispone e così via.

In linea generale parlare di dati poco sicuri nel cloud perché si teme che qualcuno possa “guardarci dentro” non ha molto senso: a parte che bisognerebbe valutare quale livello di sicurezza ci si aspetta per ogni tipo di dato (si veda il precedente articolo sulla valutazione dei rischi per la sicurezza delle informazioni), oggi molti repository di dati nel cloud forniscono ampie garanzie di sicurezza, soprattutto se sono gestiti da importanti player del settore, quali Microsoft, Google, Amazon, ecc.

Se, come al solito, decliniamo il termine Sicurezza in Riservatezza, Integrità e Disponibilità (ISO 27000 docet) e valutiamo nel complesso il livello di rischio che incombe sui dati nel cloud, vediamo che, a fronte di un livello di riservatezza più che adeguato (i dati di una PMI nel cloud normalmente sono sufficientemente protetti da sguardi indiscreti, grazie alle misure di sicurezza informatica che i fornitori più seri offrono ormai per default), certamente superiore a quello che si può ottenere all’interno dell’azienda stessa (dove potrebbero esserci soggetti interessati a curiosare dove non dovrebbero) la garanzia di integrità dei dati è più che buona, ma sulla disponibilità degli stessi occorre fare qualche riflessione.

Su quest’ultimo aspetto incide non solo l’affidabilità del fornitore di servizi cloud e dell’infrastruttura di cui dispone, ma anche la connessione internet che, ancora ogg,i non è sicuramente adeguata in molte imprese italiane, sia per velocità, sia per continuità del servizio. È proprio questo l’anello di congiunzione con la continuità operativa, più elegantemente detta business continuity.

Infine la privacy, ovvero la protezione dei dati personali con la relativa legge italiana (D.Lgs 196/2003) ed il nuovo Regolamento Europeo che sarà emanato probabilmente il prossimo anno. In questo ambito un Parere della Commissione Europea del 2012 ha per il momento fugato molti dubbi sulle garanzie legali che un’impresa dovrebbe richiedere al proprio fornitore di servizi cloud per essere tranquilla di non incorrere in pesanti problemi legali.

Uomo al PCProbabilmente molti contratti che regolamentano la fornitura di servizi cloud (spesso mascherati sotto la fornitura di software as a service) non cautelano adeguatamente l’organizzazione che, non dimentichiamolo, è titolare del trattamento dei dati memorizzati in un server chissà dove. È prassi consolidata, infatti, di numerosi fornitori di SaaS di spostare i database dei propri clienti nello spazio web più conveniente per rapporto qualità/prezzo, non importa se in Canada o in Australia In tali situazioni le aziende non dovrebbero dimenticare che come titolari del trattamento sono i responsabili di fronte alla legge su eventuali inosservanze del Codice della Privacy e che “esportare” i dati personali fuori dalla Comunità Europea non è sempre possibile, come minimo occorre richiedere il consenso dell’interessato.

Dunque quali interrogativi deve porsi un’azienda coscienziosa prima di affidare i propri dati al cloud?

Vediamo i principali, fermo restando che solo dopo una precisa valutazione dei rischi si può determinare quali aspetti sono più critici in ogni singola realtà.

  1. Il contratto con il fornitore mi garantisce adeguatamente rispetto alla normativa sulla privacy?
  2. Il livello di riservatezza necessario sui dati è adeguatamente garantito da misure di sicurezza dichiarate contrattualmente dal fornitore?
  3. La disponibilità dei dati garantita contrattualmente (SLA) è adeguata alle mie esigenze?
  4. Posso rientrare in possesso dei miei dati quando voglio e senza costi eccessivi?
  5. Il fornitore è sufficientemente affidabile? Si serve di subfornitori egualmente affidabili e resi noti contrattualmente?
  6. In caso di perdita dei dati quali sistemi di disaster recovery mi garantiscono di rientrare operativo nel più breve tempo possibile? Tale tempo è coerente con le mie esigenze operative?
  7. So esattamente in quale stato o area geografica sono memorizzati i miei dati?
  8. Ho considerato tutti i possibili fattori di rischio che possono incombere sulla mia continuità operativa?
  9. Ho definito gli obiettivi di disponibilità del servizio e di business continuity in caso di situazione di crisi?
  10. Sono in grado di monitorare il comportamento del fornitore ed eventualmente sottoporlo ad audit sul rispetto dei vincoli contrattuali?

Oggi esistono molti sistemi per garantirsi un futuro tranquillo con i dati nel cloud, ad esempio seguendo i principi ed i metodi indicati dalle norme della famiglia ISO 27000 (ISO 27001 che riporta i requisiti di un sistema di gestione della sicurezza delle informazioni certificabile, ISO 27002 che riporta le best practices, ovvero i controlli che possono essere messi in atto, ISO 27005 che è la linea guida per il risk assessment, …) includendovi i requisiti cogenti per la privacy in vigore in Italia ed in Europa. Se il problema di mantenere una certa continuità operativa costituisce un fattore critico si può adottare la metodologia esposta nella ISO 22301 ed in altri standard e linee guida sull’argomento.

Mediante gli stessi sistemi ci si può garantire in modo adeguato nei confronti del fornitore, ad esempio esaminando il contratto con un supporto legale competente, verificare se il fornitore dispone di certificazioni ISO 9001, ISO 27001, ISO 22301 oppure dispone di un Report SSAE 16 (“Statement on Standards for Attestation Engagements” n. 16 , standard AICPA per il reporting sui controlli alle organizzazioni che forniscono servizi in outsourcing, richiesto dalle aziende soggette al Sarbanes-Oxley Act o SOX,  Sezione 404).

Se ascoltiamo quello che ci raccontano gli esperti di sicurezza informatica che relazionano nei frequenti seminari o convegni sull’argomento non c’è certo da stare tranquilli nemmeno all’interno della propria azienda (tra ransomware e data leakage ogni tanto nascono minacce sempre più terrificanti per il futuro delle nostre imprese, senza dimenticare il comportamento dei collaboratori disonesti) e, quindi, un cloud consapevole può veramente essere una buona cosa.

Dall’altra parte la software house che fornisce applicazioni web-based con l’opzione di memorizzare i dati, anziché su un server interno all’azienda, su un server remoto (ovvero nel cloud) dovrebbe prendere in considerazione tutti gli aspetti sopra esposti, sia al fine di fornire un servizio pienamente conforme alle normative applicabili e di piena soddisfazione di tutte le esigenze del cliente, sia al fine di non incorrere in problemi legali nel caso in cui qualcosa andasse storto, anche solo a causa del proprio fornitore di servizi cloud. Dunque valutare quali tipi di dati verranno archiviati nel cloud dai propri clienti e quali garanzie forniscono i fornitori di spazio di archiviazione a cui ci si rivolge (le caratteristiche di un data center sicuro sono state esposte in un articolo apparso lo scorso anno sulla rivista INARCOS).

In conclusione, come per qualsiasi decisone o progetto strategico, le aziende (clienti e fornitori) dovrebbero valutare con adeguate competenze la situazione nel suo complesso ed i rischi che si potrebbe correre. Purtroppo tali competenze, informatiche, legali e gestionali spesso non sono presenti in piccole realtà poco strutturate che, quindi, rischiano di incorrere in problemi significativi e se poi trattano dati sensibili, in particolare dati sanitari, potrebbero veramente incorrere in perdite economiche e di immagine molto importanti.




La norma ISO 22301 per la certificazione della business continuity

business continuity management systemsLo standard ISO 22301 (Societal security — Business continuity management systems — Requirements) specifica i requisiti per progettare, implementare e gestire efficacemente un Sistema di gestione della continuità operativa.

Il sistema di gestione della continuità operativa (business continuity management system o BCMS) enfatizza l’importanza di:

  • comprendere le esigenze dell’organizzazione e le necessità per stabilire la politica e gli obiettivi di un sistema di gestione per la continuità del business;
  • implementare e rendere operativi controlli e misure per gestire la capacità di un’intera organizzazione nella gestione delle interruzioni dell’operatività dovute a cause accidentali;
  • monitorare e riesaminare le prestazioni e l’efficacia del sistema di gestione della continuità operativa
  • del miglioramento continuo del BCMS basato su obiettivi misurabili.

Si noti che anche la norma ISO/IEC 27031 “Information technology — Security techniques — Guidelines for information and communication technology readiness for business continuity” tratta la business continuity, ma nel contesto dell’ICT e delle tecniche di sicurezza strettamente correlata alla ISO 27001 che contiene i requisiti per la certificazione dei sistemi di gestione della sicurezza delle informazioni.

La ISO 22301 evidenzia i componenti chiave del sistema di gestione della continuità operativa, peraltro presenti anche in altri sistemi di gestione. Tra essi la politica, le persone con le loro responsabilità definite, la gestione dei processi correlati a politica, pianificazione, attuazione ed operatività del BCMS, valutazione delle prestazioni, riesame della direzione e miglioramento, nonché la documentazione in grado di fornire evidenze verificabili tramite audit sul sistema di gestione della continuità operativa.

Anche questa norma introduce il metodo del “PLAN DO CHECK ACT” già noto da altre norme dei sistemi di gestione. In particolare il modello PDCA del sistema di gestione della continuità operativa ha come input le parti interessate (clienti, proprietà/soci, dipendenti/collaboratori, fornitori, collettività) e i requisiti per la business continuity, mentre l’output del sistema è fornito alle stesse parti interessate ed è costituito dalla continuità operativa gestita.

Per questa norma il concetto di “parti interessate” o stakeholders è importante in quanto una discontinuità nell’operatività dell’organizzazione, una indisponibilità dei servizi essenziali per i clienti, un fermo delle attività produttive per un periodo più o meno lungo, possono causare danni non solo all’organizzazione stessa, ma soprattutto ai clienti che usufruiscono dei suoi prodotti/servizi e che quindi non riescono a lavorare proficuamente, ai fornitori che non possono rifornire i loro prodotti/servizi, ecc..

Scopo della norma per la gestione della business continuity è quello di specificare i requisiti atti a pianificare, stabilire, implementare, realizzare, monitorare, riesaminare, mantenere e migliorare in modo continuo un sistema di gestione documentato per proteggersi contro gli incidenti che possono accadere e fermare l’organizzazione, ma non solo. Il BCMS ha anche l’obiettivo di ridurre la probabilità che tali eventi negativi avvengono, prepararsi ad essi e rispondere in modo adeguato per ripristinare l’operatività nel più breve tempo possibile qualora l’incidente che causa lo stato di crisi si verifichi.

La norma ISO 22301 definisce alcuni termini specifici sulla materi,a tra cui il termine business continuity, business continuity management system, business impact analysis (BIA) ossia analisi di impatto sull’operatività dell’organizzazione.

Oltre ad altri termini consueti delle norme della serie ISO 9000 compare il nuovo termine informazione documentata, che ritroveremo nella nuova edizione della norma ISO 9001. Altro termine significativo mutuato dalle norme della serie ISO 27000 è quello di incidente che è definito come una situazione che potrebbe rappresentare o potrebbe portare a una distruzione, una perdita, uno stato di emergenza o una crisi. Al proposito la norma utilizza spesso il termine disruption che rappresenta un atto o un evento che interrompe la continuità (e genera discontinuità).

Sono anche fornite le classiche definizione legate alla gestione del rischio (risk assessment, risk management, rischio) tra cui il risk appetiteamount and type of risk that an organization is willing to pursue or retain») ovvero la propensione al rischio dell’organizzazione che, si vedrà in seguito, dovrà essere identificata al fine di intraprendere azioni di prevenzione idonee.

Vengono poi definiti degli indicatori specifici per questa tematica come:

  • Maximum Acceptable Outage (MAO) ovvero il tempo massimo ritenuto accettabile che può trascorrere – a fronte di un evento avverso – durante il quale non viene fornito un prodotto/servizio o bon viene svolta un’attività.
  • Maximum Tolerable Period of Disruption (MTPD) ovvero il tempo massimo tollerabile che può trascorrere a fronte degli impatti negativi conseguenti ad un incidente come risultato della mancata fornitura di un prodotto, erogazione di un servizio o svolgimento di un’attività operativa. SI noti che rispetto al MAO precedente il MTPD è un periodo potenzialmente superiore in quanto si può presumere che gli impatti negativi di una interruzione di un servizio possano durare più a lungo dell’interruzione stessa.
  • Minimum Business Continuity Objective (MBCO) che rappresenta il livello di servizio minimo accettabile dall’organizzazione per raggiungere i propri obiettivi di business durante una l’interruzione della continuità dovuta all’incidente (periodo di crisi)
  • Recovery Point Objective (RPO) ovvero il punto (l’istante nel tempo) al quale le informazioni sono coerenti e possono essere ripristinate per consentire la ripresa delle attività (denominato anche Maximum Data Loss).
  • Recovery Time Objective (RTO): periodo di tempo entro il quale i servizi erogati, la produzione, i servizi di supporto e le funzionalità operative devono essere ripristinati dopo l’incidente che ha generato la discontinuità.

Il capitolo 4 della norma denominato “Contesto dell’organizzazione” – che ritroveremo nella nuova ISO 9001 del 2015 – contiene gli elementi per comprendere il contesto dell’organizzazione (punto 4.1 della norma). La norma stabilisce che nell’ambito del Sistema di gestione per la continuità operativa debbono essere identificati i bisogni dell’organizzazione e delle sue parti interessate, che dovranno essere tenuti in debito conto nella progettazione del sistema di gestione dell’organizzazione, la quale dovrà anche identificare e documentare le attività svolte dall’organizzazione stessa, le sue funzioni, i servizi, i prodotti e tutto ciò che è necessario per identificare i potenziali impatti legati a incidenti distruttivi che possono generare discontinuità operativa.

Inoltre dovranno essere documentati i collegamenti tra la politica per la continuità operativa e gli obiettivi dell’organizzazione e la sua politica, inclusa una strategia generale di gestione dei rischi e l’approccio dell’organizzazione ai rischi correlati alla business continuity, ovvero la propria propensione al rischio.

Al punto 4.2 sono descritti gli aspetti riguardanti la comprensione delle esigenze delle parti interessate, ovvero i requisiti legali e regolamentari cui l’organizzazione è soggetta. Ciò aiuterà nella definizione dello scopo e campo di applicazione del sistema di gestione di continuità operativa (4.3). A tale riguardo la norma stabilisce le modalità attraverso le quali l’organizzazione deve stabilire quali processi prodotti e servizi sono compresi nel sistema di gestione e quali parti dell’organizzazione agiscono all’interno di esso, dettagliando eventuali esclusioni che, comunque, non possono influenzare negativamente i risultati del sistema di gestione.

Al punto 4.4 la norma stabilisce che l’organizzazione deve implementare, mantenere attivo e migliorare continuamente un sistema di gestione della continuità operativa, inclusi i processi necessari e le relative interazioni fra essi, in accordo con i requisiti di questo standard internazionale (ISO 22301).

Il capitolo 5 della norma è denominato “Leadership”. In esso la norma stabilisce che l’alta direzione (ovvero il top management) deve possedere leadership e dimostrare un impegno preciso rispetto al sistema di gestione per la continuità operativa. L’impegno del management viene poi esplicitato attraverso una serie di responsabilità della direzione relative al sistema di gestione quali, ad esempio, assicurare che politiche ed obiettivi siano stabiliti, che le risorse necessarie siano messe a disposizione e che vi sia un’adeguata comunicazione all’interno dell’organizzazione relativamente ai requisiti del sistema di gestione della continuità operativa.

Sono poi stabiliti requisiti relativi alla definizione della politica per la continuità operativa e la definizione della struttura organizzativa dell’organizzazione, quindi la definizione di ruoli responsabilità ed autorità. Questi ultimi due paragrafi risultano perfettamente simili a quelli delle altre norme sui sistemi di gestione, in particolare la nuova ISO 9001:2015.

Il capitolo 6 denominato ”Pianificazione” i stabilisce che:

  • L’organizzazione deve porre in essere azioni rivolte ai rischi ed alle opportunità, in particolare assicurando che il sistema riesca a perseguire gli obiettivi ed i risultati stabiliti, prevenire o ridurre gli effetti indesiderati e mirare al miglioramento continuo.
  • Vengano definiti obiettivi per la business continuity e piani per raggiungerli; tale aspetto, con le dovute modifiche, è del tutto analogo ad altri sistemi di gestione: gli obiettivi devono essere misurabili, devono essere monitorati, occorre stabilire chi è responsabile, che cosa deve fare, quali risorse sono richieste, quando dovranno essere completate le azioni finalizzate al perseguimento degli obiettivi e come dovranno essere valutati i risultati. Unica differenza rispetto ad altri sistemi di gestione è che nella definizione degli obiettivi bisognerà tenere conto di un livello minimo di servizio o di prodotto fornito ritenuto accettabile dall’organizzazione nel raggiungimento dei suoi obiettivi.

Il capitolo 7 della norma denominato “Supporto” stabilisce i requisiti per alcune attività e processi di supporto, quali – in generale – la gestione delle risorse, le competenze del personale, la consapevolezza dello stesso personale relativamente al sistema di gestione della continuità operativa e la comunicazione, sia essa interna che esterna. In particolare, per questo tipo di sistema di gestione, le modalità ed i mezzi di comunicazione sono molto importanti per garantire la continuità del servizio anche durante i periodi di indisponibilità delle risorse critiche.

Infine l’ultimo paragrafo di questo capitolo è dedicato alle informazioni documentate, in completa analogia con il nuovo schema delle norme relative ai sistemi di gestione. I requisiti relativi alle informazioni documentate riguardano le modalità di gestione di documenti, dei dati e delle registrazioni richieste dalla norma.

A questo riguardo è opportuno precisare che, nell’ambito della business continuity, i documenti – in particolare le procedure e le istruzioni operative – necessarie per ripristinare nel più breve tempo possibile i servizi richiesti durante i periodi di crisi, dovrebbero essere accessibili dai responsabili nominati, dunque occorre prevedere supporti alternativi per i documenti che potrebbero non essere disponibili nel formato originario, su supporto elettronico o cartaceo. Pertanto tali documenti dovrebbero essere resi disponibili su supporti realmente utilizzabili in funzione del tipo di crisi (scenario) previsto in fase di pianificazione.

Il capitolo 8 della norma denominato “Operation”, la cui traduzione in lingua italiana è piuttosto incerta, rappresenta il cuore di questa normativa ISO 22301 in quanto tratta gli aspetti di pianificazione e controllo dei processi operativi, la valutazione dei rischi e l’analisi di impatto, ovvero la business impact analysis (BIA), ed infine la strategia di business continuity ovvero tutto ciò che l’organizzazione intende fare per garantire la continuità operativa, compresa la definizione dei business continuity plan o piani di continuità operativa, la loro applicazione e test.

Nei suddetti paragrafi sella sezione 8 vengono specificate, tra l’altro, le modalità di effettuazione e documentazione della business impact analysis (analisi gestionale attraverso la quale un’organizzazione valuta quantitativamente e qualitativamente gli impatti e le perdite che possono risultare se l’organizzazione stessa subisce un grave incidente, nonché il livello minimo di risorse necessarie per il ripristino dell’operatività) e della valutazione del dei rischi, per la quale può essere preso come riferimento quanto indicato nella ISO 31000  (ora anche UNI ISO 31000 – Gestione del rischio – Principi e linee guida). Occorre precisare che sia l’analiso di impatto sia la valutazione dei rischi dovranno prendere in considerazione i rischi che possono impattare la continuità operativa, quindi i rischi che si verifichino incidenti distruttivi che portino a situazioni di crisi o comunque di interruzione dell’operatività e, conseguentemente, a situazioni insostenibili per la propensione al rischio definita per l’organizzazione. A fronte di tali situazioni, in base ai risultati della valutazione dei rischi, dovranno essere determinate e poste in essere le azioni conseguenti per mantenere la continuità operativa.

Il capitolo 9 della norma tratta la “Valutazione delle prestazioni”. Vengono qui illustrati i requisiti relativi al monitoraggio, alla misurazioni, all’analisi ed alla valutazione dei processi che hanno un impatto sulla continuità operativa; in particolare vengono esplicitati i requisiti relativi ad indicatori e metriche finalizzate al monitoraggio della business continuity, sempre basandosi sui risultati della valutazione dei rischi.

Nel capitolo 9 vengono anche trattati i requisiti standard per i sistemi di gestione riguardanti gli audit interni ed il riesame del sistema da parte della direzione. Anche qui, rispetto alle altre normative sui sistemi di gestione, il focus è sui rischi risultanti dal risk assessment.

Nel capitolo 10, denominato “Miglioramento”, sono trattati le non conformità, le azioni correttive ed il miglioramento continuo. Mentre relativamente a non conformità ed azioni correttive la gestione è analoga ai sistemi gestionali descritti nelle normative del passato (ISO 9001 in primis), occorre notare che è scomparso il termine azione preventiva, sostituita da tutte quelle azioni che vengono messe in atto al fine di perseguire il miglioramento continuo del sistema e delle sue prestazioni. Premesso ciò, le non conformità relative al sistema di gestione della continuità operative – normalmente incidenti ed altre situazioni nelle quali si verifica il non soddisfacimento dei requisiti procedurali – dovranno essere identificate e dovranno essere attuate prontamente correzioni per eliminare, quando possibile, gli effetti della non conformità stessa e le relative conseguenze. Inoltre si deve valutare la necessità di intraprendere azioni correttive finalizzate ad eliminare le cause della non conformità.

In conclusione si tratta di una norma che presenta per la prima volta, insieme alla nuova ISO 27001:2013 appena pubblicata, la nuova struttura delle normative sui sistemi di gestione che ritroveremo nella ISO 9001 del 2015. Evidentemente le organizzazioni che vorranno adeguarsi a tale normativa e certificarsi secondo le proprie esigenze di business, quasi certamente avranno già messo in atto e certificato un sistema di gestione per la qualità ISO 9001, ma probabilmente alcune di queste organizzazioni avranno anche già implementato il sistema di gestione della sicurezza delle informazioni ISO 27001, pertanto lo sforzo per conformarsi a questa norma sulla business continuity non sarà eccessivo. Infatti molti requisiti sono comuni fra la norma ISO 22301 e la norma ISO 27001 nella quale esiste già un obiettivo di controllo riguardante la continuità operativa che impone di predisporre uno o più business continuity plan per garantire la continuità nell’erogazione del servizio o nella produzione.

Al proposito occorre notare che la norma tratta la gestione di tutti i tipi di discontinuità o interruzioni di servizio, non necessariamente solo quelli legati all’indisponibilità dei sistemi informatici, anche se quasi tutte le organizzazioni vedono come principale pericolo per la propria continuità operativa il blocco dei sistemi informatici che ormai governano quasi tutte le attività aziendali.

Quali saranno, infine, le organizzazioni interessate a certificarsi secondo la ISO 22301? Probabilmente tutte le organizzazioni che operano nel settore dei servizi, anche pubblici, e che devono garantire ai propri clienti una certa continuità del servizio, ovvero banche, assicurazioni, fornitori di servizi in outsourcing, fornitori di servizi sul cloud ((si veda il parere della Commisione Europea al riguardo) o comunque servizi Web, fornitori di servizi di assistenza tecnica in settori particolarmente critici.

Le principali normative sull’argomento richiamate esplicitamente o implicitamente da questa norma sono le seguenti:

  • ISO 22300, Societal security — Terminology
  • ISO/IEC 27031, Information technology — Security techniques — Guidelines for information and communication technology readiness for business continuity
  • BS 25999-1, Business continuity management — Code of practice
  • BS 25999-2, Business continuity management — Specification
  • UNI ISO 31000 – Gestione del rischio – Principi e linee guida

La continuità operativa per la Pubblica Amministrazione nel Codice per l’Amministrazione Digitale: vai al sito DIGITPA

Aggiornamento: Oggi disponibile anche in italiano la norma UNI EN ISO 22301:2014 Sicurezza della società – Sistemi di gestione della continuità operativa – Requisiti