GDPR · Amministratore di sistema · Servizi in cloud · Enti e imprese

Amministratore di sistema: il GDPR non lo nomina mai, e proprio per questo va riscritto

Il Regolamento europeo non contiene l'espressione "amministratore di sistema" e non ha mai imposto di nominarne uno. L'obbligo, in Italia, viene da un provvedimento del Garante del 2008 che è ancora vigente. Nel frattempo il cloud ha portato via metà dei compiti storici di quella figura, e in moltissime organizzazioni, pubbliche e private, l'atto di nomina è fermo a prima del maggio 2018. Non è decaduto: è diventato la fotografia di un'infrastruttura che non esiste più. Proviamo a fare ordine, da Responsabile della Protezione dei Dati (DPO).

DPO di Marco La Diega · Agosto 2026 · Lettura 11 min

Un problema diffuso, non un caso isolato

Partiamo da un dato che chi lavora sulla protezione dei dati conosce bene, e che vale allo stesso modo per un comune e per un'azienda: una quota molto ampia degli atti di nomina dell'Amministratore di Sistema oggi presenti negli archivi è stata adottata prima del maggio 2018.

Non è un dettaglio anagrafico, ma va detto con precisione, perché su questo punto circola molta confusione. Quegli atti si collocano nel quadro normativo anteriore al GDPR, quello del D.Lgs. 196/2003 e delle sue "misure minime di sicurezza", il cui riferimento tecnico era l'Allegato B del Codice. E quell'Allegato B non c'è più: è stato abrogato dall'art. 27, comma 1, lettera d), del D.Lgs. 10 agosto 2018, n. 101.

Attenzione però a cosa è caduto, perché qui sta l'equivoco che sento ripetere più spesso. È caduto il disciplinare tecnico con l'elenco delle misure minime, non l'obbligo di designare chi amministra i sistemi. Il provvedimento del Garante del 27 novembre 2008 sugli amministratori di sistema non era parte dell'Allegato B, quindi l'abrogazione non lo ha toccato. Ci torniamo tra poco.

Il problema di quegli atti, quindi, non è la validità formale. È il contenuto. Descrivono un perimetro tecnico che nella maggior parte dei casi non esiste più, non sono mai stati riesaminati, e quasi mai sono accompagnati da ciò che li renderebbe una misura di sicurezza effettiva. Sopravvivono per inerzia, come quelle cartelle condivise che nessuno cancella perché non si sa mai.

Il secondo effetto dell'inerzia è più tecnico e più interessante. Un atto di nomina non aggiornato non porta con sè quello che oggi rende quella figura effettivamente conforme: il registro degli amministratori, la tracciatura degli accessi privilegiati, il riesame periodico delle abilitazioni. E senza quelli, l'atto è una firma su un foglio, non un presidio.

Chi risponde oggi di una nomina firmata ieri

Il titolare del trattamento non è il sindaco, il direttore generale o l'amministratore delegato: è l'organizzazione. Le persone fisiche che la rappresentano lo fanno pro tempore. Per questo un atto di designazione non decade quando cambiano i vertici: resta valido fino a quando non viene revocato, aggiornato o sostituito. Chi spera che la nomina del 2006 sia "scaduta" con l'insediamento della nuova giunta, o con il nuovo consiglio di amministrazione, resterà deluso.

Nel settore pubblico questo produce l'effetto più vistoso, perché la continuità dell'ente e la scarsa abitudine a riesaminare gli incarichi tecnici fanno sopravvivere atti di vent'anni fa. Nell'impresa il principio è identico, ma la prassi di rinnovare deleghe e incarichi al cambio di gestione rende il fenomeno meno frequente. Meno frequente, non assente: i mandati commerciali si rinnovano, quelli tecnici quasi mai.

Il problema è l'altro lato della stessa medaglia. Se l'atto resta in piedi, allora il principio di responsabilizzazione di cui all'art. 5, par. 2, del GDPR resta in capo al titolare, esercitato attraverso il suo rappresentante legale attuale.

Il rappresentante legale in carica oggi risponde di una designazione che non ha firmato, che probabilmente non ha mai letto, e che attribuisce privilegi amministrativi su tutti i sistemi dell'organizzazione a un soggetto che nessuno ha più riconfermato.

E la designazione di un amministratore di sistema non è un atto neutro, per una ragione che sta scritta nel provvedimento del 2008: l'attribuzione delle funzioni deve avvenire previa valutazione dell'esperienza, della capacità e dell'affidabilità del soggetto designato, che deve offrire idonea garanzia del rispetto della normativa, sicurezza compresa. Il che è ragionevole, dato che quell'attribuzione consegna a una persona la possibilità tecnica di accedere a qualunque dato trattato, compresi quelli sanitari, giudiziari e relativi al personale.

Quindi la designazione non è una firma: è un giudizio. E un giudizio formulato vent'anni fa, su un contesto tecnico che non esiste più e mai riesaminato da allora, non è un giudizio consolidato. È un giudizio dimenticato.

Non serve un colpo di scena giuridico per rimettere le cose in ordine. Serve fare quello che il provvedimento del 2008 chiede da sempre e che quasi nessuno fa: la verifica almeno annuale dell'operato, con esito documentato. Se quella verifica esiste, l'atto del passato è vivo e vegeto. Se non esiste, il rappresentante legale attuale ha ereditato una posizione di rischio senza esserne mai stato informato.

Il rischio della concentrazione

C'è poi una questione di architettura, non di persone. Quando i privilegi amministrativi su tutti i sistemi restano stabilmente in capo a un'unica utenza, viene meno la possibilità di una verifica indipendente e quella di ricostruire chi ha fatto cosa. È un rischio tecnico: il problema è il disegno, non chi lo occupa.

E si corregge con due misure che il GDPR chiede comunque: privilegio minimo (ciascuno accede solo a ciò che gli serve) e riesame periodico delle abilitazioni, con evidenza documentale.

Quando la figura aveva perfettamente senso

Chiariamo subito una cosa: negli anni Novanta e Duemila l'amministratore di sistema era una figura necessaria, non un vezzo burocratico.

C'era il CED (Centro Elaborazione Dati) in casa. Server fisici in una stanza con il condizionatore che d'estate faceva paura. Centralino IP da configurare. Antivirus da aggiornare macchina per macchina. Dischi di archiviazione in sede. Nastri con le copie di sicurezza da portare via il venerdì.

In quel mondo, se il server cadeva era un problema vostro, e se un virus entrava in rete era colpa della configurazione fatta in casa. L'amministratore di sistema si occupava di:

• continuità operativa, cioè tenere i servizi accesi anche quando qualcosa si rompe (macchine raddoppiate e commutazione automatica sulla riserva)
• copie di sicurezza e ripristino, decidendo quanti dati si è disposti a perdere e in quanto tempo si torna operativi (di solito stabiliti a occhio)
• sicurezza dell'infrastruttura (aggiornamenti correttivi, gestione degli accessi, registrazione delle attività, sorveglianza dei sistemi)
• pianificazione della capacità, cioè capire quando comprare il server nuovo
• ripristino dopo un evento disastroso, di solito documentato in un file aperto una volta sola

Tutto in casa. Il fornitore esterno, se c'era, faceva manutenzione correttiva e nulla più.

Era un ruolo verticale su un'infrastruttura verticale. Coerente.

Amministratore di sistema o amministratore dei sistemi?

Poi qualcosa si è rotto, e non è stato il cloud. È stata la moltiplicazione.

Perché oggi, in un comune come in un'azienda, non c'è "il sistema". Ci sono i sistemi, al plurale. E ognuno ha un suo pannello di amministrazione, un suo fornitore, un suo contratto:

• il gestionale documentale, di norma erogato come servizio in cloud e non installato in sede
• il centralino telefonico, che oggi viaggia sulla rete dati ed è un servizio di un operatore
• la posta elettronica e il sito istituzionale, su fornitori diversi
• la videosorveglianza, con il suo apparato locale e il suo manutentore
• contabilità, presenze, servizi a cittadini o clienti, ciascuno con il proprio applicativo e il proprio contratto
• le copie di sicurezza, che stanno in tre posti diversi e nessuno sa esattamente quali

Chiamare "amministratore di sistema" chi dovrebbe presidiare tutto questo è come chiamare "autista" chi coordina una flotta. Tecnicamente non è sbagliato. Praticamente non descrive il lavoro.

Se vogliamo essere precisi (e un filo ironici), la denominazione corretta oggi sarebbe amministratore dei sistemi. Plurale. Perché il singolare descrive un mondo che non esiste più da almeno dieci anni.

Cosa dice davvero il GDPR

E qui arriviamo alla parte che sorprende sempre chi la sente per la prima volta.

Il Regolamento UE 2016/679, il GDPR (General Data Protection Regulation), non contiene l'espressione "amministratore di sistema". Mai. Neanche una volta. Potete cercare: non c'è.

Quello che il GDPR prevede è un'architettura di responsabilità completamente diversa, costruita su due articoli.

Art. 28, il responsabile del trattamento. Se affidate infrastruttura o applicativi a un soggetto esterno, quel soggetto tratta dati per conto vostro e diventa responsabile del trattamento. È lui che amministra i sistemi che vi eroga, sulla base di un contratto che deve indicare cosa fa, come lo fa, con quali misure di sicurezza e cosa succede alla fine del rapporto. In pratica: l'amministratore di sistema esterno esiste, ma il GDPR lo chiama art. 28.

Art. 29, e art. 2-quaterdecies del Codice Privacy, i soggetti autorizzati. Chi accede ai dati dall'interno lo fa solo su istruzione del titolare, entro un perimetro definito per iscritto. Non serve una figura unica che controlla tutto: serve che ciascuno sia autorizzato a fare esattamente ciò che gli compete. In pratica: l'amministrazione interna esiste, ma il GDPR la distribuisce.

E sopra i due articoli c'è la norma che conta davvero, l'art. 32: impone di adottare misure tecniche e organizzative adeguate a garantire un livello di sicurezza adeguato al rischio, con riguardo a riservatezza, integrità, disponibilità e capacità di ripristino. È una norma volutamente neutrale dal punto di vista tecnologico: dice quale risultato ottenere, non quale figura nominare.

Il vecchio impianto del 196/2003 ragionava per adempimenti: c'è una lista di misure minime, c'è una figura che le presidia, si mette una firma e si è a posto. Il GDPR ragiona per responsabilizzazione (art. 5, par. 2): dimostrate di avere valutato il rischio e adottato misure adeguate, poi organizzate il presidio come vi serve.

Detto in modo brutale: il GDPR non ha mai chiesto l'amministratore di sistema. Chiede che i sistemi siano amministrati bene e che voi siate in grado di dimostrarlo. Che non è la stessa cosa, ed è molto più impegnativo.

E allora da dove viene l'obbligo? Il provvedimento del 2008

Domanda legittima: se il GDPR non lo nomina, perché nei documenti aziendali e degli enti l'amministratore di sistema c'è ancora, e perché il Garante continua a chiederlo?

Perché la figura sopravvive in un provvedimento generale del Garante per la Protezione dei Dati Personali del 27 novembre 2008, modificato nel giugno 2009, quello sulle misure e sugli accorgimenti prescritti ai titolari dei trattamenti effettuati con strumenti elettronici relativamente alle attribuzioni delle funzioni di amministratore di sistema. Quel provvedimento chiedeva tre cose molto concrete: designazione individuale, registro degli amministratori, log degli accessi conservati e non alterabili.

E qui la sorpresa: quel provvedimento è ancora vivo, con valore di linea guida ai sensi dell'art. 22, comma 4, del D.Lgs. 101/2018. Non è archeologia normativa e non è stato travolto dal GDPR.

Il raccordo tra i due piani funziona così. Il Regolamento europeo fissa l'obiettivo (art. 32, misure adeguate al rischio) e l'onere di dimostrarlo (art. 5, par. 2, principio di responsabilizzazione). Il provvedimento del 2008 dice, per l'ordinamento italiano, come quell'obiettivo si dimostra quando si parla di utenze con privilegi elevati: designazione individuale, elenco aggiornato degli amministratori, verifica almeno annuale del loro operato, log degli accessi completi, inalterabili e conservati per un periodo non inferiore a sei mesi.

Quindi non è il GDPR che vi chiede l'atto di nomina. L'atto di nomina è il modo con cui, in Italia, si dimostra di rispettare l'art. 32 del GDPR sulla gestione degli accessi privilegiati. Sono due cose diverse, e confonderle porta esattamente all'errore opposto a quello di partenza: pensare che con il Regolamento europeo la designazione sia diventata superflua.

Lo ha ricordato il Garante con il provvedimento del 16 gennaio 2025 (caso RealMaps), dove è stata sanzionata una società che, tra le altre cose, consentiva l'accesso ai sistemi tramite account condivisi fra più utenti. Il ragionamento dell'Autorità è pulito: se gli accessi avvengono con credenziali condivise e non personali, non si riesce più a ricondurre l'accesso al soggetto formalmente autorizzato, e questo vanifica anche l'efficacia dei controlli sui file di log e delle misure previste dal provvedimento del 2008. Nello stesso caso l'Autorità ha contestato anche l'accessibilità al database da parte di soggetti esterni all'organizzazione, tra cui il fornitore di servizi ICT, in assenza di una valida attribuzione ai sensi dell'art. 2-quaterdecies.

Ed è qui che il modello ereditato dal periodo precedente al 2018 mostra la crepa: chi si trova in quella condizione non ha un problema di atto mancante, hanno un problema di presidio mancante. E il presidio non si nomina: si esercita.

Chi ha il potere di verificare le registrazioni degli accessi

L'obbligo è del titolare del trattamento: il provvedimento del 2008 prescrive la verifica dell'operato degli amministratori di sistema con cadenza almeno annuale, per accertarne la rispondenza alle misure organizzative, tecniche e di sicurezza adottate. Non è una facoltà, è un adempimento. Si esercita attraverso la struttura che il titolare individua (il presidio informatico, la direzione sistemi informativi, l'ufficio per la transizione digitale), ma la responsabilità resta in capo al titolare.

Il responsabile del trattamento fa lo stesso per i propri amministratori: tiene il proprio elenco e verifica il proprio personale. Il titolare, su quel perimetro, controlla per via contrattuale ai sensi dell'art. 28, chiedendo accesso alle registrazioni per le proprie verifiche. Ed è il Garante a disporre dei poteri istruttori e ispettivi, in forza dell'art. 58 del GDPR e degli artt. 157 e seguenti del Codice.

Il DPO sorveglia, non verifica in proprio. L'art. 39 gli assegna la sorveglianza dell'osservanza della normativa, quindi può e deve chiedere evidenza che la verifica annuale sia stata fatta, ma non la esegue al posto del titolare e non ha un potere ispettivo autonomo.

Restano due limiti che contano più di tutto il resto. Il primo: l'amministratore di sistema non può essere l'unico custode delle registrazioni che lo riguardano, perché il provvedimento le vuole complete, inalterabili e verificabili nella loro integrità. Se può cancellarle o modificarle, la misura non esiste. Il secondo: quelle registrazioni non possono essere usate per il controllo a distanza dell'attività lavorativa, per il vincolo dell'art. 4 dello Statuto dei lavoratori. Servono a verificare l'uso dei privilegi, non la produttività di chi li esercita.

Il cloud ha spostato le responsabilità dentro il contratto

Aggiungiamo l'altro pezzo. Quando si passa a un gestionale erogato in cloud dal partner tecnologico, cioè a un programma che non è più installato sui propri server ma fornito come servizio, una parte consistente dei compiti storici dell'amministratore di sistema smette materialmente di essere eseguibile dall'interno.

L'infrastruttura di base, il motore della banca dati, le copie di sicurezza, la continuità operativa, il ripristino dopo un guasto grave: sono dentro il servizio. Non c'è un server su cui intervenire e non ci sono aggiornamenti correttivi da applicare a mano.

Chi le fa? Il partner tecnologico, in qualità di responsabile del trattamento ex art. 28. E la fonte della responsabilità non è più un decreto di nomina interno: è il contratto, con i suoi livelli di servizio garantiti (quanto il fornitore promette che il servizio resterà acceso), le sue clausole sulla registrazione degli accessi, i suoi obblighi di verifica.

Quello che resta in casa su quei sistemi è la gestione delle identità e dei permessi: chi entra, con quale profilo, fino a quando.

E qui il paradosso: la gestione dei profili è proprio l'attività che un amministratore di sistema unico non dovrebbe svolgere da solo, perché non sa cosa fanno davvero i colleghi dell'ufficio tributi, dei servizi sociali o dell'amministrazione del personale. Lo sa il loro responsabile.

Le obiezioni che mi farete (e hanno ragione)

Prima che qualcuno mi scriva, mettiamo sul tavolo le obiezioni serie. Sono tutte fondate, e chi conclude "quindi cloud e via, non serve più nessuno" ha capito male l'articolo.

Gli ambienti sono ibridi, non cloud. In un'organizzazione di medie dimensioni convivono applicativi in cloud, gestionali storici sui server interni che nessuno osa toccare, videosorveglianza locale, rete, postazioni, stampanti, e quel vecchio server che serve una sola procedura ma quella procedura serve. Tutto questo va amministrato in casa.

Ci sono vincoli normativi. Localizzazione dei dati, classificazione di dati e servizi, e nel settore pubblico la qualificazione dei servizi cloud: non tutto può andare su qualunque cloud, e le scelte vanno istruite e documentate.

Le competenze non sono sparite, sono migrate. Anche per amministrare risorse virtuali servono reti, protezione perimetrale, archiviazione, permessi, sistemi operativi. Non si salta il gradino. E uscire da un fornitore per portare i dati altrove è un progetto, non una mail: il piano di uscita si pensa prima di firmare.

Senza competenza interna, la crisi si paga tre volte. Quando il servizio cade alle tre di notte e chiama chi risponde di quel servizio, "ho verificato il contratto e domani chiediamo il ristoro" non è una risposta accettabile.

Tutte queste obiezioni non salvano l'amministratore di sistema in versione 2006. Dicono una cosa diversa: serve più competenza di prima, non meno. Solo distribuita diversamente.

Un modello che funziona: amministrazione distribuita

Proviamo a tradurre tutto questo in un modello concreto, del tipo che si può mettere in un atto. Non è la cronaca di quello che ha fatto qualcuno: è uno schema, adattabile a comuni, aziende sanitarie, regioni, ordini professionali, società e studi professionali, cioè a qualunque organizzazione con un'infrastruttura in parte in cloud e in parte in casa.

Invece di un amministratore di sistema unico e accentrato, tre livelli.

Livello 1: il partner tecnologico (art. 28)

Amministra i sistemi che eroga: infrastruttura, banche dati, copie di sicurezza, continuità operativa, ripristino dopo un guasto grave, sicurezza dell'infrastruttura. Nel contratto devono comparire la qualifica di responsabile del trattamento e gli obblighi visti sopra: elenco dei propri amministratori, registrazioni degli accessi inalterabili e conservate, messa a disposizione per le verifiche. Se nella vostra convenzione queste righe non ci sono, il problema non è l'atto di nomina.

Livello 2: i responsabili di area o funzione (art. 29 e art. 2-quaterdecies)

Ciascuno amministra profili, credenziali e permessi dei propri collaboratori, sui sistemi di propria competenza. Con designazione individuale scritta e istruzioni operative, non con una circolare generica. Perché è il responsabile dell'ufficio che sa se un collaboratore deve vedere anche i dati sanitari o no.

Livello 3: il presidio tecnico interno

Chi amministra ciò che è rimasto in casa (rete interna, postazioni di lavoro, apparati e server installati in sede) e chi coordina il tutto. Anche qui designazione individuale, elenco, registrazioni.

Con tre regole minime valide per tutti i livelli:

• autenticazione a più fattori attiva su tutte le utenze con privilegi, cioè password più un secondo codice
• privilegio minimo nell'assegnazione dei permessi
• disattivazione immediata delle utenze del personale cessato o trasferito, che è la falla più comune e anche la più banale

E la vecchia nomina?

Chiariamo un punto, perché è il più frainteso di tutto il ragionamento: chi adotta un modello di questo tipo non abolisce le designazioni, le riscrive. Il provvedimento del 2008 chiede che ogni utenza con privilegi elevati sia attribuita a una persona individuata, e questa esigenza non cambia di una virgola quando i sistemi si spostano in cloud. Cambia soltanto chi va designato e per cosa.

Da qui due strade, entrambe percorribili. La prima: aggiornare la designazione esistente, riportandola dentro il perimetro effettivo, che a quel punto è la gestione delle identità e dei sistemi rimasti in casa e non l'infrastruttura erogata dal partner tecnologico. La seconda: prendere atto che la designazione originaria descriveva un'organizzazione tecnica superata e sostituirla, non con un'altra figura unica, ma con l'insieme delle designazioni previste dai tre livelli.

In entrambi i casi vanno fatte tre cose molto poco romantiche: censire le credenziali amministrative esistenti, rigenerare quelle riferite a designazioni superate, aggiornare l'elenco degli amministratori. E in entrambi i casi restano validi gli obblighi accessori del 2008: verifica almeno annuale dell'operato e log degli accessi tracciati, inalterabili e conservati.

Quello che non funziona è la terza strada, che è anche la più battuta: lasciare l'atto vecchio dov'è e sperare che nessuno chieda i log.

L'amministratore diffuso e il registro dei trattamenti

Nel GDPR esiste la contitolarità: più soggetti che determinano insieme finalità e mezzi del trattamento, con una ripartizione trasparente delle rispettive responsabilità. È il riconoscimento normativo di un fatto elementare: la titolarità non è sempre un punto, a volte è una rete.

Quello che raccontiamo in questo articolo è l'equivalente tecnico sul versante dell'amministrazione. Chiamiamolo amministratore diffuso: non un soggetto unico che detiene tutte le chiavi, ma un insieme coordinato di soggetti, interni ed esterni, ciascuno con un perimetro definito, una designazione formale e una tracciabilità propria. Il partner tecnologico ex art. 28 sull'infrastruttura, i responsabili di area ex art. 29 sui profili, il presidio interno su ciò che resta in casa.

Il modello è più robusto del precedente, ma ha un prezzo: se le chiavi sono distribuite, serve una mappa. Altrimenti la distribuzione non è un modello organizzativo, è solo disordine con un nome elegante.

Quello che serve davvero (e che quasi sempre esiste già)

Arriviamo al punto. Se l'amministratore di sistema unico non regge più, cosa serve?

Serve una figura che sappia fare quattro cose insieme: capire l'infrastruttura vera, conoscere il cloud e i suoi limiti, leggere un contratto riconoscendo un livello di servizio scritto per non essere mai violato, e quando qualcosa cade sapere cosa fare nei primi trenta minuti. In una parola: governare i fornitori invece di essere governata da loro.

Chiamiamola, come si dice ormai comunemente, responsabile ICT (Information and Communication Technology). Non "amministratore di sistema". Non solo architetto cloud, che disegna infrastrutture ignorando i vincoli reali di chi le userà. Non solo gestore di contratti, che sa negoziare ma non sa cosa sia un log.

E qui arriva l'ironia migliore di tutta la storia: questa figura, quasi sempre, esiste già. In azienda si chiama responsabile dei sistemi informativi, o direttore IT, e siede a un tavolo dove si decide il budget ma non le architetture. Nel settore pubblico è persino prevista da una norma: è l'RTD (Responsabile per la Transizione Digitale), l'ufficio dirigenziale dell'art. 17 del CAD (Codice dell'Amministrazione Digitale), incaricato del coordinamento strategico dello sviluppo dei sistemi informativi, della connettività, delle banche dati e dei servizi digitali.

Cioè: mentre negli archivi giacciono atti che nominano un amministratore di sistema per un'infrastruttura che non esiste più, la figura che servirebbe è già lì. Solo che in troppi casi è una casella riempita per adempimento, senza tempo, senza budget e senza supporto tecnico specialistico, mentre le credenziali amministrative continuano a stare dove stavano.

Il problema, in altre parole, non è che manchi la figura. È che ne abbiamo due: una che non serve più e una a cui non diamo il mandato per funzionare.

In sintesi

La scheda operativa da portarsi in ufficio lunedì.

L'amministratore di sistema non è morto. Si è diviso in tre: un contratto, una serie di designazioni interne e un ruolo di governo. Il difficile non è capirlo. Il difficile è scriverlo in un atto, tenerlo aggiornato in un registro e poi rispettarlo.

Marco La Diega