Scegliere un dpia software significa verificare se una decisione può essere ricostruita, non soltanto se un modulo può essere compilato. Chi ha descritto il trattamento? Chi ha valutato i rischi per gli interessati? Quale versione ha ricevuto il parere del DPO e su quali evidenze si basa l’approvazione?
Per confrontare le soluzioni, porta in demo un caso concreto e chiedi di eseguire modifiche, revoche di accesso e nuove approvazioni. Il risultato da cercare è un fascicolo coerente: contenuti, responsabilità, controlli e decisioni devono restare collegati anche dopo una revisione.
Prima del workflow: cosa deve documentare la valutazione
L’articolo 35 del GDPR prevede la valutazione d’impatto quando un trattamento può presentare un rischio elevato per i diritti e le libertà delle persone fisiche. La DPIA deve comprendere la descrizione del trattamento, la valutazione di necessità e proporzionalità, i rischi per gli interessati e le misure previste per affrontarli.
Il titolare chiede il parere del DPO, quando designato. L’articolo 39 assegna al DPO compiti di consulenza sulla DPIA e di sorveglianza del suo svolgimento. Il software deve quindi permettere di distinguere chi prepara la valutazione, chi formula un parere e chi assume la decisione organizzativa.
Gli articoli citati non prescrivono un unico workflow applicativo. I test descritti di seguito sono criteri operativi di selezione: aiutano a verificare la qualità delle prove, ma non costituiscono una certificazione di conformità né un parere legale.
Un dpia software deve separare ruoli e decisioni
Una configurazione con un solo profilo amministratore e un unico pulsante “Approva” rende difficile capire come si è arrivati alla decisione. Parti invece dalle responsabilità reali e traducile in autorizzazioni verificabili.
Questa matrice è un esempio da adattare alla struttura aziendale, non un modello imposto dal GDPR.
| Ruolo operativo | Attività nel processo | Evidenza da conservare |
|---|---|---|
| Process owner | Descrive finalità, flussi e modalità del trattamento | Versione della descrizione e conferma dei dati forniti |
| Referente IT o sicurezza | Documenta misure tecniche e relativi test | Configurazioni, risultati dei test e limiti rilevati |
| DPO, quando designato | Formula il parere e sorveglia lo svolgimento | Parere riferito a una versione identificabile |
| Approvatore secondo le deleghe interne | Decide per il titolare entro il proprio mandato | Decisione, motivazione ed eventuali condizioni |
| Auditor | Verifica il fascicolo senza modificarlo | Accesso in lettura ed export del perimetro esaminato |
Il profilo applicativo non sostituisce la nomina, la delega o la responsabilità del titolare. Anche il DPO può contribuire alla preparazione del documento: il punto è non confondere tale contributo con l’assunzione della decisione sul trattamento.
Chiedi inoltre cosa succede quando un owner cambia funzione o lascia l’organizzazione. La pratica deve poter essere riassegnata senza perdere l’attribuzione storica delle attività.
Verificare i permessi con prove negative
Nel dpia software, i permessi vanno verificati tentando anche operazioni che dovrebbero essere impedite. Un revisore esterno può vedere una DPIA non assegnata? Un autore può modificare un parere già acquisito? Un utente disattivato conserva accesso tramite un collegamento condiviso?
Prepara account di prova per autore, revisore e approvatore. Esegui le stesse operazioni con ciascun profilo e conserva l’esito, indicando ambiente, data e configurazione dei permessi. Uno screenshot isolato del menu non dimostra che il controllo funzioni.
Verifica anche gli accessi amministrativi. Se un amministratore può intervenire sui contenuti o sui ruoli, chiedi come vengono registrate queste operazioni e chi può controllarle. La sola presenza di un profilo “super admin” non è un difetto; l’assenza di visibilità sul suo utilizzo è invece una lacuna da valutare.
Log: ricostruire gli eventi senza affidarsi al badge “audit trail”
Un registro utile deve rispondere a quattro domande: chi ha agito, cosa ha fatto, quando e su quale oggetto o versione. Per le modifiche rilevanti serve inoltre ricostruire il contenuto precedente e quello successivo, attraverso differenze registrate o versioni conservate.
La dicitura “ultima modifica” non basta. Non chiarisce, per esempio, se sia cambiata una finalità del trattamento oppure soltanto un refuso.
Eventi da cercare nel registro
Durante la demo del dpia software, verifica la registrazione di creazione e revisione della valutazione, cambi di stato, pareri, approvazioni, sostituzione degli allegati e modifiche ai permessi. Per le operazioni di esportazione o cancellazione, chiedi quale tracciabilità sia disponibile e con quali limiti.
L’ordine degli eventi deve essere comprensibile: controlla il riferimento temporale, il fuso orario e l’attribuzione delle azioni eseguite da integrazioni o account tecnici. Un evento registrato come “sistema” può essere insufficiente se non permette di risalire all’operazione che lo ha generato.
Chiedi anche chi possa modificare o cancellare il registro. Espressioni come “log immutabile” richiedono una spiegazione tecnica verificabile, non soltanto una dichiarazione commerciale. Le buone pratiche per un audit trail verificabile aiutano a distinguere la cronologia visibile nell’interfaccia dalle prove ricostruibili in audit.
Anche i log hanno un perimetro privacy
I log possono contenere dati personali. I principi di minimizzazione e limitazione della conservazione dell’articolo 5 del GDPR richiedono quindi attenzione anche a questo livello.
Per documentare i test, usa dati sintetici anziché copiare informazioni reali di clienti o dipendenti. Verifica accessi al registro, criteri di conservazione e comportamento degli export. La conservazione illimitata non è automaticamente una garanzia migliore: deve esserci una scelta motivata, coerente con le finalità e con gli obblighi applicabili.
Approvazioni: collegare la decisione alla versione esaminata
Il controllo più importante sulle approvazioni è il legame con il contenuto. Nel dpia software, uno stato “approvato” deve permettere di individuare la versione esaminata, l’identità di chi ha deciso, la data e le eventuali condizioni.
Prova questa sequenza: acquisisci un parere, approva la valutazione e modifica poi una misura di sicurezza. Il sistema conserva la decisione sulla versione precedente? Segnala che il contenuto corrente è diverso? Permette di avviare un nuovo riesame?
Non è necessario che ogni modifica editoriale faccia ripartire l’intero processo. È però necessario definire criteri interni per distinguere una correzione formale da una variazione sostanziale. Nuove categorie di dati, destinatari aggiuntivi o cambiamenti nelle misure possono richiedere una rivalutazione.
Parere, dissenso e decisione non sono la stessa cosa
Il parere del DPO deve rimanere distinguibile dalla decisione del titolare. Se contiene osservazioni, il fascicolo dovrebbe mostrare come siano state trattate: modifica della valutazione, nuova misura, approfondimento oppure decisione motivata.
Anche un’approvazione condizionata deve essere leggibile. “Approvato con riserva” è ambiguo se non chiarisce quali attività restano aperte, chi le deve completare e se il trattamento possa iniziare prima della loro chiusura.
Infine, l’approvazione interna non sostituisce la consultazione preventiva dell’autorità quando ricorrono le condizioni dell’articolo 36 del GDPR. Un pulsante di accettazione del rischio non risolve, da solo, il percorso previsto dalla norma.
Remediation: dalla misura prevista alla prova di efficacia
Una misura descritta nella DPIA può essere pianificata, implementata oppure verificata. Questi stati non sono equivalenti. Il fascicolo deve permettere di capire quali controlli siano già operativi e quali dipendano da attività future.
Per ogni remediation significativa, associa un responsabile, una scadenza, un criterio di completamento e un’evidenza attesa. Per esempio, “limitare gli accessi” è troppo generico; “rimuovere i privilegi non necessari e verificare gli accessi dei profili coinvolti” rende il risultato controllabile.
Non chiudere l’attività soltanto perché è stato caricato un allegato. Un documento di configurazione dimostra una scelta tecnica; un test coerente con il rischio può dimostrare che il controllo opera come previsto. Il collegamento tra rischio, misura ed evidenze di audit evita che la DPIA diventi un archivio di file senza contesto.
Quando il dpia software gestisce le azioni correttive, verifica cosa accade alla scadenza e chi può dichiararle completate. Se una verifica fallisce, deve essere possibile riaprire l’attività o registrarne una nuova, mantenendo visibile la storia. La chiusura tecnica, inoltre, non comporta automaticamente la rivalutazione del rischio: verifica come vengono collegate le due attività.
Una prova guidata da portare in demo
Usa uno scenario sintetico: una piattaforma per la gestione delle richieste dei dipendenti, con documenti allegati e accessi differenziati. Non serve riprodurre tutta l’organizzazione. Basta introdurre una modifica capace di incidere sulla valutazione, come l’accesso di un nuovo gruppo di utenti.
Concorda prima i risultati attesi. Durante la prova registra ciò che funziona, ciò che richiede configurazione e ciò che non è disponibile.
| Prova | Operazione da eseguire | Risultato da verificare |
|---|---|---|
| Separazione degli accessi | Tentare l’apertura con un account non assegnato | Accesso impedito secondo la configurazione prevista |
| Integrità del parere | Tentare di modificare un parere acquisito | Originale preservato e nuova revisione distinguibile |
| Versione approvata | Cambiare una misura dopo l’approvazione | Distinzione tra versione approvata e contenuto corrente |
| Revoca dei permessi | Disattivare l’account del revisore | Accesso revocato, anche sui canali condivisi previsti |
| Ricostruzione esterna | Esportare il fascicolo | Decisioni, versioni ed evidenze comprensibili fuori dal sistema |
Al termine, fai esaminare l’export a una persona che non abbia seguito la demo. Deve riuscire a identificare il trattamento, il parere, la decisione e le azioni ancora aperte senza dipendere dalle spiegazioni del fornitore.
Un dpia software può avere un’interfaccia chiara e produrre un export incompleto. Per questo la valutazione deve comprendere sia il lavoro quotidiano sia la ricostruzione del fascicolo da parte di un auditor.
Come trasformare i test in una decisione di acquisto
Evita di sommare funzionalità come se avessero tutte lo stesso peso. Definisci prima i requisiti bloccanti per il tuo processo: per esempio, conservazione delle versioni approvate, attribuzione delle decisioni e revoca degli accessi.
Per ogni requisito registra l’esito del test e la prova disponibile. Distingui ciò che è stato verificato direttamente da ciò che compare soltanto nella documentazione commerciale. Se il risultato dipende da un’integrazione o da una configurazione, indica la dipendenza e chi se ne farà carico.
Le lacune non hanno tutte la stessa gravità. Un’etichetta poco chiara può essere correggibile; l’impossibilità di ricostruire la versione oggetto di una decisione può compromettere l’intero fascicolo. La scelta deve riflettere queste differenze, non solo il numero di risposte positive.
Domande frequenti
Il DPO deve approvare la DPIA nel software? Il GDPR distingue il ruolo consultivo e di sorveglianza del DPO dalla responsabilità del titolare. Il workflow dovrebbe rendere visibili parere e decisione senza attribuire automaticamente al DPO la responsabilità dell’approvazione organizzativa.
Per approvare una DPIA serve una firma elettronica qualificata? L’articolo 35 non prescrive una specifica firma elettronica qualificata. Sul piano operativo, verifica identità del decisore, contenuto esaminato, versione e tracciabilità. Eventuali ulteriori esigenze dipendono dal contesto e dalle regole applicabili.
Quando va riesaminata una DPIA già approvata? L’articolo 35, paragrafo 11, prevede il riesame quando necessario, almeno se cambia il rischio rappresentato dal trattamento. Il sistema dovrebbe supportare l’identificazione dei cambiamenti e conservare la storia delle valutazioni precedenti.
Un audit trail dimostra da solo la conformità? No. Dimostra eventi registrati entro il proprio perimetro. Deve essere accompagnato da una valutazione adeguata, misure documentate, prove dei controlli e decisioni attribuibili.
Verifica il fascicolo, non soltanto il workflow
Per confrontare un dpia software con le tue esigenze, parti dalle prove che vuoi poter consegnare: versione valutata, parere, decisione, controlli e remediation. AuditReady centralizza evidenze con ownership, versioni e audit trail, insieme alla gestione di rischi e azioni correttive.
Richiedi una demo del modulo GDPR di AuditReady usando lo scenario di prova descritto, per verificare come viene organizzato il fascicolo e quali evidenze possono essere esportate.
audit-ready evidence pack demo / not legal advice