Playbook anti-ransomware per sistemi documentali e repository: cosa fare prima, durante e dopo un incidente

Un attacco ransomware contro un ente pubblico non colpisce soltanto server, applicativi o postazioni di lavoro. Colpisce la capacità dell’ente di lavorare, decidere, dimostrare, ricostruire e garantire continuità ai procedimenti.

Quando vengono cifrati o resi indisponibili sistemi documentali, repository, cartelle condivise, archivi digitali, workflow e piattaforme collegate al protocollo, il problema non è solo informatico. Diventa immediatamente organizzativo, amministrativo e documentale.

Un ente può avere un buon manuale, procedure definite e un sistema documentale formalmente attivo. Ma se, davanti a un ransomware, non sa quali repository sono critici, quali backup sono davvero recuperabili, quali fascicoli servono per garantire i servizi essenziali, quali log sono disponibili, chi decide le priorità di ripristino e come comunicare alle strutture operative cosa fare, allora la continuità documentale è molto più fragile di quanto sembri.

Per questo serve un playbook anti-ransomware per i sistemi documentali. Non un documento generico di cybersecurity, ma una guida operativa che metta insieme IT, gestione documentale, conservazione, privacy, direzione, protocollo, archivio e strutture operative.

Questo contenuto si collega direttamente al pillar sulla security-by-design nella gestione documentale. Lì il tema era progettare accessi, log, segregazione dei ruoli e privilegi minimi fin dall’inizio. Qui il punto è più pratico: cosa deve avere pronto un ente per ridurre l’impatto di un ransomware e ripartire senza perdere controllo documentale.

Perché un playbook documentale è diverso da un piano cyber generico

Molti enti hanno già documenti di sicurezza, piani di continuità, procedure IT o indicazioni generali per incidenti informatici. Sono strumenti importanti, ma spesso non entrano abbastanza nel dettaglio della dimensione documentale.

Un sistema documentale ha caratteristiche specifiche:

• contiene documenti amministrativi, atti, allegati, fascicoli e spesso informazioni personali o riservate;
• è collegato a protocolli, workflow, PEC, firme, pubblicazione, conservazione e sistemi verticali;
• ha valore probatorio e organizzativo;
• supporta procedimenti ancora aperti;
• deve garantire reperibilità e ricostruibilità anche dopo un incidente.

Per questo, in caso di ransomware, non basta chiedersi se “il server torna su”. Bisogna chiedersi:

• quali documenti sono stati cifrati o resi indisponibili;
• quali fascicoli sono coinvolti;
• quali procedimenti restano bloccati;
• quali versioni sono recuperabili;
• quali backup sono integri;
• se i log sono disponibili;
• se esistono copie non governate in circolazione;
• quali attività documentali possono proseguire in modalità degradata;
• quali comunicazioni interne ed esterne sono necessarie.

Questa è la differenza tra un piano IT e un vero playbook documentale anti-ransomware.

Prima dell’incidente: cosa preparare davvero

La parte più importante del playbook si costruisce prima dell’attacco. Durante un incidente non c’è tempo per inventare ruoli, priorità e procedure.

Mappare gli asset documentali critici

Il primo passo è sapere quali sistemi e repository sono davvero critici.

Non basta un elenco applicativo generico. Serve una mappa che distingua:

• sistema di protocollo;
• sistema documentale;
• repository di atti e fascicoli;
• cartelle condivise ancora usate nei processi;
• workflow documentali;
• integrazioni con PEC, firme, pubblicazione e conservazione;
• sistemi verticali che producono o ricevono documenti rilevanti;
• archivi storici o ibridi ancora consultati.

Per ogni asset andrebbe indicato almeno:

• owner tecnico;
• owner funzionale;
• dati e documenti contenuti;
• procedimenti impattati;
• criticità per la continuità operativa;
• priorità di ripristino;
• dipendenze con altri sistemi.

Senza questa mappa, il ripristino rischia di seguire solo logiche tecniche e non priorità amministrative.

Definire le priorità documentali di continuità

In caso di ransomware, non tutto può ripartire nello stesso momento. Bisogna sapere prima quali processi documentali sono essenziali.

Per esempio:

• protocollo in entrata e uscita;
• atti urgenti;
• procedimenti con scadenze legali;
• documenti collegati a servizi sanitari o assistenziali;
• gare e contratti in scadenza;
• personale;
• contenziosi;
• comunicazioni obbligatorie;
• pubblicazioni non differibili.

Questa priorità non può essere decisa solo dall’IT. Deve essere condivisa con direzione, RTD, gestione documentale, responsabili di procedimento e, quando serve, legale e privacy.

Verificare backup e ripristino, non solo backup

Molti enti dicono di avere backup. La domanda vera è: sono ripristinabili?

Per i sistemi documentali, un backup utile deve essere:

• aggiornato;
• isolato o comunque protetto rispetto all’attacco;
• coerente con database, file, metadati e configurazioni;
• testato periodicamente;
• collegato a tempi di ripristino realistici;
• accompagnato da procedure chiare.

Un backup non testato è una promessa, non una garanzia.

Nel documentale questo è ancora più importante, perché recuperare solo i file senza metadati, fascicoli, log o relazioni può non bastare. L’ente deve poter ripristinare un contesto, non solo una massa di documenti.

Preparare modalità operative degradate

Un playbook serio deve prevedere cosa fare quando il sistema documentale non è disponibile.

Per esempio:

• come registrare provvisoriamente documenti urgenti;
• come gestire comunicazioni essenziali;
• quali canali alternativi sono autorizzati;
• quali attività devono essere sospese;
• quali attività possono proseguire con tracciamento manuale;
• come rientrare nel sistema una volta ripristinato;
• chi valida la ricostruzione successiva.

Il punto non è creare procedure parallele permanenti. È evitare che, durante l’emergenza, ogni struttura inventi la propria soluzione.

Chiarire ruoli e responsabilità

In caso di incidente, la confusione sui ruoli amplifica il danno.

Devono essere chiari almeno:

• chi coordina la risposta tecnica;
• chi valuta l’impatto sui procedimenti;
• chi decide le priorità di ripristino documentale;
• chi comunica alle strutture operative;
• chi presidia privacy e data breach;
• chi valuta impatti legali e scadenze;
• chi documenta decisioni e azioni svolte;
• chi autorizza il ritorno alla normalità.

Qui torna utile la logica della matrice RACI nella PA, perché un incidente cyber è uno dei casi in cui la distinzione tra chi esegue, chi decide, chi consulta e chi informa non può restare implicita. È anche uno dei punti in cui la governance documentale negli enti complessi mostra se è davvero operativa o solo formale.

Durante l’incidente: cosa fare per non perdere controllo

Quando l’incidente è in corso, la priorità è contenere il danno, preservare evidenze e mantenere il controllo operativo.

Isolare senza cancellare evidenze

La risposta tecnica deve puntare a contenere l’attacco, ma senza compromettere le evidenze utili alla ricostruzione. Log, sistemi, timestamp, alert, utenti coinvolti e operazioni sospette possono essere fondamentali per capire cosa è accaduto.

Per il documentale, questo significa anche capire quali repository sono stati toccati, quali documenti risultano indisponibili e quali processi sono stati impattati.

Attivare una cabina di regia ridotta ma completa

Non serve coinvolgere subito tutti. Serve un gruppo ristretto con competenze essenziali:

• IT / sicurezza;
• RTD;
• gestione documentale;
• direzione o crisis management;
• privacy / DPO;
• legale, se ci sono impatti su scadenze, contenziosi o obblighi;
• referenti delle aree operative più colpite.

La cabina di regia deve decidere rapidamente cosa fermare, cosa mantenere, cosa comunicare e cosa ripristinare per primo.

Bloccare le scorciatoie non governate

Durante un incidente, le persone cercano soluzioni rapide. È comprensibile, ma pericoloso.

Se ogni ufficio inizia a salvare documenti su dispositivi locali, inviare file via canali non autorizzati o ricostruire fascicoli in modo autonomo, l’ente rischia di generare una seconda crisi: documentale, non solo informatica.

Per questo il playbook deve indicare chiaramente quali canali alternativi sono consentiti e quali no.

Documentare le decisioni prese

Anche durante l’emergenza, l’ente deve tenere traccia delle decisioni rilevanti:

• quando è stato rilevato l’incidente;
• quali sistemi sono stati isolati;
• quali processi sono stati sospesi;
• quali deroghe operative sono state autorizzate;
• quali comunicazioni sono state inviate;
• quali attività sono proseguite in modalità degradata;
• quali ripristini sono stati effettuati.

Sembra paradossale, ma durante un incidente documentale bisogna produrre buona documentazione dell’incidente stesso.

Dopo l’incidente: ripristinare non significa solo riaccendere

Una delle illusioni più pericolose è pensare che il problema finisca quando i sistemi tornano disponibili. In realtà, per la gestione documentale, il ripristino vero inizia dopo.

Verificare integrità e coerenza

Bisogna controllare che documenti, metadati, fascicoli, versioni e log siano coerenti. Non basta che i file siano di nuovo accessibili.

Ricostruire le attività svolte in modalità degradata

Tutto ciò che è stato fatto fuori dal sistema deve essere riportato dentro un tracciato governato:

• documenti ricevuti;
• protocolli provvisori;
• comunicazioni urgenti;
• autorizzazioni;
• atti prodotti;
• fascicoli temporanei;
• decisioni prese.

Questa fase è delicata perché può generare duplicazioni, errori o perdita di contesto. È anche il momento in cui si vede se l’ente sa costruire un fascicolo informatico difendibile anche a partire da attività svolte in emergenza.

Analizzare le cause documentali, non solo tecniche

Dopo l’incidente, l’ente dovrebbe chiedersi:

• i permessi erano troppo ampi;
• i repository erano troppo frammentati;
• i backup erano incompleti;
• i log erano insufficienti;
• le procedure di emergenza erano poco chiare;
• gli utenti hanno usato canali non governati;
• alcune dipendenze applicative non erano note.

Questa analisi permette di migliorare il modello, non solo di chiudere il caso, e prepara il terreno a un audit di sicurezza documentale strutturato.

Aggiornare il playbook

Un playbook non è statico. Ogni incidente, simulazione o quasi-incidente deve generare aggiornamenti:

• ruoli;
• priorità;
• procedure;
• contatti;
• tempi di ripristino;
• comunicazioni;
• controlli;
• formazione.

I segnali che il tuo ente non è pronto

Ci sono segnali molto concreti:

• nessuno sa quali repository documentali sono davvero critici;
• i backup esistono ma non vengono testati;
• i fascicoli non sono ripristinabili insieme a metadati e relazioni;
• non esiste una procedura per protocollazione o gestione urgente in modalità degradata;
• le strutture operative non sanno cosa fare se il sistema è indisponibile;
• gli accessi privilegiati non sono rivisti periodicamente;
• non è chiaro chi comunica cosa durante l’incidente;
• non esiste una procedura per rientrare ordinatamente nel sistema dopo l’emergenza.

Se anche solo alcuni di questi punti sono veri, il rischio non è teorico. È operativo.

Un modello minimo di playbook documentale

Un playbook anti-ransomware per sistemi documentali dovrebbe contenere almeno queste sezioni:

Sezione	Contenuto
Ambito	Quali sistemi, repository e flussi documentali sono coperti.
Asset critici	Elenco dei sistemi e dei repository rilevanti, con priorità.
Ruoli e contatti	Chi fa cosa durante l’incidente.
Procedure di contenimento	Cosa isolare, cosa sospendere, cosa preservare.
Modalità operative degradate	Come gestire attività urgenti quando il sistema è indisponibile.
Backup e ripristino	Dove sono i backup, come vengono testati, quali tempi sono attesi.
Privacy e comunicazioni	Come valutare eventuali data breach e come comunicare internamente.
Rientro alla normalità	Come riportare dentro il sistema ciò che è stato gestito fuori.
Post-incident review	Come analizzare l’accaduto e aggiornare il modello.

Un test pratico da fare nei prossimi 30 giorni

Scegli un repository documentale critico e prova a simulare queste domande:

• se domani fosse indisponibile, quali procedimenti si fermerebbero;
• chi verrebbe avvisato per primo;
• quali backup useremmo;
• in quanto tempo potremmo ripristinare;
• cosa perderemmo oltre ai file;
• come gestiremmo protocolli o atti urgenti;
• come ricostruiremmo ciò che è accaduto durante il fermo.

Se le risposte non sono chiare, il playbook non è ancora pronto. Per il quadro nazionale di riferimento su prevenzione e risposta agli incidenti è utile seguire le indicazioni dell’Agenzia per la Cybersicurezza Nazionale.

Dalla resilienza tecnica alla continuità documentale

Un ransomware non mette alla prova solo l’infrastruttura IT. Mette alla prova la capacità dell’ente di conoscere i propri documenti, governare le priorità e ripristinare processi senza perdere tracciabilità.

Scopri come Docsuite Next può aiutarti a progettare una gestione documentale più sicura, resiliente e pronta alla continuità operativa.

Domande frequenti

Perché serve un playbook anti-ransomware specifico per i sistemi documentali?

Perché i sistemi documentali non contengono solo file, ma procedimenti, fascicoli, metadati, versioni, log e responsabilità. Un piano cyber generico potrebbe non coprire questi aspetti.

Il backup dei documenti è sufficiente?

No. Serve verificare che siano ripristinabili anche metadati, relazioni, fascicoli, configurazioni e log necessari alla ricostruzione del contesto documentale.

Chi deve partecipare alla gestione dell’incidente?

IT e sicurezza sono essenziali, ma servono anche RTD, gestione documentale, conservazione, privacy, direzione e referenti delle strutture operative impattate.

Cosa sono le modalità operative degradate?

Sono procedure temporanee che permettono di gestire attività urgenti quando il sistema documentale non è disponibile, evitando che ogni ufficio inventi soluzioni non governate.

Cosa bisogna fare dopo il ripristino tecnico?

Verificare integrità e coerenza di documenti, fascicoli, metadati e log; ricostruire le attività svolte fuori sistema; aggiornare playbook, controlli e formazione.