I dati sono spesso l’asset più prezioso di un’azienda e, insieme, la sua responsabilità più pesante: una violazione colpisce due volte, sul piano operativo e su quello legale. In Italia il conto medio di una violazione di dati è di 3,31 milioni di euro (IBM Cost of a Data Breach 2025). Per chi decide, la domanda non è se servano misure di protezione — il GDPR le richiede — ma se quelle già adottate proteggano davvero qualcosa o siano rimaste una dichiarazione d’intenti.
Cosa chiede davvero il GDPR
Il GDPR non prescrive una lista di tecnologie. L’articolo 32 chiede misure tecniche e organizzative «adeguate al rischio», e cita cifratura e pseudonimizzazione come esempi possibili, non come obblighi. Il principio che regge tutto è l’accountability (art. 5, par. 2, e art. 24): essere conformi e poterlo dimostrare. Ed è qui che la carta mostra i suoi limiti. Il registro dei trattamenti documenta le attività di trattamento; non dice dove si trovano i dati, chi vi accede e con quali protezioni. Un registro che dichiara cifratura e controllo degli accessi mai implementati non è una difesa: davanti a un’ispezione diventa un’aggravante, con sanzioni che a seconda della violazione possono arrivare alla fascia più alta prevista dall’art. 83 GDPR. La parte documentale e organizzativa è coperta dalla cybercompliance; qui contano le misure tecniche che devono esistere davvero.
Non solo GDPR: la protezione dei dati come requisito di filiera
La protezione dei dati, fatta bene, è anche un argomento commerciale. I clienti più strutturati chiedono garanzie ai fornitori con questionari e requisiti contrattuali, e hanno le loro ragioni: la sicurezza di un fornitore diventa la loro, e un partner con accesso ai sistemi è un canale d’ingresso già fidato. Rispondere ai loro questionari con misure verificabili, invece che con autodichiarazioni, accorcia le trattative e consolida i rapporti.
Cosa facciamo
- Mappiamo dove vivono i dati critici dell’azienda e chi vi accede — l’analisi del terreno che precede qualunque struttura: non si protegge ciò che non si conosce.
- Applichiamo la cifratura con standard di settore — AES-256 per i dati a riposo, TLS per quelli in transito: se un dispositivo viene rubato, un backup finisce nelle mani sbagliate o il traffico viene intercettato, i dati restano illeggibili.
- Configuriamo la Data Loss Prevention (DLP) con policy calibrate sui flussi reali dell’azienda, non su regole generiche: controlla i dati in uscita e blocca i trasferimenti indebiti, per errore o intenzionali.
- Mettiamo ordine negli accessi con autenticazione multi-fattore (MFA) e permessi basati sui ruoli (RBAC) — ogni persona accede solo a ciò che serve alla sua funzione — e attiviamo il logging degli accessi, così ogni tentativo, riuscito o fallito, lascia traccia.
- Negli ambienti di sviluppo e test, dove le informazioni reali non dovrebbero mai circolare, proteggiamo i dati con data masking e tokenization.
Cosa ottieni
- Un inventario dei dati critici con i relativi rischi: non coincide con il registro dei trattamenti, ma è la base concreta per alimentarlo e per dimostrare l’accountability che il GDPR richiede.
- Misure tecniche proporzionate al valore di ciò che proteggono, integrate in larga parte negli strumenti già in uso.
- Una visione d’insieme di chi accede a cosa e di quali policy sono attive, con log dei tentativi di accesso utilizzabili in un audit o dopo un incidente.
- Un impatto più contenuto se la violazione avviene comunque: dati cifrati a riposo e accessibili solo a chi di dovere valgono molto meno per chi li sottrae — e la sola cifratura ne riduce il costo medio, in Italia, di circa 249.000 euro (IBM Cost of a Data Breach 2025).
La protezione dei dati funziona quando è cucita sui trattamenti reali dell’azienda, ed è lì che conviene partire. Descrivici dalla pagina contatti che tipo di dati gestisci e come: ti indichiamo le misure che mancano e quelle che puoi semplificare. E se sospetti che una violazione sia già in corso, non partire dalla mappatura: passa dal CSIRT.
// domande frequenti
Il GDPR obbliga a cifrare i dati aziendali?
No. L'articolo 32 del GDPR richiede misure tecniche e organizzative «adeguate al rischio» e cita la cifratura come esempio possibile, non come obbligo. Per dati sanitari, finanziari o giudiziari la cifratura è di fatto lo standard atteso. Ciò che conta è poter dimostrare che la scelta — cifrare o no — discende da una valutazione del rischio documentata.
Registro dei trattamenti e inventario dei dati sono la stessa cosa?
No. Il registro dei trattamenti documenta le attività di trattamento: che cosa l'organizzazione fa con i dati personali e perché. Un inventario dei dati è una mappa tecnica: dove i dati risiedono, chi vi accede, con quali protezioni. Il GDPR disciplina il primo (art. 30), ma è il secondo a renderlo veritiero e a sostenere l'accountability: senza sapere dove vivono i dati, il registro descrive intenzioni, non realtà.
Abbiamo già DPO e registro dei trattamenti: questo servizio cosa aggiunge?
La documentazione dichiara le misure; l'attuazione tecnica le rende verificabili. Un registro che cita cifratura e controllo degli accessi mai configurati non protegge nulla e, in caso di ispezione o di violazione, pesa contro l'azienda invece di difenderla. Il lavoro utile parte dal confronto tra ciò che i documenti dichiarano e ciò che i sistemi fanno davvero, e colma lo scarto.
Che differenza c'è tra data masking e tokenization?
Il data masking sostituisce i dati reali con dati fittizi ma realistici, utilizzabili per sviluppo, test e analisi senza esporre le informazioni originali. La tokenization sostituisce il dato sensibile con un token privo di valore al di fuori del sistema che lo ha generato: chi intercetta il token non ottiene un dato utilizzabile. Spesso si usano insieme: il masking negli ambienti di sviluppo e test, la tokenization nei flussi operativi che trattano dati sensibili.
È un intervento una tantum o un servizio continuativo?
Entrambe le cose. Mappatura dei dati, scelta e implementazione delle misure sono un progetto con un inizio e una fine. La protezione, però, degrada se nessuno la mantiene: gli accessi vanno rivisti quando le persone cambiano ruolo, le policy DLP quando cambiano i flussi, le misure quando arrivano nuovi trattamenti. CyberQuake lavora in entrambe le modalità: intervento singolo o supporto continuativo con revisioni periodiche.
Le misure si integrano con i sistemi che usiamo già, come Microsoft 365 o Google Workspace?
Sì, ed è il criterio guida: cifratura, MFA, controllo degli accessi e buona parte delle policy DLP si configurano sugli strumenti già in uso — Microsoft 365, Google Workspace, gestionali e infrastrutture esistenti — senza imporre piattaforme nuove. Componenti aggiuntivi si introducono solo dove gli strumenti attuali non bastano, e la scelta viene motivata in termini di rischio coperto, non di tecnologia da vendere.