GDPR Articolo 32: la multa è per il test che non hai fatto

Due decisioni GDPR sono arrivate nelle stesse 48 ore questa settimana, e solo una ha fatto notizia. Il 21 settembre la Data Protection Commission irlandese ha multato Google per 403 milioni di euro per come trattava i dati di geolocalizzazione — il numero che tutti hanno citato. Quella che dovrebbe preoccupare ogni CISO è più piccola e silenziosa: il 22 settembre il garante svedese ha multato il fornitore software Miljödata per circa 183.000 dollari dopo una violazione che ha esposto i dati di 2,2 milioni di persone. Il garante non ha multato Miljödata per essere stata violata. L'ha multata per i controlli di sicurezza specifici che non aveva prima della violazione — e li ha nominati.

Quella distinzione è tutta la storia. L'enforcement GDPR sta silenziosamente passando da "hai perso dei dati, ecco la sanzione" a "le tue misure tecniche erano inadeguate ai sensi dell'Articolo 32, e possiamo indicare quali". La seconda formulazione è molto più pericolosa, perché la multa non aspetta più la violazione peggiore. Aspetta che un garante guardi il tuo set di controlli e trovi una lacuna.

Cosa ha sanzionato davvero il garante svedese

Miljödata sviluppa sistemi HR e di gestione dell'ambiente di lavoro usati da circa l'80% dei comuni svedesi. Nell'agosto 2025 un threat actor — poi autodefinitosi "Datacarry" — ha violato l'azienda, interrotto i servizi in oltre 200 regioni, chiesto 1,5 BTC e, al mancato pagamento, pubblicato i dati rubati. I record esposti non erano email di marketing: numeri di identità personale, dati su assenze per malattia e riabilitazione, persino segnalazioni di incidenti che coinvolgevano minori.

L'autorità svedese IMY, chiudendo l'istruttoria un anno dopo, ha fondato la sanzione sull'Articolo 32 del GDPR — l'articolo sulla "sicurezza del trattamento". Le due mancanze contestate erano precise:

• Test inadeguati del nuovo software prima della messa in produzione.
• Assenza di monitoraggio automatizzato in tempo reale dell'ambiente.

Rileggetele da ingegnere, non da giurista. Il garante non ha detto "avreste dovuto avere firewall migliori". Ha detto che avete rilasciato software che non avevate testato adeguatamente, e che non avevate alcun modo continuo di vedere un attaccante muoversi nei vostri sistemi. Non sono lacune documentali. Sono i due controlli che avrebbero (a) intercettato il difetto sfruttabile prima della produzione e (b) intercettato l'esfiltrazione mentre avveniva, non quando Datacarry ha pubblicato il dump.

"Non siamo stati violati per negligenza — siamo stati violati, e poi hanno deciso che i controlli erano inadeguati."

È esattamente la trappola. L'adeguatezza ex Articolo 32 si valuta a posteriori, rispetto allo stato dell'arte del momento. Un controllo di cui non puoi dimostrare l'esistenza è, ai fini dell'enforcement, un controllo che non avevi.

Cosa richiede davvero l'Articolo 32 del GDPR

Molti team trattano l'Articolo 32 come una vaga clausola "tenete i dati al sicuro". È più specifico di così, e in quella specificità vivono ora le multe. L'Articolo 32(1) impone a titolari e responsabili di attuare "misure tecniche e organizzative adeguate" tenendo conto dello "stato dell'arte", e definisce due obblighi che si sovrappongono direttamente alle contestazioni a Miljödata:

Clausola Art. 32	Cosa impone davvero	La lacuna di Miljödata
32(1)(b)	Riservatezza, integrità, disponibilità e resilienza permanenti dei sistemi di trattamento	Nessun monitoraggio in tempo reale per rilevare una perdita di riservatezza in corso
32(1)(d)	Una procedura per testare, verificare e valutare regolarmente l'efficacia delle misure tecniche	Test inadeguati del nuovo software prima del rilascio

La formula "testare, verificare e valutare regolarmente l'efficacia" non è aspirazionale. È un obbligo giuridico presente nel regolamento dal 2018, e ora viene fatto valere come tale. Un penetration test annuale, archiviato e dimenticato, è una risposta debole a "testare … regolarmente l'efficacia" quando il software che rilasci cambia ogni settimana. Lo "stato dell'arte" è un riferimento mobile: ciò che nel 2020 valeva come test adeguato non è ciò che un garante si aspetta nel 2026, quando esfiltrazione autonoma e sfruttamento in giornata sono il modello di minaccia di base.

I 403 milioni a Google e la trappola dell'accountability

La decisione su Google, ampiamente ripresa per la sua entità, sembra un caso di natura diversa — riguarda liceità, trasparenza e conservazione su Web & App Activity, Location History e Location Accuracy, non una violazione. Ma porta la stessa lezione di fondo per i team di sicurezza. Per la funzione Location Accuracy, la DPC ha riscontrato una violazione del principio di accountability perché Google non era in grado di dimostrare che il trattamento fosse lecito, corretto e trasparente.

Non era in grado di dimostrare. È la parola ricorrente nell'enforcement moderno: l'onere non è solo essere conformi, ma dimostrarlo, su richiesta, con evidenze anteriori alla richiesta stessa.

"I dati di geolocalizzazione possono aumentare enormemente l'utilità di un servizio online, ma possono anche rivelare informazioni private significative sulle persone." — Graham Doyle, Deputy Commissioner, DPC irlandese

Mettendo insieme i due casi, il pattern è inequivocabile. Miljödata non poteva dimostrare test o monitoraggio adeguati. Google non poteva dimostrare la liceità del trattamento. In entrambi, ciò che mancava non era il controllo in astratto — era una registrazione difendibile e contestuale che il controllo esistesse e funzionasse. L'enforcement si è spostato sullo strato probatorio.

L'Articolo 32 GDPR è ora una priorità di enforcement, non una casella

Non è una stranezza isolata svedese. Lo stesso obbligo — "misura l'efficacia dei tuoi controlli, in modo continuo, e sappilo dimostrare" — è scritto in ogni norma a cui un'organizzazione europea risponde contemporaneamente:

• L'Articolo 21 della NIS2 richiede "politiche e procedure per valutare l'efficacia delle misure di gestione dei rischi di cibersicurezza" — lo stesso linguaggio di test e valutazione, ora con la responsabilità personale del management.
• DORA va oltre per le entità finanziarie, imponendo threat-led penetration testing (TLPT) con cadenza definita e conservazione dei risultati come evidenza di vigilanza.
• L'Articolo 32(1)(d) del GDPR sta alla base di entrambi e — come mostra Miljödata — viene fatto valere per conto proprio.

Il problema operativo che ne nasce non è "a quale framework conformarsi". È che un singolo controllo mancante — niente test continuo, niente rilevamento in tempo reale — è ora simultaneamente una multa GDPR, un rilievo NIS2 e una lacuna DORA. Una debolezza, tre garanti, e ciascuno vuole il proprio fascicolo di evidenze. I team che gestiscono tutto questo come tre progetti di audit separati bruciano lavoro producendo tre versioni della stessa prova, e ancora non sanno rispondere a "mostrami il test eseguito sulla release che è stata violata, e mostrami che hai visto l'esfiltrazione".

Da dove devono arrivare davvero le evidenze

La decisione su Miljödata merita una lettura attenta perché il garante, forse involontariamente, ha scritto una specifica in due righe di cosa significhino "misure adeguate" nel 2026: testa il software prima di rilasciarlo, e monitora l'ambiente in esecuzione in tempo reale. Tutto il resto in difesa discende dal chiudere quelle due lacune con evidenze mostrabili a un auditor.

È la domanda operativa che Zero Hunt è costruito per risolvere, e l'Articolo 32 la inquadra più nettamente di qualsiasi brochure. L'obbligo di "testare regolarmente … l'efficacia" si soddisfa con una validazione continua e attivata dal cambiamento, non con uno scatto annuale: il motore offensivo a 10 agenti di Zero Hunt lancia una campagna completa contro un asset nuovo o modificato entro un'ora dalla sua comparsa sul perimetro, così la domanda "abbiamo testato questa release" ha una risposta firmata prima che quella release diventi quella nel rapporto di incidente. La lacuna del "monitoraggio in tempo reale" è esattamente ciò che affronta il modello di AI Traffic Analysis sull'appliance — quattro teste di inferenza in parallelo che leggono il traffico per esfiltrazione e movimento laterale mentre accadono, non nella revisione dei log del mattino dopo, che è precisamente la finestra che a Miljödata mancava mentre Datacarry preparava il dump.

Ciò che trasforma entrambi in una difesa contro una contestazione ex Articolo 32 è lo strato di evidenze sottostante: ogni scansione, finding e remediation è mappato in continuo su 32 framework — GDPR, NIS2 Titolo 13, DORA incluso il TLPT RTS 2025, ISO 27001 — e firmato ECDSA al momento della scrittura, così il record è contestuale e verificabile per costruzione. Quando un garante pone la domanda di Miljödata — dimostra che il test era adeguato e dimostra che avresti visto tutto questo — la risposta è un fascicolo firmato con una marca temporale anteriore alla richiesta, non una corsa a ricostruire com'era il set di controlli un anno prima. La multa, sempre più, non è per la violazione. È per l'evidenza che non hai saputo produrre. È la lacuna da chiudere prima che arrivi la lettera.

Se stai mappando tutto questo sui tuoi obblighi, la nostra nota sul testing continuo tra NIS2 e DORA approfondisce la questione della cadenza. Per vedere il modello di evidenze sul tuo ambiente, contattaci.