Chi risponde delle misure tecniche e organizzative nella protezione dei dati personali e come si distribuiscono gli obblighi

La risposta breve, per chi deve orientarsi senza perdere tempo, è netta: la responsabilità ricade sia sul titolare del trattamento sia sul responsabile del trattamento. Non sono figure decorative né etichette da contratto. Sono soggetti chiamati a dimostrare, con atti concreti, di aver messo in piedi misure tecniche e organizzative adeguate al rischio reale del trattamento. Il GDPR non chiede una sicurezza astratta, ma una sicurezza calata nella materia viva dei dati, nei sistemi usati, nelle persone che li toccano e nei danni che potrebbero prodursi se qualcosa va storto.

Il punto, in pratica, è questo: chi decide finalità e mezzi del trattamento non può lavarsene le mani, e chi tratta i dati per conto altrui non può limitarsi a eseguire ordini senza farsi carico della sicurezza. L’articolo 32 del regolamento europeo costruisce un dovere condiviso, ma non confuso. La linea di confine esiste: il titolare governa, il responsabile attua dentro il perimetro ricevuto, ma entrambi devono reagire al rischio con misure proporzionate, verificabili e aggiornate. È qui che la protezione dei dati smette di essere burocrazia e diventa organizzazione reale, quasi ingegneria del quotidiano.

La regola di base: la sicurezza non è un optional né una formula vuota

Nel GDPR la sicurezza del trattamento è un obbligo sostanziale, non un vezzo amministrativo. L’articolo 32 dice che titolare e responsabile devono mettere in atto misure tecniche e organizzative adeguate per garantire un livello di sicurezza commisurato al rischio. La parola decisiva è adeguate: non significa perfette, ma coerenti con il tipo di dati trattati, con la sensibilità delle informazioni, con la dimensione dell’organizzazione e con la probabilità che si verifichi un incidente.

Questo capovolge una vecchia abitudine molto italiana: cercare il modulo giusto, il timbro giusto, la checklist salvifica. Qui non esiste una ricetta universale. Un archivio di fatture, un ospedale, una scuola, una società di marketing o un comune non hanno lo stesso profilo di esposizione. Il regolamento costringe a ragionare come farebbe un buon tecnico: prima si guarda dove può rompersi il sistema, poi si decide come rinforzarlo. È una logica da officina, non da scaffale.

La sicurezza, inoltre, va letta insieme ai principi di responsabilizzazione e di protezione dei dati fin dalla progettazione e per impostazione predefinita. Significa che il trattamento va pensato bene prima di partire, non rattoppato dopo. Se un software raccoglie più dati del necessario, se gli accessi sono troppo ampi, se le copie si moltiplicano senza controllo, il problema non è solo tecnico: è giuridico. E quando il danno arriva, non si misura solo nel numero dei file esfiltrati, ma nella perdita di fiducia, nell’esposizione delle persone, nel tempo sprecato per ricostruire ciò che si poteva prevenire.

Chi fa cosa: titolare e responsabile non hanno la stessa posizione

Il titolare del trattamento è il regista del trattamento. Decide perché i dati vengono raccolti e quali strumenti usare. Per questo è il primo soggetto chiamato a costruire l’architettura di sicurezza, a valutare i rischi e a dimostrare che il sistema regge. Non basta dire che il fornitore informatico si occupa della parte tecnica. Il titolare resta il perno della catena, perché è lui che determina il quadro generale e che deve scegliere partner affidabili, imporre istruzioni chiare e controllare che vengano rispettate.

Il responsabile del trattamento, invece, opera per conto del titolare. Ma il fatto che agisca su istruzione non lo rende passivo. L’articolo 28 gli impone di offrire garanzie sufficienti e di applicare misure idonee. In altre parole, non può presentarsi al tavolo dicendo solo che sa fare il servizio. Deve anche sapere farlo in modo sicuro. Un fornitore cloud, un consulente paghe, un’agenzia che gestisce campagne, una software house che conserva database: tutti possono diventare responsabili, e tutti devono provare di essere attrezzati.

Qui nasce un equivoco frequente: molti credono che il titolare possa trasferire la responsabilità e il responsabile possa rinviarla al cliente. Non funziona così. La responsabilità nel GDPR è a cerchi concentrici, non a cascata cieca. Se il contratto è scritto male, se le istruzioni sono vaghe, se il livello di protezione non è stato verificato, il problema si espande in tutta la filiera. La normativa non ama le catene opache; preferisce relazioni documentate, verificabili e, soprattutto, comprensibili a posteriori. Quando arriva un’ispezione o un data breach, i vuoti contrattuali si trasformano in ferite aperte.

Le misure di sicurezza non si scelgono per abitudine, ma per rischio: se il trattamento cambia, cambia anche l’assetto di protezione. — Nota tecnica di prassi ricavabile dall’impianto del GDPR

Misure tecniche: il lato visibile della sicurezza

Le misure tecniche sono la parte materiale della difesa. Crittografia, pseudonimizzazione, autenticazione forte, gestione degli accessi, backup, registri di tracciamento, segmentazione delle reti, aggiornamenti software, protezione fisica dei locali. Sono tutti strumenti che non eliminano il rischio, ma lo abbassano. La loro efficacia sta nel far perdere forza all’attacco o nel contenere il danno quando qualcosa sfugge di mano.

La cifratura, per esempio, non è una parola elegante da inserti aziendali: è un sistema matematico che rende leggibili i dati solo a chi possiede la chiave. Se un portatile sparisce, un disco viene rubato o un file finisce nel posto sbagliato, i dati cifrati restano molto più difficili da usare per chi non è autorizzato. La pseudonimizzazione opera in modo diverso: separa i dati identificativi dal resto delle informazioni, riducendo l’impatto di un eventuale accesso improprio. Sono tecniche utili, ma non magiche. Non sostituiscono il controllo umano né la disciplina interna.

Altrettanto importante è la capacità di garantire riservatezza, integrità, disponibilità e resilienza dei sistemi. È un lessico tecnico, ma dietro ci sono fatti concreti: chi può vedere i dati, chi può modificarli, se il sistema resta in piedi quando arriva un guasto, se i servizi ripartono in tempi accettabili dopo un incidente. Un database accessibile da troppi utenti, un backup mai testato o un software lasciato indietro di molte versioni non sono dettagli. Sono crepe nella diga. E le crepe, in informatica come in edilizia, non fanno rumore finché l’acqua non passa.

Il regolamento pretende anche procedure per testare e verificare regolarmente l’efficacia delle misure. Questo punto è spesso ignorato, ma è uno dei più seri. Una difesa non testata è una difesa immaginaria. Il test può essere un controllo sugli accessi, una simulazione di perdita dati, un audit interno, una prova di ripristino, una revisione dei privilegi. Senza questo passaggio, la sicurezza diventa una fotografia sbiadita, buona solo per i documenti, non per la realtà.

Misure organizzative: la parte che fallisce per prima quando manca disciplina

Le misure organizzative sono meno appariscenti, ma spesso più decisive delle soluzioni tecnologiche. Riguardano procedure, ruoli, istruzioni, formazione, controlli interni, gestione dei fornitori, limitazione degli accessi e ordine nelle responsabilità. In molti casi, il punto debole non è il software. È la persona che lascia aperta la sessione, il reparto che condivide password, l’ufficio che conserva documenti sensibili su scrivanie affollate, il dirigente che pretende velocità ma non chiede tracciabilità.

La formazione del personale è un esempio chiarissimo. Non serve a trasformare tutti in giuristi o sistemisti. Serve a far capire che i dati personali hanno un peso, che non si mandano allegati sensibili a casaccio, che non si usa la stessa password per tutto, che una richiesta sospetta va verificata prima di aprire porte inutili. Nella pratica, molti incidenti nascono da scorciatoie banali: una mail sbagliata, un link cliccato senza attenzione, un archivio condiviso con permessi troppo larghi. La tecnologia può limitare i danni, ma l’errore umano resta il primo corridoio aperto.

La logica organizzativa impone anche istruzioni precise e una catena di comando leggibile. Chi può autorizzare l’accesso? Chi decide la cancellazione? Chi approva il fornitore? Chi interviene se si sospetta una violazione? Se queste risposte non esistono, o restano implicite, il trattamento entra in una zona grigia che il GDPR non tollera volentieri. La sicurezza non coincide con la buona volontà; coincide con l’ordine dei compiti. Ed è proprio nelle strutture più piccole, dove tutti fanno tutto, che questo ordine tende a sfaldarsi più in fretta.

La vulnerabilità più costosa non è sempre il malware, ma l’assenza di procedure ripetibili quando il problema si presenta. — Osservazione tecnica coerente con l’articolo 32 del GDPR

Il rischio come metro: niente sicurezza astratta, solo scelte proporzionate

Il GDPR non pretende lo stesso livello di protezione per ogni trattamento, perché il rischio non è mai uguale. Qui entra in scena una logica molto concreta: si valuta la natura dei dati, l’ampiezza del trattamento, il contesto e le finalità, poi si stimano probabilità e gravità degli effetti possibili. Un archivio con dati sanitari, un portale pubblico con dati sensibili, una piattaforma di recruiting o una banca dati commerciale non pongono gli stessi problemi. Nemmeno la stessa difesa sarebbe sensata.

L’articolo 32 richiama in modo esplicito i rischi di distruzione, perdita, modifica, divulgazione non autorizzata e accesso accidentale o illecito. Dietro queste formule c’è la realtà: un ransomware che blocca i server, un attacco phishing che ruba credenziali, un errore di configurazione nel cloud, un invio errato a destinatari non autorizzati, un dipendente che esporta file senza controllo. Il rischio non vive solo nel crimine informatico spettacolare. Vive anche nelle routine stanche, nei clic distratti e nei sistemi lasciati andare per inerzia.

La parola adeguato va letta insieme a un’altra espressione poco amata ma decisiva: stato dell’arte. Non significa comprare l’ultima tecnologia solo perché è nuova. Significa verificare cosa è ragionevole oggi per quel tipo di trattamento, con quel budget, per quei dati, in quel contesto. Un piccolo studio professionale non avrà la stessa infrastruttura di una banca, ma non per questo è esentato dal proteggere il contenuto delle proprie cartelle. L’adeguatezza è una misura elastica, non un alibi.

In questo senso il GDPR è severo ma non ipocrita. Sa che la sicurezza totale non esiste. Però pretende che si possa spiegare, a posteriori, perché si è scelto un determinato assetto, perché certi rischi sono stati giudicati accettabili e perché le misure adottate erano proporzionate. È una responsabilità di metodo, oltre che di risultato.

Contratti, istruzioni e controllo sulla filiera dei fornitori

La sicurezza dei dati oggi si gioca spesso fuori dalle mura dell’azienda. Cloud, consulenti, software in abbonamento, call center, società di payroll, agenzie marketing, piattaforme di ticketing: il trattamento passa di mano in mano, e ogni passaggio aggiunge un punto di attrito. Per questo il rapporto tra titolare e responsabile va definito con precisione. Il contratto o altro atto giuridico deve fissare materia, durata, natura, finalità, tipo di dati e categorie di interessati, oltre agli obblighi e ai diritti del titolare.

Il responsabile, dal canto suo, deve trattare i dati solo su istruzione documentata. Deve inoltre garantire la riservatezza delle persone autorizzate, adottare misure di sicurezza, assistere il titolare nella gestione dei diritti degli interessati, nella sicurezza, nelle valutazioni d’impatto e nelle notifiche di violazione. Se si affida a un subresponsabile, non può farlo in modo anarchico: serve autorizzazione preventiva, specifica o generale, e il titolare deve poter conoscere e, in certi casi, contestare la catena ulteriore.

Questo punto è spesso il più fragile nelle organizzazioni medio-piccole, dove il contratto si riduce a poche righe standard e la verifica si ferma al preventivo più basso. Ma il prezzo basso, in materia di dati, può diventare un conto molto salato quando scoppia un incidente. Una piattaforma scelta male, con server fuori controllo o assistenza lenta, può trasformare un semplice problema operativo in una perdita di ore, clienti e credibilità. Il GDPR, in sostanza, chiede di leggere i fornitori come si leggerebbe un impianto elettrico: non basta che funzioni all’accensione, deve reggere nel tempo e in emergenza.

Chi usa un fornitore esterno non trasferisce il rischio, lo redistribuisce. E se non controlla, se lo riprende tutto. — Sintesi giuridico-operativa coerente con l’articolo 28 e l’articolo 32 del GDPR

Data breach: quando la sicurezza si misura nella reazione

La vera prova di un sistema non è l’assenza assoluta di incidenti, ma la capacità di reagire bene quando l’incidente arriva. Il GDPR impone al titolare di notificare all’autorità di controllo le violazioni di dati personali entro 72 ore da quando ne viene a conoscenza, salvo che sia improbabile il rischio per i diritti e le libertà delle persone fisiche. Se il rischio è elevato, va informato anche l’interessato, senza ingiustificato ritardo. Qui non conta il rituale della scusa, conta il tempo.

Per capire la logica della norma basta pensare a una perdita di controllo su file contenenti dati identificativi, accessi, informazioni economiche o dati sanitari. Se quei dati possono essere usati per furto d’identità, frodi, discriminazioni o danni reputazionali, la violazione non è un episodio amministrativo. È un fatto che tocca la vita concreta delle persone. Per questo il regolamento pretende anche la documentazione interna degli incidenti, persino di quelli non notificati, con circostanze, effetti e misure adottate.

Un sistema maturo non improvvisa la gestione della crisi. Ha un flusso interno, individua chi decide, chi raccoglie le informazioni, chi parla con l’autorità, chi preserva le prove, chi blocca i flussi compromessi, chi ripristina i servizi. Senza questa struttura, le 72 ore diventano una corsa nel fango. E la corsa nel fango finisce quasi sempre con una segnalazione tardiva, una ricostruzione confusa e un danno che poteva essere contenuto.

Il ruolo del DPO e perché non sostituisce nessuno

Il responsabile della protezione dei dati, o DPO, non è il custode unico della sicurezza. È una figura di supporto, vigilanza e indirizzo. Serve a facilitare l’attuazione del regolamento, a sensibilizzare il personale, a sorvegliare la valutazione d’impatto e a fare da snodo di competenza. In alcuni casi la sua designazione è obbligatoria, ma anche quando non lo è resta un indicatore di maturità organizzativa, soprattutto nei contesti complessi o ad alto rischio.

Qui conviene essere franchi: il DPO non può prendere il posto del titolare, né del responsabile, né del reparto IT. Se manca la volontà del vertice, se le procedure non esistono, se il personale non è formato, il DPO diventa una figura decorativa. Il GDPR non lo voleva così. Lo immagina indipendente, autorevole, dotato di competenze adeguate e messo in condizione di operare senza conflitti di interesse. In una macchina ben costruita, è un sensore; non il motore.

La sua presenza, però, aiuta a evitare un altro difetto molto comune: la sicurezza ridotta a slogan. Quando il DPO funziona, ricorda a tutti che la valutazione del rischio va fatta sul serio, che i trattamenti vanno mappati, che le istruzioni devono essere comprensibili, che l’accesso ai dati non si concede per comodità. È una figura che porta metodo dove spesso regna l’abitudine. E l’abitudine, in protezione dati, è una pessima consigliera.

Il DPO non decide al posto del titolare, ma impedisce che le decisioni vengano prese senza aver visto il rischio. — Formula coerente con il ruolo di cui agli articoli 37, 38 e 39 del GDPR

La domanda che conta davvero: chi paga quando qualcosa va male?

Dal punto di vista giuridico, la responsabilità può essere concorrente. Se il danno deriva da un trattamento illecito o da misure inadeguate, titolare e responsabile possono rispondere secondo il rispettivo ruolo e secondo gli obblighi che ciascuno ha violato. Il regolamento non premia l’alibi della delega. Se il titolare sceglie male, istruisce male o controlla male, il problema è suo. Se il responsabile devia dalle istruzioni o trascura gli obblighi direttamente impostigli, ne risponde a sua volta. La catena di colpa, in questo campo, è concreta e molto meno elegante di quanto si vorrebbe.

La parte più delicata è la documentazione. Chi adotta misure serie lascia tracce: analisi del rischio, policy, log di accesso, verbali di test, contratti con i fornitori, registri dei trattamenti, istruzioni al personale, report di incident response. Questi documenti non servono per abbellire una cartella. Servono per dimostrare che le decisioni sono state prese prima del danno, non dopo. È una differenza enorme, anche davanti all’autorità di controllo.

Ed è qui che la protezione dei dati mostra il suo volto più realistico: non si misura sulla promessa, ma sulla prova. Chi ha costruito un sistema sensato può spiegare le proprie scelte, correggere gli errori e migliorare nel tempo. Chi ha improvvisato, invece, scopre troppo tardi che la sicurezza non era un progetto, ma una speranza male organizzata. Il GDPR, con la sua durezza sobria, ha scelto un criterio semplice: la fiducia si guadagna prima, quando tutto sembra tranquillo, non dopo, quando il danno è già entrato dalla porta di servizio.

Quando la sicurezza smette di essere teoria e diventa responsabilità quotidiana

La questione non è solo normativa: è culturale. Le misure tecniche e organizzative adeguate non sono la cornice della protezione dati, sono il suo corpo. Senza di esse il diritto alla riservatezza resta una frase elegante, buona per i documenti ma fragile nella pratica. Per questo il GDPR spinge titolari e responsabili a pensare come gestori di un sistema vivo, non come compilatori di moduli. Ogni trattamento produce attrito, ogni attrito produce rischio, e ogni rischio chiede una risposta proporzionata.

La domanda iniziale, in fondo, va letta così: chi risponde? Rispondono entrambi, ciascuno per la propria posizione e con il proprio margine di potere. Il titolare perché decide il trattamento e deve governarlo con prudenza. Il responsabile perché lo esegue e deve farlo senza abbassare la soglia di sicurezza. L’idea di fondo è brutale nella sua semplicità: chi maneggia dati personali deve essere capace non solo di proteggerli, ma di spiegare come lo fa, con quali mezzi e con quale logica.

Nel tempo dei sistemi interconnessi, questa responsabilità condivisa è la vera frontiera della protezione dati. Non basta avere un buon firewall o una policy ben scritta. Serve una disciplina che regga alla distrazione, alla fretta, al fornitore che sbaglia, al dipendente inesperto, al malware che si infiltra, al contratto redatto male. È lì che si vede chi ha davvero preso sul serio la sicurezza, e chi invece ha solo fatto finta di crederci.