Articolo 32 GDPR e WordPress: cosa significa «sicurezza adeguata»

L'articolo 32 del GDPR non indica un plugin, un'impostazione del server o una lunghezza minima delle password. Chiede una sicurezza adeguata al rischio, e per la maggior parte dei siti WordPress questo si traduce in un elenco breve e concreto: HTTPS ovunque, software aggiornato, accessi personali con autenticazione a due fattori, backup che sono stati davvero ripristinati e controlli regolari. Chi mette in pratica queste misure ed è in grado di dimostrarlo copre già gran parte di ciò che l'articolo 32 si aspetta da un tipico sito WordPress.

Questa guida traduce l'articolo 32, paragrafo 1, lettere a)–d), in misure concrete per WordPress, punto per punto. Tratta anche i due obblighi collegati: documentare le misure adottate (responsabilizzazione) e assicurarsi che provider di hosting e agenzia facciano la loro parte.

GDPR e sicurezza WordPress: che cosa dice l'articolo 32

L'articolo 32 del GDPR obbliga sia il titolare del trattamento (l'azienda) sia ogni responsabile del trattamento (per esempio il provider di hosting) a mettere in atto misure tecniche e organizzative adeguate. Che cosa sia adeguato dipende dallo stato dell'arte, dai costi di attuazione, dalla natura, dall'oggetto, dal contesto e dalle finalità del trattamento, oltre che dal rischio per le persone i cui dati vengono trattati.

L'articolo elenca poi quattro elementi che queste misure comprendono, «tra le altre, se del caso»:

• a) la pseudonimizzazione e la cifratura dei dati personali;
• b) la capacità di assicurare su base permanente la riservatezza, l'integrità, la disponibilità e la resilienza dei sistemi e dei servizi;
• c) la capacità di ripristinare tempestivamente la disponibilità e l'accesso ai dati personali in caso di incidente;
• d) una procedura per testare, verificare e valutare regolarmente l'efficacia delle misure.

Alla base c'è l'articolo 5, paragrafo 1, lettera f): i dati personali vanno trattati in modo da garantirne un'adeguata sicurezza. E un tipico sito WordPress tratta più dati personali di quanto il suo proprietario immagini: account utente, commenti con nome, indirizzo email e indirizzo IP, invii dei moduli di contatto, iscrizioni alla newsletter, ordini WooCommerce e log del server.

Un approccio basato sul rischio: stato dell'arte e costi

L'articolo 32 è volutamente basato sul rischio. Il sito aziendale con un solo modulo di contatto, il negozio online con migliaia di account clienti e l'area riservata che conserva informazioni sanitarie non richiedono lo stesso impegno, ma ciascuno ha bisogno di un livello commisurato a ciò che potrebbe andare storto. L'articolo 32, paragrafo 2, indica i rischi da valutare: distruzione, perdita, modifica, divulgazione non autorizzata o accesso, in modo accidentale o illegale, ai dati personali.

«Stato dell'arte» va inteso come «consolidato e ampiamente disponibile», non come «il prodotto più costoso sul mercato». HTTPS, versioni software supportate e accesso a due fattori per gli amministratori sono oggi stato dell'arte, e costano poco. I costi possono giustificare un piccolo blog senza un web application firewall di classe enterprise. Difficilmente giustificano la rinuncia alle basi.

Articolo 32, paragrafo 1, lettere a)–d): le misure WordPress

La tabella collega ogni lettera alle misure WordPress più comuni e alle prove che conviene conservare.

a) Cifratura e pseudonimizzazione

L'intero sito va servito solo via HTTPS, compresi /wp-admin/ e tutti i moduli; HSTS si aggiunge quando questa configurazione funziona in modo affidabile. Le password non vengono cifrate ma trasformate in hash, ed è l'approccio corretto: da WordPress 6.8 l'hash delle password degli utenti viene calcolato con bcrypt.

I backup sono la copia dei dati personali che più spesso si dimentica. Vanno cifrati e conservati lontano dal server web. Una vera pseudonimizzazione è rara su un tipico sito WordPress, ma alcune misure affini riducono il rischio: troncare gli indirizzi IP negli strumenti di analisi e nei log, e non tenere nel database gli invii dei moduli di contatto più a lungo del necessario. I dati che non si conservano non possono essere sottratti.

b) Riservatezza, integrità, disponibilità e resilienza

Prima di tutto gli aggiornamenti. Patchstack, un fornitore di soluzioni di sicurezza, ha contato 11.334 nuove vulnerabilità nell'ecosistema WordPress nel 2025, il 91% delle quali nei plugin. Per quelle sfruttate più intensamente, la mediana ponderata del tempo fino allo sfruttamento di massa è stata di cinque ore (report di Patchstack). Conviene attivare gli aggiornamenti automatici dove hanno senso (il core li offre per plugin e temi da WordPress 5.5) ed eliminare i plugin inutilizzati. La nostra guida ai plugin vulnerabili spiega come verificarli.

Il secondo pilastro è il controllo degli accessi: un account personale per ogni persona, il ruolo più basso sufficiente (Editore, Autore o Collaboratore invece di Amministratore) e l'autenticazione a due fattori per ogni amministratore, che il core di WordPress non include. Per proteggere l'integrità, gli editor dei file nella bacheca si rimuovono da wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );

Di tanto in tanto conviene confrontare i file del core con i checksum ufficiali (wp core verify-checksums con WP-CLI). Per disponibilità e resilienza serve un hosting con risorse e monitoraggio adeguati. Nessun plugin può assorbire un attacco DDoS di grandi dimensioni: è un compito per una CDN o un firewall perimetrale. La guida ufficiale all'hardening di WordPress elenca altre impostazioni lato server.

c) Ripristinare la disponibilità dopo un incidente

Un backup conta solo se si riesce a ripristinarlo. Occorre salvare file e database, tenere almeno una copia esterna e fuori dalla portata dell'account amministratore di WordPress, e provare un ripristino completo su un sito di staging. Conviene annotare quanto tempo ha richiesto: «tempestivamente» si sostiene molto meglio con un tempo di ripristino misurato che con una speranza.

d) Testare, verificare e valutare regolarmente

Il GDPR non fissa una cadenza, quindi tocca all'azienda stabilirne una e rispettarla. Un punto di partenza ragionevole per una piccola impresa: una scansione automatica ogni settimana, una revisione di account utente e plugin ogni trimestre, un test di ripristino due volte l'anno e una verifica aggiuntiva dopo ogni incidente o modifica importante. Ciò che è stato trovato e corretto va registrato, con le date.

Il plugin Security Audit & Compliance di secaudit.eu può coprire una parte dei test: cerca malware, file del core modificati, plugin obsoleti e password deboli, collega i risultati all'art. 32 del GDPR e mostra un riepilogo di conformità a schermo; i report firmati (PDF, CSV) sono inclusi in secaudit.eu Pro. Una scansione supporta la documentazione; da sola non rende un sito conforme.

Responsabilizzazione: documentare le misure (art. 5, par. 2)

In base all'articolo 5, paragrafo 2, il titolare del trattamento deve essere in grado di comprovare il rispetto delle norme. In pratica serve un documento sulla sicurezza breve e sempre aggiornato, non un faldone che nessuno legge. Dovrebbe contenere:

• Un inventario: hosting, versione di WordPress, plugin, temi, servizi esterni
• Chi ha accesso, con quale ruolo, e chi approva i nuovi account
• Le misure per le lettere da a) a d), con la nota sul rischio che le giustifica
• Un registro degli aggiornamenti e le date di scansioni, revisioni degli accessi e test di ripristino
• La procedura per gli incidenti, compresa la notifica del data breach entro 72 ore
• Gli accordi sul trattamento dei dati con i responsabili del trattamento

Il documento va rivisto una volta l'anno e ogni volta che il sito cambia in modo significativo. La nostra checklist di sicurezza WordPress è un buon punto di partenza per l'inventario.

Hosting e agenzie: responsabili del trattamento ai sensi dell'art. 28

Il provider di hosting conserva il database e i backup. Un'agenzia o un freelance con accesso da amministratore può leggere ogni dato dei clienti. Entrambi agiscono di norma come responsabili del trattamento, e con ciascuno serve quindi un accordo sul trattamento dei dati ai sensi dell'articolo 28. Lo stesso articolo consente di ricorrere solo a responsabili che presentino garanzie sufficienti di misure tecniche e organizzative adeguate, e l'accordo deve obbligarli ad adottare le misure richieste dall'articolo 32.

Meglio porre domande concrete che affidarsi a un modello standard. Dove vengono conservati i backup, e per quanto tempo? L'accesso a due fattori è obbligatorio sul pannello di hosting e sugli account dell'agenzia? Con quale rapidità verrà comunicato un incidente di sicurezza? Quando il contratto con un'agenzia termina, i suoi account vanno rimossi e le credenziali condivise cambiate il giorno stesso.

Le violazioni degli articoli da 25 a 39, compreso l'articolo 32, possono essere sanzionate fino a 10 milioni di euro o fino al 2% del fatturato mondiale annuo, se superiore (art. 83, par. 4, lett. a). Il momento in cui la documentazione servirà più probabilmente, però, è dopo un incidente, quando l'autorità di controllo (in Italia il Garante per la protezione dei dati personali) chiederà quali misure erano in atto.

Domande frequenti

L'articolo 32 richiede un plugin di sicurezza specifico?

No. Richiede misure adeguate, non prodotti. Un plugin può aiutare per alcune di esse, come l'accesso a due fattori o le scansioni, ma aggiornamenti, backup, revisioni degli accessi e contratti ne fanno parte allo stesso modo.

L'articolo 32 si applica a un piccolo sito senza account utente?

Sì, non appena il sito tratta dati personali, per esempio invii dei moduli di contatto, commenti o log del server con indirizzi IP. Le misure crescono con il rischio.

HTTPS basta per la lettera a)?

No. HTTPS protegge i dati in transito. Backup, esportazioni e database sul server richiedono una protezione propria.

Questo articolo ha carattere informativo generale e non costituisce consulenza legale.