Un accesso risulta avvenuto alle 10:15, ma il documento cui viene confrontato riporta le 12:15. Prima di concludere che i fatti siano incompatibili, bisogna sapere a quale riferimento temporale corrispondano le due registrazioni. Nei procedimenti per accesso abusivo, la cronologia può incidere sull’attribuzione, sull’esistenza dell’autorizzazione e sulla sequenza delle operazioni.
Il problema non consiste nel presumere che i log siano errati. Consiste nel rendere verificabile il loro significato. Un numero accompagnato da una data diventa un elemento utilizzabile per il confronto quando sono noti il sistema che lo ha prodotto, il tipo di evento e le eventuali trasformazioni applicate nell’esportazione.
Quale evento è stato registrato
Occorre distinguere l’ora di autenticazione dall’ora di un’operazione e dall’ora in cui un registro è stato raccolto o esportato. Se l’accusa riguarda un accesso dopo la revoca di un incarico, il riferimento deve essere collegato all’evento pertinente. La data di estrazione del file non indica quando sia avvenuto l’ingresso nel sistema.
Il difensore può chiedere che siano spiegati i campi presenti nel registro e la funzione dell’applicazione che li genera. Una colonna denominata «ultimo accesso» non si interpreta soltanto attraverso il suo nome. Vanno esaminati il significato previsto dal sistema, l’eventuale aggiornamento automatico e il modo in cui quel valore è stato utilizzato nella relazione investigativa.
UTC, ora locale e scostamento indicato
Un registro può esprimere il tempo in UTC oppure in un’ora locale accompagnata dallo scostamento rispetto a UTC. Nel formato descritto dalla RFC 3339, un valore come 10:15 con scostamento +02:00 corrisponde alle 08:15 UTC. Due valori numericamente diversi possono quindi indicare il medesimo istante. Questo esempio è puramente illustrativo e presuppone che lo scostamento sia effettivamente documentato.
Non va attribuito d’ufficio un fuso a una registrazione che non lo specifica. Il consulente può verificare configurazione del sistema, documentazione dell’esportazione e impostazioni utilizzate per visualizzare i dati. Anche una schermata può presentare un tempo trasformato dall’interfaccia: il confronto richiede di conoscere il rapporto fra il dato conservato e quello mostrato.
Fuso corretto e orologio sincronizzato non sono la stessa cosa
Un sistema può conoscere il proprio riferimento temporale e avere comunque un orologio non correttamente sincronizzato. La RFC 5424, relativa ai messaggi syslog, distingue informazioni sul fuso e sulla sincronizzazione; prevede anche dati facoltativi sull’accuratezza. Non tutti i registri adottano però quel protocollo o contengono quelle informazioni.
La verifica deve riguardare il sistema effettivo. Sono pertinenti, quando disponibili, configurazioni, registri della sincronizzazione e documentazione di anomalie. Non è sufficiente osservare che un errore di orologio è teoricamente possibile. Occorre stabilire se esistano elementi che lo mostrino e quanto possa incidere sul confronto concreto.
Precisione del dato e margine del confronto
Un registro che esprime soltanto minuti consente verifiche diverse da uno che include secondi o frazioni di secondo. Inoltre, il numero di cifre visualizzato non prova di per sé l’accuratezza dell’orologio. La difesa deve distinguere precisione della rappresentazione e attendibilità della misura, evitando conclusioni più dettagliate di quanto permettano le informazioni disponibili.
Se la contestazione dipende da pochi secondi di differenza, il margine deve essere spiegato. Un confronto con registri di un altro sistema richiede di verificare entrambi gli orologi. La coincidenza o la divergenza va riferita agli eventi comparabili e ai rispettivi limiti; non basta disporre le righe in ordine numerico per ottenere una sequenza certa.
Origine dei registri e passaggi di elaborazione
Il materiale può provenire da un servizio, da un dispositivo o da una piattaforma che raccoglie registri di più componenti. Occorre distinguere il tempo indicato dalla fonte da quello di ricezione nel sistema di raccolta. La documentazione tecnica sul trattamento dei log, compresa la guida NIST SP 800-92, considera rilevanti sincronizzazione e normalizzazione proprio per collegare eventi provenienti da fonti diverse.
La relazione dovrebbe rendere riconoscibili le conversioni compiute e conservare il collegamento con i dati acquisiti. Un’esportazione in un formato diverso può essere necessaria per l’analisi; bisogna però capire quali valori siano originali e quali derivino da un’elaborazione. Se una conversione cambia anche il giorno indicato, la cronologia va ricostruita sull’istante effettivo.
La cronologia rispetto all’autorizzazione e all’attribuzione
L’art. 615-ter c.p. riguarda un’introduzione abusiva o una permanenza contro la volontà di chi può escludere l’utilizzatore. Quando l’episodio è confrontato con un permesso temporaneo o una revoca, il momento delle due vicende deve risultare omogeneo. Anche i documenti dell’autorizzazione hanno una fonte temporale da verificare: invio, ricezione e decorrenza dichiarata possono essere diversi.
Per l’attribuzione personale, la cronologia può essere confrontata con la disponibilità del dispositivo o altri dati pertinenti. Non ogni discordanza prova che abbia operato un’altra persona; non ogni coincidenza identifica l’autore. Il significato dipende dal collegamento fra il singolo evento e gli elementi su cui si fonda la ricostruzione.
Che cosa chiedere nel procedimento
Una richiesta utile può individuare i registri originali, il periodo, i campi temporali e la documentazione della configurazione. Può inoltre chiedere che siano chiariti eventuali scostamenti e conversioni utilizzati nella relazione. L’art. 247 c.p.p. impone, nella perquisizione informatica, misure per conservare i dati originali e impedirne l’alterazione; l’art. 254-bis riguarda le copie acquisite presso fornitori.
Il consulente tecnico può descrivere una cronologia con il relativo margine di incertezza, mantenendo distinguibili fatti registrati e inferenze. La difesa collega queste osservazioni al punto dell’accusa interessato. Non esiste un automatismo per cui un problema temporale annulli ogni dato: bisogna spiegare quali confronti rimangano affidabili e quali richiedano ulteriori accertamenti.
I registri disponibili devono essere conservati nel loro contesto, senza correggerli per farli coincidere con altre fonti. Nel giudizio, la prova della colpevolezza è valutata oltre ogni ragionevole dubbio ai sensi dell’art. 533 c.p.p. Una cronologia controllabile aiuta a discutere la ricostruzione concreta, evitando di trattare come certa un’informazione temporale della quale non sia stato chiarito il significato.
Per il quadro generale della materia, il sito contiene anche la guida sull’accesso abusivo a un sistema informatico.
Fonti normative e istituzionali
Codice penale, articolo 615-ter — testo vigente all’11 ottobre 2026; Codice di procedura penale, articolo 247 — testo vigente all’11 ottobre 2026; Codice di procedura penale, articolo 254-bis — testo vigente all’11 ottobre 2026; Codice di procedura penale, articolo 533 — testo vigente all’11 ottobre 2026; IETF, RFC 3339, sezioni 4 e 5: riferimento UTC e scostamenti temporali; IETF, RFC 5424, sezioni 6.2.3 e 7.1: timestamp e qualità del tempo; NIST SP 800-92, Guide to Computer Security Log Management: normalizzazione e sincronizzazione. Fonti consultate il 10 ottobre 2026.
Il contenuto ha finalità informativa. La valutazione della singola posizione richiede l’esame degli atti e delle circostanze concrete.
Informazioni e recapiti dello Studio
Avv. Davide Tutino · Studio Legale Tutino · Foro di Catania. Per informazioni sull’assistenza difensiva nei procedimenti penali: 095 9991325, 392 3838383 · davide@tutino.sicilia.it. Sede e informazioni professionali nella pagina dello Studio a Catania.
Revisione giuridica ed editoriale: 11 ottobre 2026.
