Report di audit di sicurezza WordPress: quali prove conservare

Se un cliente, un auditor o un assicuratore chiede di dimostrare che il sito WordPress è protetto, «teniamo tutto aggiornato» non è una risposta. Servono registri. Un report di audit di sicurezza WordPress li riunisce in un unico documento che un'altra persona può leggere e verificare. Questo articolo spiega che cosa conservare, come deve essere una voce utile e come mantenerla aggiornata senza che diventi un secondo lavoro.

Perché serve un report di audit di sicurezza WordPress: dimostrare, non dichiarare

Ai sensi del GDPR, il titolare del trattamento deve essere in grado di dimostrare la conformità. Non basta applicare i principi (art. 5, par. 2). L'art. 32, par. 1, lett. d), richiede inoltre una procedura per testare, verificare e valutare regolarmente le misure di sicurezza. Se la procedura è reale, lascia una traccia documentale.

Lo stesso vale per chi lavora sul sito. Hosting provider e agenzie con accesso amministrativo sono in genere responsabili del trattamento ai sensi dell'art. 28, e i loro clienti chiederanno quindi lo stesso tipo di prove. Per capire quali debbano essere le misure vere e proprie, si veda la nostra guida all'art. 32 GDPR per WordPress.

La documentazione ha dei limiti. Può offrire la prova che le misure sono state attuate, ma da sola non dimostra che restino efficaci. Non rende sicuro un sito, e le sole carte non adempiono gli obblighi del GDPR. Una documentazione obsoleta può essere peggio di nessuna: una policy di backup che descrive un plugin rimosso l'anno scorso segnala all'auditor che i registri non vengono mantenuti.

I sei registri che auditor e clienti guardano davvero

1. Inventario. Elenca la versione del core, ogni plugin e tema con la relativa versione, l'hosting provider, la versione di PHP e i servizi di terze parti utilizzati. Indica inoltre quali dati personali tratta ciascun componente. Una voce utile dice, ad esempio: «Plugin del modulo di contatto, salva le richieste nel database (nome, e-mail, messaggio), richieste eliminate dopo 90 giorni secondo la nostra policy». L'inventario va aggiornato a ogni modifica e confrontato con la situazione reale ogni trimestre.

2. Registro degli aggiornamenti. Ogni riga riporta la data, il componente, la versione precedente e quella nuova, chi ha eseguito l'aggiornamento e se è stato automatico. Si aggiunge una voce per ogni modifica. Gli aggiornamenti automatici contano, ma qualcuno deve verificare che il sito funzioni ancora dopo l'intervento.

3. Report delle scansioni. Conservare i report datati e le relative registrazioni di follow-up secondo una policy di conservazione documentata, invece di sovrascrivere semplicemente il report precedente. Per ogni rilievo va annotato come è stato risolto: corretto, accettato con motivazione oppure falso positivo. Un report con dieci rilievi e nessun seguito dimostra che la scansione è stata eseguita. Non dimostra che si sia intervenuti sui risultati.

4. Backup e test di ripristino. Si registrano la pianificazione, il luogo di archiviazione dei backup, il periodo di conservazione, la data e l'esito dell'ultimo ripristino di prova. Un job di backup riuscito non è la prova che il ripristino funzioni. Come punto di partenza pratico, conviene testare il ripristino ogni trimestre e dopo le modifiche rilevanti; la frequenza va adeguata ai propri rischi e alle esigenze di recupero. I dati personali ripristinati vanno protetti in un ambiente di test isolato.

5. Elenco degli accessi. Si annotano chi ha quale ruolo, se l'autenticazione a due fattori è attiva per ciascun account, quando gli accessi sono stati riesaminati per l'ultima volta e quando sono stati rimossi ex collaboratori o agenzie. Si aggiorna a ogni modifica e si riesamina ogni mese.

6. Registro degli incidenti. Va registrato ogni incidente di sicurezza, comprese le violazioni dei dati personali che si è deciso di non notificare. L'art. 33, par. 5, impone di documentare tutte le violazioni: i fatti, le conseguenze e i provvedimenti adottati. La notifica vera e propria è trattata nella nostra guida alla notifica entro 72 ore.

Come sono le buone prove (e cosa non vale)

Le buone registrazioni hanno quattro caratteristiche in comune:

• Ogni voce è datata.
• Ogni voce riporta il nome di chi l'ha inserita.
• Tutte le voci sono conservate in un unico posto, in modo coerente.
• Vengono scritte nella routine, non ricostruite la settimana prima di un audit.

Un auditor di solito si accorge quando un registro è stato compilato in un solo pomeriggio.

Si confrontino due versioni dello stesso fatto. Debole: «Aggiorniamo i plugin con regolarità». Più solida, come modello: «[data], [plugin], [versione precedente] a [nuova versione], aggiornamento automatico, [verifica eseguita], controllato da [nome]». Ogni segnaposto va sostituito con i dati effettivi. La seconda formulazione si può verificare e dimostra un'abitudine.

Le esportazioni valgono più degli screenshot. Un CSV con le versioni dei plugin o un PDF con il report di scansione mantiene i dati e la data. Lo screenshot ritagliato della dashboard prova poco e non si può ricercare. Gli screenshot vanno usati solo per impostazioni prive di esportazione, indicando la data nel nome del file.

Le registrazioni vanno conservate fuori dal server WordPress. Se il sito viene compromesso, l'attaccante non deve poter modificare le prove, e le registrazioni servono comunque durante la bonifica. Un'unità condivisa con controllo degli accessi può essere una soluzione pratica: limitare la modifica, attivare la cronologia delle versioni e proteggerla con credenziali separate da quelle del sito WordPress.

Il tutto va tenuto proporzionato. Per una piccola impresa, un foglio di calcolo con una scheda per ogni registro e una cartella datata di PDF è un ottimo fascicolo di prove. Nessuno si aspetta una piattaforma di governance per un sito di dieci pagine.

Rispondere ai questionari dei fornitori dei clienti NIS2

Agenzie, freelance e sviluppatori di plugin ricevono questionari di sicurezza anche quando la NIS2 non si applica direttamente a loro. Il motivo è l'art. 21, par. 2, lett. d), della direttiva NIS2. La direttiva prevede misure di sicurezza della catena di approvvigionamento, il che può spingere i clienti a chiedere prove ai fornitori. Gli obblighi applicabili derivano dalla normativa nazionale di recepimento: occorre verificare la legge nazionale NIS2 del proprio Paese. Se rientri nell'ambito di applicazione il cliente o il fornitore è una questione distinta, trattata in NIS2 e il tuo sito WordPress.

Le domande variano in base al cliente e al contratto, quindi va letto il questionario effettivo. Gli argomenti in genere seguono le misure dell'art. 21, par. 2, e ciascuno corrisponde a un registro già tenuto:

Si risponde solo a ciò che si può provare. Dove il modulo offre solo sì/no, conviene aggiungere una breve nota o mettere a disposizione il documento, ad esempio: «Sì, con cadenza mensile. Ultimi tre report di scansione disponibili su richiesta». Se una misura è solo parzialmente attuata, va detto. Una risposta esagerata in un contratto di fornitura è già di per sé un rischio.

Domande delle assicurazioni cyber: stesse prove, ma leggere il modulo

Le compagnie di assicurazione pongono domande proprie, con formulazioni diverse da una all'altra. Le risposte fornite possono contare in seguito, se si presenta una richiesta di indennizzo. Occorre rispondere con esattezza, conservare una copia datata di ciò che è stato inviato e ricontrollare le risposte quando l'assetto cambia. Un nuovo hosting provider o l'abbandono dell'obbligo di 2FA sono esempi di tali cambiamenti.

I temi ricorrenti, come backup, autenticazione a più fattori e patching, corrispondono agli stessi sei registri. Che cosa richieda una specifica polizza e come le risposte incidano sulla copertura sono questioni da risolvere con il testo della polizza e con il broker.

Tenere aggiornata la documentazione senza lavoro in più

Il calendario che segue è un punto di partenza pratico, non un minimo di legge. Va adeguato ai propri rischi, alla frequenza dei cambiamenti e ai requisiti contrattuali:

Il riesame annuale dovrebbe essere approvato da una persona con adeguata autorità. Per i soggetti rientranti nella normativa nazionale NIS2, l'art. 20 impone agli organi di gestione di approvare e sovrintendere le misure di cybersicurezza e di seguire una formazione. Una firma annuale, da sola, non dimostra una sorveglianza continua: vanno conservate le registrazioni di decisioni, riesami e azioni successive.

Le esportazioni conviene automatizzarle. Con WP-CLI, un cron job mensile sul server o uno script eseguito dalla propria postazione può produrre file datati:

wp core version > core-$(date +%F).txt
wp plugin list --format=csv > plugins-$(date +%F).csv
wp theme list --format=csv > themes-$(date +%F).csv
wp user list --role=administrator --format=csv > admins-$(date +%F).csv

I comandi vanno eseguiti da una directory esterna alla web root, indicando a WP-CLI il sito con --path=/path/to/wordpress, in modo che le esportazioni non siano mai raggiungibili pubblicamente. Poi si copiano nell'archivio delle prove. L'esportazione degli amministratori contiene indirizzi e-mail, quindi va trattata come dato personale.

I report delle scansioni appartengono alla stessa cartella. Il plugin Security Audit & Compliance di secaudit.eu esporta un report e un CSV con i rilievi associati all'art. 32 GDPR, all'art. 21 NIS2 e all'OWASP Top 10:2025, da archiviare direttamente nella cartella delle prove. Un report del genere mostra che un controllo è stato eseguito e che cosa ha rilevato, nient'altro. Per le misure che stanno dietro a ciascun registro, si può usare la nostra checklist di sicurezza WordPress.

Modello: struttura di un report di audit di sicurezza WordPress

Si può copiare questa struttura e compilarla a partire dai sei registri:

1. Ambito e data: quali siti, quale periodo, chi ha redatto il report.
2. Sito e responsabili: titolare, referente tecnico, responsabili del trattamento (hosting, agenzia) e stato dei relativi accordi di trattamento dei dati (art. 28).
3. Sintesi dell'inventario: core, PHP, numero di plugin e temi, servizi di terze parti, dati personali trattati.
4. Misure in atto, associate all'art. 32, par. 1, lett. a)–d): cifratura; riservatezza, integrità e disponibilità; capacità di ripristino; verifiche periodiche.
5. Stato di aggiornamenti e vulnerabilità: componenti obsoleti, vulnerabilità note, correzioni pianificate.
6. Risultati delle scansioni e rimedi: data di ogni scansione, rilievi, risoluzione.
7. Backup e test di ripristino: pianificazione, archiviazione, conservazione, data ed esito dell'ultimo test.
8. Riesame degli accessi: account per ruolo, copertura 2FA, account rimossi, data del riesame.
9. Incidenti e violazioni registrati (art. 33, par. 5), comprese quelle non notificate.
10. Rischi aperti e azioni pianificate, ciascuna con un responsabile e una scadenza.
11. Approvazione: nome, ruolo, data.

Questo mese conviene iniziare da due cose: un'esportazione dell'inventario e un ripristino di prova su un sito di staging. Insieme coprono diverse delle aree dei questionari indicate nella tabella sopra. Per aggiungere alla cartella report di scansione datati, il plugin di audit di secaudit.eu esegue i controlli sul sito ed esporta i risultati → secaudit.eu.

Il presente articolo ha carattere di informazione generale e non costituisce consulenza legale.

FAQ

Per quanto tempo vanno conservate le registrazioni di sicurezza?

Il GDPR non fissa un unico periodo di conservazione per queste registrazioni. Vanno conservate finché servono a dimostrare la conformità, verificando se il proprio settore o i contratti prevedano termini specifici. I periodi di conservazione si definiscono per tipo di registro e finalità; i dati personali non vanno trattenuti a tempo indeterminato solo perché la configurazione è ancora in uso. I dati personali contenuti nei registri, come gli indirizzi e-mail degli amministratori, non vanno conservati oltre il necessario.

Un report di audit senza rilievi significa che rispettiamo il GDPR?

No. Un report mostra che determinati controlli tecnici sono stati superati in una certa data. Il GDPR riguarda anche basi giuridiche, consenso, contratti con i responsabili del trattamento, diritti degli interessati e altro. Anche sul fronte della sicurezza, una scansione pulita non dice nulla su come il personale gestisca password o phishing.

La nostra agenzia può tenere la documentazione per nostro conto?

Sì, e spesso le agenzie dispongono dei dati migliori. Il titolare del trattamento resta però responsabile. Gli obblighi di documentazione vanno inseriti nell'accordo ai sensi dell'art. 28, specificando che cosa viene registrato, con quale frequenza e come ottenere l'accesso. Conviene tenere una copia propria, in modo che le prove non escano dall'azienda insieme all'agenzia.