Il problema reale: un’applicativo demografico inattivo
Lunedì, ore 8:40. L’applicativo dei servizi demografici non risponde. Allo sportello ci sono già tre persone in fila: una deve ritirare un certificato, una ha appuntamento per la carta d’identità, una è lì per un cambio di residenza. Il responsabile dell’ufficio prende il telefono e chiama l’informatico: “Quando torna su?”. È una domanda legittima, ma è la domanda sbagliata, fatta nel momento sbagliato.
La domanda giusta doveva essere posta sei mesi prima: “Quanto tempo possiamo restare fermi? E cosa facciamo nel frattempo?”. Questa semplice inversione di tempistica evidenzia come la continuità del servizio sia un problema di pianificazione, non di reazione.
Una scena ricorrente in decine di comuni
Lavorando con numerosi comuni, ho osservato la medesima dinamica con piccole varianti: cambia l’ufficio, cambia l’applicativo, non cambia la convinzione di fondo. La continuità del servizio è, in fin dei conti, un problema dell’ICT, ma è anche, e soprattutto, un problema di governance.
La catena invisibile che sostiene un servizio digitale
Per chi lavora in un ufficio, il servizio digitale funziona come una lampadina: premi l’interruttore e si accende. Nessuno si chiede da quale centrale arrivi la corrente, finché non salta. Dietro la “lampadina” di un servizio comunale, però, c’è una catena lunga: il PC dell’operatore, la rete, il server o il data center del fornitore, l’applicativo, il database, le integrazioni con piattaforme nazionali come ANPR, pagoPA e App IO, la connettività, l’alimentazione elettrica.
Ogni anello può rompersi. E quando si rompe, il servizio si ferma, a prescindere da chi abbia la colpa.
Responsabilità condivise, non un solo “colpevole”
Delegare tutto all’ICT sembra prudenza: “non è il mio mestiere, se ne occupano i tecnici”. In realtà è una forma di evitamento. L’ICT sa come ripristinare un server, ma non sa quanto costa all’ente un giorno di anagrafe ferma, quali scadenze di legge scattano se il protocollo non registra, quali pratiche non possono attendere. Queste informazioni le ha solo chi il servizio lo eroga.
Tre livelli di responsabilità
Diciamolo chiaramente: la continuità operativa non è “compito dell’ICT”. Ma non è nemmeno solo compito del responsabile del servizio. È una responsabilità su tre livelli, e il guaio nasce quando uno dei tre fa finta che non lo riguardi.
Chi gestisce tributi, anagrafe, protocollo, SUAP o servizi sociali deve saper dire quanto il servizio può restare fermo, quanti dati può permettersi di perdere, quali attività sono critiche e quali possono attendere, come si lavora se il sistema non c’è. Senza queste risposte l’ICT tira a indovinare. E di solito indovina male: o sovradimensiona, spendendo troppo, o sottodimensiona, e lo scopre al primo guasto.
Il ruolo dell’ICT
Il compito dell’ICT, interno o esterno, è tradurre quei requisiti in soluzioni: backup, replica, ridondanza, contratti con livelli di servizio adeguati, test periodici di ripristino. E dire con chiarezza quando un requisito costa più di quanto l’ente può spendere.
Sindaco, giunta, segretario, dirigenti: tocca a loro decidere quanto rischio accettare e quante risorse investire. Non è un dettaglio tecnico, è una scelta di governo.
Quadro normativo: NIS2 e GDPR
Non è solo buon senso organizzativo. Il D.Lgs. 138/2024, che recepisce la direttiva NIS2, all’articolo 23 chiama in causa direttamente gli organi di amministrazione e direzione: sono loro ad approvare le misure di gestione del rischio e a risponderne. Va detto con precisione: tra gli enti locali la norma riguarda città metropolitane, comuni sopra i 100.000 abitanti e capoluoghi di regione.
Per la gran parte dei comuni italiani non è un obbligo diretto. Ma è il modello verso cui si muove tutto il sistema, e la logica vale per chiunque: la responsabilità sta in alto e sta nel servizio, non nella sala server.
C’è poi il GDPR, che vale per tutti: l’articolo 32 chiede al titolare del trattamento di garantire la capacità di ripristinare tempestivamente disponibilità e accesso ai dati personali in caso di incidente. Il titolare è l’ente, non il tecnico.
Concetti chiave da conoscere
- Backup. È una copia dei dati conservata separatamente dall’originale. La domanda vera è: dove sta la copia, e qualcuno ha mai provato a ripristinarla? Un backup mai testato è una speranza, non una garanzia.
- Retention. È il tempo per cui si conservano le copie. Se un errore o una manomissione vengono scoperti dopo tre settimane e i backup coprono solo gli ultimi sette giorni, si sono conservate solo copie del dato già sbagliato.
- Disaster recovery. È il piano per riattivare i sistemi dopo un evento grave: incendio, allagamento, attacco informatico, guasto del data center. Non è il backup, è ciò che serve per tornare operativi usando il backup.
- RTO (Recovery Time Objective). È il tempo massimo entro cui il servizio deve tornare disponibile. Quattro ore? Due giorni? Una settimana? Dipende dal servizio, ed è il responsabile che deve dirlo.
- RPO (Recovery Point Objective). È la quantità massima di dati che si può perdere, misurata in tempo. Un RPO di 24 ore significa accettare di rifare il lavoro di un giorno intero.
Il prezzo della resilienza
Il punto è che RTO e RPO non sono parametri tecnici. Sono decisioni di servizio con un prezzo: più si abbassano, più costa la soluzione. È esattamente il tipo di trade‑off che non si può delegare a chi il servizio non conosce.
Una convinzione diffusa è: “ora siamo in cloud, quindi il problema è del fornitore”. È vero solo in parte. Il cloud sposta la responsabilità tecnica dell’infrastruttura, non quella del servizio.
Cloud SaaS e le domande da porre
- Il backup è incluso nel contratto o è un servizio a parte?
- Qual è la retention prevista?
- I dati sono replicati in un’altra sede?
- Se il fornitore ha un incidente, entro quanto torna operativo il servizio, e dove è scritto?
- Se il contratto finisce, come si riprendono i dati, in che formato e in quanto tempo?
La qualificazione dei servizi cloud da parte dell’Agenzia per la Cybersicurezza Nazionale assicura requisiti minimi di sicurezza e affidabilità, ma non decide al posto dell’ente quali livelli di servizio gli servono. Quello resta un compito di chi compra.
Quando le piattaforme nazionali sono il collo di bottiglia
C’è una parte della continuità operativa su cui l’ICT dell’ente non ha alcun potere. Se ANPR, pagoPA o un’altra piattaforma nazionale non rispondono, il Comune non può fare nulla per accelerare il ripristino. Può però decidere come lavorare nel frattempo.
La modalità degradata è competenza del servizio. Come si registra una richiesta se il sistema non c’è? Quali pratiche si possono raccogliere su carta e caricare dopo? Cosa si dice al cittadino allo sportello e cosa si pubblica sul sito? Chi decide di rimandare gli appuntamenti?
Procedura degradata: un esempio pratico
Un ufficio anagrafe può stabilire una procedura in cui:
- Le pratiche di cambio residenza vengono annotate su modulo cartaceo standard.
- I dati raccolti vengono inseriti in un foglio di calcolo protetto entro 24 ore dal ritorno del sistema.
- Il cittadino riceve un avviso scritto che la pratica sarà completata entro cinque giorni lavorativi.
Nessun informatico può scrivere queste procedure al posto dell’ufficio. Può solo aiutare a progettarle, testarle e integrarle con gli eventuali sistemi di backup.
Il momento cruciale: la fase di contrattazione
Il momento in cui la continuità operativa si decide davvero non è il giorno del guasto. È il giorno in cui si scrive il capitolato o si rinnova il contratto. Se una garanzia non è scritta, dopo non la si ottiene, oppure la si paga a prezzo di emergenza.
Ecco le domande minime da porre a ogni fornitore di applicativi e servizi, in locale o in cloud:
- Qual è il RTO garantito per il servizio?
- Qual è il RPO garantito?
- Come vengono gestiti i backup: frequenza, localizzazione, test di ripristino?
- Che livello di replica geografica è previsto?
- Quali sono le penali in caso di mancato rispetto dei SLA?
- Come avviene la migrazione dei dati al termine del contratto?
- Chi è il responsabile della gestione delle emergenze e qual è il piano di comunicazione?
Non serve essere tecnici per fare queste domande. Serve sapere che la continuità operativa è una responsabilità condivisa, che deve essere definita in anticipo, testata regolarmente e inserita nei contratti con chi fornisce la tecnologia.
Conclusioni: dalla reazione alla proattività
Un comune che non ha pianificato la continuità operativa rischia di trasformare un piccolo guasto in una crisi di servizio, con impatti su cittadini, imprese e sulla stessa amministrazione. La risposta non è affidare tutto all’ICT, ma creare un dialogo strutturato tra responsabili di servizio, esperti tecnologici e fornitori.
Solo così si potranno definire RTO, RPO, backup e procedure degradate in modo coerente con le reali esigenze operative, evitando sprechi e garantendo al cittadino un servizio ininterrotto, anche quando la “lampadina” digitale si spegne.