Quando un sito WordPress viene compromesso, la prima preoccupazione è tecnica: togliere il malware, chiudere l’accesso, tornare online. Ma se sul sito ci sono account di clienti, ordini, richieste inviate dai moduli di contatto o iscritti a una newsletter, c’è una seconda domanda che non può aspettare la fine della bonifica: l’attacco ha coinvolto dati personali, e se sì, bisogna notificarlo al Garante?
La risposta dipende da fatti precisi, e quei fatti emergono proprio dall’analisi forense: quali dati erano raggiungibili, se qualcuno li ha letti o esportati, per quanto tempo l’attaccante è rimasto dentro. In questo articolo vediamo cosa prevede il Regolamento europeo (GDPR) per le violazioni dei dati personali, chi deve fare cosa quando il sito è gestito da un’agenzia o da un fornitore di hosting, e come le prove raccolte sul server aiutano a prendere una decisione motivata entro i tempi previsti.
Questo articolo ha uno scopo informativo e non costituisce consulenza legale. La valutazione di una violazione e la decisione di notificarla spettano al titolare del trattamento, con il supporto del proprio responsabile della protezione dei dati (DPO), se nominato, o di un professionista qualificato.
Un sito hackerato è sempre un data breach?
L’articolo 4, punto 12, del GDPR definisce la violazione dei dati personali come «la violazione di sicurezza che comporta accidentalmente o in modo illecito la distruzione, la perdita, la modifica, la divulgazione non autorizzata o l’accesso ai dati personali trasmessi, conservati o comunque trattati». Servono entrambi: un incidente di sicurezza e dati personali coinvolti.
Non ogni compromissione, quindi, è un data breach. Un sito vetrina senza utenti né moduli che salvano dati, infettato con link di spam SEO, potrebbe non toccare alcun dato personale. Al contrario, una backdoor su un negozio online dà in genere all’attaccante accesso al database e quindi ai dati dei clienti: la possibilità concreta di accesso va considerata anche senza prove di lettura.
Le linee guida 9/2022 del Comitato europeo per la protezione dei dati (EDPB), nella versione 2.0 adottata il 28 marzo 2023, riprendono una classificazione utile anche in chiave tecnica. Si parla di violazione della riservatezza quando i dati sono divulgati o consultati senza autorizzazione, di violazione dell’integrità quando sono alterati, di violazione della disponibilità quando se ne perde l’accesso o vengono distrutti. Un ransomware che cifra il database viola la disponibilità, uno skimmer che copia i dati del checkout la riservatezza; un singolo incidente può ricadere in più categorie.
Quali dati personali tiene un sito WordPress
Per valutare il rischio bisogna prima sapere cosa c’è nel database, e spesso nemmeno chi gestisce il sito lo sa con precisione. Un’installazione WordPress tipica contiene più dati personali di quanto sembri:
wp_usersewp_usermeta: nomi utente, indirizzi email, nomi visualizzati, hash delle password (da WordPress 6.8 calcolati con bcrypt) e, per i clienti di WooCommerce, indirizzi di fatturazione e spedizione e numeri di telefono;wp_comments: nome, email e indirizzo IP di chi ha commentato, anche anni fa;- gli ordini di WooCommerce: con l’archiviazione ad alte prestazioni (HPOS) stanno nelle tabelle
wp_wc_ordersewp_wc_order_addresses, nelle versioni precedenti inwp_postsewp_postmeta, e comprendono anagrafiche, indirizzi, prodotti acquistati e IP del cliente; - le richieste inviate dai moduli, che molti plugin salvano nel database: Gravity Forms, per esempio, nelle tabelle
wp_gf_entryewp_gf_entry_meta; - iscritti alla newsletter, prenotazioni, candidature con curriculum allegato in
wp-content/uploads, registri di attività di plugin di sicurezza o di statistiche con gli IP dei visitatori.
I numeri delle carte di pagamento di solito non sono sul sito, perché i gateway li raccolgono con moduli ospitati sui propri server. Ma uno skimmer JavaScript nel checkout li intercetta nel browser del cliente prima che arrivino al gateway: in quel caso i dati non sono mai stati nel database, ma sono stati comunque sottratti, e la violazione c’è.
Titolare e responsabile: chi deve fare cosa
L’obbligo di notifica ricade sul titolare del trattamento, cioè l’azienda, il professionista o l’associazione che decide perché e come vengono trattati i dati: nel caso di un sito aziendale, di solito l’azienda proprietaria del sito. L’agenzia web che lo gestisce, il fornitore di hosting che amministra il server o il consulente che si occupa della manutenzione sono tipicamente responsabili del trattamento ai sensi dell’articolo 28, e il loro ruolo è definito dal contratto o dall’atto di nomina.
L’articolo 33, paragrafo 2, stabilisce che il responsabile «informa il titolare del trattamento senza ingiustificato ritardo dopo essere venuto a conoscenza della violazione». Le linee guida EDPB precisano che il responsabile non deve valutare il rischio prima di avvisare il titolare: deve solo accertare che la violazione sia avvenuta e comunicarlo, eventualmente fornendo i dettagli in più riprese man mano che emergono. La valutazione e la decisione di notificare restano al titolare, anche quando il contratto autorizza il responsabile a presentare la notifica per suo conto.
In pratica, questo significa che l’agenzia che scopre un’infezione sul sito di un cliente non può limitarsi a pulirlo e mandare la fattura: deve avvisare il cliente per tempo, con le informazioni che ha, perché i tempi del titolare iniziano a scorrere in genere proprio da quella comunicazione. Se lo stesso incidente riguarda più clienti, il responsabile deve informare ciascuno di loro.
Le 72 ore: da quando si diventa «consapevoli»
L’articolo 33, paragrafo 1, chiede al titolare di notificare la violazione all’autorità di controllo «senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui ne è venuto a conoscenza, a meno che sia improbabile che la violazione dei dati personali presenti un rischio per i diritti e le libertà delle persone fisiche». Oltre le 72 ore, la notifica va accompagnata dai motivi del ritardo.
Il punto delicato è il momento da cui si contano le ore. Secondo le linee guida EDPB, il titolare diventa consapevole quando ha «un ragionevole grado di certezza» che si sia verificato un incidente di sicurezza che ha compromesso dati personali. Dopo una prima segnalazione è ammesso un breve periodo di indagine per stabilire se la violazione c’è davvero, ma l’indagine deve iniziare subito: non si può rimandare l’analisi per spostare in avanti l’orologio. Se l’analisi conferma che un attaccante ha avuto accesso al database, da quel momento la consapevolezza c’è.
L’articolo 33, paragrafo 4, prevede inoltre che, se non è possibile fornire tutte le informazioni insieme, queste possano essere fornite «in fasi successive senza ulteriore ingiustificato ritardo». È la situazione normale in un incidente informatico: entro le 72 ore si notifica ciò che si sa, indicando che l’analisi è in corso, e si integra la notifica quando la ricostruzione è completa. Aspettare la fine della bonifica per avere un quadro perfetto è un errore.
Valutare il rischio con le prove forensi
Per valutare il rischio servono fatti, non impressioni, ed è qui che il lavoro tecnico diventa decisivo. Se, come consigliamo nell’articolo sulle prime due ore dopo un attacco, è stata fatta una copia forense di file, database e log prima di pulire, le domande principali hanno una risposta verificabile.
Da quando l’attaccante era dentro? La data del primo file malevolo, del primo accesso anomalo al pannello o della creazione di un amministratore fantasma delimita la finestra di esposizione. Una timeline dei file con le date di modifica e di cambio stato, confrontata con gli access log del server, permette di collocare gli eventi:
# Timeline dei file modificati nel periodo sospetto (sulla copia forense)
find ./copia/public_html -newermt '2026-08-01' -printf '%T+ %C+ %u %s %p\n' | sort
# Amministratori con data di registrazione
wp user list --role=administrator --fields=ID,user_login,user_email,user_registeredI dati sono stati letti o esportati? Alcune tracce indicano un’estrazione con buona probabilità: dump SQL o archivi comparsi nella cartella pubblica e scaricati, strumenti di gestione del database come Adminer caricati dall’attaccante, chiamate massive alle API REST di WooCommerce per clienti e ordini, risposte di dimensioni anomale verso un unico indirizzo IP.
# Dump e archivi creati nella document root nel periodo sospetto
find ./copia/public_html -newermt '2026-08-01' -type f \
\( -name '*.sql' -o -name '*.sql.gz' -o -name '*.zip' -o -name '*.tar.gz' \)
# Chi li ha scaricati, con esito e byte trasferiti (formato di log combined)
grep -E '\.(sql|sql\.gz|zip|tar\.gz) HTTP' ./copia/log/access.log* \
| awk '{print $1, $4, $7, $9, $10}'
# Richieste alle API REST di WooCommerce su clienti e ordini
grep -E '/wp-json/wc/v[0-9]+/(customers|orders)' ./copia/log/access.log* \
| awk '{print $1}' | sort | uniq -c | sort -rn | headL’assenza di tracce, però, non equivale a una prova di assenza. Una webshell che interroga il database direttamente e restituisce l’output in una risposta POST lascia nei log solo una riga con la dimensione della risposta, e molti hosting conservano i log per pochi giorni. In questi casi la valutazione deve partire da ciò che l’attaccante poteva fare: con un accesso in esecuzione di codice PHP, poteva leggere l’intero database. Nei nostri interventi l’analisi dei log è assistita da modelli di intelligenza artificiale eseguiti in locale, senza che i dati del cliente lascino l’infrastruttura, ma la conclusione resta un giudizio da motivare per iscritto.
Che dati e quante persone? Il numero di utenti, ordini e voci dei moduli nella finestra di esposizione è indispensabile per la notifica. Gli elementi che le linee guida indicano per valutare la gravità sono il tipo di violazione, la natura e la quantità dei dati, la facilità di identificare le persone, la gravità delle conseguenze, eventuali categorie vulnerabili come i minori, il numero di interessati.
Notificare al Garante: la procedura online
In Italia l’autorità di controllo è il Garante per la protezione dei dati personali. Con il provvedimento del 27 maggio 2021, dal 1° luglio 2021 la notifica si presenta esclusivamente con la procedura telematica disponibile sul portale dei servizi online del Garante. La pagina del Garante dedicata al data breach raccoglie le istruzioni, il modello di notifica (da usare solo come anteprima, non per l’invio) e uno strumento di autovalutazione che aiuta a capire quali adempimenti scattano dopo un incidente.
Il contenuto minimo della notifica è fissato dall’articolo 33, paragrafo 3: la natura della violazione, con le categorie e il numero approssimativo di interessati e di registrazioni coinvolte; il nome e i contatti del DPO o di un altro punto di contatto; le probabili conseguenze; le misure adottate o proposte per porvi rimedio e attenuarne gli effetti. Le misure adottate, per un sito, sono la bonifica, il cambio delle credenziali e l’hardening successivo.
Un consiglio pratico: tenere un documento condiviso tra tecnici e referente privacy in cui ogni fatto accertato è annotato con data, ora e fonte.
Comunicare agli interessati quando il rischio è elevato
La notifica al Garante e la comunicazione alle persone coinvolte sono due obblighi distinti, con soglie diverse. L’articolo 34 prevede che, quando la violazione è suscettibile di presentare un rischio elevato per i diritti e le libertà delle persone, il titolare la comunichi agli interessati senza ingiustificato ritardo, con un linguaggio semplice e chiaro, descrivendo almeno le probabili conseguenze, le misure adottate e un punto di contatto.
Lo stesso articolo indica tre casi in cui la comunicazione non è richiesta: se i dati erano protetti con misure che li rendono incomprensibili a chi non è autorizzato, come la cifratura; se le misure adottate dopo la violazione rendono improbabile il rischio elevato; se la comunicazione individuale richiederebbe sforzi sproporzionati, e allora si procede con una comunicazione pubblica. Va notato che gli hash delle password non sono equivalenti a dati cifrati: un hash robusto rallenta un attacco, ma password deboli restano recuperabili, ed è prudente chiedere comunque agli utenti di cambiarle.
Per un negozio online colpito da uno skimmer, dove sono stati sottratti nomi, indirizzi e dati delle carte, il rischio elevato è difficile da escludere: le persone devono poter bloccare le carte e riconoscere tentativi di frode.
Il registro delle violazioni, anche senza notifica
C’è un obbligo che vale sempre, qualunque sia l’esito della valutazione. L’articolo 33, paragrafo 5, chiede al titolare di documentare «qualsiasi violazione dei dati personali, comprese le circostanze a essa relative, le sue conseguenze e i provvedimenti adottati per porvi rimedio». Le linee guida EDPB incoraggiano a tenere un registro interno delle violazioni, notificate o no, in cui annotare anche il ragionamento seguito: se si è concluso che il rischio era improbabile, il registro deve spiegare perché.
È qui che la documentazione tecnica mostra il suo valore nel tempo. Una riga come «sito compromesso, nessun dato coinvolto» non regge a un controllo; una ricostruzione che dice quale file è stato caricato, da quale indirizzo, in quale data, con quali privilegi, quali tabelle erano raggiungibili e quali verifiche sui log hanno escluso un’esportazione, invece, sì. La relazione tecnica della bonifica, con la timeline e l’elenco degli indicatori di compromissione, è l’allegato naturale della voce di registro.
Conviene conservare anche la copia forense, in un luogo protetto e per un periodo definito, perché potrebbe servire se emergessero elementi nuovi. Anche la copia contiene dati personali, e va trattata con le stesse cautele del sito.
Gli errori più frequenti nascono dalla fretta. Il primo è ripristinare un backup prima di analizzare: il sito torna online, ma le prove necessarie a capire se i dati sono stati letti vengono sovrascritte, e il malware può sopravvivere al ripristino. Il secondo è considerare chiusa la questione quando il sito è pulito, senza che nessuno abbia fatto la valutazione privacy, magari perché il fornitore ha risolto senza avvisare il titolare.
Quando interveniamo su un sito compromesso, la pulizia garantita in 6, 12 o 24 ore per ogni installazione WordPress comprende la conservazione delle prove e una relazione tecnica con la ricostruzione dell’attacco: vettore di ingresso, finestra temporale, dati raggiungibili, tracce di esportazione trovate o escluse. Non sostituisce la valutazione del titolare e del suo consulente, ma fornisce i fatti su cui basarla, in tempo utile per le 72 ore. Se hai un incidente in corso e dati personali potenzialmente coinvolti, contattaci prima di ripristinare o cancellare qualcosa.
