Il sito web di una clinica o di uno studio medico gestisce qualcosa che nessun altro settore gestisce nella stessa misura: dati sanitari.
Un paziente che prenota una visita online, che compila un form per una prima consulenza, che carica referti o descrive sintomi attraverso un'area riservata — sta affidando alla tua infrastruttura digitale informazioni che il GDPR classifica come categoria speciale di dati personali, quella con il livello di protezione più alto previsto dalla norma.
Eppure la maggior parte dei siti di cliniche e studi medici italiani gira su WordPress con plugin non certificati, form che salvano i dati in chiaro nel database, e nessuna valutazione d'impatto sulla protezione dei dati mai effettuata.
Questo articolo spiega cosa dovrebbe fare — tecnicamente e legalmente — il CMS che gestisce il sito della tua struttura sanitaria. Non per spaventarti, ma perché sapere cosa è in gioco è il primo passo per gestirlo correttamente.
Perché i dati sanitari richiedono un livello di protezione diverso
Il GDPR distingue tra dati personali comuni e categorie particolari di dati. I dati relativi alla salute rientrano nelle categorie particolari — insieme a dati genetici, biometrici, giudiziari, religiosi e sessuali. Questa classificazione non è formale: comporta obblighi tecnici e organizzativi aggiuntivi che si applicano a chiunque tratti questi dati, incluse le strutture sanitarie private.
In pratica, se il sito della tua clinica raccoglie anche solo il motivo della visita attraverso un form di prenotazione, stai trattando dati particolari. Se hai un'area riservata dove i pazienti consultano referti o comunicano con i medici, stai trattando dati particolari. Se il form di contatto permette al paziente di descrivere la sua situazione clinica, stai trattando dati particolari.
Le misure tecniche richieste per questi dati non sono opzionali: sono obblighi di legge con sanzioni che arrivano fino a 20 milioni di euro o al 4% del fatturato annuo globale per le violazioni più gravi.
I requisiti tecnici specifici per siti di strutture sanitarie
1. Crittografia dei dati nei form e nelle aree riservate
Ogni dato sanitario trasmesso attraverso il sito — prenotazioni, descrizioni di sintomi, allegati di referti — deve essere protetto in trasmissione e in conservazione.
La trasmissione in HTTPS è il requisito minimo, ma non è sufficiente per i dati sanitari. La conservazione nel database deve prevedere crittografia a livello applicativo: i dati devono essere illeggibili anche per chi accede fisicamente al database senza le chiavi di decrittazione. Su WordPress, la grande maggioranza dei plugin per form salva i dati in chiaro nella tabella del database — accessibili a chiunque abbia accesso al pannello phpMyAdmin o al backup del database.
KeideaCMS usa crittografia AES-256 sui dati dei form nel database — lo stesso standard usato in ambito bancario e ospedaliero. Non è un'opzione da attivare: è integrato nel core del sistema. Puoi approfondire l'architettura di sicurezza di KeideaCMS qui.
2. Separazione tra ambiente pubblico e pannello di amministrazione
Su WordPress il pannello di amministrazione è raggiungibile da qualsiasi browser all'indirizzo /wp-admin — pubblicamente accessibile, noto a tutti gli attaccanti, bersaglio di tentativi di accesso automatizzati ogni giorno. Per un sito che gestisce dati sanitari, questa configurazione è inaccettabile.
Il pannello di amministrazione del CMS deve essere separato dall'ambiente pubblico, accessibile solo da IP autorizzati, e protetto da autenticazione a due fattori. Non come configurazione aggiuntiva — come requisito di default dell'architettura.
3. Log degli accessi ai dati sanitari
Il GDPR e le linee guida del Garante della Privacy per il settore sanitario richiedono la tracciabilità degli accessi ai dati dei pazienti. Chi ha acceduto a quali dati, quando, da quale dispositivo. Questo non è solo un requisito di sicurezza — è un requisito di accountability che permette di rispondere a eventuali richieste dell'autorità di controllo.
Su WordPress questa funzionalità non esiste di default e richiede plugin aggiuntivi — plugin che a loro volta aggiungono superficie di attacco e dipendono dalla qualità dello sviluppatore che li mantiene.
4. Gestione del consenso informato digitale
Per raccogliere dati sanitari attraverso il sito, il paziente deve prestare un consenso specifico, informato e documentabile. Non il generico banner cookie — un consenso esplicito per il trattamento di dati relativi alla salute, con la possibilità di revocarlo in qualsiasi momento e con tracciamento della data e modalità di acquisizione.
Questo consenso deve essere archiviato in modo che possa essere dimostrato in caso di contestazione. Un'implementazione corretta richiede che il CMS gestisca questa logica in modo nativo, non attraverso plugin di terze parti con policy di conservazione dei dati proprie e non sempre trasparenti.
5. WAF e protezione da SQL injection
Un attacco SQL injection su un database che contiene dati sanitari è una violazione di dati di categoria speciale. L'obbligo di notifica al Garante scatta entro 72 ore, il rischio reputazionale è elevato, e le sanzioni per mancata adozione di misure tecniche adeguate si sommano a quelle per la violazione stessa.
Un Web Application Firewall integrato nel core del CMS — non aggiunto come plugin — intercetta queste richieste prima che raggiungano il database. È la differenza tra sicurezza architetturale e sicurezza aggiuntiva: la prima risolve il problema alla radice, la seconda riduce il rischio senza eliminarlo.
NIS2: il secondo obbligo che molte strutture sanitarie ignorano
Dal 2024, la direttiva europea NIS2 ha esteso i requisiti di cybersecurity a un numero molto più ampio di soggetti, includendo esplicitamente il settore sanitario. Le strutture sanitarie private di dimensioni medie e grandi rientrano nella categoria dei soggetti importanti, con obblighi specifici di gestione del rischio informatico e di notifica degli incidenti.
Tra i requisiti NIS2 rilevanti per l'infrastruttura web: adozione di misure tecniche proporzionate per gestire i rischi per la sicurezza dei sistemi informatici, capacità di rilevare e rispondere agli incidenti, e notifica agli organi competenti entro 24 ore dalla scoperta di un incidente significativo.
Un sito web che gestisce prenotazioni online, aree riservate pazienti o comunicazioni cliniche è parte dell'infrastruttura informatica soggetta a NIS2. Non è un dettaglio tecnico da delegare al provider di hosting — è una responsabilità del management della struttura.
Performance: perché contano anche per una clinica
C'è un'idea diffusa che le strutture sanitarie non abbiano bisogno di siti veloci — che i pazienti cerchino affidabilità, non velocità. È un ragionamento sbagliato per due motivi concreti.
Il primo è il ranking. Google usa i Core Web Vitals come fattore di posizionamento nelle ricerche organiche. Un sito lento viene penalizzato nelle ricerche per "clinica [città]", "medico specialista [area]", "prenotazione visita [specializzazione]". In un mercato dove molte strutture investono in visibilità online, la velocità del sito incide direttamente sulla capacità di acquisire nuovi pazienti attraverso la ricerca organica.
Il secondo è l'esperienza del paziente. Un paziente che arriva sul sito della tua struttura in un momento di preoccupazione per la propria salute e trova un sito lento, difficile da navigare su mobile, con un form di prenotazione che non funziona correttamente — non prenota. Va sul sito della struttura concorrente che carica in un secondo.
KeideaCMS mantiene TTFB inferiore a 200ms e punteggi Core Web Vitals nel verde strutturalmente. Non con plugin di cache aggiunti sopra un sistema non ottimizzato — con un'architettura progettata per la velocità dalla base.
La DPIA: quando è obbligatoria e cosa deve includere
Per i trattamenti ad alto rischio — e il trattamento di dati sanitari attraverso un sito web rientra quasi sempre in questa categoria — il GDPR richiede una Valutazione d'Impatto sulla Protezione dei Dati (DPIA) prima di iniziare il trattamento.
La DPIA per un sito che gestisce dati sanitari deve includere: la descrizione del trattamento e delle sue finalità, una valutazione della necessità e proporzionalità delle operazioni di trattamento, una valutazione dei rischi per i diritti e le libertà degli interessati, e le misure tecniche e organizzative adottate per gestire quei rischi.
La sezione sulle misure tecniche è quella in cui l'infrastruttura del CMS viene esaminata nel dettaglio. Un CMS con crittografia AES-256 dei dati, WAF integrato, pannello admin separato, log degli accessi e aggiornamenti gestiti è molto più difendibile in una DPIA di un WordPress con plugin vari — alcuni dei quali potrebbero essere stati aggiornati l'ultima volta due anni fa.
Il caso dell'area riservata pazienti: i requisiti aggiuntivi
Molte cliniche e strutture diagnostiche stanno implementando aree riservate dove i pazienti possono consultare referti, comunicare con i medici, visualizzare lo storico delle visite. Questi sistemi amplificano i requisiti di sicurezza in modo significativo.
Un'area riservata pazienti richiede: autenticazione robusta con opzione di autenticazione a due fattori, sessioni con timeout automatico, crittografia end-to-end per le comunicazioni cliniche, controllo granulare dei permessi (il medico X vede solo i pazienti assegnati a lui), e log completo di ogni accesso a ogni documento.
Implementare questi requisiti su WordPress con plugin di terze parti è tecnicamente possibile ma architetturalmente fragile: ogni plugin aggiunge dipendenze, ogni aggiornamento è un potenziale punto di rottura, e la responsabilità della conformità rimane tua anche se il problema è nel codice di un plugin scritto da uno sviluppatore in un altro continente.
Cosa succede concretamente in caso di violazione
Vale la pena essere espliciti su cosa significa una violazione di dati sanitari per una struttura medica privata.
L'obbligo di notifica al Garante scatta entro 72 ore dalla scoperta. Se i dati esposti riguardano la salute dei pazienti, questi vanno notificati individualmente. Il Garante può aprire un'istruttoria che valuta le misure tecniche adottate — e se trova che erano inadeguate, le sanzioni si sommano. La copertura mediatica di una violazione di dati sanitari in una struttura privata ha impatti reputazionali che non si recuperano facilmente.
E poi c'è la responsabilità professionale. I medici e i direttori sanitari sono responsabili del trattamento dei dati dei loro pazienti — non solo l'ufficio IT o il provider di hosting. Una violazione causata da misure tecniche inadeguate può avere conseguenze che vanno oltre le sanzioni amministrative.
Se vuoi valutare concretamente lo stato del sito attuale della tua struttura — sicurezza, compliance GDPR e NIS2, performance — puoi richiedere un audit gratuito. Puoi anche vedere perché WordPress non è la scelta adeguata per strutture sanitarie qui.
