Esiste un documento che la legge impone di avere e che la maggior parte delle farmacie italiane non ha mai visto. Si chiama DPA, Data Processing Agreement, e dovrebbe essere allegato al contratto con il fornitore del software gestionale. Chi non ce l'ha sta violando il GDPR. Chi ce l'ha, nella maggior parte dei casi, possiede un documento che non protegge nulla.
Questa non è un'ipotesi. È il risultato dell'analisi dei contratti e degli allegati GDPR di due diversi produttori di gestionali farmaceutici, condotta nell'ambito della nostra indagine sulla sicurezza dei software per farmacie.
Cos'è un DPA e perché è obbligatorio
Quando un fornitore di software gestisce i dati dei pazienti di una farmacia, e lo fa ogni giorno, il GDPR (Articolo 28) obbliga le parti ad avere un contratto scritto che stabilisca regole precise: cosa il fornitore può fare con quei dati, come li protegge, cosa succede in caso di violazione, a chi può trasmetterli, e cosa accade quando il rapporto contrattuale finisce.
Questo contratto si chiama DPA, Data Processing Agreement, o in italiano "Accordo per il Trattamento dei Dati". In termini giuridici, definisce il rapporto tra il titolare del trattamento (la farmacia, che decide finalità e mezzi del trattamento) e il responsabile del trattamento (il fornitore del software, che tratta i dati per conto della farmacia).
Senza questo documento, una farmacia sta affidando i dati sanitari dei propri pazienti, compresi preparazioni con stupefacenti, terapie oncologiche, prescrizioni psichiatriche, a un soggetto terzo senza alcun vincolo formale su come quei dati vengono gestiti. In caso di ispezione del Garante Privacy, è probabilmente la prima cosa che viene chiesta.
Tre domande che ogni farmacia dovrebbe porsi
La questione riguarda circa 20.000 farmacie italiane e può essere sintetizzata in tre passaggi.
Primo: il DPA esiste? La farmacia ha un documento firmato con il proprio fornitore software che disciplini il trattamento dei dati personali ai sensi dell'Articolo 28 del GDPR? In molti casi, il documento non è mai stato sottoscritto, oppure è sepolto tra le clausole di un contratto di licenza che nessuno ha mai letto per intero. Se la risposta è no, c'è un problema urgente da risolvere.
Secondo: cosa dice? Chi ha un DPA, lo ha mai letto? Specifica quali misure di sicurezza il fornitore adotta per proteggere i dati? Indica chi può accedere ai dati durante la teleassistenza? Stabilisce cosa succede in caso di data breach? Definisce cosa accade ai dati quando il contratto scade?
Terzo: corrisponde alla realtà? Le dichiarazioni contenute nel DPA corrispondono a quello che il software effettivamente fa? Il divario tra le promesse contrattuali e la realtà tecnica è il cuore del problema, come vedremo.
Cosa abbiamo trovato analizzando due contratti reali
L'analisi ha riguardato i contratti di licenza e gli allegati GDPR di due diversi produttori di gestionali farmaceutici, software utilizzati complessivamente da oltre 14.000 farmacie italiane.
In entrambi i casi, il DPA esisteva. Era formalmente corretto. Conteneva le parole giuste: "Privacy by Design", "misure tecniche e organizzative adeguate", "cifratura dei dati personali", "accountability". Uno dei due produttori si impegnava persino a notificare eventuali violazioni entro 24 ore via PEC.
Sulla carta, tutto in ordine.
L'analisi tecnica dei software, tuttavia, ha rivelato una realtà radicalmente diversa:
- Credenziali di accesso ai dati: la password predefinita di fabbrica del database, nota a qualsiasi informatico, mai modificata su migliaia di installazioni
- Cifratura dei dati personali: assente. I dati sanitari dei pazienti sono conservati in chiaro, leggibili da chiunque acceda al database
- Registro degli accessi (audit trail): inesistente. Nessuna traccia di chi accede ai dati, quando, da dove
- Permessi di accesso ai file: in un caso, aperti a qualsiasi utente del sistema operativo
- Account amministratore: configurato senza password dal produttore stesso
Il DPA prometteva una cosa. Il software ne faceva un'altra. Il documento che dovrebbe proteggere la farmacia e i suoi pazienti è, nei fatti, lettera morta.
Promesse contrattuali vs. realtà tecnica
Entrambi i produttori dichiarano nei rispettivi DPA il rispetto della "Privacy by Design". L'analisi tecnica dei software dimostra l'opposto: password di fabbrica, assenza di cifratura, nessun registro degli accessi. Un impegno contrattuale non rispettato è un inadempimento, non una garanzia.
Quando il contratto contraddice sé stesso
In uno dei due casi analizzati, il contratto presenta una contraddizione interna particolarmente significativa.
In un allegato, il produttore dichiara formalmente di non trattare "alcun dato particolarmente sensibile riferibile all'interessato". In un altro allegato dello stesso contratto, compilato dalla stessa azienda, tra i dati trattati durante l'assistenza compare esplicitamente la voce "stato di salute, assistenza sanitaria, prestazioni sanitarie".
Le due dichiarazioni sono incompatibili. Una delle due è necessariamente falsa. In entrambi i casi, la discrepanza configura una violazione dell'obbligo di trasparenza previsto dal GDPR.
Il database di quel software, nel caso analizzato, conteneva effettivamente dati sanitari di categoria speciale: preparazioni con stupefacenti, sostanze dopanti, cannabis medica, veleni. Tutti associati a nomi di pazienti. Il produttore ne era consapevole, tanto da dichiararlo in uno degli allegati. Ma nell'informativa privacy sosteneva il contrario.
Le cinque domande che un DPA dovrebbe contenere
L'analisi dei contratti e dei software ha permesso di identificare cinque questioni fondamentali che qualsiasi DPA nel settore farmaceutico dovrebbe affrontare in modo specifico e verificabile.
1. Come vengono protette le credenziali di accesso ai dati?
Il DPA dovrebbe specificare se le credenziali di accesso al database sono uniche per ogni installazione o condivise tra tutte le farmacie clienti. In uno dei casi analizzati, la stessa credenziale era condivisa tra oltre 10.000 farmacie e consentiva l'accesso al Fascicolo Sanitario Elettronico di 9 regioni italiane. Un DPA generico che parla di "misure adeguate" senza specificare questo aspetto non fornisce alcuna garanzia reale.
2. Il database è cifrato?
I dati sanitari dei pazienti dovrebbero essere cifrati sia in transito sia a riposo. In entrambi i casi analizzati, il database non era cifrato. In uno dei due, il produttore aveva cifrato le proprie schede tecniche commerciali ma non i dati dei pazienti, dimostrando di possedere le competenze tecniche per farlo e di aver scelto di non applicarle ai dati sanitari.
3. Esiste un registro degli accessi?
Il GDPR impone il principio di accountability: la capacità di dimostrare chi ha fatto cosa, quando, e per quale motivo. Senza un registro degli accessi, in caso di violazione dei dati è impossibile ricostruire cosa è accaduto. In entrambi i software analizzati, il registro degli accessi era completamente assente.
4. I dati vengono trasmessi a terzi?
Uno dei due software analizzati trasmetteva dati verso decine di server esterni, inclusi alcuni su protocolli non cifrati. L'altro prevedeva contrattualmente la possibilità di affidare il trattamento dei dati a terzi in qualsiasi momento, con un meccanismo di silenzio-assenso: la farmacia aveva solo 15 giorni per opporsi, e l'unica alternativa all'accettazione era la rescissione dell'intero contratto. Un DPA dovrebbe indicare con precisione a chi vengono trasmessi i dati e su quali basi giuridiche.
5. Chi può accedere ai dati durante la teleassistenza?
Quando un tecnico del fornitore si collega in remoto alla postazione della farmacia per assistenza, ha potenzialmente accesso a tutti i dati presenti nel sistema: prescrizioni, codici fiscali dei pazienti, preparazioni con sostanze controllate. In uno dei casi analizzati, il software includeva nella propria cartella di installazione tre diverse versioni di un programma di accesso remoto e uno strumento di esecuzione comandi a distanza normalmente utilizzato in contesti di attacco informatico. Il DPA dovrebbe disciplinare in modo puntuale cosa il tecnico può e non può fare durante queste sessioni.
Il diritto di audit: presente ma svuotato
Un aspetto particolarmente significativo riguarda il diritto del farmacista di verificare come il fornitore gestisce i dati.
L'Articolo 28 del GDPR prevede che il responsabile del trattamento debba "mettere a disposizione del titolare tutte le informazioni necessarie per dimostrare il rispetto degli obblighi" e "consentire e contribuire alle attività di revisione, comprese le ispezioni".
In uno dei contratti analizzati, questo diritto esiste sulla carta ma è subordinato a una condizione: se l'audit comporta un costo per il fornitore, la farmacia deve pagarlo. Senza alcun limite massimo previsto. In pratica, il meccanismo disincentiva l'esercizio del controllo: la farmacia che volesse verificare come vengono gestiti i dati sanitari dei propri pazienti si troverebbe a dover finanziare l'operazione.
Un DPA generico non protegge nessuno
Il problema di fondo è che la maggior parte dei DPA nel settore farmaceutico, quando esistono, sono documenti generici costruiti con formule standard. Dichiarano il rispetto dei principi del GDPR senza specificare come vengono concretamente attuati.
Un DPA che dice "adottiamo misure adeguate di sicurezza" senza specificare quali misure è come un contratto assicurativo che dice "copriamo i danni" senza specificare quali danni. In caso di contestazione, non offre alcuna protezione reale.
Cosa verificare nel proprio contratto
Il primo passo è recuperare il contratto di licenza del software gestionale e cercare l'allegato relativo al trattamento dei dati personali (DPA, o "designazione del Responsabile del Trattamento"). Se non esiste, va richiesto formalmente al fornitore. Se esiste, va confrontato con la realtà tecnica del software. Le dichiarazioni generiche di conformità non sono sufficienti: il GDPR richiede misure specifiche, documentate e verificabili.
La responsabilità è condivisa, ma non in parti uguali
Il GDPR è chiaro nell'identificare la farmacia come titolare del trattamento, con le responsabilità che ne derivano. Ma queste responsabilità presuppongono che il software fornito consenta di adempierle. Se il software non implementa la cifratura, non produce registri degli accessi e non offre strumenti di sicurezza configurabili, la farmacia si trova nell'impossibilità materiale di rispettare obblighi che il fornitore ha contrattualmente garantito di supportare.
La giurisprudenza del Garante Privacy e delle corti europee riconosce sempre più spesso questa asimmetria: il titolare che si è affidato in buona fede a un fornitore professionale, in un mercato caratterizzato da posizioni quasi-monopolistiche, si trova in una posizione giuridicamente diversa da chi ha consapevolmente scelto di non proteggere i dati.
Resta il fatto che, oggi, migliaia di farmacie italiane operano con contratti che promettono protezioni inesistenti, su software che non rispettano i requisiti minimi del GDPR, custodendo i dati sanitari di milioni di cittadini.
Le vulnerabilità sono state comunicate alle Autorità competenti.
Il report completo
L'analisi completa dei contratti e dei software, con le implicazioni legali e le azioni possibili per le farmacie, è disponibile nel report gratuito.
