Governance dei pagamenti di riscatti ransomware per NIS2 e DORA

Sono le 3:17 di un giorno feriale del 2026. Maria, Responsabile della sicurezza delle informazioni di una piattaforma fintech in forte crescita, viene coinvolta in una riunione di crisi da un messaggio del coordinatore degli analisti SOC: cifratura diffusa confermata, servizi core indisponibili e un gruppo ransomware dichiara di aver esfiltrato 2 TB di dati dei clienti.

Il CEO entra per primo nella chiamata. Seguono la funzione legale. Poi privacy, finanza, comunicazione, l’assicuratore cyber, un fornitore forense e il team delle operazioni cloud. Un portale nel dark web mostra un conto alla rovescia di 48 ore e una richiesta a sette cifre in criptovaluta.

Il CEO pone la domanda che ogni Responsabile della sicurezza delle informazioni teme.

“Possiamo pagare, e chi è autorizzato a decidere?”

La risposta sbagliata è trattarla come un problema di negoziazione. La risposta corretta è trattarla come un problema di governance.

Nel 2026, la governance delle decisioni di pagamento dei riscatti ransomware non è più una scelta tecnica e privata di gestione della crisi. Può essere esaminata da autorità di regolamentazione, auditor, assicuratori, clienti, forze dell’ordine, azionisti e consiglio di amministrazione. Una decisione di pagamento incrocia esposizione a sanzioni, valutazione di una violazione dei dati personali, condizioni dell’assicurazione cyber, obblighi contrattuali, comunicazioni di crisi, conservazione delle evidenze, notifica per fasi NIS2, classificazione degli incidenti DORA, notifica GDPR e miglioramento post-incidente.

Per questo Clarysec consiglia ai clienti di costruire la governance delle decisioni di pagamento dei riscatti ransomware all’interno del SGSI prima dell’incidente. ISO/IEC 27001:2022 fornisce la struttura del sistema di gestione. I controlli ISO/IEC 27002:2022 forniscono il modello operativo. Zenith Blueprint: roadmap in 30 passi per auditor e Zenith Controls: guida alla conformità trasversale aiutano a trasformare tale struttura in evidenze pratiche e verificabili in sede di audit.

Un playbook ransomware che si limita a dire “notificare la funzione legale” non è sufficiente. L’organizzazione deve sapere chi può autorizzare la negoziazione, come viene eseguita la verifica sanzionatoria, quando l’assicuratore deve approvare, come viene documentata la classificazione GDPR, NIS2 e DORA e come vengono protette le evidenze mentre i team di ripristino operano sotto pressione.

Perché le decisioni ad hoc sui pagamenti dei riscatti ransomware falliscono

Una decisione di pagamento di un riscatto ransomware viene spesso descritta come binaria: pagare o non pagare. In realtà, la decisione ha almeno sei livelli:

1. L’evento è confermato, contenuto e classificato correttamente?
2. Sono coinvolti dati personali, dati regolamentati o l’erogazione di servizi critici?
3. L’organizzazione è legalmente autorizzata a comunicare o effettuare transazioni con l’attore della minaccia?
4. L’assicurazione cyber richiede preavviso, fornitori approvati, consenso o evidenze specifiche?
5. Il pagamento ridurrebbe l’impatto aziendale oppure aumenterebbe il rischio legale, finanziario e reputazionale?
6. Chi ha l’autorità di decidere e come viene registrata tale decisione?

Durante un incidente in corso, team non coordinati tendono spesso a muoversi in direzioni diverse. Il CFO può considerare il riscatto come un costo aziendale rispetto a un downtime crescente. La funzione legale vede sanzioni, reati finanziari ed esposizione normativa. Il DPO sta valutando se dati cifrati o esfiltrati generino una violazione dei dati personali soggetta a notifica. La conformità monitora le scadenze di notifica NIS2 e DORA. Il Responsabile della sicurezza delle informazioni cerca di conservare le evidenze mentre ripristina i servizi. Il CEO vuole una raccomandazione prima che scada il timer dell’attaccante.

Senza un processo decisionale formale, la voce più forte nella stanza può diventare il modello di governance. È esattamente la situazione che la regolamentazione moderna sulla cybersicurezza mira a prevenire.

NIS2 rende la cybersicurezza una responsabilità gestionale. Article 20 riguarda governance e responsabilità degli organi di gestione, mentre Article 21 richiede misure di gestione del rischio che coprano gestione degli incidenti, continuità operativa, gestione dei backup, gestione delle crisi, sicurezza della catena di fornitura, controllo degli accessi, gestione degli asset, MFA e valutazione dell’efficacia. Article 23 introduce la notifica per fasi degli incidenti significativi, inclusi l’allarme precoce entro 24 ore, la notifica entro 72 ore e la relazione finale entro un mese, ove applicabile.

Per gli enti finanziari, DORA è il quadro normativo settoriale sulla resilienza operativa digitale. Article 5 attribuisce all’organo di gestione la responsabilità della gestione del rischio ICT. Articles 17, 18 e 19 riguardano la gestione, la classificazione e la segnalazione degli incidenti gravi connessi alle ICT. DORA richiede inoltre capacità di risposta e ripristino, backup e ripristino, apprendimento post-incidente, test e gestione del rischio ICT di terze parti.

GDPR aggiunge una valutazione separata ma sovrapposta. Se il ransomware causa distruzione, perdita, alterazione, divulgazione non autorizzata o accesso accidentale o illecito a dati personali, il titolare del trattamento deve valutare se si è verificata una violazione dei dati personali. Se la notifica è richiesta, il termine per l’autorità di controllo è generalmente di 72 ore dal momento in cui se ne viene a conoscenza. In presenza di un rischio elevato per le persone fisiche, può essere richiesta anche la comunicazione agli interessati.

La conclusione è semplice: la domanda sul riscatto non deve essere posta per la prima volta nella sala di crisi.

Controlli ISO 27001:2022 che sostengono la governance dei pagamenti

Un SGSI ISO/IEC 27001:2022 non è una checklist per auditor. È un sistema di gestione per assumere decisioni basate sul rischio. La governance dei pagamenti di riscatti ransomware appartiene a tale sistema perché combina valutazione del rischio, trattamento del rischio, ruoli, obblighi legali, risposta agli incidenti, continuità, gestione dei fornitori e miglioramento continuo.

I controlli più rilevanti dell’Allegato A di ISO 27001:2022 formano una catena di controllo integrata.

In Zenith Controls, la sezione relativa ad A.5.24, pianificazione e preparazione della gestione degli incidenti di sicurezza delle informazioni, classifica il controllo come correttivo, collegato a riservatezza, integrità e disponibilità e allineato ai concetti di risposta e ripristino. Collega inoltre A.5.24 ad A.5.25 valutazione degli eventi, A.5.27 apprendimento dagli incidenti, A.8.15 registrazione, A.8.16 monitoraggio, A.5.29 sicurezza durante le interruzioni, continuità e contatto con le autorità.

Questo è rilevante perché la governance dei pagamenti di riscatti ransomware è una catena. Se non puoi rilevare e classificare l’evento, non puoi decidere. Se non puoi conservare le evidenze, non puoi difendere la decisione. Se gli obblighi legali non sono mappati, la negoziazione o il pagamento possono essere illeciti. Se le opzioni di ripristino non sono testate, i dirigenti possono essere spinti a decidere sulla base della paura anziché dei fatti.

Zenith Controls descrive in modo diretto il rapporto tra preparazione e processo decisionale:

“5.25 è il punto decisionale che determina quando un evento supera la soglia e diventa un incidente di sicurezza, attivando le azioni descritte in 5.26. Una valutazione tempestiva e accurata degli eventi assicura che la risposta agli incidenti non sia né ritardata né indirizzata in modo errato.”

La stessa guida collega A.5.31, requisiti legali, statutari, normativi e contrattuali, a privacy, conservazione delle registrazioni, riesame indipendente e conformità alle politiche interne. Per il ransomware, A.5.31 è il punto in cui verifica sanzionatoria, obblighi assicurativi, coinvolgimento delle forze dell’ordine, contratti con i clienti, doveri di protezione dei dati e notifiche regolamentari di settore sono raccolti in un unico Registro di conformità.

Il modello Clarysec a cinque gate per la governance dei pagamenti di riscatti ransomware

Il modello Clarysec separa la governance delle decisioni di pagamento dei riscatti ransomware in cinque gate. L’obiettivo non è rendere più facile il pagamento. È fare in modo che qualsiasi decisione, incluso il rifiuto di pagare, sia basata su evidenze, sottoposta a riesame legale, autorizzata e verificabile in sede di audit.

Questo modello utilizza la logica di trattamento del rischio di ISO 27001. Un pagamento ransomware non è un controllo di sicurezza. È, al massimo, un’opzione di crisi considerata in un contesto di trattamento del rischio e ripristino. Prima di un incidente, l’organizzazione dovrebbe avere già deciso come trattare i rischi ransomware: mitigarli mediante controlli, trasferire parte dell’esposizione finanziaria tramite assicurazione, evitare dipendenze legacy inaccettabili oppure accettare esplicitamente il rischio residuo ove giustificato.

Nella fase di Gestione del rischio, Step 13, Pianificazione del trattamento del rischio e Dichiarazione di Applicabilità, Zenith Blueprint indica alle organizzazioni di determinare le opzioni di trattamento per ciascun rischio e documentarle nel Registro dei rischi. Avverte che il trasferimento, ad esempio tramite assicurazione cyber, non elimina la necessità di controlli, perché spesso il trasferimento riguarda l’impatto finanziario e non la probabilità. Afferma inoltre:

“L’accettazione deve essere esplicita e approvata dalla direzione, in particolare per qualsiasi rischio Medio. I rischi Alti sono raramente accettati, salvo quando siano realmente inevitabili e concordati al massimo livello.”

Questa indicazione è direttamente rilevante per la governance dei pagamenti di riscatti ransomware. Se al consiglio di amministrazione viene chiesto di accettare il rischio residuo del rifiuto del pagamento, oppure il rischio legale e reputazionale dell’approvazione di una negoziazione, l’accettazione deve essere esplicita, registrata e approvata dall’autorità corretta.

La Politica di gestione del rischio di Clarysec rafforza lo stesso principio:

“Le decisioni di trattamento del rischio devono essere allineate alle opzioni predefinite”
Dalla clausola 5.5.

Una decisione sul riscatto non è quindi una scorciatoia rispetto alla gestione del rischio. Deve essere trattata come una decisione formale e documentata di trattamento del rischio, nell’ambito di un’autorità definita.

Autorità di policy: chi può decidere sotto pressione?

Molti fallimenti legati al ransomware sono fallimenti di governance mascherati da fallimenti tecnici. Qualcuno contatta l’attaccante fuori dal canale approvato. Qualcuno promette il pagamento prima dell’approvazione dell’assicuratore. Qualcuno ripristina i sistemi e sovrascrive evidenze forensi. Qualcuno informa i clienti troppo presto, troppo tardi o con fatti inesatti.

Le politiche Clarysec sono progettate per eliminare questa ambiguità.

Per le PMI, la Politica sui ruoli e sulle responsabilità di governance - PMI fornisce una regola semplice:

“Tutte le decisioni, eccezioni ed escalation di sicurezza significative devono essere registrate e tracciabili.”
Dalla sezione “Requisiti di governance”, clausola della politica 5.5.

La Politica di risposta agli incidenti - PMI assegna l’autorità di escalation:

“Il Direttore generale (GM) è responsabile dell’autorizzazione di tutte le decisioni di escalation degli incidenti, delle notifiche regolamentari e delle comunicazioni esterne.”
Dalla sezione “Requisiti di governance”, clausola della politica 5.1.1.

Collega inoltre gli incidenti sui dati dei clienti agli obblighi normativi:

“Quando sono coinvolti dati dei clienti, il Direttore generale deve valutare gli obblighi legali di notifica in base all’applicabilità di GDPR, NIS2 o DORA.”
Dalla sezione “Trattamento del rischio ed eccezioni”, clausola della politica 7.4.1.

Per le organizzazioni più grandi, la Politica sui ruoli e sulle responsabilità di governance enterprise richiede l’escalation immediata in presenza di esposizione legale o violazioni dei dati soggette a notifica:

“Escalation legale/regolatoria: gli incidenti che comportano potenziale esposizione legale o violazioni dei dati soggette a notifica devono essere immediatamente escalati al Responsabile Affari Legali e Conformità e alla Direzione esecutiva.”
Dalla sezione “Requisiti di applicazione della politica”, clausola della politica 6.4.3.

La Politica di risposta agli incidenti enterprise definisce l’autorità esecutiva durante gli incidenti gravi. La clausola 4.6.1 stabilisce che il ruolo del Team di Direzione esecutiva è:

“Assumere decisioni strategiche durante incidenti ad alta gravità, inclusa l’approvazione delle notifiche e delle comunicazioni pubbliche.”

In un contesto ransomware, Clarysec considera discussione sul pagamento, autorizzazione alla negoziazione, avviso ai clienti, dichiarazione regolamentare e comunicazione pubblica come decisioni strategiche, non come azioni tecniche.

Ne deriva una regola pratica di governance: il Responsabile della sicurezza delle informazioni può raccomandare, il team di gestione dell’incidente può valutare, la funzione legale può fornire pareri, la finanza può validare le modalità di pagamento, l’assicuratore può concedere o negare la copertura, ma la Direzione esecutiva o il Consiglio di amministrazione devono assumere la titolarità della decisione secondo un’autorità predefinita.

Escalation presidiata rispetto alle sanzioni prima di qualsiasi negoziazione

Un processo ransomware presidiato rispetto alle sanzioni parte da un divieto: nessun dipendente, contraente, fornitore, broker, negoziatore o addetto alla risposta agli incidenti può negoziare, promettere, agevolare o trasferire valore a un attore della minaccia senza un riesame legale approvato.

Il controllo legale deve avvenire prima di qualsiasi ingaggio attivo con l’attaccante, non dopo la comparsa di un indirizzo wallet. Il processo dovrebbe includere:

• Coinvolgimento del consulente legale prima di qualsiasi comunicazione oltre alla raccolta passiva delle evidenze.
• Identificazione dell’attore della minaccia utilizzando, ove disponibili, input forensi, intelligence sulle minacce e forze dell’ordine.
• Verifica di sanzioni e parti soggette a restrizioni per nomi di gruppi, alias, indirizzi wallet, infrastrutture, intermediari e canali di pagamento.
• Consultazione con le forze dell’ordine valutata e registrata.
• Notifica all’assicuratore cyber secondo i termini della polizza prima di nominare fornitori o avviare negoziazioni.
• Coinvolgimento del DPO o del responsabile privacy se possono essere coinvolti dati personali.
• Conferma da parte del CFO o del responsabile finanza dei controlli di pagamento, della segregazione dei compiti, dei controlli antifrode e dei requisiti di approvazione del consiglio di amministrazione.
• Registrazione della decisione esecutiva con le alternative considerate, inclusi ripristino, contenimento, sospensione del servizio, comunicazione ai clienti e rifiuto di pagare.
• Conservazione delle evidenze relative a comunicazioni dell’attaccante, indicatori, dettagli del wallet, riunioni decisionali, approvazioni e consulenza esterna.

Per il ransomware, il registro normativo dovrebbe includere almeno le seguenti fonti di obblighi.

Le organizzazioni dovrebbero inoltre definire chi può bloccare la decisione di pagamento. Funzione legale, conformità, DPO, consulente in materia di sanzioni o consiglio di amministrazione dovrebbero avere autorità esplicita per sospendere negoziazione o pagamento se la verifica è incompleta, le evidenze non sono affidabili, le condizioni dell’assicuratore non sono soddisfatte o l’azione può violare legge o contratto.

Conservazione delle evidenze: non distruggere le prove mentre ripristini il servizio

I team ransomware si affrettano naturalmente a ripristinare le operazioni. Ma se il ripristino distrugge log, snapshot, note di riscatto, campioni di malware, immagini di memoria o messaggi dell’attaccante, l’organizzazione può perdere la capacità di dimostrare cosa è accaduto.

Nella fase Controls in Action, Step 23, Controlli organizzativi, Zenith Blueprint indica alle organizzazioni di convalidare e testare le capacità di gestione degli incidenti definendo eventi di sicurezza soggetti a segnalazione, documentando il processo decisionale e preservando le evidenze forensi. Istruisce i team a:

“Acquisire e registrare tutte le decisioni, i ruoli e le comunicazioni (5.26) e aggiornare il piano con le lezioni apprese (5.27). Confermare che siano in essere procedure per preservare le evidenze forensi (5.28), inclusi snapshot dei log, backup e isolamento sicuro dei sistemi interessati.”

Lo stesso passo spiega A.5.28 con un linguaggio comprensibile a qualsiasi consiglio di amministrazione:

“ciò che puoi provare conta tanto quanto ciò che è realmente accaduto”

La Politica per la raccolta delle evidenze e l’analisi forense enterprise di Clarysec rafforza il principio secondo cui le evidenze devono rimanere tracciabili:

“Un registro della catena di custodia deve accompagnare tutte le evidenze fisiche o digitali dal momento dell’acquisizione fino all’archiviazione o al trasferimento e deve documentare:”
Dalla sezione “Requisiti di governance”, clausola della politica 5.6.

Per le PMI, la Politica per la raccolta delle evidenze e l’analisi forense - PMI è volutamente pratica:

“Deve sempre essere creata una copia forense o un’esportazione; l’evidenza originale non deve mai essere modificata direttamente.”
Dalla sezione “Requisiti di applicazione della politica”, clausola della politica 6.1.1.

Richiede inoltre la consultazione legale quando possono esistere impatti su HR, aspetti legali o clienti:

“Se l’incidente comporta un potenziale impatto sulle Risorse Umane (HR), legale o sui clienti, il GM deve consultare il consulente legale prima di procedere con l’applicazione o l’escalation.”
Dalla sezione “Requisiti di governance”, clausola della politica 5.4.2.

Durante il Gate 2 dovrebbe essere aperto un pacchetto evidenze pratico. Creare una cartella riservata per le evidenze dell’incidente. Esportare cronologie SIEM, rilevazioni EDR, log di audit cloud, log di accesso del provider di identità, stato dei job di backup, note di riscatto, screenshot, messaggi dell’attaccante, indirizzi wallet, campioni di file, riferimenti ai pareri legali, corrispondenza con l’assicuratore e decisioni delle riunioni. Assegnare un custode. Registrare i valori hash ove appropriato. Non consentire agli amministratori di ripulire i sistemi interessati prima dell’acquisizione forense, salvo che lo richiedano la sicurezza delle persone, la protezione di servizi critici o un contenimento approvato dalla direzione esecutiva.

Un unico foglio di classificazione per NIS2, DORA e GDPR

Un incidente ransomware può attivare più scadenze. La difficoltà non è solo conoscere i termini. È sapere quando l’organizzazione ne è venuta a conoscenza, cosa sapeva in quel momento e come sono state assunte le decisioni di classificazione.

NIS2 Article 23 richiede agli enti essenziali e importanti di notificare senza indebito ritardo al CSIRT o all’autorità competente gli incidenti significativi. La significatività è collegata a grave interruzione operativa, perdita finanziaria o danno materiale o immateriale considerevole a terzi. Il modello per fasi include allarme precoce entro 24 ore, notifica entro 72 ore, aggiornamenti intermedi se richiesti e relazione finale entro un mese dalla notifica dell’incidente ove applicabile.

DORA richiede agli enti finanziari di definire e attuare la gestione degli incidenti connessi alle ICT, registrare incidenti e minacce informatiche significative, classificare gli incidenti utilizzando criteri quali clienti interessati, durata, diffusione geografica, perdita di dati, criticità e impatto economico, e segnalare gli incidenti gravi connessi alle ICT alle autorità competenti tramite relazioni iniziali, intermedie e finali.

GDPR pone una domanda diversa ma sovrapposta: l’incidente ha causato una violazione dei dati personali? In tal caso, è probabile che comporti un rischio per le persone fisiche? Se la soglia di notifica è raggiunta, la notifica all’autorità di controllo deve essere valutata rispetto al termine di 72 ore. In presenza di un rischio elevato, può essere necessaria anche la comunicazione agli interessati.

Clarysec raccomanda di utilizzare un unico foglio di classificazione ransomware con sezioni separate per ciascun regime.

Questo approccio si adatta alle clausole ISO 27001 su valutazione del rischio, trattamento del rischio e informazioni documentate. È inoltre allineato a NIST CSF 2.0. La funzione GOVERN di NIST CSF 2.0 si aspetta che le organizzazioni comprendano parti interessate, obblighi legali e normativi, propensione al rischio, ruoli, politiche, supervisione e rischio di terze parti. I suoi esiti di rilevazione, risposta e ripristino supportano dichiarazione dell’incidente, analisi, coordinamento della risposta, notifica alle parti interessate, esecuzione del ripristino e validazione del ripristino.

Per gli enti finanziari, DORA può operare come regime settoriale di cybersicurezza per gli obblighi NIS2 sovrapposti, ma ciò non elimina la necessità di comprendere l’applicabilità di NIS2 per entità del gruppo, fornitori ICT, servizi gestiti o dipendenze cloud. La risposta pratica non è mantenere playbook separati. È eseguire un unico modello di evidenze SGSI mappato a tutti gli obblighi pertinenti.

Assicurazione cyber e coordinamento dei fornitori sono controlli di governance

L’assicurazione cyber può essere utile, ma non è una strategia ransomware. È un meccanismo di trasferimento del rischio con condizioni. Durante un evento ransomware, l’assicuratore può richiedere notifica immediata, uso di società del panel, approvazione preventiva della negoziazione, conservazione delle evidenze, prova del fallimento dei backup, prova di controlli ragionevoli e riesame legale prima di qualsiasi considerazione sul pagamento.

DORA rende il rischio ICT di terze parti un dominio di conformità di primo livello. NIS2 Article 21 richiede inoltre sicurezza della catena di fornitura e considerazione delle vulnerabilità e delle pratiche di cybersicurezza dei fornitori. ISO 27001 supporta la stessa logica attraverso controlli su fornitori e cloud come A.5.19-A.5.23, oltre ai controlli su incidenti, continuità e aspetti legali.

Zenith Controls collega la preparazione agli incidenti ai partner esterni, incluse società forensi, funzione legale, PR e contatto con le autorità. Dal punto di vista dell’audit, l’assenza di partner esterni pre-identificati può essere considerata una lacuna di preparazione perché può ritardare la risposta durante un incidente reale.

Per la governance dei pagamenti di riscatti ransomware, Clarysec raccomanda di pre-negoziare:

• Retainer forense o condizioni di risposta rapida.
• Disponibilità di consulenti legali esterni per violazioni, sanzioni e strategia del privilegio legale.
• Percorso di notifica all’assicuratore cyber ed elenco dei fornitori approvati.
• Percorso di escalation del provider cloud per snapshot, log, isolamento e ripristino.
• Procedure di collaborazione sugli incidenti con MSSP o MDR.
• Processo di riesame PR e comunicazioni di crisi.
• Controlli di approvazione bancaria o finanziaria per qualsiasi pagamento straordinario.
• Protocollo di contatto con le forze dell’ordine.

Questo si mappa bene sugli esiti NIST CSF 2.0 relativi alla catena di fornitura, inclusi ruoli e responsabilità dei fornitori, due diligence, requisiti contrattuali di cybersicurezza, coordinamento degli incidenti dei fornitori e attività successive alla cessazione.

Un playbook pratico di escalation per i pagamenti di riscatti ransomware

I cinque gate possono essere tradotti in un playbook operativo. Ogni passo deve essere documentato, assegnato a un titolare e testato.

L’obiettivo non è garantire una decisione comoda. Potrebbe non esistere alcuna decisione comoda. L’obiettivo è assicurare che la decisione sia autorizzata, basata su evidenze, informata sul piano legale e difendibile.

Il tabletop di 90 minuti che dimostra la preparazione

Il modo più semplice per testare la governance dei pagamenti di riscatti ransomware non è un red team tecnico. È un tabletop decisionale.

Usa Zenith Blueprint, fase Controls in Action, Step 23, per validare la capacità di gestione degli incidenti. Seleziona uno scenario ransomware ed esegui un’esercitazione a tempo. L’obiettivo non è decidere in anticipo che l’organizzazione pagherebbe o non pagherebbe mai. L’obiettivo è dimostrare che l’organizzazione può arrivare a una decisione governata.

Scenario: una banca dati clienti ospitata in cloud è cifrata, l’attaccante dichiara l’esfiltrazione, esistono backup ma non sono ancora stati sottoposti a test di integrità, l’assicuratore non è stato notificato e l’attaccante fornisce un indirizzo wallet con scadenza a 48 ore.

Checklist dell’esercitazione:

• Dichiarare l’incidente e assegnare il Responsabile della gestione dell’incidente.
• Aprire il log decisionale ransomware.
• Classificare l’evento utilizzando i criteri A.5.25.
• Identificare asset e servizi aziendali interessati.
• Determinare se sono coinvolti dati personali.
• Attivare i workflow di valutazione GDPR, NIS2, DORA e contrattuale.
• Notificare funzione legale, DPO, direzione esecutiva, assicuratore e fornitore forense.
• Conservare le evidenze prima di azioni distruttive di ripristino.
• Verificare integrità dei backup e opzioni di ripristino.
• Eseguire la verifica sanzionatoria prima di qualsiasi negoziazione.
• Registrare se è richiesta la consultazione con le forze dell’ordine.
• Redigere dichiarazioni preliminari per clienti e autorità di regolamentazione.
• Presentare le opzioni decisionali all’autorità esecutiva.
• Registrare decisione, motivazione, dissensi, approvazioni e azioni successive.
• Pianificare il riesame post-incidente e le azioni di miglioramento dei controlli.

L’output dovrebbe essere un pacchetto evidenze completo: elenco dei partecipanti, cronologia, foglio di classificazione, log decisionale, bozze di comunicazione, azioni legali, azioni per l’assicuratore, risultanze sui backup e lezioni apprese. Quel pacchetto è oro per l’audit perché dimostra la governance in funzione prima di una crisi reale.

Come auditor e autorità di regolamentazione testeranno il processo

Auditor con background diversi esamineranno lo stesso processo ransomware da prospettive differenti.

Zenith Controls fornisce una metodologia di audit dettagliata per A.5.24, A.5.25 e A.5.31. Per A.5.24, gli auditor esaminano il Piano di risposta agli incidenti, le classificazioni di gravità, i ruoli, le liste di contatto, le istruzioni di notifica regolamentare, le esercitazioni e gli accordi con partner esterni. Per A.5.25, riesaminano se esistono criteri di classificazione degli eventi, se le registrazioni di gestione degli alert mostrano decisioni di indagine ed escalation, se vengono utilizzati SIEM e threat intelligence e se i team DPO o legale sono coinvolti quando possono essere interessati dati personali. Per A.5.31, gli auditor cercano registri normativi, mappatura della conformità, evidenze di riesame, copertura dell’audit interno e reportistica all’alta direzione.

Il rischio di audit non è soltanto che un’organizzazione abbia pagato o rifiutato di pagare. Il rischio di audit è che nessuno possa dimostrare come sia stata presa la decisione.

Dall’estorsione al miglioramento dei controlli

La governance ransomware non termina quando i sistemi sono ripristinati. ISO 27001 richiede miglioramento continuo. A.5.27 apprendimento dagli incidenti di sicurezza delle informazioni è centrale per tale aspettativa. DORA richiede analisi della causa radice e controlli aggiuntivi. La relazione finale NIS2 richiede misure di mitigazione e probabile causa radice ove applicabile. L’accountability GDPR richiede documentazione delle decisioni e delle misure di sicurezza.

Ogni riesame post-incidente ransomware dovrebbe rispondere a queste domande:

• Le scadenze di notifica sono state identificate correttamente?
• L’autorità decisionale ha funzionato come previsto?
• Il riesame legale e sanzionatorio è avvenuto sufficientemente presto?
• Il coordinamento con l’assicuratore ha aiutato o ritardato la risposta?
• I backup erano completi, segregati, ripristinabili e testati?
• I log erano sufficienti per valutare accesso ed esfiltrazione?
• I fornitori hanno risposto secondo contratto?
• Le comunicazioni ai clienti sono state accurate e tempestive?
• I dirigenti hanno ricevuto le informazioni corrette al momento corretto?
• Quali controlli, politiche, contratti o attività formative devono cambiare?

Queste risposte dovrebbero aggiornare il Registro dei rischi, la Dichiarazione di Applicabilità, il Piano di risposta agli incidenti, la strategia di backup, i contratti con i fornitori, il piano di comunicazione e il programma di formazione.

Nella fase ISMS Foundation and Leadership, Step 5, Zenith Blueprint sottolinea la pianificazione delle comunicazioni esterne, inclusa l’identificazione di clienti, autorità di regolamentazione, partner e pubblico, la determinazione di cosa e quando comunicare e la definizione di chi comunica. Per il ransomware, quel passo diventa il ponte tra risposta tecnica e tutela della fiducia.

Costruire la registrazione decisionale prima della nota di riscatto

Il momento migliore per governare una decisione sul riscatto è prima che l’attaccante fissi la scadenza.

Se il tuo playbook ransomware non definisce autorità decisionale, riesame legale, verifica sanzionatoria, approvazione dell’assicuratore, conservazione delle evidenze, classificazione NIS2 e DORA, valutazione della violazione GDPR e documentazione a livello di consiglio di amministrazione, l’organizzazione ha una lacuna di governance in attesa di una crisi.

Clarysec aiuta le organizzazioni a costruire questa capacità nel SGSI utilizzando:

• Zenith Blueprint: roadmap in 30 passi per auditor per attuazione ISO 27001 per fasi, trattamento del rischio, pianificazione delle comunicazioni e validazione della capacità di gestione degli incidenti.
• Zenith Controls: guida alla conformità trasversale per mappare i controlli ISO 27001 su NIS2, DORA, GDPR, NIST CSF, COBIT 2019, ISO/IEC 27035, ISO/IEC 27701, ISO/IEC 27005 ed evidenze di audit.
• Politiche Clarysec enterprise e per PMI, incluse Politica di risposta agli incidenti, Politica di risposta agli incidenti - PMI, Politica per la raccolta delle evidenze e l’analisi forense, Politica per la raccolta delle evidenze e l’analisi forense - PMI, Politica sui ruoli e sulle responsabilità di governance, Politica sui ruoli e sulle responsabilità di governance - PMI e Politica di gestione del rischio.
• Template pratici per tabletop ransomware, log decisionali, matrici di escalation legale, pacchetti evidenze e fogli di lavoro per la reportistica di conformità trasversale.

Non aspettare la chiamata delle 3 del mattino per scoprire chi può decidere. Riesamina il tuo Piano di risposta agli incidenti rispetto ai cinque gate di Clarysec, esegui un tabletop di 90 minuti sul pagamento di un riscatto ransomware e costruisci una registrazione decisionale presidiata rispetto alle sanzioni e pronta per l’audit, in grado di reggere l’esame di autorità di regolamentazione, assicuratori e del tuo stesso consiglio di amministrazione.