Legal hold per incidenti informatici: evidenze per GDPR, NIS2 e DORA

Alle 4:17, Maria, CISO di un fornitore SaaS fintech, ricevette la chiamata a cui ogni responsabile della sicurezza si prepara e che, nonostante tutto, spera non arrivi mai. I server critici di produzione non rispondevano. I file erano cifrati. Sullo schermo di un amministratore junior era aperta una richiesta di riscatto.

Alle 4:28, il team di risposta agli incidenti voleva isolare i sistemi interessati e ridistribuire un’infrastruttura pulita. Alle 4:41, il team di ingegneria chiese se fosse possibile ruotare le credenziali, eliminare i file temporanei e ricostruire i container. Alle 5:03, il DPO avvertì che l’ambiente compromesso conteneva identificativi dei clienti e metadati delle transazioni. Alle 5:16, il consulente legale entrò nel canale di crisi con una sola istruzione: “Non distruggete potenziali evidenze. Potrebbe essere necessario un legal hold.” Alle 5:30, il COO chiese se fossero stati attivati gli obblighi di segnalazione DORA. Alle 6:00, Maria ricordò le scadenze NIS2: un preallarme potrebbe essere dovuto entro 24 ore, una notifica più completa entro 72 ore e una relazione finale entro un mese.

Poi arrivò la domanda che decide se un incidente informatico diventa difendibile o caotico:

“Abbiamo ancora i log?”

Questo è il problema di governance post-incidente che molti piani di risposta sottovalutano. Non basta rilevare, contenere e ripristinare. Nel 2026, le organizzazioni devono anche dimostrare che cosa è accaduto, conservare le evidenze pertinenti, evitare di compromettere gli artefatti forensi, rispettare la minimizzazione dei dati prevista dal GDPR, supportare la vigilanza NIS2 e mantenere registrazioni del rischio ICT DORA in grado di resistere ad audit, contenziosi e riesami regolatori.

Il legal hold per incidenti informatici e la conservazione delle evidenze si collocano nel punto di intersezione tra operazioni di sicurezza, privacy, funzione legale, conformità, ingegneria cloud, gestione dei fornitori e audit. Se il processo viene improvvisato durante una violazione, l’organizzazione può perdere le evidenze necessarie per l’analisi della causa radice, le segnalazioni alle autorità competenti, le richieste assicurative, la difesa in giudizio, le azioni disciplinari nei confronti dei dipendenti e l’assurance verso i clienti. Se viene applicato in modo eccessivo, l’organizzazione può conservare dati personali in misura sproporzionata e creare un secondo problema di conformità.

L’approccio di Clarysec consiste nel rendere il legal hold un processo SGSI controllato, non una reazione dettata dal panico. Il modello collega la governance ISO/IEC 27001:2022, i controlli ISO/IEC 27002:2022 su evidenze e logging, la responsabilizzazione GDPR, la segnalazione degli incidenti NIS2 e le evidenze di rischio ICT DORA in un unico sistema operativo. Questo sistema indica ai team che cosa conservare, chi può autorizzare la conservazione, per quanto tempo le evidenze restano soggette a legal hold, chi può accedervi e quando la cancellazione può riprendere.

Le prime 24 ore decidono se le evidenze sopravvivono

In molti incidenti reali, le evidenze non vengono distrutte dagli attaccanti. Vengono distrutte dalle normali attività operative.

Scade il periodo di conservazione dei log cloud. Un container viene ridistribuito. Un endpoint viene sottoposto a reimaging prima dell’acquisizione della memoria. Un amministratore SaaS esporta un CSV per l’indagine e poi modifica il file. Un ingegnere in buona fede elimina script malevoli prima di creare una copia forense. Un job di conservazione del data warehouse rimuove le registrazioni necessarie per determinare quali clienti siano stati interessati.

L’organizzazione può comunque ripristinare l’operatività, ma perde la prova. Questa distinzione è sostanziale.

Ai sensi del GDPR, un titolare del trattamento deve essere in grado di dimostrare la conformità ai principi di protezione dei dati, inclusi integrità e riservatezza, limitazione della finalità, minimizzazione dei dati e limitazione della conservazione. Se una violazione dei dati personali può comportare un rischio per le persone fisiche, l’Article 33 può richiedere la notifica all’autorità di controllo senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui se ne è venuti a conoscenza. Se la violazione può comportare un rischio elevato per le persone fisiche, l’Article 34 può richiedere la comunicazione agli interessati coinvolti.

Ai sensi della NIS2, i soggetti essenziali e importanti devono gestire gli incidenti significativi tramite segnalazione e vigilanza per fasi. Ai sensi di DORA, le entità finanziarie devono registrare gli incidenti connessi alle ICT, classificare gli incidenti rilevanti, segnalarli, svolgere l’analisi della causa radice e conservare evidenze relative agli asset ICT, alle funzioni aziendali e alle dipendenze da terze parti.

ISO/IEC 27001:2022 fornisce la struttura del sistema di gestione per tutto questo. La clausola 4.2 richiede all’organizzazione di determinare le esigenze e le aspettative delle parti interessate, inclusi i requisiti legali, regolatori e contrattuali pertinenti alla sicurezza delle informazioni. La clausola 4.3 richiede che il campo di applicazione del SGSI consideri interfacce e dipendenze, aspetto critico quando le evidenze si trovano presso un fornitore di servizi cloud, un prestatore di servizi di sicurezza gestiti, una piattaforma di pagamento o un helpdesk esternalizzato. La clausola 6.1 collega tali obblighi ai rischi per la sicurezza delle informazioni e al relativo trattamento. La clausola 7.5 richiede informazioni documentate controllate. La clausola 8 richiede pianificazione operativa e controllo.

Il Zenith Blueprint: roadmap in 30 passi per auditor di Clarysec spiega perché questo deve essere progettato prima dell’incidente, non durante. Nella fase Controlli in azione, passo 23, la guida per il controllo ISO/IEC 27002:2022 5.28 afferma:

“Quando si verifica un incidente di sicurezza delle informazioni, uno degli elementi più critici, eppure spesso trascurati, della risposta è costituito dalle evidenze. Non log, non screenshot, non ricostruzioni narrative informali, ma evidenze correttamente conservate, rispettose della catena di custodia e resistenti alla manomissione.”

Lo stesso passo 23 aggiunge che “ciò che si può dimostrare conta quanto ciò che è effettivamente accaduto”. Questa frase distingue la risposta agli incidenti dalla risposta agli incidenti difendibile. Un’autorità competente, un auditor del cliente, un tribunale, un assicuratore o un’autorità di controllo non accetterà una ricostruzione verbale se l’organizzazione non può mostrare log conservati, marcature temporali affidabili, registrazioni controllate e una catena di custodia documentata.

Il legal hold non significa “conservare tutto per sempre”

Un legal hold per incidenti informatici è una sospensione formale della normale cancellazione o dello smaltimento di registrazioni, log, backup, immagini, comunicazioni e altre evidenze definite che possono essere pertinenti a un’indagine, un contenzioso, una richiesta dell’autorità competente, un audit o una controversia contrattuale.

L’errore più comune è trattare il legal hold come un’istruzione generalizzata: “Non cancellate nulla.” Questo crea rischi di privacy, costi e operatività. Il GDPR non scompare durante un incidente informatico. I dati personali devono comunque essere trattati in modo lecito, corretto e trasparente, per finalità determinate, limitati a quanto necessario e conservati solo per il tempo necessario. L’Article 5(2) aggiunge la responsabilizzazione, ossia l’organizzazione deve essere in grado di dimostrare tali decisioni.

È qui che la libreria di policy Clarysec diventa operativa. La Policy di conservazione dei dati e smaltimento sicuro per PMI stabilisce:

“Il legal hold e la sospensione della cancellazione prevalgono sui requisiti standard di conservazione e impediscono la cancellazione dei dati.”

Per le organizzazioni più grandi, la Policy enterprise di conservazione e smaltimento dei dati, clausola 6.4.1, afferma:

“Se viene emesso un legal hold con sospensione della cancellazione (ad esempio in pendenza di contenzioso, indagine o audit), i dati altrimenti soggetti a distruzione devono essere conservati oltre il normale periodo di conservazione.”

La stessa policy enterprise richiede che il legal hold sia:

“Documentato e approvato dal consulente legale e dal Responsabile della protezione dei dati (DPO)”

Questo modello di approvazione non è burocrazia. È il meccanismo di bilanciamento tra conservazione probatoria e contenimento del rischio privacy. Il consulente legale conferma la base contenziosa, investigativa o regolatoria. Il DPO conferma che ambito, finalità, categorie di dati personali, controlli di accesso ed estensione della conservazione restino proporzionati.

Per le PMI senza una funzione legale strutturata o una funzione DPO dedicata, la stessa logica decisionale può essere applicata da un vCISO, dal referente privacy, dall’amministratore delegato e da un consulente esterno, purché l’autorizzazione sia documentata, limitata nel tempo e riesaminata.

La tensione di conformità che ogni CISO deve risolvere

Dopo un grave incidente di sicurezza, parti interessate diverse richiedono evidenze diverse. La funzione legale vuole la conservazione. La privacy vuole la minimizzazione. Le autorità competenti vogliono i fatti. Le operations vogliono il ripristino. I clienti vogliono assurance. Gli auditor vogliono evidenze oggettive.

Gestire queste esigenze tramite workflow separati di privacy, funzione legale, SOC e audit produce facilmente contraddizioni. Un SGSI ISO/IEC 27001:2022 unificato le integra in un unico processo di rischio, controllo ed evidenze.

Lo stack di controlli per una conservazione delle evidenze difendibile

Il legal hold per incidenti informatici non è un singolo controllo ISO/IEC 27002:2022. È una relazione tra controlli.

La Zenith Controls: guida alla cross-compliance di Clarysec mappa il controllo ISO/IEC 27002:2022 5.28, Raccolta delle evidenze, come controllo correttivo a supporto di riservatezza, integrità e disponibilità. Si colloca nei concetti di cibersicurezza Detect e Respond e nella capacità operativa di gestione degli eventi di sicurezza delle informazioni.

La stessa guida Zenith Controls collega 5.28 alla risposta agli incidenti di sicurezza delle informazioni, al logging e monitoraggio, alla protezione delle registrazioni e alla segnalazione degli eventi. La logica è concreta: i responder agli incidenti hanno bisogno di log e artefatti prima che la bonifica modifichi la scena, chi effettua segnalazioni regolatorie ha bisogno di fatti affidabili e gli investigatori hanno bisogno di evidenze che non siano state alterate.

Il controllo ISO/IEC 27002:2022 5.33, Protezione delle registrazioni, è altrettanto importante. Supporta i requisiti legali e di conformità, la gestione degli asset e la protezione delle informazioni. Collega la protezione delle registrazioni a classificazione, backup, smaltimento sicuro, requisiti legali e contrattuali, controllo degli accessi e risposta agli incidenti. In pratica, un legal hold non deve solo acquisire evidenze. Deve proteggere integrità, riservatezza e disponibilità della registrazione probatoria stessa.

Per la registrazione, il controllo ISO/IEC 27002:2022 8.15, Logging, è la base. Si collega a 8.16, Attività di monitoraggio, e 8.17, Sincronizzazione degli orologi. Se i log sono incompleti, modificabili dagli amministratori, non sincronizzati temporalmente o conservati per un periodo troppo breve, il processo probatorio può fallire prima ancora che l’indagine inizi.

Il Zenith Blueprint, nella fase Controlli in azione, passo 19, rafforza questo punto con un’indicazione pratica sul logging:

“I log che registrano attività, eccezioni, errori e altri eventi rilevanti dovrebbero essere prodotti, archiviati, protetti e analizzati.”

Avverte inoltre che la protezione dei log include la limitazione dell’accesso e l’uso di meccanismi quali hashing o archiviazione write-once per prevenire la manomissione. Il passo 19 collega la sincronizzazione degli orologi alla coerenza forense, spiegando che orologi sincronizzati consentono di allineare i log di sistemi diversi ai fini dell’indagine.

Responsabilizzazione GDPR: conserva ciò che serve, giustifica ciò che mantieni

Il GDPR crea la tensione più evidente nella conservazione delle evidenze di incidente. I team di sicurezza spesso vogliono più dati. I team privacy ne vogliono meno. Un legal hold difendibile concilia entrambe le esigenze.

Log e artefatti possono contenere indirizzi IP, ID utente, indirizzi e-mail, identificativi dei dispositivi, registrazioni di autenticazione, testo dei ticket di supporto, screenshot, esportazioni dei clienti o dati appartenenti a categorie particolari. La conservazione delle evidenze costituisce quindi trattamento. L’avviso di legal hold deve documentare base giuridica, finalità, ambito, restrizioni di accesso, data di riesame della conservazione e trigger di smaltimento.

La Policy di protezione dei dati e privacy per PMI di Clarysec stabilisce:

“Devono essere raccolti e conservati solo i dati personali minimi necessari”

La Policy per la raccolta delle evidenze e l’analisi forense enterprise collega esplicitamente la gestione delle evidenze forensi a:

“GDPR Article 5, inclusi limitazione della finalità e minimizzazione dei dati”

Questo è il principio operativo. Non conservare un intero database di produzione se l’evidenza pertinente è una traccia di audit circoscritta, un registro degli accessi, una registrazione delle query e l’elenco degli utenti interessati. Non concedere a ogni responder accesso alle evidenze grezze se sono sufficienti estratti pseudonimizzati o accesso basato sui ruoli. Non conservare artefatti di incidente a tempo indeterminato dopo la cessazione dell’esigenza legale, regolatoria e di audit.

Una buona registrazione di legal hold conforme al GDPR risponde a sette domande:

1. Quale incidente o indagine ha attivato il legal hold?
2. Quali categorie di dati personali possono essere incluse?
3. Perché ciascuna categoria di evidenze è necessaria?
4. Chi ha approvato il legal hold e quando?
5. Chi può accedere alle evidenze?
6. Quando sarà riesaminato il legal hold?
7. Quale processo di cancellazione o smaltimento sicuro riprende al rilascio del legal hold?

È così che la conservazione delle evidenze evita di diventare sovra-conservazione di dati personali.

NIS2: legal hold per la segnalazione degli incidenti per fasi

Per le organizzazioni rientranti nell’ambito di applicazione, NIS2 cambia l’aspettativa sulle evidenze da “utile internamente” a “necessaria per la vigilanza”.

NIS2 si applica a molti soggetti essenziali e importanti nell’UE, inclusi fornitori di infrastrutture digitali, fornitori di servizi di cloud computing, fornitori di servizi di data center, reti di distribuzione dei contenuti, prestatori di servizi fiduciari, fornitori di comunicazioni elettroniche, prestatori di servizi gestiti, prestatori di servizi di sicurezza gestiti e alcuni fornitori digitali come mercati online, motori di ricerca online e piattaforme di social networking.

L’Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate, incluse analisi dei rischi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, sviluppo sicuro, valutazione dell’efficacia, formazione, crittografia, sicurezza delle risorse umane, controllo degli accessi, gestione degli asset e autenticazione. L’Article 20 attribuisce agli organi di gestione la responsabilità di approvare e supervisionare tali misure.

Per il legal hold, il punto chiave della NIS2 è l’Article 23. Gli incidenti significativi richiedono segnalazioni per fasi: preallarme entro 24 ore dal momento in cui si viene a conoscenza dell’incidente, notifica dell’incidente entro 72 ore, relazioni intermedie su richiesta e relazione finale non oltre un mese dalla notifica a 72 ore. La relazione finale richiede descrizione, gravità, impatto, probabile tipo di minaccia o causa radice, misure di mitigazione e impatto transfrontaliero ove applicabile.

Se l’incidente riguarda dati personali, le autorità competenti NIS2 possono cooperare con le autorità di controllo GDPR. Questo aumenta la necessità di una narrativa probatoria unica che supporti sia la vigilanza sulla cibersicurezza sia la responsabilizzazione privacy.

DORA: le evidenze di rischio ICT vanno oltre i log di sicurezza

Per le entità finanziarie, DORA è il regime settoriale di resilienza operativa. Si applica dal 17 gennaio 2025 e copre gestione del rischio ICT, segnalazione degli incidenti ICT rilevanti, test di resilienza, condivisione delle informazioni e gestione del rischio ICT di terze parti. Per le entità finanziarie che sono anche soggetti essenziali o importanti ai sensi della NIS2, DORA opera in genere come atto giuridico dell’Unione settoriale per il rischio ICT e la segnalazione degli incidenti.

DORA è fortemente basata sulle evidenze per progettazione. L’Article 17 richiede un processo di gestione degli incidenti connessi alle ICT. L’Article 18 disciplina la classificazione degli incidenti connessi alle ICT e delle minacce informatiche. L’Article 19 riguarda la segnalazione degli incidenti gravi connessi alle ICT. Le entità finanziarie devono inoltre mantenere assetti di governance e controllo, identificare funzioni critiche o importanti, documentare asset e dipendenze ICT e svolgere analisi della causa radice.

Questo significa che il legal hold DORA deve coprire evidenze di resilienza operativa, non solo artefatti di sicurezza. Dopo una compromissione dell’identità cloud che incide sulle operazioni di pagamento, il legal hold può includere log del provider di identità, storico degli accessi privilegiati, log di audit cloud, allerte SIEM, immagini degli endpoint, analisi dell’impatto sulle transazioni dei clienti, registrazioni di attivazione della continuità operativa, evidenze di backup e ripristino, comunicazioni con i fornitori, briefing agli organi di gestione, analisi della causa radice e validazione delle azioni correttive.

DORA rende inoltre inevitabili le evidenze ICT di terze parti. Gli Articles 28 a 30 richiedono gestione del rischio ICT di terze parti, registri degli accordi contrattuali, due diligence, valutazione del rischio di concentrazione e contratti scritti con diritti e obblighi. Per funzioni critiche o importanti, i contratti dovrebbero supportare obblighi di avviso e segnalazione del provider, assistenza sugli incidenti, cooperazione con le autorità, diritti di accesso, ispezione e audit, nonché strategie di uscita.

Se il tuo fornitore di servizi cloud, MSP, MSSP, processore di pagamento o dipendenza SaaS detiene i log pertinenti, il processo di legal hold deve essere già incorporato nei contratti con i fornitori. In caso contrario, durante un incidente rilevante potresti scoprire che la finestra standard di conservazione del provider è più breve del ciclo di vita della tua segnalazione regolatoria.

Come Clarysec rende operativo il legal hold durante una violazione SaaS

Consideriamo l’ambiente fintech SaaS di Maria. L’incidente può comportare accesso non autorizzato a identificativi dei clienti, metadati delle transazioni, sistemi amministrativi e registrazioni di un SOC esternalizzato. La società serve istituzioni finanziarie dell’UE, si basa su infrastruttura cloud e può essere soggetta a GDPR, obblighi contrattuali DORA e doveri NIS2.

La prima azione non è conservare tutto. La prima azione è attivare una decisione controllata.

Il coordinatore dell’incidente invia una richiesta di legal hold al consulente legale, al DPO o al referente privacy, al CISO e al titolare del processo aziendale. La richiesta include ID incidente, data e ora, sistemi interessati, categorie di dati sospette, percorsi regolatori iniziali, categorie di evidenze proposte e rischi immediati di cancellazione.

Utilizzando la Policy enterprise di conservazione e smaltimento dei dati, il legal hold viene documentato e approvato dal consulente legale e dal DPO. Per le PMI, la Policy di conservazione dei dati e smaltimento sicuro per PMI fornisce la regola di sospensione della cancellazione. L’autorizzazione include una data di riesame allineata alle milestone dell’indagine, alle scadenze di segnalazione regolatoria e al rischio atteso di contenzioso o controversia contrattuale. Non dice “per sempre”. Dice “fino al rilascio mediante decisione autorizzata dopo riesame”.

Successivamente, il team congela i log e gli artefatti pertinenti. La Policy di logging e monitoraggio per PMI stabilisce:

“I log devono essere posti in legal hold con sospensione della cancellazione e protetti contro alterazione o cancellazione”

Il team sospende la cancellazione per casi SIEM, log di identità, log di audit cloud, log applicativi, log delle query di database, eventi WAF e metadati delle allerte SOC. I log esportati sono archiviati in uno storage delle evidenze ad accesso ristretto con hashing, controllo delle versioni e autorizzazioni in sola lettura ove appropriato.

La regola di raccolta è semplice: conservare le evidenze senza modificare gli originali. La Policy per la raccolta delle evidenze e l’analisi forense per PMI stabilisce:

“Deve sempre essere creata una copia forense o un’esportazione; l’evidenza originale non deve mai essere modificata direttamente.”

Gli ingegneri possono eseguire la bonifica, ma solo dopo che siano stati creati gli snapshot, le esportazioni o le copie forensi richiesti, salvo che sia necessario un contenimento immediato per prevenire un danno in corso. Se la bonifica d’emergenza avviene prima, la motivazione viene documentata.

La stessa policy per PMI afferma:

“Per ciascun incidente deve essere mantenuto un semplice log della catena di custodia (ad esempio un file Excel o un modello di documento).”

Per gli ambienti enterprise, la Policy per la raccolta delle evidenze e l’analisi forense, clausola 5.6, richiede:

“Un log 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:”

In pratica, il log della catena di custodia registra ID evidenza, descrizione, sistema sorgente, incaricato della raccolta, metodo di acquisizione, valore hash ove applicabile, fonte temporale, posizione di archiviazione, eventi di accesso, trasferimenti, copie di analisi e destinazione finale.

Infine, la registrazione dell’indagine stessa deve essere protetta. La Policy di audit e monitoraggio della conformità enterprise stabilisce:

“Tutti i log di audit, le risultanze e i report di remediation devono essere conservati, cifrati e protetti contro la manomissione.”

Tale requisito si applica alla cronologia dell’incidente, al log decisionale, all’avviso di legal hold, alle comunicazioni con le autorità competenti, alle comunicazioni con i clienti, all’analisi della causa radice e alle evidenze delle azioni correttive.

Le informazioni documentate che gli auditor esamineranno

La clausola 7.5 di ISO/IEC 27001:2022 richiede che le informazioni documentate necessarie al SGSI e richieste dalla norma siano controllate. Il Zenith Blueprint, nella fase Fondazione e leadership del SGSI, passo 6, traduce questo requisito in indicazioni pratiche: i documenti dovrebbero avere identificazione, formato, riesame, approvazione, controllo delle versioni, accesso controllato, protezione dell’integrità, controllo delle modifiche, conservazione e disposizione.

Il passo 6 osserva inoltre che registrazioni quali log di monitoraggio, rapporti di audit e file di indagine sugli incidenti possono essere riservate e dovrebbero essere condivise secondo il principio del need-to-know, con diritti di modifica limitati agli utenti autorizzati.

Un pacchetto di evidenze difendibile dovrebbe includere:

• Avviso di legal hold e approvazione.
• Classificazione dell’incidente e decisione sulla gravità.
• Inventario delle evidenze.
• Log della catena di custodia.
• Conferma della conservazione dei log.
• Immagine forense o registrazioni di esportazione.
• Valori hash o controlli di integrità ove applicabile.
• Elenco degli accessi allo storage delle evidenze.
• Evidenze di segnalazione regolatoria.
• Valutazione privacy e analisi dell’impatto sui dati personali.
• Richieste di evidenze ai fornitori e relative risposte.
• Analisi della causa radice.
• Evidenze delle azioni correttive e validazione.
• Riesame del legal hold e decisione di rilascio.

Più forte è il controllo delle informazioni documentate, più semplice sarà l’audit.

Evidenze di fornitori e cloud: il punto di errore che molti team trascurano

Le evidenze più difficili spesso non si trovano all’interno dell’organizzazione. Sono detenute da un fornitore di servizi cloud, una piattaforma SaaS, un MSSP, un MSP, un processore di pagamento, un provider di identità o un team di sviluppo esternalizzato.

L’Article 21 della NIS2 include la sicurezza della catena di fornitura e gli aspetti di sicurezza dei rapporti con fornitori diretti o prestatori di servizi. DORA va oltre per le entità finanziarie, richiedendo registri ICT di terze parti, due diligence, analisi del rischio di concentrazione e contratti con assistenza sugli incidenti, segnalazione da parte del provider, cooperazione con le autorità, diritti di audit e disposizioni di uscita per funzioni critiche o importanti.

Anche il NIST Cybersecurity Framework 2.0 tratta il rischio della catena di fornitura come una disciplina di ciclo di vita. La sua funzione Govern include esiti di gestione del rischio dei fornitori per strategia, ruoli, contratti, due diligence, monitoraggio, partecipazione agli incidenti e disposizioni di uscita. I profili CSF possono esprimere requisiti obiettivo di cibersicurezza verso i fornitori, aspetto utile quando si traducono le esigenze probatorie del legal hold in clausole contrattuali.

I contratti con i fornitori dovrebbero disciplinare:

• Tipi di log di sicurezza disponibili per il cliente.
• Periodi di conservazione predefiniti e opzioni di conservazione estesa.
• Processo di richiesta di conservazione d’emergenza.
• Tempo necessario per conservare le evidenze dopo la richiesta del cliente.
• Formati di esportazione forense.
• Supporto alla catena di custodia.
• Cooperazione con le autorità competenti.
• Obblighi probatori di sub-responsabili o subappaltatori.
• Restrizioni su localizzazione e trasferimento dei dati.
• Cancellazione sicura dopo il rilascio del legal hold.

Il Zenith Blueprint, nella fase Controlli in azione, passo 18, fornisce una disciplina analoga per il trasferimento dei supporti fisici, richiedendo cifratura, imballaggi antimanomissione, tracciamento, log di trasporto, inventario dei supporti e audit del registro. La stessa logica si applica ai trasferimenti di evidenze cloud: preservare l’integrità, tracciare la custodia, restringere l’accesso e confermare la ricezione.

Come auditor e autorità competenti testeranno il processo di legal hold

Un processo di legal hold appare diverso a seconda del mandato del revisore. Clarysec utilizza Zenith Controls come bussola di cross-compliance, in modo che lo stesso pacchetto di evidenze possa soddisfare più prospettive senza duplicare il lavoro.

L’auditor ISO si concentrerà sulla conformità e sulle evidenze oggettive. Il revisore GDPR si concentrerà su necessità, limitazione della finalità e responsabilizzazione dimostrabile. Il revisore NIS2 si concentrerà sui fatti relativi alla segnalazione degli incidenti significativi e sulla responsabilità della direzione. Il revisore DORA si concentrerà su governance del rischio ICT, gestione degli incidenti rilevanti, dipendenze da terze parti e lezioni apprese. L’auditor COBIT 2019 o in stile ISACA si concentrerà su governance, progettazione dei controlli, funzionamento dei controlli e assurance sulla qualità delle informazioni.

Un solo pacchetto di evidenze può servire tutti questi interlocutori, se viene progettato in questo modo.

Checklist pratica per il legal hold degli incidenti informatici nel 2026

Usa questa checklist prima del prossimo grave incidente di sicurezza, non durante.

Questa checklist diventa più efficace quando è integrata nel piano di trattamento del rischio del SGSI, nei requisiti di sicurezza dei fornitori, nei runbook di risposta agli incidenti, nell’architettura di logging e nella governance privacy.

Dal panico post-violazione alla resilienza pronta per l’audit

La chiamata delle 4 del mattino sarà sempre stressante. Non deve trasformarsi in caos.

Un processo maturo di legal hold per incidenti informatici offre a ogni parte interessata un percorso controllato. La funzione legale ottiene una conservazione difendibile. La privacy ottiene minimizzazione e riesame. Il CISO ottiene integrità delle evidenze. Il DPO ottiene responsabilizzazione. Il consiglio di amministrazione ottiene fatti affidabili. I revisori NIS2, DORA e GDPR ottengono evidenze oggettive invece di spiegazioni improvvisate.

La metodologia in 30 passi di Clarysec non tratta il legal hold come un memorandum legale autonomo. Lo tratta come una capacità operativa del SGSI.

In Zenith Blueprint, il passo 6 costruisce la libreria delle informazioni documentate, incluse regole di conservazione e disposizione. Il passo 19 rafforza logging e sincronizzazione degli orologi affinché le indagini possano ricostruire le cronologie. Il passo 23 rende operativa la raccolta delle evidenze e la catena di custodia. Il passo 18 aggiunge disciplina nella gestione dei supporti quando le evidenze si spostano fisicamente o tra parti.

In Zenith Controls, Clarysec collega i controlli ISO/IEC 27002:2022 sottostanti in modo che i clienti possano vedere come la raccolta delle evidenze dipenda da logging, monitoraggio, risposta agli incidenti, protezione delle registrazioni, controllo degli accessi, backup, privacy e requisiti legali.

Nella libreria di policy Clarysec, gli ancoraggi operativi del workflow sono già definiti: Policy di conservazione e smaltimento dei dati, Policy di conservazione dei dati e smaltimento sicuro per PMI, Policy per la raccolta delle evidenze e l’analisi forense, Policy per la raccolta delle evidenze e l’analisi forense per PMI, Policy di logging e monitoraggio per PMI, Policy di protezione dei dati e privacy per PMI e Policy di audit e monitoraggio della conformità.

Se il tuo piano di risposta agli incidenti dice “conservare le evidenze” ma non definisce autorità di legal hold, ambito delle evidenze, sospensione della cancellazione, catena di custodia, conservazione presso i fornitori, minimizzazione GDPR e criteri di rilascio, non è ancora pronto per l’audit.

Costruisci il processo prima della violazione. Clarysec può aiutarti a creare una capacità difendibile di legal hold per incidenti informatici e conservazione delle evidenze usando Zenith Blueprint: roadmap in 30 passi per auditor, Zenith Controls: guida alla cross-compliance e i template di policy Clarysec, tra cui la Policy di conservazione e smaltimento dei dati, la Policy per la raccolta delle evidenze e l’analisi forense, la Policy di audit e monitoraggio della conformità, la Policy di logging e monitoraggio per PMI, la Policy di protezione dei dati e privacy per PMI e la Policy per la raccolta delle evidenze e l’analisi forense per PMI.

Scarica i toolkit, richiedi un riesame delle policy Clarysec o prenota una valutazione della preparazione alla conservazione delle evidenze prima del prossimo audit, della prossima richiesta dell’autorità di controllo o del prossimo importante riesame di sicurezza da parte di un cliente.