Protocollo informatico e GDPR: permessi errati, data breach e sanzione nel caso Sassari

Un data breach non nasce necessariamente da un attacco informatico. Può essere sufficiente un profilo utente configurato in modo troppo permissivo perché un documento riservato diventi accessibile a chi non è autorizzato a conoscerlo. È quanto emerge dal provvedimento dell’11 giugno 2026 con cui il Garante per la protezione dei dati personali ha sanzionato la Città Metropolitana di Sassari per 12mila euro. Una decisione che trasforma un errore apparentemente tecnico in una lezione concreta su privacy by default, minimizzazione e accountability.

Il 29 luglio 2026 il Garante per la protezione dei dati personali ha richiamato, nella propria Newsletter n. 550, un provvedimento adottato l’11 giugno 2026 nei confronti della Città Metropolitana di Sassari. Al centro della vicenda non vi è un’intrusione esterna, ma la configurazione non corretta dei profili di accesso al protocollo informatico dell’ente.

Il caso è particolarmente significativo perché dimostra che la sicurezza dei dati personali non coincide soltanto con la protezione da malware, ransomware o attacchi provenienti da Internet. Anche un’autorizzazione interna eccessiva può determinare una violazione di dati personali e un trattamento illecito.

Da una comunicazione riservata all’apertura dell’istruttoria

La vicenda ha riguardato una comunicazione relativa alla possibile rilevanza disciplinare della condotta di una dirigente. Il documento, qualificato come riservato, risultava consultabile all’interno del sistema di protocollo da una platea più ampia di quella necessaria.

Secondo quanto ricostruito nel provvedimento, la nota era potenzialmente visibile a 29 persone operanti nell’ente. Per 7 di esse, in particolare, era stato associato erroneamente un profilo destinato agli operatori dell’ufficio protocollo. L’anomalia non riguardava quindi soltanto il modo in cui era stato classificato il singolo documento, ma anche la corrispondenza tra ruolo organizzativo, mansioni e privilegi applicativi.

La violazione è stata portata all’attenzione del Responsabile della protezione dei dati e notificata al Garante all’inizio di aprile 2025. L’ente ha poi ridotto i privilegi, azzerato i profili e proceduto a una nuova configurazione delle utenze. La successiva correzione, tuttavia, non ha eliminato l’illiceità del trattamento già avvenuto.

Visibilità potenziale e accessi effettivi non sono la stessa cosa

Uno degli aspetti più rilevanti del caso riguarda la ricostruzione tecnica dell’incidente. Nel corso dell’istruttoria l’ente ha dichiarato di non poter stabilire quali soggetti avessero effettivamente consultato la nota, perché non erano disponibili le copie di backup dei file di log necessarie alla verifica.

Occorre quindi distinguere due piani:

1. l’accessibilità del documento, determinata dai privilegi assegnati agli utenti;
2. la consultazione effettiva, che avrebbe richiesto evidenze di logging utilizzabili e conservate secondo criteri coerenti con le finalità di sicurezza e controllo.

L’assenza della prova di un accesso effettivo da parte di ogni utente non ha reso lecita la configurazione. Per il Garante, il fatto che dati personali fossero accessibili a persone non autorizzate era già incompatibile con i principi applicabili. La tracciabilità, inoltre, non è utile soltanto per individuare responsabilità dopo un incidente: è essenziale per definire il perimetro della violazione, valutarne il rischio e dimostrare le attività svolte dal titolare.

Anche un collega può essere un “terzo” rispetto al trattamento

La decisione ricorda un principio spesso sottovalutato: l’appartenenza alla stessa organizzazione non autorizza automaticamente una persona a conoscere tutti i dati trattati dall’ente o dall’impresa.

Un dipendente o collaboratore che non abbia necessità di accedere a determinate informazioni in ragione delle proprie mansioni può essere considerato, rispetto a quello specifico trattamento, un soggetto non autorizzato. La consultabilità interna di un documento riservato può quindi tradursi in una comunicazione illecita di dati personali, anche se le informazioni non sono mai uscite dal perimetro informatico dell’organizzazione.

Da qui discende la necessità di collegare le abilitazioni non a categorie generiche di utenti, ma a funzioni effettive, uffici, responsabilità e specifiche esigenze operative.

I principi GDPR richiamati dal Garante

Il Garante ha rilevato la violazione di un insieme articolato di disposizioni. Il nucleo della decisione riguarda:

3. la liceità del trattamento;
4. la minimizzazione dei dati e della loro accessibilità;
5. l’integrità e la riservatezza;
6. il principio di responsabilizzazione del titolare;
7. la protezione dei dati fin dalla progettazione e per impostazione predefinita;
8. le condizioni applicabili ai dati appartenenti a categorie particolari e ai dati relativi a reati.

Il provvedimento richiama, tra gli altri, gli articoli 5, 6, 9, 10 e 25 del GDPR, oltre alle pertinenti disposizioni del Codice privacy italiano. È importante osservare che, nel dispositivo, l’Autorità non ha qualificato la vicenda attraverso una contestazione autonoma dell’articolo 32 GDPR. Il fulcro giuridico è stato individuato soprattutto nella scorretta progettazione e configurazione dell’accessibilità, nella mancanza di coerenza tra autorizzazioni e mansioni e nella conseguente conoscibilità dei dati da parte di soggetti non legittimati.

Questa precisazione evita di ridurre il caso a una formula generica come “misure di sicurezza inadeguate”: la decisione riguarda il modo in cui la protezione dei dati deve essere incorporata nella struttura del sistema e nei processi organizzativi.

Privacy by default significa accesso necessario, non accesso comodo

L’articolo 25 GDPR richiede che, per impostazione predefinita, siano trattati soltanto i dati personali necessari per ciascuna finalità. Il principio riguarda anche l’accessibilità delle informazioni.

In un sistema documentale, ciò significa che il profilo iniziale non dovrebbe offrire la visibilità più ampia per poi demandare agli utenti il compito di evitare documenti non pertinenti. Il modello corretto parte dal perimetro minimo necessario e amplia i privilegi soltanto quando esiste una funzione che lo giustifica.

Il Garante aveva già indicato, nelle Linee guida del 14 giugno 2007 sul trattamento dei dati dei lavoratori pubblici, la necessità di prevenire la conoscibilità ingiustificata delle informazioni relative al rapporto di lavoro. Nel provvedimento del 2026 l’Autorità ribadisce che, per i documenti relativi ai dipendenti, possono essere necessarie procedure di protocollazione differenziate o riservate.

La correzione tempestiva è importante, ma non cancella la violazione

Dopo la segnalazione, l’ente ha adottato misure correttive, riducendo i privilegi e riconfigurando le utenze. Il Garante ne ha tenuto conto insieme alla collaborazione offerta nel corso dell’istruttoria, all’assenza di precedenti pertinenti e al fatto che, nel periodo interessato, era in corso una migrazione organizzativa e informatica.

Questi elementi hanno inciso sulla quantificazione della sanzione, fissata in 12mila euro. Non hanno però escluso la responsabilità per il trattamento illecito già realizzato. Il principio operativo è chiaro: intervenire rapidamente limita gli effetti dell’incidente e può essere valutato favorevolmente, ma la conformità deve essere costruita prima che i dati diventino accessibili oltre il necessario.

Cosa dovrebbero verificare enti e imprese

Il caso riguarda una pubblica amministrazione e alcune delle basi giuridiche richiamate sono proprie del settore pubblico. I principi relativi a minimizzazione, integrità, riservatezza, accountability e privacy by design/default hanno però portata generale e interessano anche le organizzazioni private.

Una verifica efficace dei sistemi di gestione documentale dovrebbe includere almeno:

1. Mappatura di ruoli e autorizzazioni: ogni profilo deve corrispondere alle mansioni effettive e alle categorie di documenti necessarie.
2. Applicazione del principio del minimo privilegio: l’accesso più ampio deve essere un’eccezione motivata, non l’impostazione ordinaria.
3. Flussi separati per i documenti riservati: dati sanitari, disciplinari, giudiziari e altre informazioni delicate richiedono procedure e livelli di visibilità specifici.
4. Revisioni periodiche e controlli in occasione dei cambiamenti: migrazioni, riorganizzazioni, trasferimenti di personale e variazioni di mansione devono attivare una revisione dei privilegi.
5. Logging adeguato e verificabile: i log devono permettere di ricostruire gli accessi, con tempi di conservazione definiti sulla base delle finalità e dei rischi, senza trasformarsi in strumenti di controllo indiscriminato dei lavoratori.
6. Test delle configurazioni: non basta documentare il modello autorizzativo; occorre verificare periodicamente ciò che i diversi profili possono realmente visualizzare, scaricare e modificare.
7. Gestione coordinata degli incidenti: area IT, responsabili di processo, DPO e vertici organizzativi devono sapere chi valuta l’evento, chi contiene la violazione e chi decide gli adempimenti previsti dagli articoli 33 e 34 GDPR.

Questa checklist costituisce una traduzione operativa dei principi applicabili e non una riproduzione delle prescrizioni del provvedimento. Le misure concrete devono essere selezionate in funzione del contesto, della natura dei dati, dell’architettura del sistema e dei rischi per gli interessati.

La lezione del caso Sassari

La decisione mostra che il controllo degli accessi non è un semplice compito di amministrazione tecnica. È un elemento sostanziale della conformità al GDPR.

Un sistema può essere protetto verso l’esterno e rimanere comunque non conforme se consente, al proprio interno, una visibilità più ampia di quella giustificata. Per questo autorizzazioni, log, processi riservati e revisioni periodiche devono essere governati congiuntamente: la protezione dei dati non dipende soltanto dalla presenza di uno strumento, ma dalla qualità delle scelte con cui viene configurato e utilizzato.