Il sistema europeo di produzione e conservazione delle prove elettroniche

Applicabile dal 18 agosto 2026 — focus operativo per autorità giudiziaria, polizia giudiziaria e personale tecnico-forense

In sintesi
Dal 18 agosto 2026 l’autorità giudiziaria di uno Stato membro può rivolgersi direttamente allo stabilimento designato o al rappresentante legale di un prestatore di servizi in un altro Stato membro per ottenere la conservazione (EPOC-PR) o la produzione (EPOC) di prove elettroniche, senza dover passare per l’assistenza giudiziaria o per l’ordine europeo di indagine.
Quattro categorie di dati, con presupposti crescenti: abbonati, sola identificazione dell’utente, traffico, contenuto.
Termini stringenti: 10 giorni per la produzione, 8 ore nei casi di emergenza; l’obbligo di conservazione dura 60 giorni, prorogabili di 30.
Per traffico e contenuto: presupposti rafforzati quanto ad autorità competente e gravità del reato e, di regola, notifica all’autorità di esecuzione. La qualità giuridica della richiesta e la qualità tecnica dell’identificatore sono due facce della stessa attività: un certificato impreciso non produce risultati, un certificato privo dei presupposti produce dati inutilizzabili.
Avvertenza
Il documento ha finalità informativa e operativa. Non sostituisce il testo del Regolamento, la normativa nazionale, le istruzioni dell’Autorità giudiziaria o i protocolli dell’ufficio. Le linee guida SIRIUS sono uno strumento pratico volontario: aiutano a compilare correttamente i certificati, ma non modificano la disciplina normativa.

1. Oggetto, destinatari e fonti

Il documento riepiloga il quadro normativo e le indicazioni operative sul pacchetto e-evidence, pienamente applicabile dal 18 agosto 2026, con specifica attenzione ai profili che interessano l’attività di polizia giudiziaria e la gestione delle richieste ai prestatori di servizi: piattaforme di social networking e messaggistica, servizi di hosting, servizi di comunicazione elettronica, registri e registrar.

È destinato a un pubblico misto — magistrati, ufficiali e agenti di polizia giudiziaria, personale informatico-forense — e per questo alterna la ricostruzione dell’impianto normativo a indicazioni compilative e tecniche direttamente utilizzabili.

È costruito su tre corpi di materiali:

  • il regolamento (UE) 2023/1543 e la direttiva (UE) 2023/1544, con il regolamento di esecuzione (UE) 2025/1550 sulle specifiche tecniche del sistema informatico decentrato;
  • la normativa italiana di adeguamento: d.lgs. 30 dicembre 2025, n. 215 e d.lgs. 30 dicembre 2025, n. 216;
  • le linee guida SIRIUS per la compilazione del certificato di ordine europeo di produzione (EPOC), giugno 2026, elaborate nell’ambito del progetto SIRIUS di Eurojust ed Europol, e le corrispondenti linee guida per l’EPOC-PR.

Fonte/riscontro: Reg. (UE) 2023/1543; Dir. (UE) 2023/1544; Reg. di esecuzione (UE) 2025/1550; D.Lgs. 215 e 216 del 2025; Linee guida SIRIUS EPOC, giugno 2026.

2. Cosa cambia dal 18 agosto 2026

Il regolamento introduce un canale europeo specifico per ottenere o preservare prove elettroniche detenute da prestatori che offrono servizi nell’Unione. La novità principale è la possibilità, nei casi previsti, di rivolgere l’ordine direttamente allo stabilimento designato o al rappresentante legale del prestatore in un altro Stato membro, senza dover passare per i tradizionali meccanismi di assistenza giudiziaria.

Il fondamento è l’articolo 82, paragrafo 1, TFUE e il principio del reciproco riconoscimento delle decisioni giudiziarie. La scelta dello strumento regolamentare — direttamente applicabile — in una materia tradizionalmente affidata alla cooperazione mediante direttive è stata definita particolarmente incisiva, perché sposta il baricentro dell’interlocuzione dall’autorità centrale al prestatore di servizi, al quale è attribuito un ruolo attivo di ricezione e verifica del certificato.

Gli elementi da fissare fin d’ora:

  • due strumenti: ordine europeo di produzione, per ottenere i dati, e ordine europeo di conservazione, per congelarli in vista di una successiva richiesta di produzione;
  • quattro categorie di dati: dati relativi agli abbonati, dati richiesti al solo scopo di identificare l’utente, dati sul traffico, dati relativi al contenuto;
  • tempi stringenti: per l’EPOC, ordinariamente entro 10 giorni; nei casi di emergenza senza indebito ritardo e comunque entro 8 ore; per l’EPOC-PR conservazione senza indebito ritardo, con obbligo che cessa dopo 60 giorni salvo conferma di una successiva richiesta di produzione;
  • notifica all’autorità di esecuzione per i dati di traffico non richiesti al solo scopo di identificare l’utente e per i dati di contenuto, salvo la specifica eccezione territoriale e residenziale dell’art. 8;
  • trasmissione digitale attraverso il sistema informatico decentrato, individuato dalla documentazione SIRIUS come JUDEX, con soglia tecnica di 25 MB per singolo trasferimento;
  • quadro italiano: il d.lgs. 215/2025 individua autorità e procedure, il d.lgs. 216/2025 attua la direttiva sugli stabilimenti designati e sui rappresentanti legali.
DataAdempimento
18 agosto 2025Termine per la notifica alla Commissione, ex art. 31, delle autorità competenti all’emissione, convalida, trasmissione, ricezione ed esecuzione degli ordini, nonché delle lingue accettate.
18 febbraio 2026Termine di recepimento della direttiva (UE) 2023/1544 e di notifica delle disposizioni sanzionatorie.
18 agosto 2026Data di applicazione del regolamento (art. 34, par. 2) e termine entro il quale i prestatori che offrono servizi nell’Unione devono avere designato lo stabilimento o nominato il rappresentante legale. Per i prestatori che iniziano a operare dopo il 18 febbraio 2026 il termine è di sei mesi dall’avvio dell’attività.

Fonte/riscontro: Reg. (UE) 2023/1543, artt. 31 e 34; Dir. (UE) 2023/1544, art. 7; D.Lgs. 215 e 216 del 2025.

Il nuovo sistema non sostituisce gli strumenti esistenti: vi coesiste. Gli strumenti tradizionali continuano a operare nei rapporti con Stati terzi, mentre l’e-evidence opera dentro il perimetro unionale e verso i prestatori che offrono servizi nell’Unione, anche se stabiliti fuori.

Il rapporto con l’ordine europeo di indagine va ricostruito in termini di specialità funzionale: quando ricorrono i presupposti del regolamento, l’ordine europeo di produzione o di conservazione è la via propria per acquisire la prova digitale presso il prestatore; l’OEI resta lo strumento generale per gli atti investigativi che richiedano l’intervento dell’autorità dello Stato di esecuzione o che esulino dall’ambito oggettivo del regolamento.

Il precedente da conoscere
Le Sezioni unite, con le sentenze gemelle n. 23755 e n. 23756 del 29 febbraio 2024 in tema di criptofonini, hanno stabilito che, quando ricorrono i presupposti della cooperazione giudiziaria fra Stati membri, l’acquisizione transfrontaliera deve passare per il canale cooperativo europeo, senza che sia possibile ricorrere a strumenti interni per eluderlo: l’art. 234-bis c.p.p. opera esclusivamente fuori dalle ipotesi di cooperazione.
Le stesse pronunce hanno chiarito che, attivato il canale europeo, il controllo del giudice dello Stato di emissione si colloca prevalentemente sul piano dell’utilizzabilità della prova nel processo nazionale, senza trasformarsi in una verifica generalizzata delle modalità investigative dell’autorità straniera.

Fonte/riscontro: Relazione n. 25/2026 dell’Ufficio del Massimario, §§ 3.2 e 4; Sez. U, nn. 23755 e 23756 del 29/02/2024.

3. Lessico essenziale

TermineSignificato operativo
EPOEuropean Production Order: la decisione, ossia l’ordine europeo di produzione.
EPOCEuropean Production Order Certificate: il certificato con cui l’ordine di produzione viene trasmesso al destinatario.
Ordine europeo di conservazioneDecisione che impone di preservare dati specifici per evitarne rimozione, cancellazione o modifica, in vista di una successiva richiesta di produzione.
EPOC-PREuropean Preservation Order Certificate: il certificato con cui viene trasmesso l’ordine europeo di conservazione.
Autorità di emissioneAutorità competente dello Stato che emette l’ordine.
Autorità di convalidaAutorità giudiziaria che convalida l’ordine quando il regolamento o il diritto nazionale lo richiedono.
Autorità di esecuzioneAutorità dello Stato del destinatario, coinvolta nei casi di notifica o nell’esecuzione coattiva.
DestinatarioDi regola lo stabilimento designato o il rappresentante legale del prestatore di servizi.
JUDEXInterfaccia operativa del sistema informatico decentrato per la trasmissione di certificati, notifiche e dati.
EPO non significa EPOC
Nella pratica è facile usare impropriamente i due acronimi come sinonimi. L’ordine è la decisione dell’autorità; l’EPOC è il certificato standardizzato trasmesso al destinatario. La stessa distinzione vale fra ordine europeo di conservazione ed EPOC-PR.

Fonte/riscontro: Reg. (UE) 2023/1543, artt. 3 e 9; Linee guida SIRIUS EPOC, sezioni A-M.

4. Ambito di applicazione e destinatari

Il sistema riguarda prove elettroniche in procedimenti penali e, nei casi previsti, l’esecuzione di pene o misure detentive. Il dato può essere tecnicamente memorizzato anche fuori dallo Stato dell’autorità richiedente: ciò che rileva è che il prestatore offra servizi nell’Unione e che l’ordine sia indirizzato al soggetto giuridicamente designato a riceverlo.

Sono ricompresi i prestatori che forniscono nell’Unione una o più delle seguenti categorie di servizi:

  • servizi di comunicazione elettronica, compreso l’accesso a Internet;
  • servizi di comunicazione interpersonale;
  • servizi di nomi di dominio Internet e di numerazione IP, inclusi registri, registrar e servizi privacy o proxy connessi ai nomi di dominio;
  • altri servizi della società dell’informazione che consentono agli utenti di comunicare fra loro oppure che memorizzano o trattano dati per conto dell’utente, quando tale funzione è una componente caratteristica del servizio: social network, marketplace, hosting.

Restano esclusi i servizi finanziari — bancari, creditizi, assicurativi, riassicurativi, previdenziali, relativi a titoli e fondi, di pagamento e di consulenza sugli investimenti — e i servizi offerti esclusivamente all’interno di un singolo Stato membro. L’esclusione non pregiudica la facoltà delle autorità nazionali di rivolgersi con gli strumenti interni ai prestatori stabiliti o rappresentati nel proprio territorio: le acquisizioni puramente nazionali restano disciplinate dal diritto interno.

Il sistema e-evidence non va quindi letto come una competenza universale fondata sulla mera presenza del dato «nel cloud»: è una procedura europea con presupposti soggettivi, territoriali e procedurali propri. Ne consegue, per converso, che le principali piattaforme di social networking e di messaggistica con stabilimento o rappresentante legale nell’Unione rientrano a pieno titolo fra i destinatari degli ordini, nei limiti dei dati che effettivamente detengono.

Fonte/riscontro: Reg. (UE) 2023/1543, artt. 1-3 e 7; Dir. (UE) 2023/1544, considerando 7-8 e art. 3; D.Lgs. 216/2025, artt. 3-4.

5. Le quattro categorie di dati

La corretta classificazione del dato è decisiva: incide sull’autorità competente, sulle condizioni di emissione, sulla necessità di notifica e sulle garanzie procedurali. Le definizioni sono all’art. 3, punti 9-12.

CategoriaEsempiImpatto operativo
1. Dati relativi agli abbonatiNome, data di nascita, indirizzo postale o geografico, e-mail e telefono forniti, dati di fatturazione e pagamento, tipo e durata del servizio, dati tecnici e identificativi delle interfacce usate al momento della registrazione o dell’attivazione, dati di convalida dell’uso del servizio. Sono esclusi password e altri mezzi di autenticazione.Categoria meno invasiva. Per l’EPO può essere richiesta per tutti i reati, se ricorrono le altre condizioni.
2. Dati richiesti al solo scopo di identificare l’utenteIndirizzo IP e, se necessario, porta sorgente e marche temporali pertinenti; identificativi tecnici equivalenti e informazioni connesse.Servono esclusivamente ad attribuire un identificativo a un utente in una specifica indagine penale.
3. Dati sul trafficoFonte e destinatario di una comunicazione o di altra interazione, ubicazione del dispositivo, data, ora, durata, dimensioni, percorso, formato, protocollo e tipo di compressione, log-in e log-off.Più invasivi. Soglie più rigorose per l’EPO; di regola notifica ex art. 8.
4. Dati relativi al contenutoTesto, voce, video, immagini, suoni e ogni altro dato digitale diverso dai dati di abbonato e dai dati sul traffico.Massimo impatto sulla sfera privata; stesse condizioni rafforzate previste per i dati di traffico.
Nota tecnica: IP, porta sorgente e timestamp
Nelle reti con NAT e CGNAT un indirizzo IP pubblico, da solo, può non essere sufficiente a identificare univocamente l’utente. Quando disponibile e pertinente va indicata anche la porta sorgente, con un timestamp preciso e il fuso orario. Le linee guida SIRIUS insistono in modo particolare sulla precisione dell’identificatore e della marca temporale.

La qualificazione non è puramente nominale: lo stesso elemento può assumere categoria diversa a seconda del servizio e della funzione che vi svolge. Le linee guida segnalano, ad esempio, che una data di nascita — normalmente dato di abbonato — può assumere natura di dato di contenuto quando esorbita dalla funzione identificativa dell’utente. Prima di compilare il certificato è quindi opportuno verificare le informazioni del prestatore e le indicazioni SIRIUS.

Fonte/riscontro: Reg. (UE) 2023/1543, art. 3, punti 9-12; Linee guida SIRIUS EPOC, sezioni E-F.

6. Dati di contenuto e sistemi di cifratura

La possibilità giuridica di richiedere dati relativi al contenuto mediante un ordine europeo di produzione non implica che il prestatore sia tecnicamente in grado di fornirli in forma intelligibile.

Il regolamento affronta espressamente il rapporto fra e-evidence e cifratura. Il considerando 20 stabilisce che l’applicazione del regolamento non deve pregiudicare l’uso della cifratura da parte dei prestatori o degli utenti: i dati possono essere oggetto di produzione o conservazione anche quando sono cifrati, ma il regolamento non impone al prestatore alcun obbligo di decifrazione.

Principio operativo
L’ordine europeo di produzione obbliga il prestatore a produrre i dati nella propria disponibilità secondo le condizioni previste dal regolamento, ma non gli attribuisce capacità tecniche o chiavi crittografiche che non possiede.

Occorre distinguere tre situazioni tecnicamente diverse, che producono esiti opposti sul piano acquisitivo.

Sistema di protezioneDisponibilità del contenuto per il prestatore
Cifratura del trasporto (ad es. TLS)Il traffico è cifrato fra client e server, ma il prestatore riceve e tratta normalmente il contenuto in chiaro. Il contenuto eventualmente conservato può quindi essere producibile.
Cifratura dei dati con chiavi gestite dal prestatoreI dati possono essere memorizzati cifrati, ma il prestatore possiede o controlla le chiavi necessarie alla decifrazione e può quindi, tecnicamente, produrli in forma intelligibile.
End-to-end encryption (E2EE)Le chiavi necessarie a leggere il contenuto sono disponibili sugli endpoint autorizzati e non, in linea di principio, al prestatore, che può quindi non essere tecnicamente in grado di produrre il contenuto in chiaro.

Nel modello E2EE, in forma semplificata: dispositivo A → cifratura → infrastruttura del prestatore → dato cifrato → dispositivo B → decifrazione. Il prestatore svolge una funzione di trasporto e, eventualmente, di conservazione, ma non dispone necessariamente delle chiavi che consentono di ricostruire il messaggio originale.

Meta ha introdotto la cifratura end-to-end di default per le conversazioni personali e le chiamate di Messenger. Secondo la documentazione tecnica del prestatore, il contenuto è protetto dal momento in cui lascia il dispositivo del mittente fino a quando raggiunge quello del destinatario e neppure Meta può vedere quanto inviato o comunicato, salvo casi specifici, ad esempio quando l’utente decide di segnalare un messaggio alla piattaforma.

Un EPOC che richieda i messaggi scambiati fra due account Messenger in un determinato intervallo temporale può quindi incontrare un limite tecnico: se il contenuto è protetto mediante E2EE e Meta non ne possiede una copia decifrabile, l’ordine non determina la disponibilità della chiave né impone al prestatore di realizzare una procedura di decrittazione.

La situazione va verificata servizio per servizio e nel momento storico cui si riferiscono i dati. Instagram aveva introdotto una modalità E2EE opzionale per i messaggi diretti, ma la funzione è stata eliminata a partire dall’8 maggio 2026. I nuovi direct message non sono quindi più protetti da quella specifica forma di cifratura, il che rende tecnicamente possibile al prestatore accedere ai contenuti trattati dalla propria infrastruttura, fermo restando che la concreta produzione dipende dall’effettiva disponibilità, dalla conservazione e dalle caratteristiche del dato richiesto.

Per acquisizioni relative a periodi precedenti non deve invece essere presunto automaticamente che ogni conversazione sia disponibile in chiaro: occorre verificare se la specifica conversazione fosse stata originariamente protetta tramite E2EE e quale materiale il prestatore conservi ancora.

In presenza di E2EE è opportuno distinguere il contenuto della comunicazione dalle informazioni relative alla comunicazione. Il prestatore può continuare a detenere, in funzione delle caratteristiche del servizio e dei tempi di conservazione, dati dell’account, identificatori, indirizzi IP, marche temporali, informazioni su sessioni e dispositivi e altri dati di traffico o di contesto. Possono inoltre esistere contenuti divenuti separatamente disponibili al prestatore: la stessa Meta precisa che, quando un utente segnala un messaggio, il contenuto interessato può essere reso accessibile alla piattaforma ai fini della gestione della segnalazione.

Principio da ricordare
La cifratura non sottrae automaticamente il dato all’ambito dell’ordine europeo di produzione, ma l’EPOC non costituisce una chiave di decifrazione. La concreta possibilità di ottenere il contenuto dipende dall’architettura del servizio e dalle effettive capacità tecniche del prestatore.

Fonte/riscontro: Reg. (UE) 2023/1543, considerando 20 e art. 5; documentazione tecnica dei prestatori citati.

7. L’ordine europeo di produzione (EPO / EPOC)

L’ordine europeo di produzione consente di ottenere direttamente dal destinatario i dati già conservati dal prestatore o per suo conto: messaggi di posta elettronica, messaggi scambiati tramite applicazioni, informazioni utili all’identificazione del responsabile. Deve essere necessario e proporzionato e, in linea generale, deve poter essere disposto alle stesse condizioni in un caso interno analogo.

Dati richiestiCondizione relativa al reatoNotifica art. 8Termine del destinatario
AbbonatiTutti i reati, nel rispetto delle altre condizioni del regolamento.NoPrima possibile, massimo 10 giorni.
Solo identificazione dell’utenteTutti i reati, nel rispetto delle altre condizioni.NoPrima possibile, massimo 10 giorni.
Traffico non richiesto ai soli fini identificativiReato punibile nello Stato di emissione con pena detentiva massima di almeno tre anni, oppure specifiche categorie di reati indicate dal regolamento.Sì, salvo eccezioneMassimo 10 giorni; 8 ore in emergenza.
ContenutoCome per i dati sul traffico.Sì, salvo eccezioneMassimo 10 giorni; 8 ore in emergenza.

Oltre alla soglia dei tre anni, per traffico e contenuto il regolamento ammette specifiche fattispecie, quando il reato sia commesso in tutto o in parte mediante un sistema informatico:

  • frodi e falsificazioni di mezzi di pagamento diversi dai contanti, artt. 3-8 della direttiva (UE) 2019/713;
  • abuso e sfruttamento sessuale dei minori e pornografia minorile, artt. 3-7 della direttiva 2011/93/UE;
  • attacchi contro i sistemi di informazione, artt. 3-8 della direttiva 2013/40/UE;
  • reati di terrorismo e connessi, artt. 3-12 e 14 della direttiva (UE) 2017/541.

La verifica va sempre svolta sul caso concreto, secondo i presupposti dettagliati dall’art. 5.

Il destinatario trasmette i dati il prima possibile e comunque entro 10 giorni dalla ricezione dell’EPOC. Nel caso di emergenza ai sensi del regolamento il termine è senza indebito ritardo e comunque entro 8 ore.

Quando l’EPOC deve essere notificato all’autorità di esecuzione, la produzione resta di norma sospesa fino alla scadenza dei 10 giorni, salvo che l’autorità di esecuzione confermi prima che non farà valere alcun motivo di rifiuto. Nel frattempo il destinatario deve comunque agire tempestivamente per preservare i dati richiesti, a meno che le informazioni contenute nel certificato non consentano di identificarli.

  • Indicare almeno un identificatore preciso; se necessario combinarne più di uno.
  • Limitare l’intervallo temporale e il perimetro dell’account ai dati realmente necessari.
  • Evitare formule come «tutti i dati» o «tutti i contenuti».
  • Mantenere coerenza fra identificatori (sezione E), categorie e dataset richiesti (sezione F), presupposti (sezione G) e date.
  • Descrivere necessità e proporzionalità collegando i dati richiesti al fatto, alla fase investigativa e al valore probatorio atteso.
Regola pratica SIRIUS / JUDEX Nel workflow JUDEX i dati relativi agli abbonati e alla sola identificazione non vanno combinati nello stesso EPOC con traffico e contenuto. Se servono entrambi i gruppi occorre predisporre certificati distinti e collegarli nella sezione relativa alle richieste precedenti o correlate.

Fonte/riscontro: Reg. (UE) 2023/1543, artt. 5, 8 e 10; Linee guida SIRIUS EPOC, sezioni C, E, F, G, K.

8. L’ordine europeo di conservazione (EPOC-PR)

L’ordine europeo di conservazione impedisce che dati specifici vengano rimossi, cancellati o modificati mentre si prepara una successiva richiesta di produzione, che potrà avvenire — secondo i presupposti applicabili — tramite assistenza giudiziaria, ordine europeo di indagine oppure ordine europeo di produzione. È strumento funzionale e temporaneo, non acquisitivo. Può riguardare qualsiasi categoria di dati e, se sussistono le condizioni, può essere emesso per tutti i reati.

L’ordine deve essere necessario e proporzionato al fine di impedire rimozione, cancellazione o modifica dei dati, tenendo conto dei diritti della persona sottoposta a indagini o imputata. Può essere emesso per tutti i reati, ove sarebbe stato ammissibile in un caso interno analogo, ovvero per l’esecuzione di una pena o misura di sicurezza detentiva di almeno quattro mesi, irrogata con decisione non pronunciata in contumacia, nei confronti di condannato latitante.

Dalla formulazione dell’art. 6, paragrafo 3, discendono alcuni limiti di rilievo pratico:

  • non può essere emesso per dare esecuzione a una misura cautelare personale;
  • non può essere emesso per acquisire una notizia di reato, presupponendo un procedimento penale già instaurato;
  • non può essere emesso nell’ambito di procedimenti civili, amministrativi o tributari;
  • non può essere emesso in esecuzione di un ordine europeo di indagine passivo;
  • non può essere emesso per l’esecuzione di condanna a pena detentiva superiore a quattro mesi quando la sentenza sia stata pronunciata in contumacia; sul punto si registra un disallineamento con il nostro ordinamento, che conosce le sole figure dell’assenza consapevole e dell’assenza non consapevole.

Non operano invece i limiti di gravità previsti dall’art. 5, paragrafo 4, per l’ordine di produzione.

Ai sensi dell’art. 6, paragrafo 4, l’ordine indica:

  • autorità di emissione e, se applicabile, autorità di convalida;
  • destinatario corretto;
  • utente o altro identificativo univoco necessario a individuare i dati;
  • categoria di dati e, se opportuno, intervallo temporale;
  • disposizioni penali applicabili dello Stato di emissione;
  • motivazione di necessità e proporzionalità, da redigere sul caso concreto e non con formule di stile: è l’elemento più frequentemente trascurato.

Ricevuto l’EPOC-PR, il destinatario conserva i dati senza indebito ritardo. L’obbligo cessa dopo 60 giorni, salvo che l’autorità di emissione confermi, con il modulo di cui all’allegato V, l’avvenuta emissione di una successiva richiesta di produzione; entro i 60 giorni l’autorità può prorogare l’obbligo di ulteriori 30 giorni con il modulo dell’allegato VI. Confermata la richiesta di produzione, i dati restano conservati per tutto il tempo necessario. Venuta meno la necessità, l’autorità informa senza indebito ritardo il destinatario.

Il destinatario utilizza il modulo dell’allegato III per segnalare: possibili interferenze con immunità o privilegi o con le norme su libertà di stampa ed espressione; l’impossibilità di eseguire per certificato incompleto, viziato da errori manifesti o insufficiente, chiedendo chiarimenti; l’impossibilità materiale non imputabile; ogni altro motivo di mancata conservazione.

Termine da presidiare
L’autorità di emissione deve reagire entro cinque giorni dalla ricezione della richiesta di chiarimenti: decorso inutilmente tale termine, il prestatore è esonerato dagli obblighi di conservazione. Va quindi individuato fin dall’inizio chi presidia la casella e gestisce l’interlocuzione con il provider.

La notifica preventiva all’autorità di esecuzione prevista dall’art. 8 riguarda il solo ordine di produzione di traffico e contenuto e non l’EPOC-PR: ciò non esclude il coinvolgimento successivo dell’autorità di esecuzione in caso di mancata ottemperanza.

Fonte/riscontro: Reg. (UE) 2023/1543, artt. 6, 9 e 11; materiale formativo SSM sull’EPOC-PR.

9. Autorità italiane e procedure

Il d.lgs. 30 dicembre 2025, n. 215, in vigore dal 30 gennaio 2026, individua le autorità italiane competenti e disciplina emissione, ricezione, esecuzione e riesame degli ordini. Per il lavoro operativo è essenziale distinguere categoria di dato e fase processuale.

ScenarioAutorità competente
EPO nel procedimento penalePubblico ministero e giudice che procede, nell’ambito delle rispettive attribuzioni.
EPO — traffico e contenutoIl giudice competente a pronunciarsi nel merito del procedimento, individuato secondo le regole processuali interne in relazione alla fase in cui l’ordine è emesso. Secondo l’Ufficio del Massimario la norma non radica la competenza in capo al giudice per le indagini preliminari, valorizzando la trasversalità dello strumento, utilizzabile in ogni stato e grado.
EPO prima dell’esercizio dell’azione penale — abbonati e sola identificazionePubblico ministero.
EPO in emergenza, prima dell’intervento del PMUfficiale di polizia giudiziaria, ma esclusivamente per dati relativi agli abbonati o richiesti al solo scopo di identificare l’utente: restano esclusi traffico e contenuto. Trasmissione al PM entro 48 ore e convalida nelle 48 ore successive.
Ordine europeo di conservazioneNel corso delle indagini preliminari provvede il pubblico ministero in via esclusiva, a prescindere dalla natura del dato, restando fermo il potere del giudice competente per il merito nelle fasi successive. L’esclusività si spiega con la funzione di mero congelamento dell’ordine.
Conservazione in emergenza, prima dell’intervento del PMUfficiale di polizia giudiziaria; trasmissione al PM entro 48 ore e convalida nelle 48 ore successive.

Quando lo stabilimento designato o il rappresentante legale destinatario è stabilito o risiede in Italia, sono autorità di esecuzione il Procuratore della Repubblica presso il Tribunale del capoluogo del distretto competente e il giudice per le indagini preliminari presso lo stesso Tribunale, secondo la ripartizione prevista dal decreto.

  • Il Procuratore della Repubblica è competente, fra l’altro, per la notifica ex art. 8 e per le funzioni previste dagli artt. 10, 11, 12 e 17 del regolamento.
  • In caso di richiesta di esecuzione, il Procuratore riconosce l’ordine salvo motivi di rifiuto.
  • Per gli EPO relativi ad abbonati e sola identificazione e per gli ordini di conservazione, il Procuratore dispone l’esecuzione dopo il riconoscimento.
  • Per gli EPO relativi a traffico e contenuto, dopo il riconoscimento il Procuratore trasmette al GIP, che autorizza l’esecuzione verificandone le condizioni.

Fonte/riscontro: D.Lgs. 30 dicembre 2025, n. 215, artt. 2, 3 e 6.

L’art. 2, comma 7, del d.lgs. 215/2025 prevede espressamente che i dati acquisiti mediante un ordine europeo di produzione emesso fuori dai casi o in mancanza delle condizioni stabilite dal regolamento e dal decreto non possano essere utilizzati nel procedimento.

La tecnica normativa è peculiare e va compresa bene: la sanzione processuale, che si inserisce nel sistema dell’art. 191 c.p.p., non è ancorata alla violazione di singole prescrizioni formali, ma al difetto delle condizioni sostanziali che legittimano l’emissione dell’ordine. I presupposti fissati dal regolamento e dalla normativa di adattamento — categoria del dato, autorità competente, soglia di reato, necessità e proporzionalità — diventano così i limiti effettivi dell’acquisizione probatoria.

La conseguenza operativa più importante di tutta la guida
Non esiste un sistema di impugnazioni autonome dell’ordine europeo di produzione nella fase genetica, salva la procedura attivabile a seguito dell’obiezione del prestatore. Il controllo di legalità dell’acquisizione emerge quindi, principalmente, nel momento dell’utilizzazione processuale dei dati, quando il giudice è chiamato a verificare in contraddittorio la sussistenza dei presupposti, e l’inutilizzabilità è rilevabile anche d’ufficio secondo le regole generali dell’art. 191 c.p.p.
Ma quel vaglio postula che le condizioni di emissione risultino verificabili attraverso la documentazione dell’attività investigativa: gli atti relativi all’emissione e all’esecuzione dell’ordine devono confluire nel fascicolo del pubblico ministero secondo le regole ordinarie degli artt. 357 e 373 c.p.p., diventando accessibili al giudice e alle parti attraverso i meccanismi ordinari di discovery.
Qui sta il problema pratico: una parte significativa dell’attività esecutiva si realizza attraverso comunicazioni standardizzate con il prestatore e flussi informatici che non coincidono con gli atti investigativi tradizionali. Occorre perciò individuare, fin dall’inizio, un nucleo documentale idoneo a consentire un controllo effettivo: certificato emesso, eventuale convalida, ricevute e corrispondenza con il destinatario, moduli di risposta, tracciamento della trasmissione, verifiche di integrità sul materiale ricevuto.

Due precisazioni delimitano la portata della clausola. La prima: non ogni irregolarità produce inutilizzabilità. Nel sistema interno l’incompetenza non comporta ordinariamente inutilizzabilità della prova, salvo che determini la violazione di garanzie essenziali o l’elusione di controlli giurisdizionali imposti dalla legge; trasposta nell’e-evidence, l’impostazione porta a ritenere che solo le violazioni che ledano in modo sostanziale le garanzie del regolamento producano quell’effetto, mentre le irregolarità attinenti alla mera distribuzione interna delle competenze non vi sono automaticamente idonee.

La seconda: una clausola analoga non è dettata per l’ordine europeo di conservazione, coerentemente con la sua funzione non acquisitiva. La sua eventuale illegittimità è destinata a tradursi nell’inefficacia della misura e nel venir meno dell’obbligo di conservazione, senza conseguenze dirette sull’utilizzabilità. Resta problematico il caso in cui la disponibilità del dato derivi causalmente dall’ordine illegittimo, per esempio quando esso abbia impedito una cancellazione altrimenti inevitabile.

Quando l’ordine riguarda delitti di competenza distrettuale rafforzata — artt. 51, commi 3-bis e 3-quater, e 371-bis, comma 4-bis, c.p.p., nonché i delitti di cui all’art. 118-bis delle norme di attuazione — copia del certificato EPOC o EPOC-PR è trasmessa alla Procura nazionale antimafia e antiterrorismo o al Procuratore generale presso la Corte d’appello. Ove operino i meccanismi di coordinamento europeo, l’informazione è trasmessa anche al membro nazionale di Eurojust ai sensi dell’art. 21, par. 5, del reg. (UE) 2018/1727. È un flusso da mettere in conto fin dalla predisposizione dell’atto, non un adempimento successivo.

  • Trasmissione amministrativa. L’art. 5 del d.lgs. 215/2025 individua nel Ministero della giustizia l’autorità centrale ai sensi dell’art. 4, par. 6, del regolamento.
  • Notifiche dei prestatori. Per la direttiva, l’autorità centrale cui i prestatori comunicano la designazione dello stabilimento o la nomina del rappresentante legale è il Ministero dell’interno, e in particolare l’organo per la sicurezza e la regolarità dei servizi di telecomunicazione di cui all’art. 7-bis del d.l. 144/2005. La notifica va effettuata entro trenta giorni dalla designazione; recapiti e lingua accettata sono poi pubblicati sul sito della rete giudiziaria europea in materia penale e sul portale del Ministero della giustizia. Sono queste le fonti da consultare per individuare il destinatario corretto.
  • Obiezione motivata ex art. 17. Quando il prestatore eccepisce il contrasto con obblighi derivanti dal diritto di un paese terzo, e l’autorità intenda confermare l’ordine, il riesame spetta al tribunale del capoluogo del distretto nel quale ha sede l’ufficio che ha emesso o convalidato l’ordine, ai sensi dell’art. 324, comma 5, c.p.p., se l’ordine proviene dal giudice; al giudice per le indagini preliminari se proviene dal pubblico ministero. L’autorità trasmette ordine, obiezione e documentazione entro dieci giorni dalla ricezione dell’obiezione; l’autorità investita decide entro i dieci giorni successivi. Non è previsto ricorso diretto per cassazione avverso quella decisione: la questione potrà essere riproposta nel merito, sul piano dell’utilizzabilità, da chi vi abbia interesse — fuori dal riesame il prestatore non ha più titolo per intervenire.
  • Responsabilità dei prestatori. Il d.lgs. 216/2025 prevede la responsabilità solidale fra prestatore, stabilimento designato e rappresentante legale in caso di inottemperanza, oltre a un regime sanzionatorio speciale che si affianca alle eventuali sanzioni penali.

L’art. 9 del d.lgs. 215/2025 è il segmento con l’impatto sistemico più ampio, perché tocca strumenti che useremo anche al di fuori dei casi transfrontalieri.

  • Art. 132 d.lgs. 196/2003. I nuovi commi 3 e 3-bis consentono di autorizzare l’acquisizione dei dati di traffico telefonico anche per agevolare le ricerche di un latitante condannato con sentenza definitiva a pena non inferiore a quattro mesi non pronunciata in contumacia, in coerenza con gli artt. 5 e 6 del regolamento; provvede il giudice o, nei casi d’urgenza, il pubblico ministero. I nuovi commi 3-bis.1, 3-bis.2 e 3-bis.3 introducono un ordine di conservazione «domestico» del pubblico ministero, con decreto motivato, verso fornitori e operatori di servizi telefonici, informatici o telematici, avente a oggetto i dati di traffico telefonico e telematico e le chiamate senza risposta, con esclusione dei contenuti, per un periodo non superiore a novanta giorni prorogabile fino a un massimo complessivo di sei mesi. Il comma 3-bis.2 detta una disciplina autonoma per i dati relativi agli abbonati, esclusi dalle procedure autorizzatorie dei commi 3 e 3-bis e acquisibili dal pubblico ministero o dalla polizia giudiziaria ai sensi dell’art. 348 c.p.p. Il comma 4-ter è ampliato ai dati di traffico telefonico e alle chiamate senza risposta, e la legittimazione ad adottare l’ordine di conservazione è estesa agli ufficiali di polizia giudiziaria quando esso sia emesso per finalità di accertamento e repressione di specifici reati: è il punto di maggiore impatto diretto sull’operatività dei reparti.
  • Nuovo art. 263-bis c.p.p. Copre proprio ciò che il comma 3-bis.1 dell’art. 132 esclude, cioè la conservazione dei dati relativi al contenuto: il pubblico ministero può ordinarla e la polizia giudiziaria può provvedervi in via d’urgenza, con convalida successiva. Per la prima volta esiste uno strumento tipizzato per congelare i contenuti in attesa dell’acquisizione, in luogo delle prassi atipiche finora impiegate e non sempre solide in dibattimento.

Il rilievo pratico è duplice: nei casi puramente interni non serve più ricorrere a soluzioni improprie, e nei casi transfrontalieri l’ordine interno e quello europeo diventano strumenti alternativi da scegliere consapevolmente in funzione del destinatario.

Questa è la disposizione che il personale di polizia giudiziaria userà più spesso, ed è quella con i margini di discrezionalità tecnica più ampi.

Il pubblico ministero può ordinare con decreto motivato, ai fornitori e agli operatori di servizi informatici, telematici o di telecomunicazioni, di conservare e proteggere i dati da questi detenuti per un periodo non superiore a novanta giorni, prorogabile per motivate esigenze entro un limite massimo complessivo di sei mesi. Il provvedimento può prevedere particolari modalità di custodia e l’eventuale indisponibilità dei dati da parte dei gestori o di terzi. In presenza di ragioni di urgenza l’ordine può essere anticipato dagli ufficiali di polizia giudiziaria, con comunicazione al pubblico ministero entro quarantotto ore e convalida nelle quarantotto ore successive; in mancanza di convalida il provvedimento perde efficacia.

Il potere di indicare le modalità di custodia è la parte che ci compete più direttamente. Le prescrizioni tecnicamente utili, che conviene proporre al magistrato in sede di richiesta, sono:

  • misure idonee a garantire integrità e immutabilità del dato;
  • segregazione logica delle informazioni rispetto ai sistemi ordinari di gestione, quando la segregazione fisica non sia praticabile;
  • tracciabilità degli accessi e delle operazioni compiute sui dati conservati (logging);
  • sospensione dei processi automatici di cancellazione e sovrascrittura;
  • attestazione, da parte del destinatario, delle operazioni effettivamente compiute e delle modalità adottate.
Perché l’attestazione conta
L’esecuzione dell’ordine avviene integralmente dentro i sistemi del prestatore, senza presenza dell’autorità giudiziaria. La verifica del rispetto delle modalità imposte non può quindi fondarsi su un controllo diretto: dipende dalla documentazione tecnica e dalle attestazioni fornite dal destinatario.
Tracciabilità dell’attività di conservazione e completezza della documentazione riversata nel fascicolo sono, in concreto, gli unici elementi su cui si potrà discutere in caso di contestazione.

Due avvertenze sulla redazione. L’oggetto non può essere lasciato generico: la formula «dati da questi detenuti» è più ampia delle formule tradizionali del codice, e una lettura letterale avvicinerebbe la misura a forme di conservazione investigativa generalizzata, in contrasto con la giurisprudenza della Corte di giustizia. La delimitazione — categorie di dati, utenze, account, periodi — deve emergere dalla motivazione, che è la sede del controllo di necessità e proporzionalità. Allo stesso modo, il termine va indicato in concreto e non lasciato coincidere per inerzia con il massimo di legge, pena la trasformazione del limite dei novanta giorni in durata ordinaria della misura.

Fonte/riscontro: Relazione n. 25/2026, § 13; art. 263-bis c.p.p., introdotto dall’art. 9, comma 2, d.lgs. n. 215 del 2025.

L’art. 2, comma 6, del d.lgs. 215/2025 stabilisce che l’autorità giudiziaria provvede, nei casi e nei modi previsti dalla legge processuale, a dare conoscenza alle parti e ai difensori dei dati e della documentazione acquisiti mediante ordine europeo di produzione.

La disposizione non introduce un obbligo di ostensione immediata, che confliggerebbe con il segreto investigativo e con le regole generali sulla discovery: il richiamo ai casi e ai modi della legge processuale va inteso come rinvio alla disciplina codicistica, sicché la norma ha funzione ricognitiva e ribadisce che anche i dati acquisiti con gli strumenti e-evidence seguono le ordinarie regole di conoscibilità processuale. L’informazione può quindi essere legittimamente differita finché ciò sia compatibile con le esigenze investigative.

Va tenuta distinta dall’informativa all’interessato prevista dall’art. 13 del regolamento, che riguarda i diritti della persona in quanto tale, anche fuori dalla sua eventuale veste di parte. Le due discipline sono complementari. Si ritiene inoltre che la mancata informazione all’interessato non incida sulla validità dell’acquisizione né produca conseguenze processuali: non sono configurabili, su quel versante, ipotesi di inutilizzabilità o nullità.

Fonte/riscontro: D.Lgs. 30 dicembre 2025, n. 215, artt. 2, 3, 5, 6 e 9; d.lgs. 216/2025; Relazione n. 25/2026 dell’Ufficio del Massimario della Corte di cassazione.

10. Emergenza UE e procedura accelerata italiana

Nel linguaggio operativo è importante non sovrapporre due istituti differenti.

IstitutoPresuppostoEffetto principale
Caso di emergenza — regolamento UEMinaccia imminente alla vita, all’integrità fisica o alla sicurezza di una persona, oppure a un’infrastruttura critica il cui danneggiamento o distruzione comporterebbe una minaccia imminente per la vita, l’integrità fisica o la sicurezza di una persona.Per l’EPOC: produzione entro 8 ore; possibilità di regole eccezionali sulla convalida nei casi previsti, con richiesta di convalida ex post entro 48 ore.
Procedura accelerata — d.lgs. 215/2025, art. 4Particolari ragioni di urgenza nel corso delle indagini preliminari.Modifica l’autorità che può emettere e impone previa convalida secondo le finestre di 24 e 48 ore; non coincide automaticamente con la definizione UE di emergenza.

Nella procedura accelerata italiana:

  • traffico e contenuto: EPO emesso dal PM, efficacia subordinata alla previa convalida del GIP; trasmissione entro 24 ore, decisione nelle successive 48 ore;
  • abbonati e sola identificazione: EPO emesso da ufficiali di polizia giudiziaria, efficacia subordinata alla previa convalida del PM, con le stesse finestre di 24 e 48 ore;
  • conservazione: ordine emesso da ufficiali di polizia giudiziaria, efficacia subordinata alla previa convalida del PM, con le stesse finestre.
Chi trasmette il certificato
Nella procedura accelerata l’accertamento di conformità e la convalida determinano la trasmissione del certificato da parte dell’autorità che ha convalidato: il giudice per le indagini preliminari per traffico e contenuto, il pubblico ministero per abbonati e sola identificazione. L’ufficiale di polizia giudiziaria che ha emesso l’ordine non trasmette quindi l’EPOC al prestatore: la funzione di trasmissione resta all’autorità di convalida. È un dato da tenere presente anche nel dimensionare gli accreditamenti alle piattaforme di invio.
Attenzione operativa
Non usare il termine «emergenza» come sinonimo generico di urgenza. L’emergenza del regolamento ha una definizione tassativa e produce conseguenze specifiche, fra cui il termine di 8 ore. La procedura accelerata italiana ha presupposti e sequenze di convalida propri.

Fonte/riscontro: Reg. (UE) 2023/1543, art. 3, punto 18, artt. 4 e 10; D.Lgs. 215/2025, art. 4.

11. Notifica, informazione dell’interessato e riservatezza

Per l’EPOC relativo a dati sul traffico non richiesti esclusivamente ai fini dell’identificazione dell’utente o a dati di contenuto, l’autorità di emissione deve di regola notificare l’autorità di esecuzione contestualmente alla trasmissione al destinatario.

La notifica può essere omessa quando vi siano motivi ragionevoli per ritenere che, al momento dell’emissione, siano soddisfatte entrambe le condizioni seguenti: il reato è stato commesso, è in corso di commissione o è probabile che venga commesso nello Stato di emissione; la persona i cui dati sono richiesti risiede nello Stato di emissione. La valutazione va compiuta con attenzione, perché una notifica non necessaria ritarda l’esecuzione, mentre l’omissione di una notifica dovuta espone l’atto a contestazione.

Per i dati prodotti in forza di un EPO l’obbligo di informare la persona grava sull’autorità di emissione, non sul prestatore. L’informazione può essere ritardata, limitata o omessa nei casi consentiti, quando ciò sia necessario e proporzionato per non pregiudicare indagini o procedimenti, il perseguimento dei reati, la sicurezza pubblica o nazionale, oppure i diritti e le libertà altrui. L’ordine di conservazione non comporta di per sé l’obbligo di informazione previsto dall’art. 13 per la produzione.

Destinatari e prestatori adottano misure operative e tecniche all’avanguardia per garantire riservatezza, segretezza e integrità del certificato e dei dati prodotti o conservati. Il prestatore non deve informare autonomamente l’utente dell’esistenza della richiesta.

Fonte/riscontro: Reg. (UE) 2023/1543, artt. 8 e 13; Linee guida SIRIUS EPOC, sezioni H e K.

12. La compilazione del certificato: le sezioni A-M

Le linee guida SIRIUS seguono l’impaginazione dell’allegato I al regolamento e si concentrano su tre obiettivi: chiarezza e completezza delle informazioni, coerenza fra le sezioni, prevenzione degli errori che generano ritardi o rifiuti. Alcune regole valgono per l’intero certificato:

  • di norma la trasmissione avviene tramite JUDEX; i mezzi alternativi e, a maggior ragione, la trasmissione cartacea sono riservati ai casi in cui il sistema non sia utilizzabile;
  • il certificato va compilato in una lingua accettata dal destinatario;
  • le sezioni non applicabili si lasciano in bianco, o si indica «N/A» sui moduli cartacei, senza sopprimerle quando la trasmissione non avviene tramite JUDEX;
  • i dati richiesti vanno descritti in modo chiaro, preciso e inequivocabile; nei campi di testo libero conviene usare periodi brevi e lineari, perché la traduzione automatica introduce imprecisioni proprio nella descrizione dei dati.
SezionePunti di attenzione
A — Autorità di emissione e di convalidaSempre compilata. Indicare solo Stato membro, autorità di emissione e, se del caso, autorità di convalida; i recapiti vanno nelle sezioni I e J, con cui deve esservi piena coerenza. Il numero di fascicolo non è obbligatorio ma è fortemente raccomandato: collega l’ordine al procedimento ed evita duplicazioni.
B — DestinatarioSempre compilata. Indicare denominazione completa e recapiti dello stabilimento designato o del rappresentante legale, attingendo alla banca dati collegata a JUDEX. L’indirizzamento a un destinatario diverso è ammesso solo in caso di emergenza e quando lo stabilimento o il rappresentante non abbiano reagito nei termini o non siano stati designati.
C — TerminiSelezionare una sola opzione. In mancanza si applica il termine ordinario di 10 giorni. Il termine di 8 ore va giustificato nel campo delle informazioni aggiuntive. Eventuali scadenze procedurali interne — custodia cautelare, udienza imminente, ordine di conservazione in scadenza, prescrizione — non sostituiscono i termini di legge ma orientano le priorità del destinatario.
D — Collegamento a richieste precedentiDa compilare sempre quando esiste un precedente ordine di conservazione o di produzione sugli stessi dati, indicando autorità, numero di fascicolo, date di emissione e trasmissione, destinatario e stato della richiesta. Va segnalato se i dati conservati sono prossimi alla scadenza dei 60 giorni e se sono stati emessi certificati paralleli.
E — Identificazione dei datiSempre compilata, con almeno un identificatore. Indirizzi IP completi con marca temporale e fuso orario, numeri in formato internazionale, indirizzi e-mail completi, IMEI, MAC, nomi utente e identificativi di account. Va sempre specificato il servizio interessato, essenziale per i prestatori che ne offrono più di uno. Intervalli temporali con data di inizio e fine nel formato GG/MM/AAAA, ora e fuso orario.
F — Prove elettroniche da produrreSempre compilata, con almeno una categoria e la corrispondente sottocategoria. Vanno selezionate solo le caselle strettamente necessarie. In JUDEX i dati di abbonato e di sola identificazione non possono essere combinati in un unico certificato con traffico e contenuto: occorrono certificati distinti, collegati nella sezione D. Con più utenti o account la sezione va compilata separatamente per ciascuno, in corrispondenza degli identificatori della sezione E.
G — Condizioni sottostantiSempre compilata. Indicare natura e qualificazione giuridica del reato con riferimenti normativi precisi e pena edittale, evitando la riproduzione integrale delle disposizioni. La parte sulle soglie va compilata solo per traffico non identificativo e contenuto. Qui si individua anche il ruolo del prestatore: di regola l’ordine va rivolto al titolare del trattamento e solo in via eccezionale al responsabile, quando il titolare non sia identificabile nonostante ragionevoli sforzi o quando rivolgersi ad esso pregiudicherebbe l’indagine; la motivazione va conservata in atti.
H — Informazioni all’utenteIl destinatario deve comunque astenersi dall’informare l’interessato: l’informativa spetta all’autorità di emissione. La sezione va compilata solo per differire l’informativa, selezionando i motivi applicabili. Con più certificati sullo stesso utente occorre coerenza fra tutti gli ordini.
I e J — Autorità di emissione e di convalidaSezione I sempre compilata; sezione J solo in caso di convalida. Le informazioni devono coincidere con la sezione A.
K — Autorità di esecuzione notificataDa compilare solo se la notifica è dovuta; in tal caso va compilata anche la sezione M. Indicare recapiti raggiungibili, possibilmente attivi 24 ore su 24, e utilizzare esclusivamente indirizzi istituzionali.
L — Trasferimento dei datiDa compilare quando i dati devono essere trasmessi ad autorità diversa da quella emittente o quando non è utilizzabile JUDEX. Indicare una casella effettivamente presidiata e capiente, perché i prestatori impiegano di norma link sicuri a scadenza.
M — Informazioni per la sola autorità di esecuzioneDa non trasmettere al destinatario. Contiene la motivazione su necessità e proporzionalità, la sintesi del fatto, la verifica della doppia incriminazione rispetto all’elenco dei reati e gli elementi utili a valutare eventuali motivi di rifiuto: immunità e privilegi, libertà di stampa e di espressione, diritti fondamentali, ne bis in idem.
Errori ricorrenti da evitare
Richieste generiche o sovradimensionate per oggetto e arco temporale, che espongono a contestazioni e rallentano l’esecuzione.
Incoerenze fra le sezioni A, I e J, oppure fra gli identificatori della sezione E e le categorie di dati della sezione F.
Omessa indicazione del servizio specifico presso prestatori che ne offrono più di uno.
Marche temporali prive di fuso orario e date in formato non uniforme. Motivazione su necessità e proporzionalità redatta con formule di stile anziché sul caso concreto.

Fonte/riscontro: Linee guida SIRIUS EPOC, giugno 2026, sezioni A-M; Reg. (UE) 2023/1543, allegato I.

Quando l’errore di traduzione diventa un problema probatorio
Una traduzione imprecisa o incompleta resta un’irregolarità formale priva di incidenza sostanziale, se non altera l’oggetto dell’ordine né il titolo giuridico dell’acquisizione.
Se però l’errore incide sulla qualificazione della tipologia di dati richiesti, sul perimetro dell’acquisizione o sulla base giuridica dell’ordine, ampliando o modificando i presupposti sostanziali, il vizio investe la legittimazione dell’accesso al dato e può riflettersi sull’utilizzabilità ai sensi dell’art. 2, comma 7.
È il motivo per cui affidare la traduzione a conoscenze linguistiche personali espone a rischi di disomogeneità e di errore tecnico, e per cui converrebbe attrezzarsi con soluzioni stabili — nuclei linguistici presso gli uffici distrettuali, convenzioni con traduttori qualificati, supporto centralizzato.

Fonte/riscontro: Linee guida SIRIUS EPOC, giugno 2026, sezioni A-M; Reg. (UE) 2023/1543, allegato I; Relazione n. 25/2026, § 15.1.

13. Trasmissione digitale, JUDEX e aspetti tecnico-forensi

Il regolamento prevede per le comunicazioni scritte un sistema informatico decentrato sicuro e affidabile. Il regolamento di esecuzione (UE) 2025/1550 ne definisce le specifiche tecniche e prevede l’interoperabilità tramite punti di accesso e-CODEX; le linee guida SIRIUS utilizzano il nome JUDEX per l’interfaccia operativa e ne raccomandano l’uso come canale ordinario.

Per la trasmissione delle prove elettroniche tramite il sistema decentrato è fissata una soglia di 25 MB per singolo trasferimento. Quando il materiale supera tale limite, quando il sistema non è disponibile o quando esigenze tecniche o forensi lo richiedono, può essere necessario un mezzo alternativo, che deve comunque preservare sicurezza, affidabilità, autenticità e integrità e consentire al destinatario di verificarle.

Fra i mezzi alternativi le linee guida indicano servizi di recapito elettronico qualificati, posta elettronica sicura, portali dedicati istituiti da alcuni prestatori, archiviazione cloud sicura e protocolli di trasferimento cifrati; in via residuale la consegna fisica su supporti cifrati o, per il materiale cartaceo, attraverso canali sicuri. Quando è richiesta la cifratura occorre specificarlo e fornire gli elementi necessari, ad esempio il certificato pubblico X.509, verificando la compatibilità con i sistemi dell’autorità ricevente.

Un elemento spiega perché, nei primi mesi, i canali alternativi non saranno un’eccezione teorica: l’obbligo di utilizzare il sistema decentrato decorre un anno dopo l’adozione degli atti di esecuzione previsti dall’art. 25, e i costi di integrazione gravano interamente sui prestatori. Nella fase iniziale è quindi ragionevole attendersi un ricorso significativo ai canali propri dei singoli provider, come descritto al § 13-bis.

Sul fronte del prestatore, l’adeguamento richiede tre interventi paralleli — dotare lo stabilimento designato o il rappresentante legale di poteri e risorse effettive, collegarsi al sistema decentrato, mappare le categorie di dati detenute per poter rispondere selettivamente — che procedono a velocità diverse da un operatore all’altro. È utile saperlo: nella fase di avvio la qualità e la tempestività delle risposte dipenderanno più dallo stato di preparazione del singolo destinatario che dalla norma. Va infine ricordato che l’art. 14 del regolamento consente al prestatore di chiedere il rimborso delle spese sostenute per l’esecuzione, ove il diritto dello Stato di emissione lo preveda per ordini nazionali in situazioni analoghe. Il rimborso riguarda le spese di esecuzione, non i costi infrastrutturali di collegamento al sistema.

  • Usare identificatori completi e non ambigui: IPv4 e IPv6, intervalli, indirizzi e-mail, numero di telefono in formato internazionale, IMEI, MAC, username e account ID.
  • Per IP dinamici e reti NAT: indicare data, ora, fuso orario e, quando necessario, porta sorgente.
  • Specificare il formato richiesto solo quando realmente necessario, evitando di imporre conversioni inutili al prestatore.
  • Predisporre una casella istituzionale attiva e monitorata: molti prestatori restituiscono link sicuri con scadenza o autenticazione.
  • Quando si usa un canale alternativo, documentare il mezzo, le modalità di autenticazione e l’eventuale scambio separato di password e chiavi.
  • Verificare e registrare checksum e hash forniti dal prestatore; se non forniti, calcolarli all’acquisizione documentando algoritmo, data, ora e operatore.
  • Conservare il pacchetto originale ricevuto dal prestatore, inclusi metadati, manifest, header e documentazione di accompagnamento, lavorando su copie forensi quando appropriato.
Diritto e buona pratica forense
Hash, catena di custodia e conservazione del pacchetto originale sono buone pratiche tecnico-forensi e probatorie. Non tutte sono formulate dal regolamento come prescrizioni autonome: vanno applicate in coerenza con il codice di procedura, i protocolli dell’ufficio e le regole interne di gestione della prova digitale.

Due strumenti di supporto meritano di essere conosciuti e utilizzati: la banca dati collegata a JUDEX, che riporta per ciascun prestatore lo stabilimento designato o il rappresentante legale, l’ambito territoriale, i recapiti e — su base volontaria — i servizi coperti, gli identificativi utilizzabili e i periodi di conservazione; e la piattaforma SIRIUS, che fornisce indicazioni pratiche su oltre ottanta prestatori, compresi esempi di identificatori validi e criteri di classificazione dei dati.

Fonte/riscontro: Reg. (UE) 2023/1543, art. 19; Reg. di esecuzione (UE) 2025/1550; Linee guida SIRIUS EPOC, sezioni E e L.

I termini del regolamento migliorano radicalmente i mesi delle rogatorie e le settimane dell’ordine europeo di indagine, ma introducono una tensione con le esigenze di accuratezza e completezza proprie della digital forensics, che vale la pena esplicitare perché ricade direttamente sul nostro lavoro.

  • Le otto ore. Un’estrazione eseguita sotto quella pressione può comportare errori, omissioni, perdita di metadati, contaminazione della prova. Il termine è pensato per situazioni in cui il pericolo di perdita è imminente — l’indagato per terrorismo che si accorge di essere attenzionato e cancella gli account, il sequestro in cui le comunicazioni possono indicare la localizzazione, l’attacco informatico in corso con log prossimi alla cancellazione — dove la velocità prevale sulla perfezione forense. Quella logica non è però estensibile: l’emergenza deve essere reale, documentata e verificabile ex post.
  • I dieci giorni. Sono abbondanti per dati di abbonato o di sola identificazione delimitati nel tempo. Possono rivelarsi insufficienti quando l’ordine investe l’intero contenuto di un account di posta attivo da anni, un archivio cloud dell’ordine dei terabyte o la ricostruzione delle comunicazioni di un utente su un social per più mesi. Il prestatore può rappresentare l’impossibilità tecnica e chiedere più tempo, ma deve motivarla e documentarla e non è affatto detto che la richiesta sia accolta.

Sul piano pratico questo significa due cose: delimitare l’oggetto e l’arco temporale non è solo un requisito di proporzionalità, è la condizione per ottenere un’estrazione accurata nei termini; e la qualità del dato ricevuto va verificata all’arrivo, senza presumere che un pacchetto consegnato entro la scadenza sia per ciò stesso completo.

Il regolamento fissa il quadro, ma nella pratica quotidiana il buon esito di un certificato dipende anche dal modo in cui il singolo prestatore ha organizzato la ricezione. Google Ireland Limited ha diffuso alle forze di polizia, con comunicazione del 14 agosto 2026, un aggiornamento e un documento di domande frequenti sull’invio di EPOC ed EPOC-PR. Se ne riportano i contenuti rilevanti, con un’avvertenza preliminare: si tratta di prassi aziendale e non di fonte normativa, che non modifica gli obblighi dell’art. 10 né i rimedi dell’art. 16.

Atto o comunicazioneCanale indicato dal prestatore
EPOC (modulo 1) ed EPOC-PR (modulo 2)Sistema informatico decentrato, indicato come canale ufficiale e obbligatorio. In caso di indisponibilità dell’API del sistema, o di ritardi localizzati di integrazione dello Stato emittente, la ricezione avviene tramite LERS. Chi dispone già di un account LERS è invitato a continuare a usarlo.
Moduli 5 e 6, risposte ai motivi di mancata esecuzione, richieste di revocaModulo di contatto dedicato all’e-evidence (support.google.com/policies/contact/eEvidence_Cuf). Non transitano da LERS, che accetta soltanto i moduli 1 e 2.
Emergenze estranee al framework: minaccia imminente alla vita o alla sicurezza, sicurezza nazionaleCanale LERS dedicato e separato, mantenuto anche dopo il 18 agosto 2026.
Richieste di dati non di contenuto fondate su normative localiFase transitoria a doppio binario, con valutazione caso per caso; la dismissione dei canali preesistenti sarà comunicata ai punti di contatto con anticipo.
Posta elettronicaNon ammessa per EPOC ed EPOC-PR.
Assistenza e apertura account LERSCasella lers-help@google.com, distinta dal modulo di contatto e-evidence. La piattaforma è raggiungibile all’indirizzo lers.google.com.
  • Lingua: inglese. Il regolamento rinvia alla lingua accettata dal destinatario; per questo prestatore la risposta è univoca. Un certificato in italiano è tempo perso.
  • Destinatario: l’entità europea, non genericamente il gruppo. L’ordine va indirizzato a Google Ireland Limited, Gordon House, Barrow Street, Dublino 4, D04 E5W5, Irlanda.
  • Account gestiti da entità extra-UE. Se l’account è registrato o ospitato fuori dall’Unione ed è gestito da un’entità non soggetta al framework, il prestatore dichiara di non avere titolo per la divulgazione ai sensi del regolamento. In quel caso si torna agli strumenti di assistenza giudiziaria: è lo stesso limite di perimetro che si incontra con altri gruppi statunitensi.
  • Sezione L: non si ricompila a schermo. La piattaforma limita la condivisione ai domini corrispondenti a quello del mittente e le autorità autorizzate a ricevere i dati vengono estratte direttamente dal PDF caricato. Una sezione L incompleta o incoerente si traduce in dati che non arrivano, senza che alcun campo dell’interfaccia possa rimediare.
  • Strumento di conservazione LERS ed EPOC-PR non coincidono. Sono istituti diversi e il primo non può veicolare il secondo, nonostante il banner che compare selezionando l’EPOC-PR possa indurre in equivoco.
  • EPOC di emergenza. Si segue il flusso ordinario spuntando l’apposita casella; restano ferme le condizioni di emergenza previste dal regolamento.
  • Tracciamento. Lo stato di EPOC ed EPOC-PR inviati è consultabile dall’account LERS.
  • Account e domini. L’account può essere richiesto da chi è autorità competente per l’emissione, la convalida o la trasmissione. È inoltre richiesto che il dominio istituzionale dell’ufficio sia registrato e inserito in whitelist: verifica da fare prima che serva, non quando il termine è già in corso.
Due criticità da tenere presenti
Il prestatore si riserva di rifiutare EPOC ed EPOC-PR provenienti da Stati membri che non abbiano completato il recepimento della direttiva e l’attuazione del regolamento, su qualunque canale di trasmissione. È un vaglio di adeguatezza unilaterale che il regolamento non annovera fra i motivi di mancata esecuzione: per l’Italia conviene accertare come il prestatore collochi oggi il nostro Paese, alla luce dello stato di pubblicazione del testo definitivo di adeguamento.
Le domande frequenti sono prassi aziendale, non norma. Non incidono sugli obblighi dell’art. 10 né sui rimedi dell’art. 16: se il rifiuto è ingiustificato, la strada resta la richiesta di esecuzione all’autorità dello Stato del destinatario.

Fonte/riscontro: Google Ireland Limited, «Aggiornamento importante: invio di richieste di informazioni a Google Ireland Limited a partire dal 18 agosto 2026», 14 agosto 2026; «FAQs on submitting E-Evidence Requests to Google».

14. Rifiuto, esecuzione e sanzioni

Il sistema è pensato per l’adempimento diretto da parte del prestatore, ma prevede una fase di interlocuzione e, se necessario, di esecuzione tramite l’autorità dello Stato del destinatario. Fra le situazioni che possono impedire o condizionare l’esecuzione rientrano, a seconda dello strumento e della fase:

  • ordine non emesso o convalidato da autorità competente ai sensi dell’art. 4;
  • assenza delle condizioni richieste per la categoria di dato o per il reato;
  • impossibilità materiale non imputabile al destinatario o errori manifesti nel certificato;
  • dati non detenuti dal prestatore o per suo conto al momento rilevante;
  • servizio fuori dall’ambito del regolamento;
  • immunità o privilegi, comprese le tutele connesse alla libertà di stampa e di espressione;
  • in situazioni eccezionali, rischio manifesto di violazione di un diritto fondamentale garantito dal TUE e dalla Carta.

Merita una precisazione l’obiezione motivata dell’art. 17, che il prestatore può sollevare quando ritenga che l’esecuzione lo esporrebbe alla violazione di obblighi derivanti dal diritto di un paese terzo: protezione dei dati personali, segreto delle comunicazioni, divieti di divulgazione, normative extraterritoriali che subordinano la trasmissione a specifiche autorizzazioni interne. L’obiezione non attribuisce al prestatore un potere di veto: attiva un procedimento di verifica strutturato, sottratto al soggetto privato e ricondotto alla sede giurisdizionale dello Stato di emissione. Il prestatore, in altri termini, non è un mero esecutore passivo, ma neppure l’arbitro del conflitto: segnala e attiva il controllo giurisdizionale.

I motivi di rifiuto di cui all’art. 12 non si applicano all’ordine di conservazione, avendo esso carattere temporaneo e funzionale al successivo ordine di produzione; in sede di esecuzione forzata operano i motivi tassativi dell’art. 16, paragrafo 5.

Se il destinatario non ottempera e le giustificazioni non sono accettate, l’autorità di emissione può chiedere all’autorità di esecuzione di dare esecuzione all’ordine, trasmettendo il provvedimento, il modulo dell’allegato III compilato dal destinatario e la documentazione pertinente, tradotti in una lingua accettata dallo Stato di esecuzione. L’autorità di esecuzione decide sul riconoscimento senza indebito ritardo e comunque entro cinque giorni lavorativi, ingiunge formalmente l’adempimento e informa il destinatario della possibilità di obiettare, delle sanzioni applicabili e del termine. Prima di negare il riconoscimento consulta l’autorità di emissione, che risponde entro cinque giorni lavorativi. I dati eventualmente acquisiti sono trasmessi all’autorità di emissione senza indebito ritardo.

Il regolamento richiede sanzioni effettive, proporzionate e dissuasive: per le violazioni rilevanti il tetto massimo della sanzione pecuniaria può arrivare al 2 per cento del fatturato mondiale totale annuo del prestatore relativo all’esercizio precedente, secondo la disciplina nazionale applicabile. Gli Stati membri conservano quindi una notevole autonomia nella determinazione concreta delle sanzioni.

Fonte/riscontro: Reg. (UE) 2023/1543, artt. 12 e 15-17; materiale formativo SSM, sezione sulla procedura di esecuzione.

15. Questioni aperte

Alcuni profili meritano attenzione anche sul piano operativo, in attesa dei primi arresti applicativi.

  • Tenuta della data retention interna. Con ordinanza del 26 giugno 2025 il giudice per le indagini preliminari di Catania ha sollevato questione pregiudiziale davanti alla Corte di giustizia sulla compatibilità della disciplina nazionale di conservazione dei dati di traffico con i principi eurounitari, chiedendo in particolare se i file di log — accessi e uscite con IP e marche temporali — utilizzati al solo fine di identificare l’autore di un reato possano essere esclusi dalla nozione di dati di traffico. La pendenza della questione tocca direttamente le acquisizioni identificative più frequenti nella pratica.
  • Punti aperti dell’art. 263-bis. Non è chiarito se l’indicazione delle modalità di custodia e del termine costituisca elemento necessario o eventuale del decreto, né quale sia la sorte dei dati già conservati quando l’ordine urgente della polizia giudiziaria non venga convalidato: se cioè la perdita di efficacia imponga l’eliminazione dei dati o comporti solo la cessazione dell’obbligo di ulteriore conservazione.
  • Impugnazione dell’ordine di conservazione. L’art. 18 disciplina i soli mezzi di impugnazione avverso l’ordine di produzione, davanti a un organo giurisdizionale dello Stato di emissione, con legittimazione estesa anche al terzo i cui dati siano stati richiesti. In assenza di un obbligo informativo l’indagato può non venire a conoscenza della conservazione: in concreto sarà impugnabile il solo ordine di produzione, se e quando emesso. Resta aperta l’individuazione dei rimedi interni esperibili, con il richiamo, in via di ipotesi, al modello dell’opposizione avverso la perquisizione non seguita da sequestro.
  • Ne bis in idem e principio di specialità. Per l’ordine di conservazione il regolamento non vi fa riferimento, essendo l’interlocuzione limitata all’autorità di emissione e al destinatario; per l’ordine di produzione i due profili rilevano invece nella valutazione dell’autorità di esecuzione.
  • Compressione della valutazione del destinatario. I termini di dieci giorni e di otto ore, uniti al ruolo attivo di verifica attribuito al prestatore, riducono lo spazio per un vaglio effettivo di legittimità e proporzionalità: è ragionevole attendersi, nella fase iniziale, un numero non trascurabile di richieste di chiarimento ex allegato III.
  • Disallineamenti lessicali con l’ordinamento interno. Il riferimento alla contumacia, istituto non più presente nel nostro codice di rito, impone di ricondurre la fattispecie alle categorie dell’assenza consapevole e non consapevole.
  • Rapporto fra disponibilità giuridica e disponibilità tecnica del dato. Come esposto al § 6, la diffusione della cifratura end-to-end sposta parte del problema dal piano dei presupposti a quello dell’effettiva detenzione del dato da parte del prestatore.

16. Workflow operativi

  1. Classificare il dato: abbonati, sola identificazione, traffico, contenuto.
  2. Verificare il presupposto di reato, la necessità, la proporzionalità e l’analogia con un caso interno.
  3. Individuare l’autorità italiana competente all’emissione o alla convalida in base a categoria e fase.
  4. Identificare il corretto stabilimento designato o rappresentante legale e la lingua accettata.
  5. Compilare l’EPOC con identificatori precisi, intervallo temporale e dataset strettamente necessari.
  6. Valutare se è dovuta la notifica ex art. 8 e, in caso positivo, coordinare certificato e notifica.
  7. Trasmettere via sistema decentrato o, se tecnicamente necessario, tramite canale alternativo sicuro.
  8. Monitorare i termini di 10 giorni o 8 ore e le eventuali richieste di chiarimento.
  9. Alla ricezione: verificare provenienza, integrità, completezza e catena di custodia; registrare hash e checksum.
  10. Gestire l’informazione all’interessato secondo le determinazioni dell’autorità competente.
  1. Individuare con precisione i dati a rischio di cancellazione o modifica e motivare necessità e proporzionalità.
  2. Emettere o far convalidare l’ordine secondo il d.lgs. 215/2025; nei casi urgenti distinguere emergenza UE e procedura accelerata.
  3. Compilare l’EPOC-PR con destinatario, identificatore, categoria e intervallo temporale.
  4. Trasmettere al destinatario corretto: non si applica la notifica ex art. 8, prevista per il solo EPO di traffico e contenuto.
  5. Annotare la decorrenza del periodo di 60 giorni e programmare l’eventuale proroga di 30 giorni.
  6. Prima della scadenza, se è stata emessa una successiva richiesta di produzione, inviare la conferma prevista dal regolamento.
  7. Se la conservazione non è più necessaria, informare senza indebito ritardo il destinatario.

17. Checklist prima dell’invio

Obiettivo
Ridurre richieste di chiarimento, ritardi, rifiuti e rischio di produzione di dati non pertinenti.

☐  Ho classificato correttamente la categoria di dato?

☐  L’autorità emittente o convalidante è quella corretta per quella categoria e per quella fase?

☐  Ho motivato necessità e proporzionalità sul caso concreto?

☐  Il reato soddisfa le condizioni dell’art. 5 o dell’art. 6 applicabile?

☐  Ho identificato il destinatario giuridicamente corretto?

☐  Sto usando una lingua accettata dal destinatario?

☐  Gli identificatori sono completi e verificati? È indicato il servizio specifico?

☐  Per gli IP: marca temporale e fuso orario sono precisi? È necessaria la porta sorgente?

☐  L’intervallo temporale è il più ristretto compatibile con l’obiettivo investigativo?

☐  Le sezioni E, F e G sono coerenti fra loro?

☐  Se uso JUDEX e chiedo categorie diverse, devo emettere certificati separati e collegarli?

☐  Per traffico e contenuto ho verificato l’obbligo di notifica ex art. 8?

☐  Ho selezionato correttamente il termine di 10 giorni o di 8 ore e documentato l’eventuale emergenza?

☐  Esiste un precedente ordine di conservazione? Quando scadono i 60 giorni?

☐  L’autorità indicata per ricevere i dati dispone di un canale sicuro e di una casella monitorata?

☐  Ho previsto come verificare autenticità e integrità e come documentare la ricezione?

☐  Ho definito chi gestirà eventuali chiarimenti del provider e le relative scadenze?

☐  È stato valutato il differimento dell’informativa all’interessato e ne sono stati documentati i motivi?

La Relazione dell’Ufficio del Massimario dedica l’ultima parte alle conseguenze organizzative, che vale la pena anticipare perché ricadranno sui nostri uffici prima ancora che sulla giurisprudenza.

  • Gestione dei flussi. La centralità del pubblico ministero distrettuale nella fase passiva e la concentrazione delle competenze presso specifici uffici richiedono modelli organizzativi che garantiscano continuità operativa, tempestività e tracciabilità degli atti, incompatibili con la natura volatile del dato digitale.
  • Specializzazione. La complessità tecnica delle categorie di dati, il raccordo con la giurisprudenza eurounitaria e la gestione dei conflitti con ordinamenti terzi suggeriscono lo sviluppo di competenze dedicate e di nuclei di riferimento interni agli uffici.
  • Controllo delle scansioni temporali. La compressione dei termini richiede strumenti di tracciabilità delle fasi: eventuali ritardi nella convalida o nella trasmissione incidono sull’efficacia dell’atto e sulla stabilità dell’acquisizione. Servono protocolli informatici chiari e un’archiviazione digitale dei provvedimenti facilmente individuabile e ricostruibile in vista di contestazioni.
  • Uniformità di qualificazione. Errori nel classificare il dato si riflettono sull’individuazione dell’autorità competente e sul regime dei controlli: da qui l’esigenza di linee guida condivise e di confronto sistematico fra uffici, soprattutto nella fase iniziale.
  • Statistiche. L’art. 8 del d.lgs. 215/2025 affida al Ministero della giustizia la raccolta e la trasmissione alla Commissione dei dati previsti dall’art. 28, par. 2, del regolamento; l’autorità giudiziaria trasmette al Ministero i dati necessari. A decorrere dal 18 agosto 2026 la trasmissione è annuale, entro il 31 marzo, per l’anno civile precedente. Le modalità dovranno essere costruite in modo da non compromettere il segreto investigativo: non è il contenuto della singola informazione a essere sensibile, ma la sua combinazione, che in contesti territoriali ridotti può rendere identificabile il procedimento.
  • Risorse. Le disposizioni finanziarie autorizzano uno stanziamento circoscritto all’ordine di conservazione, alla procedura accelerata e alla fase passiva, mentre per il resto le amministrazioni provvedono con le risorse disponibili a legislazione vigente. L’effettività del sistema è quindi affidata alla capacità dei singoli uffici di riorganizzare l’esistente più che all’apporto di nuove risorse.

Fonte/riscontro: Relazione n. 25/2026, §§ 14 e 15.

18. Quadro nazionale in evoluzione e riferimenti

Aggiornamento ad agosto 2026
I d.lgs. 215/2025 e 216/2025 sono pubblicati e in vigore. Un ulteriore schema di decreto legislativo per il completo adeguamento al regolamento (Atto del Governo n. 411) ha concluso l’esame parlamentare ed è stato posto all’esame definitivo del Consiglio dei ministri il 4 agosto 2026. Nelle fonti ufficiali consultate per questa guida non risulta ancora la pubblicazione in Gazzetta Ufficiale del testo definitivo: prima di usare il documento come base per procedure vincolanti occorre verificarne l’eventuale sopravvenuta pubblicazione.

Riferimenti normativi e documentali essenziali:

  • Regolamento (UE) 2023/1543 del Parlamento europeo e del Consiglio, 12 luglio 2023, relativo agli ordini europei di produzione e di conservazione di prove elettroniche nei procedimenti penali.
  • Direttiva (UE) 2023/1544 del Parlamento europeo e del Consiglio, 12 luglio 2023, sulla designazione di stabilimenti designati e sulla nomina di rappresentanti legali.
  • Regolamento di esecuzione (UE) 2025/1550 della Commissione, 28 luglio 2025, specifiche tecniche del sistema informatico decentrato.
  • D.Lgs. 30 dicembre 2025, n. 215 — autorità e procedure italiane.
  • D.Lgs. 30 dicembre 2025, n. 216 — attuazione della direttiva 2023/1544.
  • Linee guida SIRIUS per la compilazione dell’EPOC, giugno 2026, e corrispondenti linee guida per l’EPOC-PR, con la relativa nota informativa — strumento pratico non vincolante.
  • A. Marandola, «L’attuazione dei d.lgs. nn. 215 e 216 del 2025: un ulteriore tassello all’esecuzione dell’e-evidence package», Processo Penale e Giustizia, 2026.
  • Ufficio del Massimario della Corte di cassazione, Relazione n. 25/2026 del 7 aprile 2026 (rel. C. Brignone), prima lettura sistematica del quadro attuativo nazionale: è il testo di riferimento per ogni approfondimento.
  • Sez. U, nn. 23755 e 23756 del 29 febbraio 2024, sul rapporto fra canale cooperativo europeo e strumenti interni; CGUE, Grande Sezione, 30 aprile 2024, M.N. (EncroChat), C-670/22.
  • C. De Lazzaro, «L’acquisizione delle prove elettroniche nello spazio di libertà, sicurezza e giustizia: una prima implementazione dell’e-evidence package», Sistema Penale, 2026.
  • D. Gambardella, «Ordine europeo di conservazione — regolamento (UE) 2023/1543 e direttiva (UE) 2023/1544», Scuola Superiore della Magistratura, formazione decentrata.
  • Garante per la protezione dei dati personali, parere del 25 settembre 2025 sullo schema di decreto, in tema di coordinamento fra disciplina europea e disciplina interna della data retention.
  • Senato della Repubblica, dossier sull’Atto del Governo n. 330 (schema del d.lgs. 216/2025).
  • Atto del Governo n. 411 — schema di completo adeguamento nazionale, da verificare nella versione eventualmente pubblicata in Gazzetta Ufficiale.

Conclusione

Il valore operativo del nuovo sistema non consiste soltanto nella riduzione dei tempi. Cambia il modello di acquisizione: l’autorità deve essere in grado di classificare correttamente il dato, scegliere l’autorità competente, individuare il destinatario europeo, compilare un certificato tecnicamente preciso e gestire notifiche, termini e integrità della prova. La qualità della richiesta giuridica e la qualità del dato tecnico diventano due facce della stessa attività.

Per gli uffici di polizia giudiziaria e per il personale informatico-forense la conseguenza pratica è chiara: l’identificatore deve essere utilizzabile dal prestatore, la finestra temporale deve essere precisa, la categoria del dato deve essere corretta e la ricezione deve essere documentata in modo da preservare autenticità, integrità e tracciabilità. Una richiesta giuridicamente valida ma tecnicamente ambigua può fallire; una richiesta tecnicamente precisa ma priva dei corretti presupposti giuridici è inutilizzabile.

Versione: agosto 2026. Documento di sintesi: non sostituisce la lettura dei testi normativi e delle linee guida, alle quali si rinvia per ogni aspetto di dettaglio.

Data theft: piano di intervento informatico forense

Il CSIRT Italia ha segnalato la presenza online di file riservati appartenenti ai clienti di uno studio legale, presumibilmente sottratti dal file server interno dello studio. In qualità di consulente forense incaricato, l’obiettivo primario è preservare e acquisire in modo forense tutte le evidenze digitali rilevanti (server, workstation e dispositivi di rete) garantendone integrità e autenticità, in vista di una possibile indagine giudiziaria. Si seguiranno rigorosamente le best practice internazionali (es. standard ISO/IEC 27037) per identificare, raccogliere, acquisire e conservare le prove digitali. È fondamentale minimizzare qualsiasi alterazione dei dati durante la raccolta e documentare ogni attività svolta, mantenendo una catena di custodia rigorosa delle evidenze.

Assunzioni Operative: si assume che l’incidente sia recente e che i sistemi coinvolti siano ancora disponibili in sede. Il file server Linux è identificato come potenziale fonte dei dati esfiltrati; tuttavia, non si esclude il coinvolgimento di una o più delle 5 workstation Windows (ad esempio come punto d’ingresso iniziale dell’attacco). Il firewall perimetrale potrebbe contenere log utili sulle connessioni di esfiltrazione. Si dispone dell’accesso fisico a tutti i dispositivi e del consenso dello studio per procedere all’acquisizione forense. Si prevede inoltre di avere a disposizione strumenti forensi (hardware e software) adeguati, inclusi supporti di memorizzazione esterni capienti per salvare le immagini acquisite. Ogni attività verrà coordinata in modo da ridurre al minimo l’impatto sull’operatività dello studio, pur privilegiando la preservazione delle prove rispetto alla continuità di servizio.

Come primo passo, identifichiamo tutte le potenziali fonti di evidenza digitale nell’infrastruttura compromessa. In questo caso includono:

  • File server Linux (contenente i dati dei clienti) – sorgente probabile dell’esfiltrazione.
  • Workstation Windows 10 (5 unità) – potrebbero aver subito compromissioni (ad es. tramite malware o furto credenziali) usate per accedere al server.
  • Firewall perimetrale – dispositivo di rete con possibili log di traffico in uscita e regole di accesso.
  • Copie dei file esfiltrati rinvenuti online – per confronti con i dati originali e conferma dell’effettiva violazione.

Una volta identificate, si procede alla preservazione immediata dello stato dei sistemi per evitare alterazioni o perdite di informazioni volatili. In particolare:

  • Isolamento dei dispositivi dalla rete: scolleghiamo il file server e le workstation dalla rete (cavo Ethernet o Wi-Fi) per impedire ulteriori comunicazioni con l’esterno o possibili azioni di copertura da parte di un eventuale attaccante ancora connesso. Anche il firewall, se compromesso, viene isolato (ad es. rimuovendo temporaneamente la connessione WAN) mantenendolo però acceso se necessario per preservare i log in memoria.
  • Valutazione dello stato (acceso/spento) dei sistemi: se i computer sono accesi, si considera di eseguire un’acquisizione live di dati volatili. In base all’ordine di volatilità (RFC 3227), le informazioni più volatili come il contenuto della RAM e le connessioni di rete attive vanno acquisite prima di spegnere i sistemi. La memoria RAM può contenere informazioni cruciali (password in chiaro, processi malware in esecuzione, connessioni di rete attive, ecc.) che andrebbero perse allo spegnimento. Dunque, per server e workstation accesi si pianifica di catturare un dump della memoria prima di procedere oltre.
  • Documentazione della scena: prima di manipolare i dispositivi, si documenta accuratamente la scena: fotografia dei cablaggi, posizione dei dispositivi, stato dei sistemi (acceso/spento, schermate visibili), etichette o seriali. Questo aiuta a ricostruire il contesto e dimostrare che ogni passaggio è stato eseguito correttamente. Ogni attività viene annotata con data, ora, luogo e persone coinvolte, pronto per essere inserita nel registro di catena di custodia.
  • Stabilizzazione del sistema compromesso: in caso il file server Linux sia in esecuzione e si tema la presenza di malware attivo (es. una backdoor), si valuterà se conviene spegnere immediatamente dopo la raccolta della RAM. Spesso, in incidenti gravi, l’arresto immediato (es. scollegando l’alimentazione) è consigliato dopo la raccolta dei dati volatili, per evitare che malware distruttivi cancellino tracce all’arresto ordinato. Tuttavia, questa decisione va ponderata in base alla situazione (ad esempio, la presenza di servizi critici potrebbe richiedere un arresto controllato). Nel dubbio, è preferibile privilegiare l’integrità delle prove rispetto alla continuità operativa.

Dopo aver messo in sicurezza l’ambiente, si procede con l’acquisizione forense bit-a-bit dei supporti di memoria e la raccolta dei log, utilizzando strumenti e procedure tali da garantire copie esatte e immodificabili degli originali. Tutte le acquisizioni avverranno utilizzando strumentazione forense dedicata (write blocker, software di imaging) e seguendo protocolli standard. Di seguito, il dettaglio per ciascun componente:

File server Linux (acquisizione disco e memoria)

Il file server è il principale indiziato da cui sarebbero stati esfiltrati i dati. Le attività previste sono:

  • Dump della memoria RAM: ce il server è ancora acceso, si esegue una copia della memoria volatile. Su sistemi Linux, si può utilizzare ad esempio Linux Memory Extractor (LiME) (modulo kernel) o strumenti come Magnet DumpIt for Linux (tool standalone) per ottenere un file dump della RAM completo. L’operazione viene svolta rapidamente, salvando l’output su un supporto esterno montato in sola lettura. Questa acquisizione live è fondamentale perché la RAM potrebbe contenere indicazioni di processi sospetti, chiavi di cifratura, o connessioni attive dell’attaccante. Si annotano orario e configurazione del sistema al momento del dump (es. elenco processi e connessioni aperte, utilizzando comandi come ps, netstat o tool forensi,se possibile, evitando però alterazioni significative).
  • Acquisizione forense del disco: successivamente, si procede allo shutdown del server per eseguire l’acquisizione del disco in modo sicuro. Idealmente, il disco fisso del server viene rimosso dalla macchina per evitare qualsiasi modifica dovuta all’avvio del sistema operativo. Il disco viene collegato a una workstation forense tramite un write-blocker hardware (es. un Tableau) che impedisce qualsiasi scrittura accidentale sul supporto originale. In alternativa, se non fosse possibile estrarre il disco (ad es. array RAID complesso in produzione), si potrebbe avviare il server da un bootable USB forense (es. distribuzione CAINE basata su Linux Ubuntu o Kali Linux in modalità forense) che non altera i dischi interni (automount disabilitato, accesso in sola lettura). Avviato l’ambiente forense, si può usare il tool dd o dcfldd per creare un’immagine bitstream di ogni unità logica. Ad esempio: dcfldd if=/dev/sda of=/media/esterna/server-image.img hash=sha256 log=server-img.log (dove si calcola anche l’hash durante la copia). È preferibile usare dcfldd o strumenti analoghi in quanto progettati per scopi forensi (permettono di calcolare direttamente hash MD5/SHA e suddividere l’immagine in segmenti, se necessario). In alternativa, si può impiegare Guymager (tool con interfaccia grafica su Linux) che consente di creare immagini in formato raw E01 con calcolo automatico degli hash. Durante l’acquisizione, non si deve mai salvare l’immagine sullo stesso disco oggetto dell’acquisizione ma su un dispositivo di destinazione separato (ad esempio un drive USB esterno capiente formattato exFAT/NTFS). Si raccomanda il formato E01 (EnCase Evidence File) per il disco del server, poiché comprime i dati e consente di includere metadati (es. informazioni del caso, timestamp di acquisizione, etc.) utili per la catena di custodia. Al termine, viene calcolato e registrato l’hash (tipicamente MD5 e SHA-1) dell’immagine e confrontato con quello calcolato sul disco originale, per verificare la conformità bit-a-bit. Un match degli hash conferma che la copia è identica all’originale e non alterata, garantendo l’autenticità dell’evidenza. Tutte le operazioni vengono registrate nel log di acquisizione (nome del dispositivo, orari di inizio/fine, dimensione dell’immagine, algoritmi di hash utilizzati, ecc.). Il supporto originale (disco server) viene poi sigillato e conservato come evidenza originale.
  • Raccolta di log e configurazioni: oltre all’immagine completa del file system (che include comunque i log di sistema), si può procedere a estrarre copie logiche di file di log chiave per un’analisi immediata. Ad esempio, i file in /var/log/ (log di autenticazione SSH, log di Samba NFS se il server fungeva da file server di rete, log di sistema) sono cruciali per ricostruire gli accessi e le operazioni avvenute. Tali log, se disponibili, vengono copiati separatamente (sempre tramite strumenti che garantiscano l’integrità, ad es. usando cp in ambiente forense o esportandoli con nc su un’altra macchina) e i loro hash calcolati, così da poterli utilizzare per un’analisi più rapida senza dover montare subito l’intera immagine del disco. Naturalmente l’integrità di questi file è garantita anche dal fatto che provengono da un’immagine forense verificata.

Workstation Windows 10 (acquisizione disco e, se opportuno, memoria)

Le cinque workstation Windows potrebbero aver giocato un ruolo nell’incidente (es. come punto di ingresso iniziale tramite phishing o malware, o come postazioni da cui è partito l’accesso non autorizzato al server). Il piano prevede:

  • Dump della RAM (se accese): per ogni workstation ancora accesa al momento dell’intervento, si effettua prima la cattura della memoria volatile. Su Windows, uno strumento pratico è Magnet Forensics RAM Capture (DumpIt), eseguibile da chiavetta USB: con un doppio click esegue il dump completo della RAM su un file .raw o .mem. Questo richiede pochi minuti per decine di GB di RAM e fornisce istantanee dei processi in esecuzione, connessioni di rete attive, moduli caricati, ecc. Spesso i ransomware o altri malware lasciano tracce in memoria (processi o librerie iniettate) che possono essere scoperte con analisi successive (es. con Volatility). Anche credenziali o token temporanei possono risiedere in RAM, quindi questa è un’evidenza preziosa. Si salva il dump su un disco esterno, annotando ora e macchina, e si calcola l’hash anche per questi file di memoria.
  • Spegnimento e rimozione dischi: subito dopo il dump (o immediatamente, se la macchina era spenta), si spengono le workstation. Idealmente, nel caso di sospetto malware attivo, è accettabile uno spegnimento improvviso (staccando l’alimentazione o la batteria) per evitare che eventuali programmi malevoli intercettino la normale procedura di shutdown (p.es. alcuni malware possono cancellare tracce al momento dello spegnimento). Dato che abbiamo già acquisito la RAM, il rischio di perdere dati volatili importanti è mitigato. Una volta spento il sistema, si procede a rimuovere il disco interno (HDD/SSD) dalla workstation.
  • Imaging forense dei dischi: ogni disco viene etichettato univocamente (es. WS1, WS2, … WS5) e collegato tramite write-blocker a una postazione forense. Su sistemi Windows, useremo FTK Imager (software forense gratuito di AccessData/Exterro) sulla nostra workstation forense per creare immagini bitstream dei dischi. FTK Imager permette di scegliere il formato (raw dd, E01, AFF, etc.) e di calcolare automaticamente hash MD5/SHA1 durante l’acquisizione. Prima di procedere, ci assicuriamo che Windows non effettui mount automatico delle partizioni del disco inserito: infatti Windows tende a montare qualsiasi volume riconosciuto, rischiando di alterare last access time o altri metadata. L’uso del write-blocker hardware previene questo problema, garantendo che il sistema operativo forense veda il disco come sola lettura. In FTK Imager, useremo l’opzione Create Disk Image selezionando la sorgente fisica (Physical Drive) e specificando come destinazione un percorso su un drive esterno. Scegliamo il formato E01 (EnCase Evidence) per coerenza e compressione, inserendo nei metadati dell’immagine i dettagli del caso (nome caso, numero evidenza, esaminatore, etc.). Abilitiamo l’opzione di verifica hash al termine (FTK Imager calcolerà hash MD5/SHA1 e li comparerà automaticamente). Procediamo quindi all’imaging completo. Ad acquisizione terminata, verifichiamo i log di FTK Imager che riporteranno gli hash calcolati; un confronto positivo tra hash di origine e copia conferma la bontà dell’immagine. Ripetiamo questo processo per tutti i dischi delle 5 postazioni.
  • Acquisizione dati di interesse dalle workstation: le immagini dei dischi Windows conterranno informazioni quali i log di Windows (eventi di sicurezza nel registro eventi), file temporanei, cronologia di navigazione, eventuali malware presenti, ecc. Sebbene l’analisi dettagliata avverrà successivamente in laboratorio, in sede di acquisizione si può già valutare di estrarre rapidamente alcuni artefatti se immediatamente utili. Ad esempio, log di Windows Event Viewer (Security.evtx) per vedere login sospetti, o la lista di utenti e gruppi locali, possono essere esportati usando strumenti come FTK Imager stesso (che consente di sfogliare il file system e salvare file singoli) prima di smontare il disco. Tuttavia, tali operazioni non sono strettamente necessarie in campo se l’obiettivo principale è acquisire tutto per analisi approfondita successiva. L’essenziale è che le immagini siano integre e complete.

Firewall perimetrale (raccolta log e configurazione)

Il firewall costituisce il punto di ingresso/uscita della rete aziendale. Anche se potrebbe non essere opportuno spegnerlo (specie se fornisce connettività Internet allo studio) prima di aver analizzato la situazione, ai fini forensi occorre acquisire i dati che possono testimoniare le connessioni di esfiltrazione. Le azioni prevedono:

  • Esportazione dei log di traffico: la maggior parte dei firewall di classe enterprise o SMB consente di esportare i log di sistema (ad esempio file di log di sessione, eventi di intrusion detection se integrato, log VPN, ecc.) tramite interfaccia di amministrazione o SSH. Si accede al firewall (in sola lettura) e si scaricano i log relativi al periodo sospetto dell’incidente. In particolare, interessano log di connessioni uscenti (egress) dal file server o dalle workstation verso l’esterno. Questi log possono rivelare indirizzi IP di destinazione e volumi di dati trasferiti durante l’esfiltrazione. Ad esempio, se i dati sono stati caricati su un sito web o cloud, il firewall potrebbe mostrare un flusso FTP/HTTP/HTTPS anomalo in uscita da un IP interno (quello del server) verso un IP esterno sconosciuto, magari con un volume di svariati gigabyte. Tali evidenze sono cruciali per ricostruire il canale di esfiltrazione. I log vengono salvati (in formato testo o CSV) su supporto forense e ne vengono calcolati gli hash per garantirne l’integrità.
  • Configurazione e regole: si acquisisce anche la configurazione del firewall (spesso esportabile come file di backup) per vedere che porte/servizi erano aperti verso l’esterno. Ad esempio, se il file server aveva porte aperte (SSH, SMB) o se esistevano regole di port forwarding, ciò può essere rilevante. La config, una volta esportata, viene sottoposta a hash e conservata.
  • Eventuale immagine del dispositivo: se il firewall è un appliance software (ad es. basato su Linux/BSD come pfSense) con storage interno, e se l’hardware lo permette, si può anche considerare di fare un’immagine forense del suo drive (similmente a quanto fatto per server/PC). Tuttavia, molti firewall commerciali hanno filesystem proprietari o sono crittografati; spesso è sufficiente raccogliere log e config. Nel caso di un firewall standard PC-based, si potrebbe spegnere e clonare il disco con gli stessi metodi (write-blocker, etc.), ma solo dopo aver ottenuto i log volatili se non persistenti.

Evidenze dei file esfiltrati online

Parallelamente all’acquisizione interna, recuperiamo i file trapelati sul sito Internet segnalato dal CSIRT. Questi file costituiscono prova dell’avvenuta violazione e saranno utili per confronti. Le attività sono:

  • Download dei file dal sito esterno: utilizzando un computer sicuro, si scaricano i file trovati online, preservandone i metadati ove possibile. Ad esempio, se disponibili via web, si può usare wget o browser, evitando di modificarli (impostando l’orario di modifica come originario se indicato). Si registra l’URL e l’ora del download e, se possibile, si fa uno screenshot della pagina web dove erano disponibili, come documentazione.
  • Calcolo hash e conservazione: su ogni file esfiltrato scaricato, si calcolano hash (MD5/SHA1) per poterli confrontare successivamente con gli hash dei file originali sul server. In ambito forense, il confronto degli hash permetterà di dimostrare che il file online è esattamente uguale a quello presente sul server (qualora nelle immagini acquisite del server sia rinvenuto lo stesso hash), confermando così l’origine dell’esfiltrazione. Questi file scaricati diventano anch’essi evidenze digitali e vengono inseriti nella catena di custodia.
  • Metadati e attributi: si analizzano brevemente i metadati di tali file (es. proprietà del documento, autore, date di creazione/modifica) poiché potrebbero rivelare informazioni sull’origine (ad es. username del sistema dal quale provengono, versione software, etc.). Tali informazioni, se trovate, saranno poi corroborate con l’analisi interna (ad esempio, se i documenti recano come autore il nome di un dipendente dello studio, ciò può suggerire da quale PC/server provenivano).

Durante e dopo ogni acquisizione, si verifica l’integrità delle evidenze digitali e si aggiornano i documenti che compongono la Catena di Custodia:

  • Calcolo e verifica degli hash crittografici: come standard, per ogni immagine forense creata (dischi di server, PC) e per ogni file rilevante copiato (dump di RAM, log, file esfiltrati, ecc.), si calcola almeno un algoritmo di hash (tipicamente MD5 e SHA-1, oppure SHA-256 per maggiore sicurezza). Il valore di hash viene confrontato con quello ricalcolato all’occorrenza sulle stesse evidenze per assicurare che non vi siano alterazioni. Ad esempio, FTK Imager e altri tool riportano automaticamente hash MD5/SHA1 post-acquisizione. Questi hash vengono annotati nel verbale di acquisizione accanto all’identificativo dell’evidenza. La corrispondenza degli hash tra originale e copia forense prova formalmente che la copia è identica al bit all’originale, requisito fondamentale per la validità probatoria.
  • Documentazione dettagliata: si redige un verbale tecnico di acquisizione in cui per ogni dispositivo analizzato si riportano: descrizione (marca, modello, S/N), identificativo assegnato come evidenza, persona che ha eseguito l’operazione, data/ora di inizio e fine imaging, strumento usato, hash dell’immagine ottenuta, eventuali osservazioni (es. errori di lettura, settori danneggiati se presenti). Inoltre, come previsto dalle linee guida, si documenta ogni operazione svolta su ciascun reperto in ordine cronologico. La Catena di Custodia descrive l’intero ciclo di vita dell’evidenza digitale, dalla raccolta iniziale fino all’eventuale presentazione in tribunale. Ad esempio: “Evidenza E01: Disco fisso server SN… prelevato in data … ore … da Tizio, acquisito in copia forense file XYZ.E01 hash MD5=…, SHA1=…, da Caio con strumento FTK Imager vX, consegnato in custodia a Sempronio alle ore …”. Ogni trasferimento di custodia (passaggi di mano dell’evidenza, spostamento dal luogo di raccolta al laboratorio, etc.) viene parimenti registrato con data, ora, persona che consegna e persona che riceve e firma (quando possibile). Questo garantisce tracciabilità completa: in ogni momento si può stabilire chi ha avuto accesso all’evidenza e quando.
  • Protezione fisica delle evidenze: dopo l’acquisizione, i supporti originali (dischi rimossi, ecc.) vengono riposti in contenitori sigillati con etichette anti-manomissione (ad es. evidenziatori di apertura). Si appone un sigillo sia sull’originale sia su una delle copie forensi conservate (la seconda copia sarà utilizzata per l’analisi). Eventuali violazioni dei sigilli sarebbero evidenti e renderebbero dubbia l’integrità del reperto. Oltre ai sigilli fisici, si proteggono i dati da fattori esterni: ad esempio, i supporti vengono conservati in ambiente a temperatura e umidità controllata, lontano da campi elettromagnetici che potrebbero danneggiarli. Nel nostro caso, i dischi originali delle workstation e del server, dopo l’imaging, verranno ad esempio inseriti in sacchetti antistatici, sigillati, etichettati e messi in una cassaforte o armadio blindato. Lo stesso per eventuali USB contenenti i dump di RAM o i file scaricati: se tali dati sono salvati su supporti rimovibili (es. SSD esterno), anche questi supporti vengono sigillati e custoditi.
  • Conservazione delle copie forensi: le immagini forensi acquisite (file .E01, .dd, dump RAM, ecc.) verranno duplicate se possibile: una copia master immutabile, conservata come evidenza intoccabile, e una o più copie di lavoro su cui effettuare l’analisi tecnica. La copia master (ad es. su hard disk dedicato) viene anch’essa sigillata e custodita, mentre la copia di lavoro potrà essere caricata sulle workstation forensi per l’analisi senza rischiare di compromettere l’originale. In caso di contestazioni, la copia master potrà sempre essere riesaminata per verifica indipendente.

Una volta concluse le acquisizioni, le evidenze dovranno essere consegnate e/o conservate in modo appropriato in vista di procedimenti futuri:

  • Reportistica e verbali ufficiali: si consegna allo studio legale un rapporto forense preliminare che elenca tutte le evidenze raccolte e descrive sinteticamente le modalità di acquisizione seguite, certificando che sono stati rispettati i protocolli per assicurare conformità degli originali e immodificabilità delle copie. Questo rapporto include in allegato i verbali di cui sopra e i documenti costituenti la Catena di Custodia firmati dal consulente.
  • Consegna a autorità inquirenti (se previsto): se lo studio intende sporgere denuncia o se l’incidente configura reati perseguibili d’ufficio, le evidenze digitali dovranno essere messe a disposizione dell’Autorità Giudiziaria. In tal caso, si preparano i reperti secondo le regole richieste: ogni evidenza viene identificata con un numero di repertazione, descritta nel verbale di consegna e consegnata (es. alla Polizia Postale o altra forza di polizia competente). I rappresentanti dell’autorità firmano per ricevuta, entrando così loro nella catena di custodia come nuovi custodi dell’evidenza. Da quel momento, ogni accesso ai dati dovrà avvenire sotto il loro controllo o con la loro autorizzazione. È importante evidenziare che la documentazione della Catena di Custodia accompagna le evidenze: fornisce al giudice la garanzia che dal momento della raccolta alla presentazione in giudizio non vi siano state manomissioni.
  • Conservazione a lungo termine: sia lo studio sia l’autorità (se coinvolta) dovranno conservare le evidenze digitali in modo sicuro fino alla conclusione di ogni procedura legale, ed anche oltre se richiesto. Ciò significa storage in ambienti controllati, con accesso limitato solo a personale autorizzato. Ad esempio, i supporti sigillati possono essere custoditi in una sala prove dedicata con registro accessi, e le copie digitali possono essere conservate anche in cassaforte ignifuga (per prevenire perdita in caso di incendio). Si ricorda che anche i dati digitali soffrono il passare del tempo (bit rot, obsolescenza hardware): pertanto, per conservazioni prolungate, si potrebbero effettuare periodiche verifiche dell’integrità (ricalcolando gli hash a distanza di tempo per verificare che coincidano ancora) e migrazioni su nuovi supporti in caso di necessità, sempre documentando ogni passaggio.

Di seguito un riepilogo degli strumenti specifici impiegati e la motivazione della loro scelta, in accordo con le best practice forensi:

  • Write Blocker Hardware (es. Tableau, Digital Intelligence UltraBay): dispositivo essenziale che si interpone tra il supporto originale (es. SATA/SAS/USB) e la macchina forense, consentendo solo comandi di lettura. Ciò previene modifiche accidentali ai dati originali durante l’imaging . L’uso del write blocker garantisce l’immodificabilità del reperto originale in linea con i requisiti legali (copia conforme e non alterata). Abbiamo utilizzato write blocker per tutti i dischi rimossi prima di leggerli sui nostri sistemi di acquisizione.

Software di imaging forense

  • FTK Imager: scelto per l’acquisizione delle workstation Windows. È uno strumento gratuito e affidabile, in grado di creare immagini forensi (raw, E01, AFF) e di calcolare hash integrati. Supporta anche la cattura della RAM su macchine Windows con pochi click. Lo abbiamo usato per comodità e per mantenere un formato standard (E01) ampiamente accettato nelle corti. Inoltre FTK Imager genera un log dettagliato utile per testimoniare la correttezza delle operazioni.
  • dd/dc3dd: utilizzato in ambienti Linux per la sua ubiquità e controllo. dc3dd in particolare è una variante di dd orientata al digital forensics, che permette hashing on the fly e log avanzati. È stato impiegato per duplicare il disco del server Linux in maniera forense.
  • Guymager: alternativa GUI su Linux per imaging, scelta nel caso di acquisizioni tramite live CD CAINE. Genera direttamente file .E01 e calcola hash, semplificando l’operatività.
  • Tableau TD3/TX1 Forensic Imager (opzionale): si tratta di unità hardware dedicate che clonano dischi a livello hardware senza bisogno di PC. Se disponibile, avremmo potuto usarla per velocizzare l’acquisizione dei dischi grandi (soprattutto il server) con copia diretta disk-to-disk. Tali dispositivi garantiscono velocità ottimizzata e logging automatico, con verifica hash in hardware. Nel nostro scenario, abbiamo ipotizzato l’uso prevalente di software, ma è menzionato per completezza.

Strumenti per il dump della memoria volatile

  • Magnet RAM Capture (DumpIt): utilizzato per dump veloci della RAM sulle macchine Windows. Scelto per la sua semplicità (eseguibile portabile) e velocità. Il dump risultante è compatibile con i più diffusi framework di analisi della memoria (Volatility, Rekall).
  • LiME (Linux Memory Extractor): modulo kernel per Linux usato per dump di RAM del server. Scelto perché consente di ottenere un dump consistente direttamente da kernel space, con un impatto minimo sul sistema. Richiede preparazione (compilazione modulo ad hoc per la versione di kernel), perciò si potrebbe optare in alternativa per AVML (Azure VM Memory Leaker) di Microsoft, un tool user-space che non necessita compilazione. In ogni caso, l’importante è aver ottenuto la memoria prima dello spegnimento.
  • Volatility Framework (analisi post acquisizione): citato come strumento che useremo successivamente per analizzare i dump di memoria e cercare indizi (processi anomali, moduli sospetti, connessioni residue, credenziali in chiaro, ecc.).

Utilities di sistema e log collection

  • Comandi come ifconfig/ipconfig, netstat, tasklist/ps, wmic etc., possonoessere stati eseguiti durante la fase live (se fatta) per raccogliere informazioni di stato (es. elenco connessioni di rete, processi attivi, utenti loggati). Tali informazioni sono state annotate e salvate come parte delle evidenze (es. reindirizzando l’output su file di testo).
  • Per il firewall, l’interfaccia di amministrazione web/SSH integrata è stata lo strumento per estrarre i log e configurazioni. In mancanza di esportazione diretta, si poteva eseguire uno script o screenshot.
  • Hashing tools: utilizzo di algoritmi MD5, SHA-1, SHA-256 tramite tool integrati (ad es. md5sum/sha1sum su Linux, o utilità come HashCalc su Windows) per calcolare le impronte digitali delle evidenze.

In sintesi, la combinazione di questi strumenti e tecniche è stata scelta per massimizzare l’affidabilità e la completezza della raccolta delle prove, minimizzando al contempo il rischio di alterazione dei dati originali. Ogni scelta (dall’uso del write blocker all’acquisizione della RAM) è motivata da esigenze probatorie: garantire che ogni bit di informazione utile venga conservato e possa essere presentato in giudizio con adeguato fondamento di autenticità.

Al termine di queste operazioni, lo studio legale disporrà di copie forensi integre di tutti i sistemi coinvolti, pronte per l’analisi approfondita. Nelle fasi successive, in laboratorio, si potranno esaminare le immagini acquisite con software di analisi forense (come Autopsy, EnCase, X-Ways o altri) per ricostruire la timeline dell’intrusione, identificare l’eventuale malware o tecnica di attacco utilizzata, e confermare quali dati sono stati esfiltrati e come. I log di firewall e di sistema aiuteranno a determinare quando e verso dove sono stati trasmessi i dati rubati  . Tutto questo, unito alle evidenze conservate in modo corretto, permetterà eventualmente di presentare una prova tecnica solida alle autorità competenti e in sede legale, sostenendo le azioni che lo studio legale deciderà di intraprendere a tutela dei propri clienti e contro gli autori della violazione.

Fonti e riferimenti: le procedure adottate seguono gli standard riconosciuti in ambito digital forensics e incident response, tra cui le linee guida ISO/IEC 27037:2012 per la gestione delle evidenze digitali. Strumenti come FTK Imager e write-blocker hardware sono prassi comune per garantire copie forens affidabili, così come l’uso di hash crittografici per assicurare la conformità delle copie. La catena di custodia e la sigillatura dei reperti vengono gestite secondo le indicazioni della migliore dottrina forense 19 21 , assicurando in ogni momento l’integrità e l’autenticità del materiale probatorio raccolto. Con questo approccio metodico e documentato, l’indagine potrà proseguire sapendo di avere solide basi probatorie su cui fare affidamento.

Pillole di Digital Forensics

La digital forensics è una branca della Criminalistica caratterizzata dall’adozione di metodi scientificamente derivati finalizzati all’identificazione, acquisizione e/o repertamento, preservazione, validazione, verifica, analisi, l’interpretazione, documentazione e presentazione del contenuto informativo di sistemi informatici o telematici, al fine di evidenziare l’esistenza di fonti di prova digitali resistenti ad eventuali contestazioni circa la propria attendibilità e capacità probatoria sia in ambito civile che penale.

Corte di Cassazione (Sez. VI n. 3067 del 14.12.1999; Sez. V n. 31135 del 6.7.2007)

«… deve ritenersi “sistema informatico”, … , un complesso di apparecchiature destinate a compiere una qualsiasi funzione utile all’uomo, attraverso l’utilizzazione (anche parziale) di tecnologie informatiche, che sono caratterizzate – per mezzo di un’attività di “codificazione” e “decodificazione” – dalla “registrazione” o “memorizzazione”, per mezzo di impulsi elettronici, su supporti adeguati, di “dati”, cioè di rappresentazioni elementari di un fatto, effettuata attraverso simboli (bit), in combinazione diverse, e dalla elaborazione automatica di tali dati, in modo da generare “informazioni”, costituite da un insieme più o meno vasto di dati organizzati secondo una logica che consenta loro di esprimere un particolare significato per l’utente …».

«… è “sistema telematico” l’insieme di più sistemi informatici collegati tra loro per lo scambio di informazioni, purché siano connessi in modo permanente, e purché lo scambio di informazioni sia il mezzo necessario per conseguire i fini operativi del sistema. …»

Digital Investigation: si attua prima (attività preventiva volta all’acquisizione di elementi indiziari), durante il fatto reato (possono richiedere garanzie difensive);

Digital Forensics: si attua dopo il fatto reato, ossia il dispositivo scientifico arriva sempre a fatto compiuto (c.d. post-mortem) e concentra la sua azione su un specifico evento al fine di determinarne le cause. Essa può essere a sua volta in modalità:

Live: il sistema informatico non si può spegnere, quindi si è costretti ad operare sulla scena del crimine;

Dead o Static: il sistema informatico è spento, quindi cristallizzato e si può operare in laboratorio.

DEFR (Digital Evidence First Responder) ISO 27037:2012 Pt. 3.7

Definito a volte come Addetto ai Rilievi Tecnici, questi viene coinvolto nelle fasi di identificazione, repertamento e/o acquisizione e preservazione della fonte di prova digitale. Tale figura professionale non dovrebbe necessariamente svolgere un’attività di analisi.

DES (Digital Evidence Specialist) ISO 27037:2012 Pt. 3.8

Definito a volte come “Analista”, questi fornisce supporto tecnico al DEFR nelle fasi di identificazione, repertamento e/o acquisizione e preservazione delle fonti di prova digitale. Il DES deve essere caratterizzato da una formazione di tipo accademico e di comprovata esperienza nel settore tecnico-investigativo.

Il dato è la rappresentazione oggettiva di un fatto o evento che consenta la sua trasmissione oppure interpretazione da parte di un soggetto umano o di uno strumento informatico.

L’informazione è l’interpretazione e il significato assegnato a uno o più dati.

Identificazione (ISO 27037:2012 pt. 3.12): ricerca, riconoscimento e documentazione della fonte di prova digitale e rispettiva pertinenza (priorizzare le attività sulla base dell’ordine di volatilità dei dati, mitigare l’impatto sia sul sistema che sulle fonti di prova digitali).

Acquisizione (ISO 27037:2012 pt. 3.1): duplicazione del contenuto informativo della fonte di prova digitale. Consiste nell’adozione di misure tecniche, il più possibile riproducibili e/o verificabili, dirette alla duplicazione del contenuto informativo, o parte di esso, di sistemi informatici e/o telematici su adeguati supporti, tale che assicuri la conformità della copia all’originale. 

Con il termine “duplicato informatico” (art. 1 lett. i-quinquies D. Lgs. 7 marzo 2005, n. 82 – C.A.D.) s’intende l’operazione di memorizzazione, su dispositivi diversi, della medesima sequenza di valori binari del dato informatico originario.

Affinché il dato non sia condizionato dal nuovo ambiente di lavoro, vi è la necessità che questi venga memorizzato all’interno di un c.d. “forensic container”, creando così un vero e proprio “reperto virtuale”.

Repertamento (ISO 27037:2012 pt. 3.3.): attività volta ad assicurare la fonte di prova digitale e la rispettiva pertinenza, consiste nella rimozione della fonte di prova digitale e sue pertinenze dall’ambiente originario ad uno controllato (es. un laboratorio) per la successiva acquisizione ed analisi. Non sempre è possibile repertare.

Preservazione (ISO 27037:2012 p.t. 3.15): attività volta a garantire l’integrità e/o le condizioni originali della fonte di prova digitale mediante misure tecniche dirette ad: assicurare la conservazione e l’immodificabilità (conservazione dello stato dei luoghi) e impedire l’alterazione (dolo) e l’accesso incontrollato (colpa).

Validazione (ISO 27037:2012 pt. 3.24): attività di valutazione del rapporto di “pertinenzialità” tra gli elementi assicurati ed il contesto investigativo (ISO / IEC 27004: 2016).

Verifica (ISO 27041:2015 pt. 3.20): si accerta che la fonte di prova digitale ha conservato la sua integrità (ISO / IEC 27004: 2016).

Analisi (ISO 27042:2015 pt. 3.1 and ISO 27043:2015 pt. 3.3): il processo di valutazione oggettiva delle fonte di prova digitali a finché queste possano confermare, o confutare, un tesi accusatoria.

Interpretazione (ISO 27042:2015 pt. 3.9): è il processo in cui si contestualizzano le risultanze oggettive derivate dall‘attività di analisi e le si proietta in più ampio quadro accusatorio (es. Correlazione tra risultanze di più dispositivi informatici analizzati e dati forniti da terze parti).

Documentazione (es. artt. 136, 137 e 357 c.p.p.): insieme di atti e documenti in genere volti a storicizzare le attività svolte

Presentazione (es. artt. 196-198 c.p.p.): è l’esposizione, generalmente orale, delle risultanze tecnico-investigative in ambito processuale

La Catena di Custodia (CoC – ISO 27037:2012 pt. 6.1) è un documento o una serie di questi che attesta, in un dato arco temporale, la  responsabilità di un soggetto nella gestione di uno o più reperti. Essa ha inizio con l’esercizio dell’attività assicurativa e si conclude con la confisca e distruzione, ovvero la restituzione all’avente diritto del reperto.

Principi (ISO 27037):

Gli attori che intervengono sulla scena del crimine informatico, dovranno garantire i seguenti principi comuni alla maggior parte dei sistemi giurisdizionali internazionali:

Rilevanza/Pertinenza (Relevance): secondo cui bisogna dimostrare di aver acquisito e/o repertato solo elementi di pertinenza con il contesto d’indagine, avendo cura di motivarne le ragioni.

Affidabilità/Attendibilità (Reliability): secondo cui ogni processo che caratterizza la scena del crimine informatico dovrebbe essere verificabile e ripetibile. L’attuazione di tali processi dovrebbe garantire l’intera riproducibilità dell’attività tecnico-investigativa.

Sufficienza/Proporzionalità (Sufficiency): in cui il DEFR si assicura di avere a disposizione sufficiente materiale su cui svolgere le indagini.

I requisiti:

Verificabilità (Auditability): secondo cui dovrebbe essere possibile per una parte terza, indipendente alla componente di Polizia Giudiziaria ed autorizzata dall’A.G. (es. il Consulente Tecnico), poter accertare tutte le attività poste in essere sia dal DEFR che dal DES sulla scena del crimine informatico.

Ripetibilità (Repeatability): secondo cui si producono gli stessi risultati con lo stesso test nello stesso ambiente.

Riproducibilità (Riproducibility): secondo cui si producono gli stessi risultati al variare sia dell’ambiente che degli strumenti.

Giustificabilità (Justifiability): secondo cui il DEFR dovrebbe essere in grado di poter giustificare la metodologia attuata per quel particolare contesto investigativo caratterizzato da vincoli giuridici, tecnologici e logistici, oltreché di competenze tecniche dello stesso operatore.

Nel linguaggio scientifico, l’hash (ISO/IEC 10118-3:2018) è una funzione «one way», ossia che non può essere invertita, atta alla trasformazione di un testo di lunghezza arbitraria in una stringa di lunghezza fissa, relativamente limitata.

Tale stringa rappresenta una sorta di «impronta digitale» (o «sigillo elettronico») del contenuto di un file, e viene comunemente denominata come:

  • codice di hash;
  • checksum crittografico;
  • message digest.

Il codice hash, riportato nel report del Forensic Container, fa riferimento al contenuto informativo del dispositivo acquisito e non al container stesso.

Acquisizione manuale: consiste nella documentazione realizzata mediante rilievi descrittivi e tecnici (foto e video)

Acquisizione logica: consente di estrarre dati allocati e che sono accessibili tipicamente tramite:

  • API del sistema operativo (c.d. logica semplice);
  • File system (c.d. logica avanzata).

Sono da considerarsi dati allocati tutti quelli non cancellati ed accessibili tramite file system.

Un’eccezione a questa definizione è che alcuni file, come ad esempio un database SQLite, possono essere assegnate e ancora contengono record eliminati nel database.

Siamo in grado di eseguire due tipi di acquisizione logica:

  • semplice, che viene effettuata per mezzo di una acquisizione selettiva sui dati specifici dell’area utente (ad esempio contatti, agenda, registri chiamate e così via). Il risultato di questo tipo di acquisizione è simile a sistemi di backup (ad esempio iTunes, Kies, …) che usano le API specifiche e non ha bisogno di privilegi amministrativi;
  • avanzata (o del file system), che necessita il più delle volte di privilegi amministrativi, in quanto consente di estendere il suo raggio di azione non soltanto ad ristretto numero di file, ma ad una o più partizioni di un volume.

Acquisizione fisica: un’acquisizione c.d. «fisica» fornisce l’accesso integrale al contenuto informativo del supporto di memorizzazione, consentendo così di recuperare anche i dati non più allocati (cancellati o obsoleti) e ottenere un dump esadecimale.

Tali tecniche possono essere attuate tramite soluzioni:

  • software, i quali vengono eseguiti con privilegi amministrativi al fine di ottenere un’estrazione integrale dei dati presenti nella memoria di massa;
  • hardware, che consistono in un collegamento o estrazione fisica della memoria di massa.

La vera difficoltà di questa tipologia di acquisizione consiste nel riuscire a decodificare, e quindi ricostruire, i dati acquisiti.

In ambito di accertamenti tecnici può accadere che quella che è considerata un’attività ripetibile, spesso non lo è in termini giuridici

La disciplina normativa sugli atti non ripetibili (art. 360 c.p.p. ed art. 117 disp. att. c.p.p.) tende a:

  • evitare che le prove “urgenti” vengano disperse;
  • garantire il rispetto del principio del contraddittorio (art. 111 Cost.);

Presupposti:

  • indifferibilità = ora o mai più (art. 354 c.p.p.) “se non lo fai subito non lo puoi più fare”, cioè l’inerzia la prova andrebbe comunque dispersa;
  • non reiterabilità = ora e mai più (art. 360 c.p.p.) “se lo fai non lo puoi più fare”, cioè l’attività che si compie comporta, necessariamente o con un’elevata probabilità, l’alterazione o la distruzione della fonte di prova.

dd vs dcfldd vs dc3dd

Un “prontuario” pratico su dd, dcfldd e dc3dd per l’uso in digital forensics: differenze, buone prassi e comandi pronti all’uso.

dd (GNU coreutils)

Strumento standard Unix/Linux per copiare e convertire file, ma privo di funzionalità avanzate come il calcolo di checksum multipli, più file di output o una modalità di verifica. In pratica:

  • copia byte-per-byte da/un device o file (immagini “raw” .dd);
  • è ovunque (Linux, macOS, molti live-CD);
  • fa poche cose, bene: per hashing, split, log ecc. bisogna usare altri tool (es. sha256sum, split, pv).

dcfldd (forensic dd)

dcfldd è un fork avanzato di dd, sviluppato dal Dipartimento della Difesa degli Stati Uniti per scopi di informatica forense. Le differenze chiave sono che dcfldd offre la possibilità di specificare più file di output, calcola checksum multipli simultaneamente, include una modalità di verifica per confrontare file e visualizza una percentuale di avanzamento del processo, tutte funzionalità non disponibili in dd. Quindi, in pratica:

  • hashing on-the-fly (hash=sha256/sha1/md5/sha512) con salvataggio automatico (hashlog=);
  • log degli errori e dei settori danneggiati (errlog=);
  • progress/stato periodico (statusinterval=);
  • split automatico in chunk forensi (ofsplit=) e output multipli (più of= nella stessa acquisizione);
  • verifica post-acquisizione contro l’originale (vf=/verifyfile=);
  • pattern write (es. bonifica con pattern=00) — utile per sanificare dischi di destinazione, non per l’evidenza.

In breve: dd è minimale e universalmente disponibile; dcfldd riduce gli errori operativi e velocizza le procedure forensi (hash, log, split, verifica) in un solo passaggio.

Buone prassi prima di acquisire

  • Write-blocker hardware (preferibile). Se non disponibile, montare read-only:
# 1) Elenca dischi con flag RO
lsblk -o NAME,RO,SIZE,TYPE,MODEL,SERIAL

# 2) Imposta sola lettura (sul device intero, non sulla partizione)
sudo blockdev --setro /dev/sdX

# 3) Verifica che sia in sola lettura (1 = RO abilitato)
sudo blockdev --getro /dev/sdX

# 4) Rivedi lo stato
lsblk -d -o NAME,RO,SIZE,MODEL,SERIAL
----
Per tornare R/W:
sudo blockdev --setrw /dev/sdX
  • Identifica il device giusto e fotografa lo stato: sudo fdisk -l /dev/sdX
  • Prepara la cartella di caso con naming coerente (case ID, data ISO, operatore).
  • Registra in un log: modello/seriale supporto, hash pre/post, tool/parametri, orari, errori e contromisure.

Esempi con dd (baseline)

1) Acquisizione raw con gestione errori e progresso

sudo dd if=/dev/sdX of=/evidence/Caso123/disk.dd \
  bs=4M conv=noerror,sync status=progress iflag=fullblock
  • conv=noerror,sync: ignora errori di lettura e riempie con zeri per mantenere allineamento;
  • iflag=fullblock: evita letture parziali (utile con pipe/stream);
  • status=progress: barra di avanzamento (GNU dd).

2) Hash post-acquisizione (consigliato SHA-256)

cd /evidence/Caso123
sha256sum disk.dd | tee disk.dd.sha256.txt

Esempi con dcfldd (forensic-friendly)

1) Acquisizione + hash on-the-fly + log

sudo dcfldd if=/dev/sdX of=/evidence/Caso123/disk.dd \
  bs=4M conv=noerror,sync \
  hash=sha256 hashlog=/evidence/Caso123/disk.dd.sha256.txt \
  errlog=/evidence/Caso123/dcfldd.errors.log \
  statusinterval=30
  • un unico passaggio produce immagine + hash + log errori;
  • statusinterval=30: stampa stato ogni 30 s.

2) Doppia destinazione (originale + copia di lavoro)

sudo dcfldd if=/dev/sdX \
  of=/evidence/Caso123/disk.dd \
  of=/lab/Caso123/disk_working.dd \
  bs=4M conv=noerror,sync \
  hash=sha256 hashlog=/evidence/Caso123/disk.dd.sha256.txt \
  errlog=/evidence/Caso123/dcfldd.errors.log \
  statusinterval=30
  • Riduce l’eventuale rischio di divergenze tra “master” e “working copy” in caso di dispositivi danneggiati.

3) Split automatico in chunk (es. 2 GiB) per storage/FAT32

sudo dcfldd if=/dev/sdX of=/evidence/Caso123/disk.dd \
  bs=4M conv=noerror,sync \
  ofsplit=2G \
  hash=sha256 hashlog=/evidence/Caso123/disk.dd.sha256.txt \
  statusinterval=30
# Ricomposizione:
cat /evidence/Caso123/disk.dd.* > /restore/disk.dd

4) Verifica che immagine e device coincidano

# A freddo, con il device ancora in sola lettura:
sudo dcfldd if=/dev/sdX vf=/evidence/Caso123/disk.dd \
  hash=sha256 statusinterval=30
  • vf= (verify file) confronta i flussi (utile anche dopo trasferimenti/copie disk).

5) Log dettagliato dei settori danneggiati

sudo dcfldd if=/dev/sdX of=/evidence/Caso123/disk.dd \
  bs=512 conv=noerror,sync \
  errlog=/evidence/Caso123/badsectors.log \
  statusinterval=30
  • Con bs=512 ottieni il dettaglio settore-per-settore (più lento ma più preciso per i bad blocks).

Note operative e suggerimenti

  • Dimensione blocco (bs): 4M è un buon compromesso prestazioni/affidabilità. Per supporti instabili puoi scendere (1M o 512B) per aumentare la granularità dei retry/riempimenti;
  • cache OS: in alcuni contesti si usa oflag=direct/iflag=direct per bypassare la cache. Verifica che il tuo dd li supporti e valuta l’impatto sulle performance;
  • formati: dd/dcfldd producono RAW. Se il tuo flusso richiede E01/Ex01 (metadata + compressione + segmentazione nativa), usa gli strumenti libewf (ewfacquire) in alternativa;
  • conservazione: mantieni master immodificato; lavora sempre su una working copy verificata e documenta ogni passaggio;
  • sanificazione dei dischi di destinazione prima del riuso (non dell’evidenza!): # Esempio: azzera un disco di DESTINAZIONE sudo dcfldd if=/dev/zero of=/dev/sdY bs=4M pattern=00 statusinterval=30
  • ambienti non Linux: su Windows è comune operare da live Linux o appliance forense. In alternativa, considera tool dedicati (FTK Imager, ecc.) quando la policy lo consente.

Mini “cheat-sheet”

  • dd, acquisizione rapida + progress dd if=/dev/sdX of=case/img.dd bs=4M conv=noerror,sync status=progress iflag=fullblock sha256sum case/img.dd > case/img.dd.sha256.txt
  • dcfldd, acquisizione completa (hash+log) dcfldd if=/dev/sdX of=case/img.dd bs=4M conv=noerror,sync \ hash=sha256 hashlog=case/img.dd.sha256.txt errlog=case/errors.log statusinterval=30
  • dcfldd, split + doppia uscita + verifica dcfldd if=/dev/sdX of=case/img.dd of=/backup/img.dd \ ofsplit=2G bs=4M conv=noerror,sync \ hash=sha256 hashlog=case/img.dd.sha256.txt statusinterval=30 dcfldd if=/dev/sdX vf=case/img.dd hash=sha256 statusinterval=30

Cos’è dc3dd

dc3dd è una versione di dd patchata dal DoD Cyber Crime Center (DC3) pensata per la forensics. Aggiunge funzioni native come hashing on-the-fly (MD5/SHA-1/SHA-256/SHA-512), log dettagliati (anche machine-readable), split in segmenti, progress, error-logging raggruppato e funzioni di wipe/verify.

In più, a differenza di dcfldd (che è un fork), dc3dd è una patch di dd: in linea di massima segue gli aggiornamenti di dd e ha un set di opzioni diverso (non 1:1 con dcfldd).

Differenze chiave (dd vs dcfldd vs dc3dd)

  • dd (baseline): minimale e ovunque; per hash/split/log serve combinarlo con altri tool.
  • dcfldd (fork): pensato per DFIR; hash=… + hashlog=…, errlog=…, ofsplit=…, vf= per verifica contro l’originale; output multipli ripetendo of=.
  • dc3dd (patch): comandi e nomi opzioni propri:
  • Hashing: hash=md5|sha1|sha256|sha512; log in log= e/o hlog= (totali e piecewise), mlog= per log “machine-readable”.
  • Split: usa set di file con ofs=BASE.FMT + ofsz=BYTES (es. estensioni 0000, 0001, …); diverso da ofsplit= di dcfldd.
  • Output multipli & verifica: oltre a of= puoi usare hof=/hofs=: l’output viene hashato e verificato confrontando gli hash in/out; fhod= estende l’hash a tutto il device.
  • Error handling: di default, se l’input è un device, riempie di zeri i settori illeggibili; con rec=off si ferma al primo errore. (In dd/dcfldd l’equivalente pratico è conv=noerror,sync.)
  • Wipe/sanitize: wipe=/dev/sdY (zerofill o pattern), hwipe= con verifica post-wipe; puoi impostare pattern con pat=/tpat=.
  • Tuning: ssz= forza la sector size; bufsz= regola il buffer I/O per performance; verb=on per report verboso.

Esempi pratici con dc3dd (DFIR)

1) Imaging + hash + log (singolo file)

sudo dc3dd if=/dev/sdX of=/evidence/Caso123/disk.dd \
  hash=sha256 log=/evidence/Caso123/logs/dc3dd.log \
  hlog=/evidence/Caso123/logs/dc3dd.hashlog
  • Calcola SHA-256 on-the-fly e scrive log e hash (totali + piecewise).

2) Split in chunk da 2 GiB (naming automatico)

sudo dc3dd if=/dev/sdX ofs=/evidence/Caso123/disk.dd.0000 \
  ofsz=2G hash=sha256 \
  log=/evidence/Caso123/logs/dc3dd.log hlog=/evidence/Caso123/logs/dc3dd.hashlog
  • Usa ofs=BASE.FMT (qui 0000) e ofsz=2G per segmentare in disk.dd.0000, 0001, …

3) Master + working copy con verifica automatica

sudo dc3dd if=/dev/sdX \
  of=/evidence/Caso123/disk_master.dd \
  hof=/lab/Caso123/disk_working.dd \
  hash=sha256 log=/evidence/Caso123/logs/dc3dd.log hlog=/evidence/Caso123/logs/dc3dd.hashlog
  • hof= produce una copia con calcolo e verifica dell’hash rispetto all’input nella stessa passata.

4) Acquisizione con dischi “difficili” (settori e buffer)

sudo dc3dd if=/dev/sdX of=/evidence/Caso123/disk.dd \
  hash=sha256 ssz=512 bufsz=1M log=/evidence/Caso123/logs/dc3dd.log
  • Forza sector size a 512 B e limita il buffer per aumentare la resilienza su device instabili.

5) Sanificazione del disco di destinazione (non dell’evidenza!)

# Zero-fill con verifica
sudo dc3dd hwipe=/dev/sdY

# Wipe con pattern 0x00 (senza verifica)
sudo dc3dd wipe=/dev/sdY pat=00
  • Utile per preparare/bonificare i supporti di destinazione prima del riuso.

Quando preferirlo

  • Vuoi split flessibile con naming prevedibile (ofs + ofsz) e verifica integrata sugli output (hof/hofs).
  • Cerchi log ricchi (anche piecewise e machine-readable via mlog=) direttamente dal tool.

Note operative

  • Come per dcfldd, mantieni master e working copy separati e documenta hash/log nel fascicolo.
  • Puoi sostituire dcfldd con dc3dd mantenendo le stesse prassi (hash, split, log), adattando però i nomi opzione (ofsplit → ofs+ofsz, hashlog → hlog, verifica: vf → hof/hofs).

Confronto operativo (dd vs dcfldd vs dc3dd)

Attività / Featuredd (baseline)dcfldd (forensic fork)dc3dd (patch DC3)
Imaging RAWdd if=/dev/sdX of=img.dd bs=4M conv=noerror,sync status=progressdcfldd if=/dev/sdX of=img.dd bs=4M conv=noerror,sync statusinterval=30dc3dd if=/dev/sdX of=img.dd
Hash on-the-fly— (usa sha256sum dopo)hash=sha256 hashlog=img.sha256.txthash=sha256 hlog=hashes.txt (+ log= opzionale)
Log dettagliatireindirizza std{out,err}errlog=errors.log + output statolog=dc3dd.log (testuale), mlog=machine.log (machine-readable)
Split immagineesterno: split -b 2Gofsplit=2G → img.dd.000, .001…ofs=img.dd.0000 ofsz=2G → .0000, .0001…
Doppia uscita in una passata— (fai copia dopo)ripeti più of= nella stessa rigahof=working.dd (output con hash & verifica)
Verifica contro sorgenteesterno: ricalcolo hashvf=img.ddcon hof= verifica automaticamente la corrispondenza degli hash
Gestione settori danneggiaticonv=noerror,syncconv=noerror,syncriempie con zeri per default; puoi cambiare politica (fermarsi al primo errore)
Wipe/sanitize (solo dischi di destinazione)dd if=/dev/zero of=/dev/sdYpattern=00 su destinazionewipe=/dev/sdY (o hwipe= con verifica post-wipe)

Regola pratica: dd = portabilità + minimalismo; dcfldd = “tutto-in-uno” semplice (hash/log/split/verify); dc3dd = control-freak con log ricchi, split robusto e verifica integrata dell’output (hof).


Esempi pratici

1) Imaging con hash e log

dcfldd

sudo dcfldd if=/dev/sdX of=case/disk.dd bs=4M conv=noerror,sync \
  hash=sha256 hashlog=case/logs/disk.sha256.txt errlog=case/logs/errors.log \
  statusinterval=30

dc3dd

sudo dc3dd if=/dev/sdX of=case/disk.dd \
  hash=sha256 hlog=case/logs/dc3dd.hashlog log=case/logs/dc3dd.log

2) Split a 2 GiB

dcfldd

sudo dcfldd if=/dev/sdX of=case/disk.dd ofsplit=2G \
  hash=sha256 hashlog=case/logs/disk.sha256.txt
# join:  cat case/disk.dd.* > case/disk.dd

dc3dd

sudo dc3dd if=/dev/sdX ofs=case/disk.dd.0000 ofsz=2G \
  hash=sha256 hlog=case/logs/dc3dd.hashlog
# join:  cat case/disk.dd.0* > case/disk.dd

3) Master + working copy, una sola passata

dcfldd

sudo dcfldd if=/dev/sdX of=case/disk_master.dd of=lab/disk_working.dd \
  hash=sha256 hashlog=case/logs/disk.sha256.txt

dc3dd (con verifica integrata dell’output)

sudo dc3dd if=/dev/sdX of=case/disk_master.dd \
  hof=lab/disk_working.dd \
  hash=sha256 hlog=case/logs/dc3dd.hashlog log=case/logs/dc3dd.log

4) Bonifica del destinazione (non dell’evidenza!)

dcfldd

sudo dcfldd if=/dev/zero of=/dev/sdY bs=4M pattern=00 statusinterval=30

dc3dd

sudo dc3dd hwipe=/dev/sdY    # wipe + verifica
# oppure:
sudo dc3dd wipe=/dev/sdY     # wipe senza verifica

“Option mapping” veloce

Hashing

  • dd → sha256sum img.dd > img.dd.sha256.txt (post-acq)
  • dcfldd → hash=sha256 hashlog=FILE
  • dc3dd → hash=sha256 hlog=FILE (+ log=/mlog=)

Split

  • dd → split -b 2G img.dd img.dd.
  • dcfldd → ofsplit=2G → img.dd.000, .001…
  • dc3dd → ofs=img.dd.0000 ofsz=2G → .0000, .0001…

Doppia uscita

  • dd → cp/rsync dopo
  • dcfldd → più of= nella stessa riga
  • dc3dd → hof= / hofs= (con hashing/verifica)

Verifica

  • dd → ricalcolo hash device vs file
  • dcfldd → vf=img.dd
  • dc3dd → con hof= l’output è verificato contro l’input

Errori lettura

  • dd / dcfldd → conv=noerror,sync
  • dc3dd → default riempie gli errori con zeri; modalità “stop on first error” selezionabile