Il ransomware non è più un evento da trattare come emergenza esclusivamente informatica. Quando un attacco blocca file server, posta, ERP, sistemi di produzione, portali clienti o strumenti di fatturazione, il problema diventa immediatamente organizzativo: chi decide se spegnere un servizio, chi parla con i fornitori, quali dati servono per ripartire, quali clienti devono essere informati, quali evidenze vanno raccolte e quali funzioni aziendali hanno priorità.
La novità, per imprese e amministratori, è che questa domanda non può essere affrontata solo nel momento della crisi. La piena attuazione della disciplina NIS2 e la crescita degli obblighi di resilienza chiedono un cambio di prospettiva: la continuità operativa deve essere progettata, documentata e testata prima dell’incidente.
Il punto pratico è semplice: un backup non verificato, un piano di risposta mai provato o una lista fornitori aggiornata a metà non sono controlli. Sono buone intenzioni.
Perché il ransomware è un tema di governance
Nel profilo NIST IR 8374r1 dedicato al ransomware e basato sul Cybersecurity Framework 2.0, il ransomware viene collegato esplicitamente alla gestione del rischio aziendale, ai ruoli, alla supply chain, all’inventario degli asset e al ripristino. Non è un dettaglio metodologico: significa che il rischio non si esaurisce nel reparto IT.
Un attacco ransomware genera pressione immediata sulla continuità del business. Se l’azienda non ha già stabilito chi può autorizzare un fermo, quale ambiente ripristinare per primo, quali fornitori coinvolgere e quali procedure seguire, le decisioni vengono prese in condizioni peggiori: informazioni incomplete, urgenza operativa, stress reputazionale e possibili obblighi di notifica.
Per questo la risposta al ransomware dovrebbe stare nel sistema di governo aziendale, non solo in una cartella tecnica. Deve coinvolgere direzione, IT, legale, privacy, amministrazione, operations, comunicazione e procurement. Ogni funzione ha un pezzo del problema.
NIS2 sposta l’attenzione dalle policy alle evidenze
La NIS2 non va letta come un fascicolo formale da compilare una volta l’anno. L’approccio della normativa europea e delle autorità nazionali punta alla gestione concreta del rischio: misure proporzionate, responsabilità, prevenzione, rilevazione, risposta agli incidenti e continuità.
ACN ricorda che in Italia la nuova disciplina NIS è in vigore dal 16 ottobre 2024 e che l’Agenzia è l’autorità competente NIS e punto di contatto unico. Per le imprese coinvolte, direttamente o indirettamente, questo significa prepararsi a dimostrare come sono gestiti sicurezza, incidenti, fornitori e resilienza.
Il punto non è solo “avere una procedura”. La domanda più utile è: se domani un attacco rendesse indisponibile l’ERP, l’azienda saprebbe mostrare quando è stato testato l’ultimo ripristino, quali dati sono inclusi nel backup, quali fornitori devono intervenire, chi decide le priorità e quali tempi sono realistici?
Il dato ENISA: patching, test e terze parti restano aree deboli
Il report ENISA NIS Investments 2025, pubblicato nel 2026, descrive un quadro molto concreto. Tra gli elementi evidenziati ci sono patching ancora lento, test di sicurezza non sempre svolti, dipendenza crescente da fornitori ICT e servizi esterni, e ransomware indicato tra le principali preoccupazioni per i mesi successivi.
Questi dati non vanno letti come numeri astratti. Dicono che molte organizzazioni stanno investendo, ma faticano ancora su attività essenziali: aggiornare in tempo, misurare la propria esposizione, testare la risposta e governare l’interdipendenza con terze parti.
Per una PMI o una società di servizi, il rischio tipico è credere di essere protetta perché usa cloud, backup automatici o un provider gestito. In realtà il cloud non elimina la responsabilità aziendale: configurazioni, identità, privilegi, procedure di recovery, contratti, accessi amministrativi e tempi di intervento restano decisioni da governare.
Backup: la domanda non è se esistono, ma se funzionano
Nel linguaggio operativo, “abbiamo i backup” è una frase troppo generica. Un piano serio dovrebbe rispondere ad almeno cinque domande:
- quali sistemi sono inclusi e quali restano fuori;
- con quale frequenza vengono salvati dati e configurazioni;
- chi può accedere ai backup e con quali credenziali;
- quanto tempo serve per ripristinare un servizio minimo;
- quando è stato eseguito l’ultimo test documentato.
Il test è la parte che molte aziende rimandano, perché interrompe la routine e richiede coordinamento. Ma senza test non si conoscono davvero i tempi di ripristino, le dipendenze tra sistemi, gli errori di configurazione, i dati mancanti o i passaggi manuali dimenticati.
Un backup valido non è quello che “dovrebbe” funzionare. È quello che è stato ripristinato, controllato e documentato.
ERP e processi critici: ripartire non significa riaccendere tutto
Quando il ransomware colpisce l’infrastruttura aziendale, l’ERP diventa spesso il punto più delicato. Ordini, magazzino, produzione, fatture, incassi, acquisti, anagrafiche clienti e dati contabili dipendono da sistemi collegati tra loro. Ripristinare tutto insieme può essere irrealistico; ripristinare male può generare dati incoerenti.
Serve quindi una mappa dei processi critici. Non una mappa teorica, ma una vista pratica: quali attività devono riprendere entro poche ore, quali possono attendere, quali dati sono indispensabili, quali integrazioni vanno isolate, quali stampe o esportazioni possono sostenere un lavoro manuale temporaneo.
In alcuni casi il primo obiettivo non è tornare alla piena normalità, ma riattivare una capacità minima: emettere documenti essenziali, ricevere ordini urgenti, spedire prodotti già pronti, pagare scadenze critiche o mantenere aperto un canale di comunicazione con clienti e fornitori.
Fornitori e responsabilità: inserirli nel piano prima della crisi
NIST sottolinea che fornitori e terze parti rilevanti devono essere inclusi nella pianificazione, risposta e recovery dagli incidenti. È un passaggio essenziale: se il provider ERP, il gestore cloud, il consulente cybersecurity o il fornitore di connettività non sono stati coinvolti prima, durante l’attacco emergeranno ritardi, dubbi contrattuali e responsabilità poco chiare.
Una verifica minima dovrebbe includere contatti di emergenza, SLA realistici, copertura oraria, modalità di escalation, procedure per accessi privilegiati, disponibilità dei log, tempi di ripristino, gestione delle copie, responsabilità sui subfornitori e obblighi di comunicazione.
Il contratto dovrebbe essere collegato al piano operativo. Se il documento legale promette un servizio, ma il piano di recovery non indica chi lo attiva, con quale numero, con quali credenziali e con quali tempi, quella promessa resta fragile.
Una checklist essenziale per il prossimo mese
Per trasformare la resilienza in lavoro concreto, un’impresa può partire da una checklist breve:
- individuare i cinque processi aziendali che non possono fermarsi;
- associare a ogni processo sistemi, dati, persone e fornitori necessari;
- verificare backup e copie offline o isolate per gli ambienti critici;
- testare almeno un ripristino parziale e conservarne evidenza;
- aggiornare la lista dei contatti di emergenza interni ed esterni;
- definire chi decide priorità, comunicazioni e riapertura dei servizi;
- controllare privilegi amministrativi, MFA e accessi dei fornitori;
- simulare una riunione di crisi di trenta minuti con direzione, IT e funzioni operative;
- collegare incident response, privacy, NIS2 e continuità operativa in un unico flusso.
Questa checklist non risolve tutto, ma riduce il rischio più pericoloso: scoprire durante l’attacco che nessuno sa davvero come ripartire.
Conclusione
Il ransomware è una prova di maturità aziendale. Misura la qualità dei backup, ma anche la chiarezza dei ruoli, la disciplina nella gestione dei fornitori, la conoscenza dei processi e la capacità di prendere decisioni sotto pressione.
NIS2, le indicazioni ENISA e il profilo NIST non chiedono alle imprese di produrre documenti perfetti. Chiedono una cosa più concreta: trasformare la sicurezza in evidenze, test e responsabilità operative.
Chi aspetta l’incidente per capire cosa è davvero critico rischia di perdere tempo proprio quando il tempo vale di più. Chi prova il ripristino prima, invece, non elimina il rischio ransomware, ma riduce il danno, protegge la continuità e rende la governance cyber molto meno teorica.
Nota di trasparenza: questo articolo e l’immagine in evidenza sono stati realizzati anche con il supporto di strumenti di intelligenza artificiale, con revisione editoriale e verifica delle fonti.
Fonti principali: NIST IR 8374r1, Ransomware Risk Management: A Cybersecurity Framework 2.0 Community Profile; ENISA, NIS Investments 2025; ACN, la normativa NIS; Commissione europea, Cyber Resilience Act implementation guidance; NIST Cybersecurity Supply Chain Risk Management.