La Business Continuity nella gestione di un evento elettorale

Cosa potrà mai andare storto?
La Business Continuity nella gestione di un evento elettorale

A cura di Massimo Poletti

Ogni servizio erogato, digitale o meno, prevede modalità operative che generano una ragionevole aspettativa nell’utenza. In gergo tecnico, tali modalità vengono definite SLA (Service Level Agreement). Un esempio basico di SLA è il cartello con gli orari di apertura del fruttivendolo di quartiere: trovare il negozio chiuso quando dovrebbe essere aperto rappresenta un mancato rispetto del livello di servizio atteso. Il ripetersi dell’evento può allontanare il cliente che potrebbe preferire un altro esercizio.

Nel mondo ICT le variabili in gioco sono moltissime e ci sono servizi che, perlomeno in teoria, dovrebbero essere garantiti anche in caso di imprevisti. Negli anni trascorsi gestendo infrastrutture in ambito sanitario ho sempre cercato di adottare tutte le ridondanze ragionevolmente possibili (le risorse non sono infinite) data la criticità dell’ambiente o di sue parti.

Naturalmente le ridondanze per garantire la continuità di un servizio digitale possono essere anche analogiche. Ad esempio, in caso di indisponibilità della procedura informatica per le richieste di prestazioni di laboratorio in Pronto Soccorso veniva allertato un messo incaricato di fare fisicamente la spola con il laboratorio portando le richieste e ritirando le risposte.

L’organizzazione dell’evento elettorale di giugno 2025 comporta, per le Amministrazioni Comunali, un’intensa attività da parte delle OO.PP. (allestimento seggi, cartellonistica, ecc.), della Polizia Locale, dell’Ufficio Elettorale (aggiornamento elenchi, spedizione tessere, rilascio duplicati, ecc.) e, naturalmente, dell’ICT.

I seggi da gestire sono 160, distribuiti in 51 plessi diversi, per un totale di circa 101mila elettori. In ogni plesso c’è un incaricato che raccoglie le informazioni dai presidenti di seggio. Per i plessi principali i dati raccolti vengono inseriti nel programma elettorale direttamente in loco, utilizzando un notebook, mentre per gli altri la trasmissione avviene tramite “fonogramma”, termine tecnico che indica una telefonata che segue un preciso protocollo per la dettatura dei dati.

La corretta metodologia prevede un’analisi del rischio. Nel nostro caso come è avvenuta in pratica? Ci siamo riuniti, abbiamo definito lo scenario nella maniera più completa possibile e abbiamo fatto un brainstorming ipotizzando tutti gli imprevisti immaginabili. Lo scopo è garantire che le operazioni di spoglio e l’invio dei dati al Ministero dell’Interno avvengano nei tempi standard previsti.

Scenario operativo (weekend elettorale: sabato-lunedì)

• L’Ufficio Elettorale deve poter rilasciare a vista le tessere elettorali (utilizzando la procedura anagrafica) dalla mattina di sabato fino alle 15 del lunedì.
  • La procedura elettorale deve funzionare da domenica per raccogliere le affluenze e da lunedì ore 15 per l’inserimento dei voti, la generazione in tempo reale delle pagine web relative allo spoglio e l’invio automatico dei dati al Ministero dell’Interno (portale Eligendo).
  • Le postazioni di data entry, collocate in 10 plessi scolastici (36 seggi, con notebook a noleggio), devono potersi connettere all’applicativo elettorale dalle 15 del lunedì fino al termine dello spoglio. Sono dotate di “saponette” per la connessione Internet. È la prima volta che viene sperimentata questa modalità. Se l’esito sarà soddisfacente la estenderemo in futuro a tutti i plessi con almeno tre seggi.
  • La sala data entry presso l’Ufficio Elettorale deve poter ricevere telefonate dai seggi residuali (dotati di cellulare) per inserire manualmente i dati nella procedura.

Continuità operativa da garantire

• delle procedure (anagrafica e elettorale)
  • delle postazioni tessere
  • della sala data entry
  • della comunicazione dai seggi (via data entry diretto o via telefonica)

Cosa potrebbe andare storto?

Ecco un elenco non esaustivo (non dimentichiamo il chiodo che ha fermato le ferrovie) degli imprevisti considerati, con le relative azioni di mitigazione:

• Blocco delle procedure anagrafica e/o elettorale: trattandosi di servizi in cloud SaaS certificati ACN, la continuità nel funzionamento delle procedure è considerata garantita. Tuttavia, è stato attivato un servizio di assistenza telefonica per supportare eventuali difficoltà operative tenendo conto che si tratta di ambienti attivati solo saltuariamente e che molti operatori sono alla prima esperienza. Con il medesimo canale si possono ovviamente segnalare eventuali problemi di procedura.
• Malfunzionamenti nelle postazioni tessere o data entry: presenza fissa di un tecnico per l’assistenza postazioni e disponibilità di PC “muletto” in loco.
• Guasti nelle infrastrutture aziendali: reperibilità dell’assistenza sistemistica e presenza di tecnici interni per interventi negli armadi di rete, con switch di riserva pronti all’uso. In caso di problemi elettrici, è attiva la reperibilità della manutenzione OO.PP.
• Indisponibilità della connettività: in caso di problemi del provider (Lepida Scpa), sono disponibili saponette da utilizzare come hotspot per le postazioni. Per i PC fissi sono previste chiavette USB per il collegamento WiFi.
• Malfunzionamento del sistema telefonico comunale: assistenza telefonica in reperibilità e disponibilità di cellulari di riserva per gli operatori del data entry. Abbiamo un “arsenale” di cellulari base, destinati esclusivamente alle elezioni o ad
  altre emergenze
• Problemi nei PC dei plessi scolastici: abbiamo inserito nelle borse cavi di alimentazione sia Schuko che a pettine. In caso di guasti agli apparati, gli operatori procederanno con l’inserimento manuale, comunicando via telefono con la sala data entry.
• E se ci fossimo dimenticati qualcosa? Si mitiga con il buon senso, risorsa fondamentale in ogni reparto ICT.

Considerazioni finali

È stato necessario attivare varie reperibilità straordinarie e noleggiare notebook, con la conseguente gestione degli atti amministrativi, del ciclo degli acquisti, della logistica e del presidio tecnico.

Pur trattandosi di attività ormai consolidate (ci sono elezioni quasi ogni anno), è comunque necessario riconsiderare ogni volta il contesto: può essere cambiato qualcosa (infatti questa volta abbiamo il data entry dai seggi) e potrebbero emergere nuovi rischi.

Questo è un caso emblematico di gestione del rischio e della continuità operativa ICT in un Comune. Vorrei concludere con una riflessione più ampia sugli enti pubblici e la loro capacità di erogare servizi.

Le normative – in primis il GDPR e la NIS2 – impongono analisi del rischio per valutare minacce ai dati e alla continuità operativa. Ma le variabili sono tante, e cambiano rapidamente.

Esistono contesti sicuramente molto controllati: ad esempio, nel Comando della Polizia Locale gli ingressi sono presidiati e i locali tecnici chiusi a chiave. Ma in enti con decine di sedi, grandi e piccole, non sempre è così semplice: può capitare che in una piccola delegazione l’accesso al locale tecnico non sia vigilato, o che in certi giorni la sede sia chiusa ma vulnerabile alle intrusioni, esponendo a rischio di accesso non autorizzato gli switch di rete. Anche in sedi principali ci sono armadi periferici accessibili.

In questi casi servirebbe un sistema di Network Access Control (NAC), tecnologia complessa e dai costi non trascurabili.

Serve quindi, a mio avviso, una logica di miglioramento continuo. Piccoli passi, ma costanti. Questo però richiede un impegno che non può ricadere solo sull’ICT: deve essere l’intera organizzazione a integrare nel proprio processo “sicurezza e continuità operativa” la volontà di investire risorse per costruire progressivamente una postura ottimale.

Che ci sia o meno una norma come la NIS2 a responsabilizzare i vertici.