Quando tutti fanno correttamente il proprio lavoro, ma nessuno governa il problema nel suo insieme.
Gli incidenti accadono. Come la pioggia, non dipendono dalla nostra volontà: possiamo prevederli, ridurne gli effetti, attrezzarci, ma non possiamo decidere che non arrivino. Ciò che dipende da noi è un’altra cosa: sapere chi fa che cosa quando arrivano.
Immaginiamo un grande evento. È sera, migliaia di persone stanno lasciando l’impianto e tutto procede regolarmente. La security ha aperto i varchi previsti, gli steward indirizzano il pubblico, la polizia presidia la viabilità e il servizio di trasporto gestisce il deflusso dei passeggeri.
Poi una stazione della metropolitana viene temporaneamente chiusa.
La comunicazione arriva alla sala operativa, ma nessuna regola stabilisce chi debba girarla agli operatori sul terreno, con quale canale e in quanto tempo. Alcuni la ricevono, altri no. Il pubblico continua a dirigersi verso la stazione, mentre altre persone tornano indietro cercando un percorso alternativo. In pochi minuti due flussi si incrociano in uno spazio che non era stato progettato per quella situazione.
Nessuna organizzazione ha violato le proprie procedure. Ognuna ha svolto il proprio compito, nel rispetto di competenze e ruoli.
Eppure il sistema non ha funzionato.
Il problema non era dentro una delle organizzazioni. Era nello spazio tra le organizzazioni.
La sicurezza organizzata per compartimenti
Le organizzazioni moderne sono strutturate per funzioni. È normale, ed è anche necessario. La security si occupa delle minacce intenzionali, la safety della prevenzione degli incidenti e della tutela delle persone, l’IT dei sistemi informatici, le operations del funzionamento delle attività. Poi ci sono risorse umane, manutenzione, logistica, fornitori e istituzioni. Ognuno ha competenze, responsabilità e procedure definite.
Il problema nasce quando un rischio attraversa più funzioni contemporaneamente.
Pensiamo a un magazzino logistico. Un guasto al sistema di controllo accessi può sembrare un problema tecnico. Ma se impedisce ai dipendenti di entrare, blocca le operazioni. Se invece lascia aperti alcuni varchi, diventa un problema di security. Se coinvolge le uscite di emergenza, entra in gioco anche la safety. Lo stesso evento produce conseguenze diverse, che devono essere valutate e gestite insieme.
Eppure, in molte organizzazioni, ciascuna funzione continua a guardarlo attraverso il proprio perimetro di competenza.
Il rischio non rispetta l’organigramma.
Responsabilità formalmente corrette, rischio scoperto
Una delle situazioni più insidiose si verifica quando tutte le responsabilità sono state attribuite, ma nessuno ha il compito di valutare le conseguenze delle loro interazioni.
Un fornitore gestisce la videosorveglianza, un altro il controllo accessi. La vigilanza è affidata a un istituto esterno, la manutenzione dipende da un ufficio tecnico e le procedure di emergenza da un’altra funzione. Tutto perfettamente legittimo.
Ma chi verifica che questi elementi funzionino insieme? Chi stabilisce cosa deve accadere se un sistema smette di funzionare mentre un altro segnala un’anomalia? E soprattutto, chi ha l’autorità per decidere quali attività mantenere operative e quali sospendere?
Non sono domande teoriche. Devono trovare risposta prima che si verifichi un incidente, perché durante un’emergenza il tempo impiegato a stabilire chi debba decidere è tempo sottratto alla gestione del problema.
Coordinare non significa comandare tutti
Qui entra in gioco un equivoco abbastanza diffuso. Quando si parla di coordinamento si immagina spesso una struttura gerarchica nella quale qualcuno impartisce ordini e tutti gli altri eseguono. Nei sistemi complessi non funziona così.
Durante un grande evento le organizzazioni coinvolte mantengono responsabilità, competenze e catene di comando differenti. Nessun Security Manager può sostituirsi alle autorità di pubblica sicurezza, ai servizi di emergenza o ai gestori delle infrastrutture, e non dovrebbe nemmeno provarci.
Il coordinamento consiste piuttosto nel costruire un sistema in cui le informazioni circolino, le responsabilità siano comprese e le decisioni siano prese da chi ne ha effettivamente l’autorità. È il tema che la ISO 22320:2018, dedicata alla gestione degli incidenti, affronta esplicitamente: ruoli, responsabilità, flussi informativi e cooperazione tra organizzazioni diverse.
Il coordinamento non elimina le responsabilità individuali. Impedisce che diventino compartimenti stagni.
Le procedure non bastano
Un’organizzazione può avere un numero impressionante di procedure e continuare a essere vulnerabile: piano di emergenza, piano di continuità operativa (il riferimento è la ISO 22301), procedure di accesso, protocolli di comunicazione, contratti che definiscono minuziosamente gli obblighi dei fornitori. Tutti documenti utili. Ma la loro esistenza non dimostra che il sistema sia capace di affrontare una situazione complessa. Per verificarlo bisogna metterlo alla prova.
Uno degli strumenti più efficaci è il tabletop exercise: un’esercitazione nella quale i responsabili delle diverse funzioni affrontano insieme uno scenario simulato e devono decidere come reagire. Non servono effetti speciali o centinaia di partecipanti. A volte bastano una stanza, una planimetria e una domanda ben costruita.
Per esempio: sono le 18:30, il magazzino è pienamente operativo, il controllo accessi non funziona e il fornitore comunica che il ripristino richiederà almeno quattro ore. Nel frattempo viene segnalata una persona non autorizzata all’interno dell’area logistica. Chi viene informato? Chi valuta se sospendere le attività? Quali misure compensative si possono adottare, e chi le autorizza? Chi comunica la decisione ai dipendenti?
Spesso è proprio in queste esercitazioni che emergono le criticità più interessanti. Non perché manchino le procedure, ma perché ciascuno scopre che la propria procedura presuppone un’azione che qualcun altro non sapeva di dover compiere.
Da dove si comincia
Individuare il problema è metà del lavoro. L’altra metà è costruire, prima dell’evento, alcuni elementi semplici e verificabili:
- Un responsabile per i rischi trasversali. Per ogni rischio che attraversa più funzioni deve esistere un nome, non un comitato: chi lo monitora, chi lo porta all’attenzione di chi decide.
- Una matrice di escalation e di autorità decisionale. Chi può sospendere un’attività, chi può accettare un rischio residuo, chi decide quando le informazioni sono incomplete, e cosa accade se due responsabili valutano la stessa situazione in modo diverso.
- Un registro dei rischi condiviso. Non uno per funzione, ma uno che renda visibili le dipendenze tra funzioni, fornitori e sistemi.
- Canali e tempi di comunicazione definiti in anticipo. Chi informa chi, con quale mezzo, entro quanto tempo, e come si verifica che il messaggio sia arrivato.
- Esercitazioni periodiche con tutti al tavolo, fornitori compresi, e una revisione delle procedure sulla base di ciò che emerge.
Non si tratta di inventare nuove strutture burocratiche, ma di verificare se quelle esistenti siano realmente capaci di lavorare insieme.
La governance comincia dalle domande scomode
Il risk management non consiste soltanto nell’attribuire a ogni minaccia una probabilità e un impatto. Consiste anche nel capire come un’organizzazione prende decisioni rispetto a quelle minacce. La ISO 31000:2018 insiste proprio sull’integrazione della gestione del rischio nella governance, nella strategia e nei processi decisionali. La ISO 22361:2022, sulla gestione delle crisi, porta lo stesso principio nel momento più delicato: leadership, decisioni e comunicazione quando le informazioni sono incomplete e il tempo è poco.
Se le risposte alle domande sopra non sono chiare, abbiamo individuato una vulnerabilità organizzativa. Non necessariamente un errore, ma certamente qualcosa che merita attenzione.
La sicurezza non è la somma delle sue parti
Quando effettuiamo un security assessment siamo naturalmente portati a osservare ciò che possiamo vedere: accessi, recinzioni, telecamere, illuminazione, procedure, personale, sistemi tecnologici. Sono tutti elementi importanti. Ma alcune delle vulnerabilità più significative non sono visibili durante un sopralluogo. Non hanno una posizione sulla planimetria e non possono essere fotografate. Si trovano nei passaggi di responsabilità, nelle comunicazioni che diamo per scontate, nelle decisioni che nessuno sa di dover prendere.
Un cancello aperto è una vulnerabilità evidente. Un’organizzazione nella quale nessuno sa chi debba autorizzarne la chiusura può essere una vulnerabilità molto più difficile da riconoscere, e forse più pericolosa.
Un sistema composto da elementi eccellenti non è automaticamente un sistema eccellente: la sua efficacia dipende dalle relazioni tra quegli elementi, dalla capacità di condividere informazioni e dalla chiarezza con cui vengono assunte le decisioni. È qui che la security smette di essere soltanto una funzione operativa e diventa una questione di governance.
Non possiamo decidere quando pioverà. Possiamo però decidere, in anticipo, chi ha l’ombrello e chi ha l’autorità di decidere quando aprirlo. Quando qualcosa va storto, il problema raramente ha il garbo di rispettare i confini delle nostre competenze.
Siamo davvero sicuri che tutti i rischi della nostra organizzazione abbiano qualcuno che se ne occupa? O abbiamo distribuito così bene le responsabilità da lasciare scoperto ciò che le collega?
Fonti essenziali
- ISO 31000:2018 — Risk management — Guidelines. Principi, quadro di riferimento e processi per la gestione del rischio.
- ISO 22320:2018 — Security and resilience — Emergency management — Guidelines for incident management. Ruoli, responsabilità e cooperazione nella gestione degli incidenti.
- ISO 22361:2022 — Security and resilience — Crisis management — Guidelines. Leadership, processi decisionali, comunicazione e preparazione alla gestione delle crisi.
- ISO 22301:2019 — Security and resilience — Business continuity management systems — Requirements. Continuità operativa. (In probabile aggiornamento a breve, ISO/CD 22301)
Gli scenari descritti sono esempi ipotetici utilizzati per illustrare criticità organizzative e non si riferiscono a eventi o aziende specifiche.
Lascia un commento