Il tuo sito raccoglie nomi, email, indirizzi IP, richieste di contatto. Forse anche dati sanitari o fiscali. In tutti questi casi il GDPR si applica — e non basta avere un cookie banner per essere in regola.
"CMS GDPR compliant" è una di quelle espressioni usate spesso a sproposito. Qualcuno la usa per dire che il CMS ha un plugin per i cookie. Altri per dire che c'è una privacy policy. Nessuna delle due cose è sufficiente.
Questo articolo spiega cosa significa davvero conformità GDPR a livello tecnico, cosa deve fare il tuo CMS per soddisfarla, e perché la strada dei plugin su WordPress è strutturalmente rischiosa.
Vuoi sapere se il tuo sito è conforme?
Analizziamo gratuitamente la struttura tecnica del tuo sito e ti diciamo cosa manca per essere GDPR compliant.
Cosa significa davvero "CMS GDPR compliant"
Il GDPR — Regolamento Generale sulla Protezione dei Dati, in vigore dal 25 maggio 2018 — non certifica i CMS. Non esiste un timbro ufficiale che dice "questo software è conforme". La conformità dipende da come il sistema raccoglie, tratta, conserva e protegge i dati personali nella tua specifica configurazione.
Un CMS può facilitare la conformità oppure renderla strutturalmente difficile. La differenza sta nell'architettura, non nelle dichiarazioni del vendor.
Il titolare del trattamento — cioè tu, come azienda o professionista che gestisce il sito — è responsabile della conformità. Non il tuo hosting provider, non il developer che ha installato il CMS, non il plugin che gestisce i cookie. Tu.
Questo significa che scegliere un CMS tecnicamente adeguato non è una questione estetica o di preferenza: è un requisito operativo con implicazioni legali dirette.
I 6 requisiti tecnici che il tuo CMS deve soddisfare
1. Gestione consensi documentata e revocabile
Il GDPR richiede che il consenso al trattamento dei dati sia libero, specifico, informato e inequivocabile. E revocabile in qualsiasi momento con la stessa facilità con cui è stato dato.
A livello tecnico questo significa che il CMS deve registrare quando e come l'utente ha espresso il consenso — con timestamp, versione dell'informativa accettata e canale — e deve permettere all'utente di revocarlo senza dover contattare un indirizzo email o compilare un modulo cartaceo.
Un banner cookie che imposta un cookie accepted=true senza registrare nulla non è sufficiente. Un sistema che non permette la revoca granulare per finalità non è sufficiente.
2. Log degli accessi ai dati
Chi ha avuto accesso ai dati personali degli utenti, quando, e da quale dispositivo? Il GDPR richiede misure di sicurezza adeguate, e la tracciabilità degli accessi è parte integrante di queste misure — soprattutto per siti che trattano categorie particolari di dati come dati sanitari, dati giudiziari o informazioni finanziarie.
Il CMS deve permettere di sapere chi ha visualizzato o modificato un record contenente dati personali, con log conservati per un periodo adeguato.
3. Crittografia dei dati in transito e a riposo
HTTPS è il minimo — e ormai è obbligatorio. Ma la crittografia dei dati a riposo, cioè dei dati conservati nel database, è un requisito che molti siti ignorano.
Se il database viene compromesso e i dati degli utenti sono in chiaro, l'impatto sulla notifica al Garante e sulle sanzioni è significativamente diverso rispetto a dati crittografati con algoritmi robusti. La crittografia a riposo riduce la gravità della violazione e quindi l'entità delle misure correttive richieste.
4. Procedura di data breach documentata
Il GDPR impone la notifica al Garante della Privacy entro 72 ore dalla scoperta di una violazione che comporti rischi per i diritti degli interessati. Non dalla violazione — dalla scoperta.
Il CMS deve supportare questa procedura con strumenti che permettano di ricostruire rapidamente cosa è successo, quali dati sono stati coinvolti, quante persone sono state interessate. Senza log strutturati e senza strumenti di audit, ricostruire l'incidente in 72 ore è operativamente impossibile.
5. Portabilità e cancellazione dei dati su richiesta
Gli utenti hanno il diritto di ricevere i propri dati in formato leggibile da macchina (diritto alla portabilità) e di richiederne la cancellazione (diritto all'oblio). Il CMS deve supportare tecnicamente queste operazioni.
In pratica: il sistema deve permettere di esportare tutti i dati riferibili a una specifica persona fisica e di cancellarli in modo definitivo — non solo de-indexarli o renderli invisibili nel pannello, ma eliminarli dal database e dai backup.
6. Minimizzazione dei dati raccolti
Il GDPR introduce il principio di minimizzazione: raccogliere solo i dati strettamente necessari alla finalità dichiarata. Un form di contatto che raccoglie data di nascita, numero di telefono fisso e professione quando serve solo nome ed email viola questo principio.
Il CMS deve permettere di configurare i form in modo da raccogliere solo i campi necessari, senza forzare la raccolta di dati aggiuntivi per ragioni tecniche o di sistema.
Perché WordPress con plugin non è una soluzione affidabile
WordPress è costruito su un'architettura a plugin. La sicurezza, la privacy, la gestione dei consensi, i log degli accessi — tutto viene aggiunto attraverso estensioni di terze parti con cicli di aggiornamento indipendenti.
Il problema non è che i plugin siano intrinsecamente pericolosi. Il problema è strutturale: ogni plugin è un subprocessor separato, con la sua privacy policy, i suoi cookie, i suoi endpoint, il suo ciclo di aggiornamenti. Ogni plugin che raccoglie o tratta dati personali richiede un Accordo di Trattamento dei Dati (DPA) separato e va dichiarato nella lista dei subprocessor.
Un sito WordPress medio con 15-25 plugin attivi ha potenzialmente 15-25 subprocessor da gestire contrattualmente, monitorare e aggiornare. Nella pratica, nessuno lo fa.
Quando un plugin viene abbandonato dal developer, smette di ricevere aggiornamenti di sicurezza ma rimane installato e attivo — continuando a raccogliere dati, continuando a essere una superficie d'attacco, continuando a trasferire dati a server di cui non controlli più nulla.
Quanto ti costerebbe una perdita di dati?
Calcola in 10 secondi l'esposizione economica del tuo CMS
Il problema dei plugin di terze parti e dei subprocessor
Il GDPR impone che ogni soggetto che tratta dati personali per conto del titolare sia un responsabile del trattamento contrattualmente vincolato. In un ecosistema a plugin, questo significa che ogni plugin che invia dati a server esterni — analytics, form, chat, newsletter, mappe, font — deve essere coperto da un DPA firmato.
Google Fonts carica font da server Google e trasferisce l'indirizzo IP dell'utente negli USA. Un modulo di contatto che usa Mailchimp trasferisce i dati a Mailchimp. Un plugin di chat live invia i messaggi a server di terze parti. Ognuno di questi è un trasferimento di dati che richiede una base giuridica e un contratto.
In un CMS con architettura proprietaria e senza dipendenze esterne per le funzioni core, la lista dei subprocessor è controllabile e limitata. In un ecosistema a plugin, cresce in modo incontrollato ad ogni nuova installazione.
Cosa deve fare il titolare del sito in caso di data breach
Quando il sito viene compromesso e dati personali vengono o potrebbero essere stati esfiltrati, la sequenza è questa:
Primo — valutare immediatamente se la violazione comporta rischi per i diritti degli interessati. Se sì, scatta l'obbligo di notifica.
Secondo — notificare il Garante della Privacy entro 72 ore dalla scoperta, anche se non si hanno ancora tutti i dettagli. La notifica preliminare è accettata e aggiornabile.
Terzo — se la violazione comporta rischi elevati per gli interessati, comunicarlo direttamente alle persone coinvolte senza ingiustificato ritardo.
Quarto — documentare tutto: cosa è successo, quando è stato scoperto, quali dati erano coinvolti, quante persone, quali misure sono state adottate.
Il CMS che usi determina la tua capacità di rispettare questi tempi. Senza log strutturati, senza strumenti di audit, senza una procedura tecnica documentata, rispettare le 72 ore è impossibile nella pratica.
Come verificare se il tuo sito è davvero conforme
Questi sono i controlli minimi da fare:
-
Il sito usa HTTPS su tutte le pagine, incluse quelle di amministrazione?
-
I dati nel database sono crittografati o in chiaro?
-
Esiste un registro dei consensi con timestamp per ogni utente?
-
È possibile esportare tutti i dati di un singolo utente in formato strutturato?
-
È possibile cancellare definitivamente tutti i dati di un singolo utente, inclusi i backup?
-
Esiste un log degli accessi al pannello amministrativo?
-
Ogni plugin che tratta dati personali è coperto da un DPA firmato?
-
La lista dei subprocessor è aggiornata e disponibile?
-
Esiste una procedura documentata per la gestione di un data breach?
Se la risposta a più di due di queste domande è "non lo so" o "probabilmente no", il sito non è conforme — indipendentemente da cosa c'è scritto nella privacy policy.
KeideaCMS
KeideaCMS integra nativamente gestione consensi, log accessi, crittografia AES-256 e 2FA — senza plugin di terze parti da gestire.
KeideaCMS
KeideaCMS integra nativamente gestione consensi, log accessi, crittografia AES-256 e 2FA — senza plugin di terze parti da gestire.
