Analisi del rischio IT per WordPress: un metodo semplice

L'analisi del rischio IT di un sito WordPress sta su una sola pagina. Elenca ciò che si possiede, che cosa può realisticamente andare storto, quanto sarebbe grave e chi risolve cosa, entro quando. Con il metodo in cinque passi qui sotto è possibile redigerne una bozza in un pomeriggio. Il risultato è un documento concreto da mostrare quando un cliente con il suo questionario, un'assicurazione o un'autorità di controllo chiedono in base a quali criteri sono state scelte le misure di sicurezza.

Perché l'analisi del rischio IT viene prima: GDPR e NIS2

L'articolo 32, paragrafo 1, del GDPR richiede misure tecniche e organizzative adeguate al rischio, tenendo conto dello stato dell'arte e dei costi di attuazione. Non si può dimostrare che una misura sia adeguata senza aver prima stabilito qual è il rischio. L'articolo 5, paragrafo 2, aggiunge che il titolare deve essere in grado di comprovare il rispetto delle regole: la valutazione, quindi, va messa per iscritto. Le misure vere e proprie sono trattate nel nostro articolo sull'articolo 32 del GDPR per WordPress.

Se l'azienda rientra nell'ambito di applicazione della direttiva NIS2, l'elenco delle misure minime dell'articolo 21, paragrafo 2, si apre con la lettera a): politiche di analisi dei rischi e di sicurezza dei sistemi informatici. Gli obblighi vincolanti derivano però dalla normativa nazionale di recepimento, da verificare per il proprio Paese. Per cominciare si può verificare se la NIS2 si applica alla propria azienda.

Questo metodo è un punto di partenza pragmatico. Non è un'implementazione della ISO 27001 e non sostituisce un audit esterno formale.

Passo 1: elencare gli asset (siti, dati, account, fornitori)

Un asset è tutto ciò la cui perdita o il cui uso improprio danneggerebbe l'azienda. Per una piccola impresa tipica bastano quattro gruppi. Si parte dai dati personali, perché è lì che si applica il GDPR e lì l'impatto è più alto.

Meglio essere precisi. «Sito web» è troppo generico. «shop.example.com, WooCommerce con circa 40 plugin, ordini dal 2021» è utile. Se durante la stesura emerge una copia di staging dimenticata o l'account amministratore di un ex freelance, va annotato: questa scoperta basta da sola a giustificare l'esercizio.

Passo 2: individuare minacce realistiche per ogni asset

Non serve un catalogo di tutti gli attacchi possibili. Per i siti WordPress quattro gruppi di minacce coprono la maggior parte degli incidenti reali:

• Plugin e temi vulnerabili o abbandonati. Qualcuno sfrutta una falla nota prima che l'aggiornamento sia installato, oppure una falla che non verrà mai corretta.
• Credenziali rubate o condivise. Una password riutilizzata, un account «admin» condiviso o l'accesso di un'agenzia che nessuno ha rimosso.
• Guasto dell'host o del server. Un'interruzione del servizio, una perdita di dati presso il provider o una falla nel software del server stesso. Le vulnerabilità PHP2Shell ne sono un esempio: si trovavano nel runtime PHP, quindi anche un WordPress perfettamente aggiornato restava esposto.
• Errore umano. Un aggiornamento sbagliato che blocca il checkout, una pagina cancellata o un redattore a cui è stato assegnato il ruolo di Amministratore «solo per un momento».

La minaccia dei plugin merita una valutazione onesta. Nel rapporto State of WordPress Security in 2026, il fornitore Patchstack ha contato 11.334 nuove vulnerabilità nell'ecosistema WordPress nel 2025. Il 91% riguardava i plugin e per il 46% lo sviluppatore non aveva ancora reso disponibile alcuna correzione al momento della divulgazione pubblica. Per le vulnerabilità sfruttate in modo massiccio, il tempo mediano ponderato prima dello sfruttamento di massa è stato di 5 ore. Sono dati di un fornitore, ma spiegano perché «plugin vulnerabile» finisce di solito in cima al registro di un sito WordPress.

Passo 3: valutare probabilità e impatto su una scala 1–3

Si usano tre livelli, definiti con parole semplici, in modo che due persone che valutano lo stesso rischio arrivino alla stessa risposta.

Probabilità

1. Improbabile nell'arco di un anno
2. Possibile nell'arco di un anno
3. Prevedibile, oppure è già accaduto all'azienda o a un sito simile

Impatto

1. Fastidio: la correzione richiede un'ora e nessun dato è coinvolto
2. Interruzione del servizio, oppure coinvolta una quantità limitata di dati non sensibili
3. Dati personali esposti, pagamenti compromessi o attività ferma

Si moltiplicano i due valori. Un punteggio di 1–2 significa accettare, 3–4 pianificare una misura, 6–9 intervenire subito. I punteggi 5, 7 e 8 non possono comparire su questa scala, e ciò mantiene nette le fasce.

Il rischio va valutato nella situazione attuale. Un controllo che esiste e funziona riduce la probabilità. «Abbiamo i backup» conta solo se qualcuno ne ha mai ripristinato uno. Niente decimali né fattori di ponderazione: una scala 1–3 è approssimativa di proposito, e una falsa precisione dà al registro un'aria più scientifica di quanto giustifichino le conoscenze di partenza.

Passo 4: scegliere misure, responsabili e scadenze di revisione

Per ogni rischio con punteggio pari o superiore a 3 si scelgono una o due misure concrete. «Migliorare la sicurezza» non è una misura. «Attivare l'autenticazione a due fattori per i quattro amministratori entro il 17 novembre» lo è. Come responsabile va indicata una persona, non «l'IT» o «l'agenzia», e va fissata una data.

Le misure in sé sono approfondite in altri articoli. Si vedano come gestire i plugin vulnerabili e i backup WordPress che si ripristinano davvero. Il registro dei rischi deve solo riportare la decisione e rimandare alla documentazione di prova.

In ogni riga servono altre due cose. Primo, «accettare» è una decisione legittima per i punteggi bassi, purché se ne annoti il motivo. Secondo, va indicato il rischio residuo, cioè il punteggio atteso a misura attuata. Se una misura non abbassa il punteggio, probabilmente è la misura sbagliata.

Esempio pratico: registro dei rischi di un piccolo shop WooCommerce

L'esempio riguarda uno shop fittizio: un sito WooCommerce, una copia di staging, due dipendenti, un'agenzia esterna e un hosting condiviso. «P» sta per probabilità, «I» per impatto e «Dopo» per il punteggio residuo atteso.

Si legge dall'alto. Questa settimana lo shop rimuove l'account dell'agenzia e interroga l'host sulla versione di PHP: due interventi economici, da meno di un'ora ciascuno. La pulizia dei plugin segue entro la prossima settimana, perché ha il punteggio più alto. 2FA e test di ripristino sono pianificati entro il mese.

Le righe sugli errori del personale e sui moduli di contatto possono aspettare dicembre. I punteggi sono più bassi e, per gli errori del personale, il lavoro sui backup della quarta riga offre già una via di recupero. L'interruzione della newsletter viene accettata, con motivazione e data di revisione. Ogni riga termina a 3 o meno. Questo non significa che non possa accadere nulla: è un livello di rischio documentato e motivato.

Come mantenere viva l'analisi del rischio

Un'analisi del rischio che non viene mai riaperta diventa la prova che si è smesso di guardare. Va rivista al verificarsi di uno di questi eventi:

• Dopo ogni incidente o quasi-incidente, compresa un'ondata di tentativi di accesso falliti o un plugin che si è dovuto riportare alla versione precedente
• Dopo modifiche rilevanti, come un nuovo plugin che tratta dati personali, un nuovo host, una nuova agenzia o il lancio di uno shop
• Quando un fornitore o un cliente soggetto alla NIS2 invia un questionario sulla sicurezza
• A intervalli fissi scelti autonomamente, per esempio ogni trimestre o ogni anno. È una scelta dell'azienda, non un obbligo di legge

Conviene dare al documento un numero di versione e una data, e conservare le versioni precedenti. Uno storico da cui risulta che un punteggio di 9 è sceso a 3 dopo una misura è una buona prova di responsabilizzazione. La nostra guida sulla documentazione dell'audit di sicurezza mostra come il registro si inserisce tra gli altri documenti.

Il plugin di audit «Security Audit & Compliance» di secaudit.eu può aiutare nel passo 2 e a ogni revisione. Associa i risultati agli articoli 32 del GDPR e 21 della NIS2 e li esporta come report o CSV, da confrontare con il registro. Le decisioni nel registro restano dell'azienda; il plugin fornisce dati aggiornati su cui basarle. → secaudit.eu

Prossimo passo: copiare la tabella dell'esempio, sostituire le righe con i propri asset e fissare la data della prima revisione prima di chiudere il file.

FAQ

Serve la ISO 27001?

No. Questo metodo è un avvio pratico che si può svolgere con il proprio team. La ISO 27001 è uno standard completo per i sistemi di gestione, e adottarla in un secondo momento è una decisione aziendale a sé stante, spesso sollecitata da clienti di grandi dimensioni.

Quanto tempo richiede per un sito?

Per un singolo sito con una configurazione nota, una prima bozza sta in una sessione di lavoro. Il tempo se ne va soprattutto nel passo 1, per rintracciare account e fornitori. Le revisioni successive sono molto più rapide, perché si aggiorna solo ciò che è cambiato.

L'agenzia la fa una volta sola o per ogni cliente?

Ogni cliente è titolare del trattamento per il proprio sito e custodisce la propria analisi del rischio. L'agenzia può preparare una bozza che il cliente approva. Dovrebbe inoltre tenere un registro separato per i propri sistemi, come portatili, password vault e accessi agli hosting dei clienti. L'accordo sul trattamento dei dati dovrebbe descrivere chi fa cosa.

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