Le azioni esecutive dell’ICO contro le organizzazioni britanniche sono aumentate nettamente nel 2024 e 2025, con sanzioni totali superiori a 12 milioni di sterline nei due anni per carenze nelle misure di sicurezza tecniche. Il modello negli avvisi di esecuzione dell’ICO è coerente: le organizzazioni che hanno subito una violazione e non hanno potuto dimostrare di aver implementato adeguati controlli tecnici hanno affrontato le conseguenze più severe. Per gli sviluppatori, questa è una preoccupazione professionale diretta. Le decisioni che prendete riguardo alla crittografia, alla registrazione, al controllo degli accessi e alla conservazione dei dati sono i controlli tecnici che determinano se un’organizzazione può difendersi davanti all’ICO.

Questa guida è scritta per sviluppatori e team di ingegneria, non per i dipartimenti legali o di conformità. Traduce i requisiti del GDPR del Regno Unito in decisioni tecniche concrete: cosa implementare, come implementarlo e perché ogni misura esiste.

In sintesi

  • L’Articolo 32 del GDPR del Regno Unito richiede “misure tecniche appropriate” proporzionate al rischio. Per la maggior parte delle applicazioni che trattano dati personali, ciò significa crittografia a riposo e in transito, pseudonimizzazione dove fattibile, controlli degli accessi e capacità di rilevamento delle violazioni documentata.
  • Gli errori più comuni degli sviluppatori che creano esposizione al GDPR: registrare dati personali nell’output di debug, eliminare con soft delete i record che dovrebbero essere eliminati definitivamente per il diritto alla cancellazione, e non riuscire a implementare DPA con ogni servizio di terze parti che tocca i dati personali.
  • La minimizzazione dei dati è una decisione di progettazione presa a livello di campo. Se non si ha una ragione documentata per raccogliere e memorizzare un campo, non raccoglierlo.
  • Il diritto alla cancellazione richiede l’eliminazione effettiva, a cascata attraverso tutti i sistemi inclusi backup e sub-responsabili del trattamento terzi. Le eliminazioni logiche non soddisfano l’obbligo.

GDPR del Regno Unito vs GDPR dell’UE: cosa cambia per gli sviluppatori

Dopo la Brexit, il Regno Unito ha mantenuto il framework GDPR dell’UE come “UK GDPR” attraverso il European Union (Withdrawal) Act 2018. Per gli sviluppatori, i requisiti tecnici sono identici. Le differenze sono amministrative: l’autorità di vigilanza nel Regno Unito è l’Information Commissioner’s Office (ICO), non un’autorità nazionale di protezione dei dati dell’UE, e i trasferimenti transfrontalieri tra il Regno Unito e l’UE sono disciplinati dalla decisione di adeguatezza del Regno Unito (attualmente mantenuta dall’UE, sebbene periodicamente riesaminata).

La conseguenza pratica è che se si costruisce software conforme ai requisiti tecnici del GDPR dell’UE, soddisfa anche i requisiti tecnici del GDPR del Regno Unito. Il contrario è ugualmente vero. Le divergenze si trovano nelle procedure di notifica, nei meccanismi di trasferimento e nelle linee guida specifiche di esecuzione dell’ICO, che a volte differiscono nell’enfasi rispetto alle linee guida dell’EDPB.

Articolo 32: cosa richiede effettivamente

L’Articolo 32 del GDPR del Regno Unito richiede ai titolari e ai responsabili del trattamento di implementare “misure tecniche e organizzative appropriate” per garantire un livello di sicurezza adeguato al rischio, tenendo conto dello stato dell’arte, dei costi di implementazione e della natura, portata, contesto e finalità del trattamento.

Quel linguaggio è deliberatamente flessibile. Ciò che si traduce in pratica dipende dal profilo di rischio, ma l’Articolo 32(1) fornisce quattro esempi specifici:

  1. Pseudonimizzazione e crittografia dei dati personali
  2. Capacità di assicurare la continua riservatezza, integrità, disponibilità e resilienza dei sistemi e dei servizi di trattamento
  3. Capacità di ripristinare tempestivamente la disponibilità e l’accesso dei dati personali in caso di incidente fisico o tecnico
  4. Un processo per testare, valutare e verificare regolarmente l’efficacia delle misure di sicurezza

“Lo stato dell’arte” non significa che sia necessario implementare la soluzione più costosa o all’avanguardia. Significa che non si può giustificare l’uso di un approccio debole (come MD5 per l’hashing delle password) quando approcci chiaramente migliori (come Argon2) sono ben consolidati, ampiamente disponibili e non materialmente più costosi da implementare.

Crittografia a riposo

Password. Non memorizzare mai le password in chiaro e non usare mai MD5 o SHA-1 per l’hashing delle password. Entrambi sono del tutto inadatti. Usare bcrypt con un fattore di lavoro di almeno 12, o Argon2id con parametri calibrati per richiedere almeno 100 ms sull’hardware del server. Argon2id è la raccomandazione attuale di OWASP ed è preferibile per le nuove implementazioni.

1# Argon2id con libsodium (esempio Node.js)
2const hash = await argon2.hash(password, {
3  type: argon2.argon2id,
4  memoryCost: 65536,   // 64 MB
5  timeCost: 3,
6  parallelism: 1
7});

Crittografia del database. Abilitare la crittografia a riposo a livello di database. Tutti i principali database e servizi gestiti (PostgreSQL, MySQL, MongoDB Atlas, AWS RDS, Azure SQL) la supportano. La crittografia trasparente dei dati (TDE) protegge i dati su disco, ma non protegge da un utente del database compromesso con accesso alle query. Per i campi altamente sensibili (numeri di previdenza sociale, cartelle cliniche, numeri di conti finanziari), considerare la crittografia a livello di campo a livello applicativo usando AES-256-GCM con un servizio di gestione delle chiavi (AWS KMS, Azure Key Vault, HashiCorp Vault). La chiave deve essere conservata separatamente dai dati che crittografa.

Gestione delle chiavi. Non inserire chiavi di crittografia nel codice dell’applicazione e non memorizzarle nello stesso database dei dati che proteggono. Usare variabili d’ambiente per lo sviluppo e un servizio di gestione delle chiavi gestito per la produzione. Ruotare periodicamente le chiavi e assicurarsi che l’applicazione possa gestire la rotazione delle chiavi senza downtime.

Cosa non fare. Non memorizzare dati personali in chiaro nei file di log, nei file temporanei o nelle cache dell’applicazione dove la crittografia potrebbe non applicarsi. Verificare ogni percorso del codice che gestisce dati personali e assicurarsi che non persista inavvertitamente copie non crittografate.

Crittografia in transito

Configurazione TLS. Applicare TLS 1.2 come minimo, con TLS 1.3 come impostazione predefinita dove supportato. Disabilitare completamente SSLv3, TLS 1.0 e TLS 1.1. Su nginx:

1ssl_protocols TLSv1.2 TLSv1.3;
2ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
3ssl_prefer_server_ciphers off;

HSTS. Impostare l’intestazione Strict-Transport-Security con un valore max-age lungo e includeSubDomains. Un max-age di almeno 31536000 (un anno) è lo standard. Inviare alla lista di precaricamento HSTS se la distribuzione lo consente.

1Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Contenuto misto. Servire qualsiasi risorsa (immagini, script, fogli di stile, chiamate API) tramite HTTP da una pagina HTTPS crea una vulnerabilità di contenuto misto e compromette la sicurezza del trasporto. Configurare la Content Security Policy per bloccare il contenuto misto e verificare la pagina per eventuali caricamenti di risorse non HTTPS.

Servizi interni. La crittografia in transito si applica alle comunicazioni interne servizio-per-servizio così come al traffico lato utente. Le connessioni al database, le connessioni alle code di messaggi e le chiamate ai microservizi dovrebbero usare tutte TLS. Molti sviluppatori crittografano correttamente il livello lato utente e trascurano la rete interna.

Minimizzazione dei dati nel codice

La minimizzazione dei dati non è un’astrazione legale. È una decisione di progettazione presa campo per campo. Prima di raccogliere qualsiasi dato personale, chiedersi: l’applicazione ha effettivamente bisogno di questo per funzionare? Se non si riesce a rispondere a questa domanda con un caso d’uso specifico, non raccoglierlo.

In pratica ciò significa:

  • Rimuovere i campi del modulo che sono opzionali e il cui scopo è vago (ad es. “data di nascita” su un’iscrizione a una newsletter dove non si ha alcun requisito di verifica dell’età)
  • Verificare regolarmente lo schema del database e eliminare le colonne che contengono dati personali senza uso attivo
  • Impostare i periodi di conservazione a livello di schema dove possibile, usando job pianificati per eliminare automaticamente i record scaduti
  • Evitare di raccogliere dati personali altamente sensibili (informazioni sanitarie, dettagli finanziari, opinioni politiche) a meno che l’applicazione non ne abbia genuinamente bisogno, perché la valutazione del rischio dell’Articolo 32 si scala con la sensibilità dei dati trattati

Il principio di responsabilità dell’ICO richiede di poter dimostrare di aver considerato la minimizzazione dei dati. Le decisioni di progettazione documentate nell’architettura o nelle note dello sprint lo soddisfano. Le decisioni non documentate no.

Pseudonimizzazione

La pseudonimizzazione sostituisce le informazioni direttamente identificative con un token o un identificatore che non può identificare l’individuo senza accesso a una chiave o tabella di mappatura tenuta separatamente. L’Articolo 32 la elenca esplicitamente come misura tecnica raccomandata, e l’Articolo 89 prevede obblighi ridotti per il trattamento di dati pseudonimizzati a fini di ricerca.

Per l’analisi e il tracciamento del comportamento, uno schema comune è quello di fare l’hash degli identificatori utente con un salt specifico del sito usando SHA-256 prima di passarli al sistema di analisi:

1import hmac, hashlib
2
3def pseudonymise(user_id: str, site_secret: str) -> str:
4    return hmac.new(
5        site_secret.encode(),
6        user_id.encode(),
7        hashlib.sha256
8    ).hexdigest()

Il salt deve essere conservato separatamente dai dati analitici. Senza di esso, l’hash non può essere invertito per identificare l’individuo. Ciò significa che il sistema di analisi contiene solo identificatori pseudonimizzati, riducendo il profilo di rischio di una violazione di quel sistema.

La pseudonimizzazione non è anonimizzazione. Se si detiene la chiave di mappatura, l’ICO tratta i dati pseudonimizzati come dati personali. L’anonimizzazione completa, dove la re-identificazione non è possibile nemmeno con informazioni aggiuntive ragionevolmente disponibili, rimuove i dati dall’ambito del GDPR. Ottenere una vera anonimizzazione è difficile in pratica; la maggior parte delle implementazioni produce dati pseudonimizzati, che rientrano ancora nell’ambito del GDPR ma con rischio ridotto.

Diritto alla cancellazione: implementazione corretta

Il diritto alla cancellazione (Articolo 17) è uno degli obblighi GDPR tecnicamente più impegnativi da implementare correttamente. I requisiti sono specifici:

Eliminazione definitiva, non logica. Impostare un flag is_deleted e filtrarlo dalle query non soddisfa il diritto alla cancellazione. I dati devono essere effettivamente rimossi dal database. Costruire funzionalità di eliminazione definitiva per ogni entità che contiene dati personali.

Eliminazioni a cascata. Eliminare il record utente non è sufficiente se i dati personali sono conservati anche in tabelle correlate (ordini, indirizzi, log delle attività, preferenze, file caricati). Mappare ogni tabella che contiene dati personali collegati a un identificatore utente e assicurarsi che l’eliminazione si propaghi correttamente a cascata, oppure implementare un job di eliminazione esplicito che rimuova atomicamente tutti i dati associati.

Sub-responsabili del trattamento terzi. Se si sono inviati dati personali a un servizio di terze parti (piattaforma di email marketing, CRM, strumento di analisi, processore di pagamento), l’obbligo di cancellazione si estende all’istruzione di quel responsabile del trattamento di eliminare i dati. Ciò richiede:

  • Un inventario documentato di ogni servizio di terze parti che riceve dati personali
  • Un meccanismo di eliminazione confermato per ciascuno (chiamata API, ticket di supporto, gestione automatizzata delle richieste degli interessati)
  • Evidenza che l’eliminazione sia stata completata

Backup. I backup sono il problema di cancellazione più comunemente trascurato. Se si effettuano backup giornalieri del database con un periodo di conservazione di 90 giorni, una richiesta di eliminazione soddisfatta nel database live non sarà soddisfatta nei backup fino a quando non scadono. La posizione dell’ICO è che i backup ripristinati dopo la cancellazione non devono reintrodurre i dati personali eliminati. Gli approcci pratici includono: escludere i record eliminati dagli export di backup dove fattibile, implementare processi di eliminazione specifici per i backup, o usare la crittografia a livello di campo ed eliminare la chiave (rendendo i dati illeggibili, il che si avvicina allo standard della cancellazione).

Eccezioni. Il diritto alla cancellazione non è assoluto. Si possono conservare i dati necessari per rivendicazioni legali, conformità statutaria (ad esempio, registri finanziari ai sensi del Companies Act) o finalità di interesse pubblico. Documentare l’eccezione e comunicarla all’interessato quando si rifiuta o si adempie parzialmente a una richiesta di cancellazione.

Rilevamento delle violazioni e il requisito di notifica nelle 72 ore

L’Articolo 33 del GDPR del Regno Unito richiede di notificare all’ICO entro 72 ore dal momento in cui si viene a conoscenza di una violazione dei dati personali che probabilmente comporta un rischio per le persone. Non si tratta di 72 ore dall’occorrenza della violazione. Sono 72 ore da quando se ne è venuti a conoscenza. Questa distinzione crea un incentivo diretto a costruire capacità di rilevamento delle violazioni, perché l’orologio inizia a ticchettare quando la si scopre.

Cosa registrare per il rilevamento delle violazioni. L’architettura di logging dovrebbe catturare:

  • Eventi di autenticazione: accessi riusciti e falliti, sfide MFA, reimpostazioni password
  • Fallimenti di autorizzazione: richieste negate a causa di verifiche dei permessi
  • Accesso ai dati: chi ha acceduto a quali dati personali e quando, in particolare export di massa o volumi di query insoliti
  • Modifiche alla configurazione: modifiche ai permessi degli utenti, alle chiavi di crittografia o alle impostazioni di conservazione dei dati
  • Schemi anomali: accessi da indirizzi IP insoliti o in orari insoliti, letture ad alto volume di tabelle di dati personali

Cosa non registrare. Non registrare i valori dei dati personali nei log dell’applicazione. I log di debug che registrano corpi di richiesta completi, query del database con valori di parametri sostituiti, o dati del modulo inseriti dall’utente creano archivi di dati personali secondari difficili da gestire e che rientrano essi stessi nell’ambito del GDPR. Registrare identificatori (ID utente, ID sessione, ID richiesta) piuttosto che valori.

1# Sbagliato: registra l'indirizzo email effettivo
2logger.debug(f"Login attempt for user {request.form['email']}")
3
4# Corretto: registra solo un identificatore
5logger.debug(f"Login attempt, user_id={user.id}, request_id={request_id}")

Pianificazione della risposta alle violazioni. Il logging abilita il rilevamento, ma è necessario un processo documentato per ciò che accade quando si rileva una violazione. Chi viene notificato internamente? Chi prende la decisione di notifica all’ICO? Quali informazioni deve contenere la notifica all’ICO? Costruire questo processo prima di averne bisogno.

Conformità delle API di terze parti

Titolare vs responsabile del trattamento. Se si usa un servizio di terze parti che tratta dati personali per conto proprio (un fornitore di email transazionali, un fornitore di infrastrutture cloud, un processore di pagamento), sono responsabili del trattamento e si è il titolare. Si è responsabili della loro conformità al GDPR del Regno Unito in quel contesto.

Accordi sul trattamento dei dati. È necessario avere in essere un Accordo sul trattamento dei dati (DPA) scritto con ogni servizio di terze parti che tratta dati personali per conto proprio. La maggior parte dei principali fornitori SaaS (AWS, Mailchimp, Stripe, Twilio, SendGrid) offre DPA standard. Firmarli e conservarli. Se un fornitore non riesce a produrre un DPA, non è possibile usarlo legalmente per trattare dati personali ai sensi del GDPR del Regno Unito.

Sub-responsabili del trattamento. Il DPA con un responsabile del trattamento dovrebbe elencare i suoi sub-responsabili del trattamento (i servizi che a loro volta usano per trattare i propri dati). Ad esempio, il fornitore di email transazionali può usare l’infrastruttura AWS. Non è necessario avere un DPA diretto con i sub-responsabili del trattamento, ma è necessario essere consapevoli di chi sono e dove i dati vengono trattati geograficamente per finalità di conformità ai trasferimenti.

Meccanismi di trasferimento. Se un servizio di terze parti tratta dati al di fuori del Regno Unito o dell’UE, è necessario un meccanismo di trasferimento legale in essere. Per i trasferimenti dal Regno Unito, si tratta attualmente di meccanismi specifici del Regno Unito (accordi internazionali di trasferimento dati del Regno Unito, o affidamento sulle decisioni di adeguatezza del Regno Unito dove disponibili). Verificare le opzioni di residenza dei dati e la documentazione di trasferimento di ciascun servizio.

Controllo degli accessi

Principio del privilegio minimo. Gli utenti del database usati dall’applicazione dovrebbero avere i permessi minimi richiesti: lettura e scrittura su tabelle specifiche, non accesso amministrativo. Creare credenziali del database separate per i servizi a lettura intensa (reporting, analisi) e per i servizi a scrittura intensa (applicazione lato utente). Questo limita il raggio di esplosione di una credenziale compromessa.

Controllo degli accessi basato sui ruoli. Implementare RBAC nell’applicazione e rivedere regolarmente le assegnazioni dei ruoli. I ruoli tendono ad accumulare permessi nel tempo; un audit periodico rispetto a ciò di cui ogni ruolo ha effettivamente bisogno rileva il privilege creep.

Log di audit per l’accesso ai dati. Per i dati sensibili, implementare il logging di audit a livello di applicazione che registra quale utente autenticato ha acceduto a quale record di dati personali e quando. Questo è separato dai log di errore dell’applicazione e dovrebbe essere a prova di manomissione (write-once o solo di append, con accesso limitato dal codice dell’applicazione).

Checklist per sviluppatori: 10 controlli tecnici da implementare

  1. Hashing delle password. Usare bcrypt (fattore di costo 12+) o Argon2id. Rimuovere immediatamente qualsiasi hashing di password MD5 o SHA-1.
  2. Crittografia a riposo. Abilitare TDE a livello di database e implementare la crittografia a livello di campo AES-256-GCM per i dati personali altamente sensibili con chiavi in un KMS gestito.
  3. Configurazione TLS. Applicare TLS 1.2 minimo, TLS 1.3 predefinito, HSTS con max-age di un anno, nessun contenuto misto.
  4. Audit di minimizzazione dei dati. Rivedere ogni campo nello schema del database che contiene dati personali. Rimuovere o smettere di raccogliere qualsiasi campo senza un caso d’uso documentato e attivo.
  5. Implementazione dell’eliminazione definitiva. Costruire l’eliminazione a cascata verificata per tutti i dati personali collegati a un utente. Testare che l’eliminazione rimuova effettivamente i record e non li contrassegni semplicemente.
  6. Inventario dei DPA di terze parti. Elencare ogni SaaS o servizio cloud che riceve dati personali. Confermare l’esistenza di un DPA firmato per ciascuno. Rimuovere qualsiasi servizio che non riesce a fornirne uno.
  7. Igiene del logging. Verificare i log dell’applicazione per i dati personali. Rimuovere i valori dei dati personali dall’output del log a ogni livello di log. Registrare solo identificatori.
  8. Logging per il rilevamento delle violazioni. Implementare il logging strutturato per gli eventi di autenticazione, i fallimenti di autorizzazione e l’accesso ai dati in massa. Configurare avvisi per schemi anomali.
  9. Revisione del controllo degli accessi. Verificare le credenziali del database e i ruoli dell’applicazione rispetto al principio del privilegio minimo. Rimuovere l’accesso amministrativo dagli utenti del database dell’applicazione.
  10. Pseudonimizzazione per l’analisi. Sostituire gli identificatori utente diretti nelle analisi e nelle chiamate di tracciamento di terze parti con valori hash HMAC usando un segreto specifico del sito.

Punti chiave

  • I requisiti tecnici del GDPR del Regno Unito sono identici a quelli del GDPR dell’UE. Dopo la Brexit, l’ICO li applica e si deve seguire le linee guida specifiche dell’ICO per le notifiche e i trasferimenti.
  • L’Articolo 32 richiede misure tecniche appropriate proporzionate al rischio. Per la maggior parte delle applicazioni, ciò significa crittografia forte, controlli degli accessi, pseudonimizzazione e rilevamento documentato delle violazioni.
  • La minimizzazione dei dati è una decisione a livello di campo presa dagli sviluppatori, non un’astrazione legale. Se non si riesce a giustificare la raccolta di un campo, non raccoglierlo.
  • Il diritto alla cancellazione richiede l’eliminazione effettiva a cascata attraverso tutti i sistemi inclusi backup e sub-responsabili del trattamento terzi. Un flag di eliminazione logica non soddisfa l’obbligo.
  • Non registrare i valori dei dati personali. Registrare gli identificatori. I file di log sono essi stessi un archivio di dati personali e uno dei vettori di violazione più comunemente trascurati.
  • Avere un DPA firmato con ogni servizio di terze parti che tocca i dati personali. Se un fornitore non riesce a produrne uno, non è possibile usarlo legalmente per tale scopo.

Domande Frequenti (FAQ)

Il GDPR del Regno Unito si applica se tutti i miei utenti sono al di fuori del Regno Unito? Il GDPR del Regno Unito si applica se si è stabiliti nel Regno Unito, indipendentemente da dove si trovano gli utenti. Si applica anche alle organizzazioni al di fuori del Regno Unito che offrono beni o servizi a persone nel Regno Unito o monitorano il comportamento di persone nel Regno Unito. Se si è uno sviluppatore con sede nel Regno Unito che costruisce per un pubblico non britannico, il GDPR del Regno Unito si applica alle attività di trattamento.

La crittografia è obbligatoria ai sensi del GDPR del Regno Unito? La crittografia è esplicitamente elencata nell’Articolo 32(1)(a) come misura raccomandata. Non è un requisito assolutamente obbligatorio, perché il regolamento richiede misure “appropriate al rischio”. In pratica, per qualsiasi applicazione che gestisce dati personali su Internet, sarebbe molto difficile giustificare all’ICO il mancato ciframento dei dati in transito e a riposo. Trattarla come richiesta.

Cosa conta come violazione dei dati personali che richiede la notifica all’ICO? Una violazione dei dati personali è qualsiasi distruzione accidentale o illecita, perdita, alterazione, divulgazione non autorizzata o accesso non autorizzato a dati personali. Ciò include un bucket S3 mal configurato che ha esposto pubblicamente i record, un attacco di phishing che ha dato a un aggressore accesso all’account email contenente dati dei clienti, e l’eliminazione accidentale di record senza backup. Non tutte le violazioni richiedono la notifica all’ICO: solo quelle che probabilmente comportano un rischio per le persone. Le violazioni ad alto rischio richiedono anche la notifica diretta alle persone interessate.

Per quanto tempo è necessario conservare i dati personali? Il GDPR del Regno Unito non specifica periodi di conservazione. I dati devono essere conservati solo per il tempo necessario alla finalità per cui sono stati raccolti. Definire periodi di conservazione per ogni categoria di dati in possesso, documentarli nell’informativa sulla privacy e implementare l’eliminazione automatizzata. I registri finanziari vengono tipicamente conservati per sei anni ai sensi del Companies Act. I registri del consenso di marketing dovrebbero essere conservati fino al ritiro o alla scadenza del consenso.

Abbiamo bisogno di un Responsabile della Protezione dei Dati? Un DPO è obbligatorio per le autorità pubbliche, le organizzazioni che trattano dati personali sensibili su larga scala e le organizzazioni che effettuano monitoraggio sistematico su larga scala. Per la maggior parte delle aziende software britanniche, un DPO non è obbligatorio ma è consigliabile se si trattano volumi significativi di dati personali. L’ICO fornisce linee guida specifiche su questa soglia sul suo sito web.

Qual è la sanzione massima per la non conformità al GDPR del Regno Unito? L’ICO può emettere sanzioni fino a 17,5 milioni di sterline o il 4% del fatturato annuo globale (qualunque sia il più alto) per le infrazioni più gravi. Sanzioni di livello inferiore fino a 8,7 milioni di sterline o il 2% del fatturato globale si applicano a violazioni meno gravi. In pratica, la maggior parte delle sanzioni dell’ICO sono significativamente inferiori al massimo e sono calibrate in base alla gravità della violazione, alla cooperazione dell’organizzazione e alle misure adottate per rimediare al problema.