Un SIEM raccoglie chi apre un file, chi lo condivide, chi lo cancella. È esattamente ciò che serve per rispondere a un incidente — ed è anche, sul piano giuridico, un trattamento di dati personali dei dipendenti che può configurare un controllo a distanza dell’attività lavorativa. Molte aziende scoprono il problema tardi: a piattaforma già installata, quando il legale o il DPO chiede chi può leggere quei log e con quali garanzie. Vediamo cosa prevede la normativa e come si può monitorare l’infrastruttura senza rinunciare alla tutela delle persone.
In sintesi
- Il problema non è raccogliere i log, ma chi può risalire alle persone. Un SIEM installato con impostazioni predefinite mostra nomi ed email in chiaro a chiunque acceda alla dashboard.
- Il quadro normativo è duplice: art. 4 dello Statuto dei Lavoratori (accordo sindacale o autorizzazione dell’Ispettorato) e GDPR (minimizzazione, privacy by design, sicurezza del trattamento).
- NIS2 chiede logging e detection, ma non sospende le tutele del diritto del lavoro: i due piani vanno tenuti insieme, non in alternativa.
- La pseudonimizzazione all’origine risolve il conflitto: il monitoraggio resta pienamente efficace, l’identità diventa accessibile solo tramite una procedura formale e tracciata.
Lo scenario: quando il SIEM diventa uno strumento di controllo
La situazione tipica è questa. Un’azienda apre l’accesso ai dati aziendali dall’esterno — sposta il file server su Google Workspace o Microsoft 365, abilita il lavoro da remoto — e insieme all’apertura introduce un sistema di raccolta e correlazione dei log. L’obiettivo è legittimo e, in molti casi, doveroso: sapere cosa succede ai dati aziendali, poter ricostruire un incidente, accorgersi di una condivisione anomala verso l’esterno o di una cancellazione massiva di file.
Il risultato tecnico funziona. Il problema emerge quando si guarda la dashboard: accanto a ogni evento compaiono nome, cognome ed email del dipendente. Chiunque abbia accesso alla console — l’amministratore di rete, un tecnico del fornitore, in prospettiva chiunque ottenga quelle credenziali — può ricostruire l’attività quotidiana di una persona specifica: a che ora ha aperto il primo documento, quanti file ha modificato, con chi ha condiviso cosa.
Nessuno ha progettato uno strumento di sorveglianza. Ma uno strumento che consente quella sorveglianza è stato installato, e sul piano giuridico è questo che conta.
Cosa prevede la normativa
Art. 4 dello Statuto dei Lavoratori
L’art. 4 della Legge 300/1970, nella formulazione introdotta dal D.Lgs. 151/2015, stabilisce che gli impianti e gli strumenti dai quali derivi anche la possibilità di controllo a distanza dell’attività dei lavoratori possono essere impiegati esclusivamente per esigenze organizzative e produttive, per la sicurezza del lavoro e per la tutela del patrimonio aziendale. E possono essere installati solo previo accordo con le rappresentanze sindacali oppure, in mancanza, previa autorizzazione dell’Ispettorato nazionale del lavoro.
Due aspetti sono spesso sottovalutati. Il primo: la norma parla di possibilità di controllo, non di intenzione. Non rileva che l’azienda non voglia sorvegliare nessuno — rileva che lo strumento lo renda possibile. Il secondo: il comma 3 subordina l’utilizzabilità delle informazioni raccolte, a tutti i fini connessi al rapporto di lavoro, all’adeguata informativa ai lavoratori sulle modalità dei controlli e al rispetto della disciplina privacy. Dati raccolti fuori da queste condizioni rischiano di essere inutilizzabili proprio nel momento in cui servirebbero: in un contenzioso o in un procedimento disciplinare.
Nota sui “controlli difensivi”. La Corte di Cassazione (sez. lavoro, sent. 22 settembre 2021 n. 25732) ha distinto i controlli sull’attività lavorativa — soggetti all’art. 4 — dai controlli difensivi in senso stretto, mirati ad accertare condotte illecite specifiche già oggetto di fondato sospetto e svolti ex post. Questi ultimi restano fuori dall’ambito dell’art. 4, ma la Corte ha ribadito che ciò non autorizza alcun annullamento delle tutele di dignità e riservatezza del lavoratore. La distinzione, in altre parole, non è una scorciatoia: è un perimetro stretto e va documentata.
GDPR: minimizzazione, privacy by design, sicurezza
Sul versante protezione dati, il Regolamento UE 2016/679 interviene su più fronti:
- Art. 5 — principi di minimizzazione e limitazione della conservazione: si trattano i dati adeguati, pertinenti e limitati a quanto necessario, per il tempo necessario.
- Art. 25 — protezione dei dati fin dalla progettazione e per impostazione predefinita: la pseudonimizzazione è citata espressamente come misura attuativa.
- Art. 32 — sicurezza del trattamento: la pseudonimizzazione compare tra le misure tecniche adeguate al rischio.
- Art. 35 — valutazione d’impatto (DPIA): il monitoraggio sistematico di dati relativi ai lavoratori rientra tipicamente tra i trattamenti che la richiedono.
- Art. 88 — trattamento dei dati nel contesto lavorativo, che rinvia alle norme nazionali più specifiche: nel nostro ordinamento, l’art. 114 del Codice privacy richiama proprio il rispetto dell’art. 4 dello Statuto.
Sul tema della pseudonimizzazione, l’EDPB è intervenuto con apposite linee guida (01/2025), chiarendone il ruolo di misura tecnica in grado di ridurre i rischi per gli interessati pur mantenendo l’utilità del trattamento.
L’orientamento del Garante sui metadati
Un riferimento utile per capire quanto il tema sia attuale è il Documento di indirizzo del Garante privacy del 6 giugno 2024 (doc. web n. 10026277) sui programmi di gestione della posta elettronica e sul trattamento dei metadati. L’Autorità ha indicato che la raccolta e conservazione dei metadati di posta elettronica necessari al funzionamento del servizio dovrebbe di norma restare entro un periodo limitato — indicato in 21 giorni — precisando che una conservazione più prolungata può configurare una forma di controllo a distanza dell’attività dei lavoratori, con conseguente applicazione delle garanzie procedurali dell’art. 4.
Il principio che se ne ricava vale ben oltre la posta elettronica: più a lungo si conservano dati che permettono di ricostruire l’attività di una persona, più il trattamento si avvicina alla nozione di controllo a distanza. Ed è esattamente ciò che fa, per definizione, un sistema di log management.
Il paradosso: NIS2 chiede di loggare, il diritto del lavoro chiede di limitare
Qui molte organizzazioni si trovano in una posizione apparentemente senza uscita. La Direttiva NIS2 (UE 2022/2555), recepita in Italia con il D.Lgs. 138/2024, richiede ai soggetti in perimetro misure di gestione del rischio che includono il logging, il rilevamento degli incidenti e la capacità di ricostruirli. Gli standard di riferimento vanno nella stessa direzione: la ISO/IEC 27001:2022 dedica ai log e al monitoraggio i controlli 8.15 e 8.16.
Da un lato quindi un obbligo di raccogliere e conservare. Dall’altro un vincolo a non trasformare quella raccolta in sorveglianza. Il conflitto, però, è solo apparente: le due esigenze diventano incompatibili unicamente se si dà per scontato che i log debbano contenere identità in chiaro. È quell’assunto, non la normativa, a creare il problema.
La soluzione: pseudonimizzare all’origine
L’approccio che adottiamo in Cyberdef parte da una domanda diversa: perché il SIEM dovrebbe conoscere l’identità delle persone? Per correlare eventi, rilevare comportamenti anomali e far scattare gli alert, un sistema di sicurezza ha bisogno di sapere che una certa persona ha compiuto una serie di azioni — non di sapere quale persona sia.
Su questa base abbiamo realizzato una soluzione che trasforma i dati identificativi prima che raggiungano la piattaforma di monitoraggio. Nel SIEM — dashboard, alert, archivi storici — al posto di nomi ed email compaiono identificativi stabili. Il dato in chiaro non viene mascherato a posteriori: semplicemente non entra.
La ri-identificazione resta possibile — è indispensabile per poter davvero rispondere a un incidente — ma diventa un procedimento, non un’operazione a portata di click:
- Richiesta motivata. Chi ha bisogno di risalire a una persona indica il caso e la ragione. La motivazione resta agli atti.
- Approvazione di un secondo referente. Nessuno può autorizzare la propria richiesta: servono due ruoli distinti, come previsto dai principi di separazione dei compiti.
- Accesso puntuale. Si ottiene l’identità relativa a quel singolo caso, non un accesso permanente all’anagrafica degli eventi.
- Tracciamento integrale. Ogni richiesta, approvazione e consultazione finisce in un registro non alterabile: anche chi effettua le verifiche è a sua volta verificabile.
Il registro delle identità risiede su un sistema separato e con amministrazione distinta rispetto alla piattaforma di monitoraggio. Questo dettaglio architetturale è ciò che rende la garanzia reale e non dichiarativa: non esiste un livello di privilegio, all’interno del SIEM, che consenta di aggirarla.
Il monitoraggio resta efficace
È l’obiezione che riceviamo più spesso: se non vedo i nomi, che detection faccio? La risposta è che gli identificativi sono stabili — la stessa persona corrisponde sempre allo stesso identificativo, mai a uno diverso, mai condiviso con altri. Tutto ciò che dipende dalla continuità dell’identità continua quindi a funzionare senza alcuna perdita:
- le soglie comportamentali — condivisioni di massa verso l’esterno, cancellazioni anomale, download fuori scala — scattano esattamente come prima;
- la correlazione tra fonti diverse (cloud, posta, endpoint, XDR) resta possibile, perché l’identificativo è lo stesso su tutte le sorgenti;
- l’analisi storica di un incidente si ricostruisce integralmente, e solo alla fine — se serve davvero — si passa alla ri-identificazione.
Cambia una cosa sola: chi guarda la dashboard vede un utente che ha cancellato 200 file in tre minuti, non quel collega. Per attivare la risposta all’incidente è sufficiente. Per sorvegliare qualcuno, no.
Ogni requisito, una garanzia
| Requisito | Come viene soddisfatto |
|---|---|
| Nessun controllo a distanza nell’operatività ordinaria art. 4 St. Lav. |
L’identità non è visibile a nessun operatore durante il normale utilizzo della piattaforma. |
| Minimizzazione e protezione fin dalla progettazione artt. 5, 25 e 32 GDPR |
La pseudonimizzazione è incorporata nell’architettura, non aggiunta come correttivo successivo. |
| Accesso all’identità solo per finalità legittime e documentate | Procedura con motivazione obbligatoria, doppia autorizzazione e accesso limitato al singolo caso. |
| Verificabilità di chi effettua i controlli | Registro non alterabile di ogni accesso, ancorato su archiviazione immutabile. |
| Capacità di rilevare e ricostruire gli incidenti NIS2 · ISO 27001 |
Detection, correlazione multi-fonte e conservazione dei log restano pienamente operative. |
A chi serve
Questo approccio è particolarmente indicato per organizzazioni che si trovano in una di queste situazioni:
- stanno aprendo l’accesso ai dati aziendali dall’esterno (migrazione a cloud, smart working) e vogliono accompagnare il passaggio con un’informativa trasparente ai dipendenti;
- hanno rappresentanze sindacali con cui negoziare l’accordo previsto dall’art. 4, e hanno bisogno di poter mostrare garanzie tecniche concrete e non solo impegni sulla carta;
- operano in settori regolamentati o rientrano nel perimetro NIS2, dovendo conciliare obblighi di logging e tutela dei lavoratori;
- hanno ricevuto un rilievo dal DPO o dal consulente legale su una piattaforma di monitoraggio già in produzione.
Vuoi capire come si applica alla tua organizzazione?
Analizziamo insieme le sorgenti che raccogli oggi, i vincoli posti dal tuo DPO o dal tuo legale e le garanzie tecniche necessarie. La soluzione è installabile sia on-premise sia in cloud, in funzione dei vincoli di trattamento.
Nota. Questo articolo ha finalità informative e non costituisce parere legale. La valutazione della conformità di un sistema di monitoraggio va sempre condotta caso per caso, con il coinvolgimento del Responsabile della protezione dei dati e del consulente giuslavorista, tenendo conto della concreta configurazione tecnica e organizzativa adottata.
