Un software gdpr auditabile deve permettere di ricostruire un controllo anche quando chi lo ha eseguito non è disponibile: quale requisito copriva, chi ne era responsabile, quali prove sono state raccolte e come sono state gestite le anomalie. Un registro compilato o una dashboard senza segnalazioni non bastano a rispondere a queste domande.
Per scegliere la piattaforma, serve quindi un capitolato con criteri di accettazione verificabili, non soltanto un confronto tra funzionalità. Il punto è stabilire prima dell’acquisto quali risultati devono essere dimostrati, quali limiti sono accettabili e quali carenze impediscono di procedere.
Definisci il perimetro prima di confrontare le offerte
Parti da un processo circoscritto, per esempio la revisione degli accessi ai sistemi che trattano dati personali. Identifica l’owner operativo, chi verifica l’esito e chi riceve eventuali anomalie. Il DPO non va indicato automaticamente come responsabile di ogni attività: nel progetto di acquisto, distingui supervisione privacy ed esecuzione dei controlli.
Nel GDPR pubblicato su EUR-Lex, gli articoli 5, paragrafo 2, e 24 richiedono al titolare di poter dimostrare il rispetto del regolamento. Non prescrivono una particolare piattaforma né rendono obbligatoria ogni caratteristica tecnica descritta qui.
Per selezionare un software gdpr, traduci quindi il bisogno operativo in risultati osservabili: ricostruire una revisione, individuare una prova scaduta, seguire una remediation e consegnare un fascicolo comprensibile a un verificatore esterno.
Le indicazioni seguenti sono criteri tecnici e organizzativi di acquisto, non una valutazione legale del singolo trattamento.
Trasforma le funzionalità in condizioni di accettazione
Una voce come “gestione documentale” è troppo generica per un capitolato. Specifica invece cosa deve accadere quando una prova cambia, quando il suo owner lascia l’organizzazione o quando l’auditor non può accedere alla piattaforma.
Questa matrice iniziale aiuta a separare le promesse dai risultati da verificare.
| Criterio | Prova da richiedere | Condizione che blocca l’accettazione |
|---|---|---|
| Responsabilità | Un controllo assegnato con esecutore e revisore riconoscibili | Attività concluse senza poter identificare il responsabile |
| Cronologia | Ricostruzione di una modifica con autore, data e versione | Sovrascrittura senza traccia del contenuto precedente |
| Accessi | Test con profili operativi, revisore e utente non autorizzato | Visibilità indiscriminata di documenti riservati |
| Esportazione | Fascicolo leggibile fuori dalla piattaforma | File senza collegamenti a controlli, versioni o findings |
Sono condizioni proposte per l’acquisto, da adattare al rischio e al perimetro. Non equivalgono a un elenco di obblighi software imposti dal regolamento.
Identità, owner e passaggi di responsabilità
Un software gdpr deve distinguere chi carica un documento, chi esegue il controllo e chi ne verifica l’esito. Le tre persone possono coincidere in alcuni processi, ma questa scelta deve essere esplicita, non nascosta dietro un account condiviso.
Nel test di accettazione, sostituisci l’owner di un’attività aperta. Verifica che il nuovo responsabile trovi scadenza, contesto e prove già raccolte, mentre la cronologia continui a mostrare le azioni del precedente owner.
Controlla anche il comportamento alla disattivazione di un utente. La rimozione dell’accesso non dovrebbe rendere anonime le attività storiche necessarie alla ricostruzione. Chiedi al fornitore come gestisce questo equilibrio e quali configurazioni sono disponibili.
Per incarichi sensibili, inserisci nel capitolato una revisione separata dall’esecuzione. Se il team non può garantirla, documenta l’eccezione e il controllo compensativo concordato.
Cronologia e integrità: cosa chiedere a un software gdpr
“Abbiamo i log” non chiarisce quali eventi siano registrati. Chiedi di vedere modifiche ai metadati, sostituzioni di allegati, cambi di stato, approvazioni e variazioni dei permessi rilevanti per il tuo processo.
La prova richiesta deve rispondere a quattro domande: chi ha agito, quando, su quale oggetto e con quale effetto. Una data di ultimo aggiornamento non ricostruisce da sola una sequenza di decisioni.
Verifica separatamente le capacità degli amministratori: possono cancellare eventi, cambiare retroattivamente un’approvazione o modificare una versione già esportata? Non presumere che la parola “audit trail” significhi automaticamente immutabilità. Le buone pratiche per rendere verificabile un audit trail aiutano a definire questi requisiti senza confondere cronologia applicativa e garanzie di integrità.
Anche un hash, quando previsto, ha un significato limitato: può aiutare a rilevare una variazione del file rispetto all’impronta registrata, ma non dimostra che il contenuto originario fosse corretto.
Collegamenti tra controlli, prove e anomalie
Per valutare un software gdpr, verifica che una prova non sia soltanto archiviata, ma collegata al controllo pertinente, al periodo verificato e all’esito della revisione. Una policy aggiornata oggi non dimostra automaticamente che un controllo sia stato eseguito sei mesi fa.
Il sistema dovrebbe permettere di distinguere una prova acquisita da una prova verificata, oltre a rendere riconoscibili quelle superate o non più utilizzabili. I nomi degli stati contano meno della loro definizione operativa.
Una buona struttura delle evidenze di audit rende inoltre visibile il collegamento tra anomalia, azione correttiva e verifica finale. Senza questo passaggio, la piattaforma può mostrare molte attività completate senza dimostrare che il problema sia stato risolto.
Chiedi una ricostruzione completa su un caso, non una schermata con il numero totale di documenti presenti.
Verifica il fornitore prima di caricare dati reali
La valutazione riguarda anche il servizio che ospiterà documenti e metadati. Dove il fornitore tratta dati personali per conto del cliente, vanno esaminati gli elementi previsti dall’articolo 28; sicurezza e trasferimenti richiedono attenzione rispettivamente all’articolo 32 e al capo V del testo del GDPR disponibile sul sito del Garante.
Nel dossier di acquisto di un software gdpr raccogli il DPA applicabile, l’elenco dei sub-responsabili, le informazioni sulle localizzazioni del trattamento e le misure di sicurezza dichiarate. Affida la valutazione delle basi e delle garanzie contrattuali alle funzioni competenti.
Sul piano tecnico, chiedi evidenze sul controllo degli accessi, sulla gestione degli incidenti e sulle procedure di backup e ripristino. Un documento commerciale che dichiara “sicurezza elevata” non sostituisce una descrizione verificabile delle misure.
La collocazione dei server nell’Unione europea non chiude da sola l’analisi: ricostruisci anche accessi di assistenza, fornitori coinvolti e flussi effettivi. Se una risposta manca, mantieni il requisito aperto anziché considerarlo soddisfatto.
Se l’offerta comprende assistenti AI
Questa verifica si applica solo alle offerte che includono funzioni AI. Chiarisci quali documenti possono raggiungere il modello, se vengono conservati dal relativo fornitore, chi può attivare la funzione e quali condizioni regolano l’eventuale uso dei dati per addestramento.
La guida alla selezione di strumenti AI affidabili, in francese, propone un filtro operativo basato su criticità dei dati, integrazione e reversibilità. È utile per impostare le domande di selezione, non per sostituire la verifica privacy del servizio.
Nel capitolato, specifica anche come riconoscere un testo generato rispetto a un documento approvato. Una sintesi automatica può facilitare il lavoro, ma non dovrebbe diventare una prova validata soltanto perché appare nel fascicolo.
Progetta un test di accettazione ripetibile
Prima della firma, concorda un ambiente di prova con dati sintetici o opportunamente minimizzati. Il test di un software gdpr deve seguire uno script condiviso: input, azione, risultato atteso, risultato osservato ed eventuale scostamento.
Fai eseguire alcune operazioni a persone del tuo team, non soltanto al commerciale del fornitore. Registra inoltre quali passaggi richiedono assistenza, configurazioni aggiuntive o lavorazioni manuali esterne alla piattaforma.
Scenario: una prova cambia dopo l’approvazione
Crea un controllo di revisione degli accessi con owner, revisore e scadenza. Carica un elenco sintetico di utenze, registra un’anomalia e associa un’azione correttiva. Dopo l’approvazione, sostituisci l’allegato con una versione aggiornata.
Verifica che sia possibile distinguere il documento esaminato dal revisore da quello caricato successivamente. Il sistema può gestire il caso in modi diversi, per esempio richiedendo una nuova revisione o segnalando che l’approvazione riguarda la versione precedente. L’esito necessario è evitare un’associazione ambigua tra approvazione e prova.
Esporta poi il fascicolo e chiedi a un collega estraneo al test di ricostruire la sequenza. Se deve telefonare all’owner per capire cosa sia successo, il pacchetto non è ancora autosufficiente.
Scenario: un finding viene chiuso senza verifica
Apri un finding per un accesso non più necessario e assegna la remediation all’IT. Prova poi a chiuderlo inserendo soltanto un commento come “risolto”.
Il requisito di acquisto non è necessariamente un blocco automatico. Può essere un passaggio di revisione o un’eccezione chiaramente registrata. Deve però risultare evidente se la chiusura è sostenuta da una prova di rimozione dell’accesso e da una verifica successiva.
Nel test di un software gdpr, controlla anche la riapertura dell’anomalia: motivazione, nuova responsabilità e scadenza devono restare collegate alla storia precedente. Un nuovo ticket scollegato rende più difficile capire se si tratta di una ricorrenza o di un problema diverso.
Scenario: esportazione e uscita dal servizio
Richiedi un’esportazione che comprenda allegati, identificativi, versioni, responsabilità, stati e relazioni tra oggetti, nei limiti del perimetro concordato. Un PDF riepilogativo può servire alla lettura, ma non sempre basta per migrare verso un altro sistema.
Apri il pacchetto senza utilizzare la piattaforma. Verifica che i nomi dei file siano comprensibili e che un indice o un manifest permetta di collegarli ai controlli corrispondenti.
La reversibilità è un requisito operativo e contrattuale da negoziare. Chiarisci formati, tempi, costi e assistenza necessaria, oltre alle modalità di gestione delle copie residue dopo la cessazione del servizio. Non rimandare queste domande al momento in cui deciderai di cambiare fornitore.
Usa il punteggio solo dopo aver verificato i requisiti bloccanti
Un software gdpr non dovrebbe compensare una carenza critica con molte funzionalità accessorie. Prima di calcolare una media, separa i requisiti indispensabili da quelli migliorativi.
Puoi usare una scala interna semplice: 0 per requisito non dimostrato, 1 per risultato ottenibile soltanto con attività manuali esterne, 2 per risultato ottenuto con configurazione e 3 per risultato ottenuto nel flusso ordinario. È una convenzione di valutazione proposta, non uno standard normativo.
Per ogni punteggio conserva la prova e annota le dipendenze: modulo aggiuntivo, intervento del fornitore, procedura interna o limite contrattuale. Se un requisito bloccante rimane non dimostrato, la valutazione resta aperta indipendentemente dal totale.
Considera infine il costo totale di gestione: migrazione, configurazione, formazione, lavoro ricorrente degli owner ed esportazione finale. Un canone inferiore può essere annullato da riconciliazioni manuali frequenti tra fogli di calcolo, documenti e ticket.
Riporta gli esiti nel contratto e nel piano operativo
Le risposte ottenute durante la selezione devono diventare riferimenti utilizzabili dopo l’acquisto. Allega al progetto il perimetro, i criteri di accettazione, gli esiti dei test e le limitazioni note. Le clausole contrattuali richiedono la revisione delle funzioni competenti.
Prima di adottare un software gdpr, assegna anche le responsabilità interne: chi mantiene i controlli, chi aggiorna le prove, chi verifica le chiusure e chi autorizza gli accessi. Nessuna piattaforma corregge automaticamente un processo privo di owner.
Per ogni carenza accettata, definisci una misura temporanea, una scadenza e una prova di chiusura. Evita formule come “sarà gestito in fase di avvio” senza un responsabile identificato.
Prevedi infine una verifica dopo il primo ciclo operativo. Il test precontrattuale dimostra la fattibilità del flusso; il primo ciclo con gli utenti reali mostra se responsabilità e qualità delle evidenze restano sostenibili nel lavoro quotidiano.
Domande frequenti
Un software può garantire da solo la conformità GDPR? No. Può organizzare controlli, responsabilità e prove, ma la conformità dipende anche dalle decisioni sui trattamenti e dall’effettiva esecuzione delle misure. Le dichiarazioni commerciali vanno confrontate con il perimetro verificato.
Serve un audit trail immutabile per ogni attività? Non va trattato come un requisito universale. Nel capitolato definisci quali eventi devono essere ricostruibili, chi può modificarli e quali protezioni sono proporzionate al rischio. Verifica le garanzie effettive, non soltanto il nome della funzione.
Un software gdpr con molti modelli è più facile da sottoporre ad audit? Non necessariamente. I modelli possono facilitare la raccolta iniziale, ma l’auditabilità dipende dai collegamenti tra controlli, versioni, responsabilità e verifiche. Un modello compilato non dimostra da solo l’esecuzione del controllo.
Cosa fare se il fornitore non dimostra una funzione dichiarata? Registra il requisito come non verificato. Chiedi una prova ripetibile o una documentazione adeguata e valuta il limite prima della firma. Una funzione prevista nella roadmap non va conteggiata come già disponibile.
Porta alla demo un controllo completo
AuditReady centralizza evidenze con ownership, versioni e audit trail e supporta la gestione di controlli, findings e remediation. Il modo utile per valutarne l’aderenza al tuo processo è partire da un controllo reale, opportunamente minimizzato, e dal risultato che devi consegnare all’auditor.
Richiedi una demo AuditReady dedicata al GDPR con un caso che includa prova iniziale, anomalia, azione correttiva ed export finale. Usa i criteri di accettazione per verificare il flusso e far emergere eventuali limiti prima dell’adozione.
audit-ready evidence pack demo / not legal advice