Risposta breve
Controllo delle versioni e Audit-Trail sono importanti nei software per la protezione dei dati perché le organizzazioni, oltre allo stato attuale di una Elaborazione, una Valutazione d'impatto sulla protezione dei dati oppure, in caso di approvazione, devono documentarne in modo tracciabile anche la genesi. È quindi fondamentale sapere quale versione fosse in vigore in un determinato momento, chi abbia apportato una modifica, per quale motivo fosse necessaria, chi abbia verificato o approvato la modifica e quali informazioni fossero disponibili al momento della verifica o della decisione.
A Audit- In questo contesto, Trail non è una semplice funzionalità aggiuntiva di natura puramente tecnica. Aiuta a rispondere a domande fondamentali in materia di gestione e governance: cosa era in vigore in un determinato momento? Chi ha preso la decisione? Quali contenuti sono stati modificati? Per quale motivo è stata apportata la modifica? Quali rischi erano noti e quale stato era documentato al momento di un audit?
Tracciabilità dello stato della protezione dei dati documentato
Nei progetti relativi alla protezione dei dati, l’attenzione è spesso rivolta ai requisiti di contenuto. Occorre verificare, ad esempio, se il Elenco delle attività di trattamento sia completa, che le misure tecniche e organizzative siano state descritte in modo adeguato, che una Valutazione d'impatto sulla protezione dei dati sia stata completata o che la verifica di un fornitore di servizi sia stata effettuata correttamente. Lo stesso vale per l’attuazione delle misure e l’approvazione dei casi d’uso dell’IA.
Per valutare l'attendibilità di tali dati, occorre tuttavia tenere conto anche di come si sia giunti alla situazione attuale. A tal proposito sorgono in particolare le seguenti domande:
- Chi ha una Elaborazione modificato?
- Quando è stata aggiunta una nuova categoria di dati?
- Per quale motivo è stato modificato il termine di cancellazione?
- Chi ha deciso che non ci fosse Valutazione d'impatto sulla protezione dei dati è necessario?
- Quale versione era in vigore al momento di una verifica?
- Qual era la raccomandazione del garante della protezione dei dati in quel momento?
- La modifica è stata verificata o è stata semplicemente sovrascritta nel record esistente?
In assenza di tali indicazioni, ciò riguarda la Documentazione così come la governance. Uno stato che oggi appare plausibile è attendibile solo in misura limitata ai fini della verifica e della rendicontazione, se non è chiaro su quale verifica, decisione o autorizzazione si basi.
L'audit trail come strumento di controllo organizzativo
Il termine AuditIl termine "trail" viene spesso associato a file di log, timestamp, cronologie dei database o all'amministrazione di sistema. Per la gestione della protezione dei dati, tuttavia, una visione puramente tecnica di questo tipo risulta insufficiente.
Un modello strutturato in modo professionale Audit-Il trail mostra se un’organizzazione adotta decisioni in modo trasparente, attua le modifiche in modo controllato ed è in grado, in un secondo momento, di spiegare come si sia giunti a un determinato livello di protezione dei dati. Rappresenta quindi anche uno strumento di controllo organizzativo.
Ciò è strettamente legato al principio di responsabilità. Il Comitato europeo per la protezione dei dati descrive Responsabilità etica sotto il GDPR come obbligo del titolare del trattamento di garantire il rispetto dei requisiti in materia di protezione dei dati e di poterlo dimostrare. Nella pratica, ciò richiede in particolare una Documentazione delle pratiche in materia di protezione dei dati e delle decisioni su cui si basano.[1]
Il AuditIn questo contesto, il "trail" funge da traccia comprensibile di una modifica o di una decisione. Il suo valore non risiede solo nella registrazione tecnica, ma anche nella classificazione tecnica dell'operazione documentata.
I limiti di una semplice istantanea
Molti sistemi mostrano esclusivamente il record di dati corrente. Sono visibili, ad esempio, lo scopo attuale di una Elaborazione, le categorie di dati attualmente documentate, i destinatari e i termini di cancellazione, nonché il responsabile e lo stato di elaborazione.
Questi dati sono obbligatori, ma spesso non sono sufficienti per garantire la tracciabilità successiva.
Se in un Elenco delle attività di trattamento oggi è previsto un termine di cancellazione di sei mesi, mentre un anno fa era ancora documentato un termine di tre anni, si pone in un Audit Non si tratta solo della questione relativa al termine attualmente in vigore. Occorre chiarire anche perché il termine sia stato modificato, chi abbia verificato tale modifica, se essa si basi su una valutazione giuridica, su una nuova direttiva interna, su un risultato di audit o su un cambiamento di sistema e se la modifica sia stata applicata a tutte le varianti interessate.
Lo stesso vale per un caso d’uso dell’IA. Se tale caso d’uso è attualmente autorizzato, mentre tre mesi prima era ancora in fase di valutazione, deve rimanere tracciabile quale valutazione dei rischi abbia costituito la base dell’autorizzazione, quali dati fossero stati descritti in quel momento, quale versione della Model Card fosse in vigore e se l’autorizzazione fosse stata subordinata a determinate condizioni. Eventuali modifiche successive relative al fornitore, alla finalità o all’ambito dei dati possono rendere necessaria una nuova valutazione tecnica.
Il set di dati attuale riporta il risultato. Gestione delle versioni e Audit- I trail documentano il percorso delle modifiche e delle decisioni correlate.
Art. 30 del GDPR e lo sviluppo delle attività di trattamento
Il Elenco delle attività di trattamento non è un insieme di dati qualsiasi. Art. 30 GDPR richiede, tra l’altro, informazioni sulle finalità del Elaborazione, relative alle categorie di interessati e di dati personali, ai destinatari, ai trasferimenti verso paesi terzi, ai termini di cancellazione e alle misure tecniche e organizzative. Il registro deve essere tenuto per iscritto, compreso in formato elettronico, e deve essere trasmesso all’autorità competente Autorità di vigilanza da mettere a disposizione su richiesta.[2]
Nella pratica aziendale occorre quindi innanzitutto assicurarsi che le informazioni necessarie siano complete e aggiornate. Ai fini di un sistema di protezione dei dati solido, è inoltre importante che sia possibile ricostruire come tali dati siano cambiati nel corso del tempo.
Le attività di trattamento sono soggette a modifiche periodiche. I sistemi vengono sostituiti, i fornitori di servizi cambiati, le finalità ampliate, vengono inserite ulteriori categorie di dati e i termini di cancellazione adeguati. Anche le responsabilità, i trasferimenti internazionali, le valutazioni dei rischi e le misure tecniche o organizzative possono subire variazioni.
Se la directory riporta esclusivamente lo stato attuale, all'organizzazione manca una parte essenziale delle informazioni necessarie per la verifica e il controllo.
Elementi costitutivi di una documentazione delle modifiche attendibile
Una modifica salvata non equivale automaticamente a una prova attendibile della modifica stessa. Per garantire la tracciabilità tecnica, è necessario riunire diverse informazioni.
Oggetto della modifica
Occorre documentare il valore precedente e quello nuovo, il colpiti Campo e relativo oggetto di governance.
Persona o ruolo in evoluzione
Dovrebbero essere riconoscibili il personaggio, il suo ruolo e il colpiti Unità organizzativa. Qualora la modifica avvenga nell’ambito di una sostituzione, occorre tenerne conto.
Data e versione
Sono necessari la data della modifica, la colpiti Versione e stato prima e dopo la modifica.
Motivo e giustificazione
Il motivo della modifica può derivare, ad esempio, da un ticket, da un risultato di audit, da una nuova valutazione giuridica, da una modifica dei processi o dei sistemi oppure da un cambio di fornitore di servizi.
Esame
Dovrebbe essere chiaro se la modifica sia stata verificata dal responsabile della protezione dei dati, dall’ufficio legale, dal reparto sicurezza informatica, dal dipartimento competente, dalla direzione o da altri revisori.
Approvazione
Qualora sia necessaria un'autorizzazione, è opportuno documentare chi l'ha concessa, la data, l'ambito di applicazione ed eventuali condizioni.
Documenti di supporto
Tra questi possono figurare valutazioni, decisioni, e-mail, verbali, misure, accettazioni di rischio o risultati di audit.
Conseguenze della modifica
Occorre tenere conto di quanto segue: colpiti Varianti, società locali, rischi, misure, relazioni e scadenze.
Se vengono registrati solo i movimenti di sistema, senza riportare queste informazioni specifiche, la documentazione risulta spesso incompleta. Solo il collegamento tra contenuto della modifica, responsabilità, motivo, verifica ed effetto consente una classificazione attendibile.
Requisiti tecnici relativi alla gestione delle versioni
Il controllo delle versioni viene spesso ridotto alla semplice conservazione di una versione precedente e alla memorizzazione di una nuova. Questa funzione tecnica è necessaria, ma non riflette ancora pienamente i requisiti funzionali della gestione della protezione dei dati e della governance.
Una versione può avere diversi significati. Può essere una bozza, essere stata sottoposta a revisione, revisionata, approvata, storicamente valida, sostituita o archiviata. È necessario poter distinguere tra questi diversi stati.
Un progetto non deve apparire come un documento approvato Elaborazione essere trattato. Una versione precedente può essere utilizzata per un Audit continuare ad essere rilevante, sebbene non sia più in vigore dal punto di vista operativo. Una versione approvata non dovrebbe essere sovrascritta senza un processo di modifica tracciabile. È inoltre necessario verificare se una modifica, una volta approvata, debba dare luogo a una nuova revisione. Nel caso di varianti locali, può inoltre essere rilevante la versione di uno standard di livello superiore su cui si basano.
La gestione delle versioni dovrebbe quindi essere collegata a stato, validità, verifica e approvazione.
Tracciabilità temporale
Negli audit, in caso di incidenti e nell’ambito delle decisioni dirigenziali, spesso non è la situazione attuale a essere determinante, bensì quella esistente in un determinato momento.
A tal proposito, possono risultare rilevanti, tra le altre, le seguenti domande:
- Cosa è stato documentato il giorno in cui si è verificato l'incidente?
- Quale versione era in vigore al momento dell'approvazione?
- Quali misure erano ancora in sospeso al momento dell'audit?
- Quale misura era già in ritardo in quel momento?
- Quale base giuridica era stata documentata quando il Elaborazione è stato registrato?
- Qual era il termine di conservazione dei dati al momento della loro raccolta?
- Qual era la valutazione disponibile quando la direzione ha preso la sua decisione?
Un sistema che rifletta esclusivamente lo stato attuale può, di norma, fornire solo risposte limitate a queste domande. Un sistema di governance dovrebbe quindi consentire una visione contestualizzata nel tempo. Oltre a rappresentare lo stato attuale, deve essere possibile ricostruire come una Elaborazione ad esempio com’era la situazione il 15 marzo e quali modifiche sono state apportate in seguito.
Questa funzione riveste un’importanza fondamentale per gli audit interni ed esterni, la gestione degli incidenti e la rendicontazione alla direzione.
| Domanda d'esame | Senza controllo delle versioni e Audit-Percorso | Con il controllo delle versioni e Audit-Percorso |
|---|---|---|
| Quale versione era in vigore al momento dell'audit? | Lo stato deve essere ricostruito sulla base delle esportazioni, delle e-mail o dei promemoria. | Lo stato attuale può essere visualizzato in base al momento. |
| Chi ha apportato una modifica? | Il protagonista è spesso riconoscibile solo indirettamente o non è più identificabile. | La persona, il ruolo e la data sono documentati. |
| Per quale motivo è stata apportata la modifica? | L'occasione può derivare, se del caso, semplicemente da una riunione, da un ticket o dalla cronologia delle e-mail. | La motivazione e il motivo sono associati alla pratica. |
| Chi ha dato l'autorizzazione? | L'autorizzazione potrebbe essere riportata in un verbale separato. | L'approvazione, le condizioni e il responsabile dell'approvazione sono associati alla versione. |
| Quali dati sono stati sovrascritti? | Il valore precedente non è più visibile. | I valori precedenti e successivi rimangono tracciabili. |
| Quali rischi erano noti? | La valutazione di allora deve essere ricavata da diverse fonti. | È possibile verificare il livello di rischio della rispettiva versione. |
| Quali informazioni può verificare la direzione? | Spesso sono disponibili solo lo stato attuale o i report creati manualmente. | È possibile analizzare la cronologia delle modifiche, le decisioni in sospeso e le escalation. |
| Cosa può essere presentato a un revisore? | Il risultato è visibile, ma non il processo che lo ha generato. | È possibile dimostrare il percorso documentato delle decisioni e delle modifiche. |
Il confronto evidenzia che non si tratta principalmente di comodità d'uso dal punto di vista tecnico. Ciò che conta è la capacità dell'organizzazione di spiegare in modo comprensibile il proprio livello di governance e il suo sviluppo.
Esempio: modifica di un termine di cancellazione
Con il Elaborazione „Nel sistema di “gestione delle candidature” è inizialmente documentato un periodo di conservazione di sei mesi. Successivamente, l’ufficio legale rileva che per determinati documenti è previsto un periodo più lungo Immagazzinamento potrebbe essere necessario. Il dipartimento competente propone quindi un termine di dodici mesi. Il responsabile della protezione dei dati raccomanda una logica dei termini differenziata in base alle categorie di dati. La direzione approva la modifica a condizione che i dati relativi alle candidature vengano trattati separatamente.
Senza il controllo delle versioni, nel risultato potrebbe essere visibile solo la seguente indicazione:
Periodo di conservazione: dodici mesi
Con il controllo delle versioni e Audit-Trail consente invece di rappresentare l'intero processo:
- Versione 1 con un periodo di conservazione dei dati di sei mesi,
- Avvio di una revisione a seguito della segnalazione dell'ufficio legale,
- Raccomandazione del Garante per la protezione dei dati relativa a una logica differenziata dei termini,
- Decisione gestionale in base a condizioni prestabilite,
- Versione 2, che prevede un termine di dodici mesi per determinati documenti e un termine più breve per altri dati,
- Misura volta ad adeguare la configurazione del sistema,
- Nuova valutazione sei mesi dopo l'attuazione.
Il valore probatorio varia notevolmente. Nel secondo caso è possibile individuare su quali valutazioni e decisioni tecniche si basi lo stato documentato.
Esempio: modifica di un caso d'uso dell'IA
Un caso d'uso dell'IA verrà inizialmente autorizzato per la sintesi interna delle richieste dei clienti. In un secondo momento, il reparto competente intende utilizzare il risultato anche per stabilire le priorità delle richieste dei clienti. Successivamente, è previsto l'inserimento di un ulteriore campo dati nel Elaborazione vengano coinvolti.
Ciascuna di queste modifiche può essere rilevante ai fini della valutazione tecnica e dal punto di vista della protezione dei dati. In particolare, occorre verificare:
- Lo scopo del caso d'uso è cambiato?
- Se vengono aggiunti ulteriori Dati personali elaborato?
- Il rischio per le persone interessate subisce variazioni?
- La supervisione umana prevista è ancora sufficiente?
- L'ufficio legale deve riesaminare il fornitore?
- È necessario aggiornare la Model Card?
- È necessaria una nuova autorizzazione?
Senza Audit-Trail potrebbe mostrare solo la descrizione attuale del caso d'uso. Con un approccio tecnico Audit-Il trail consente di ricostruire l'evoluzione nel tempo della finalità, dell'entità dei dati, della valutazione e dell'autorizzazione.
Ciò riveste particolare importanza per la governance dell'IA, poiché il contesto di impiego, i dati utilizzati e il comportamento del modello possono cambiare anche dopo la prima messa in funzione.
Domande tipiche durante gli audit
Un revisore non si limita a verificare periodicamente se un determinato campo sia stato compilato. Per valutare l'affidabilità di un processo di protezione dei dati, sono invece rilevanti le questioni relative alle competenze, alla verifica e al processo decisionale.
Tra questi figurano in particolare:
- Chi è responsabile della procedura?
- Quando è stato verificato l'insieme di dati l'ultima volta?
- Quali dati sono stati modificati?
- Per quale motivo è stata apportata la modifica?
- Quale versione era in vigore in un determinato momento?
- Chi ha approvato la versione in questione?
- Su quale raccomandazione si è basata la decisione?
- Quale misura è stata adottata sulla base della valutazione?
- Quali rischi erano ancora in sospeso?
- Come sono state gestite le discrepanze riscontrate?
- Perché lo stato attuale può essere considerato affidabile?
Una dashboard può illustrare in modo chiaro lo stato attuale. Per rispondere a queste domande, tuttavia, è necessaria anche una documentazione che dimostri come si sia giunti allo stato documentato.
Rilevanza per i diversi processi di protezione dei dati
Controllo delle versioni e Audit-Trail sono rilevanti per numerosi processi relativi alla protezione dei dati e alla governance.
Elenco delle attività di trattamento
Devono essere documentate le modifiche relative alle finalità, alle categorie di dati, ai destinatari, Base giuridica, i termini di cancellazione, le misure tecniche e organizzative, nonché le responsabilità.
Valutazione d'impatto sulla protezione dei dati
Sono rilevanti le diverse versioni della valutazione dei rischi, le raccomandazioni, le misure, i rischi residui e le autorizzazioni.
Verifica dei fornitori di servizi
Dovrebbero rimanere tracciabili le modifiche relative al fornitore, ai subappaltatori, alle misure tecniche e organizzative, ai meccanismi di trasferimento, ai contratti e alle valutazioni dei rischi.
Richieste di informazioni da parte delle parti interessate
È possibile registrare le singole fasi di elaborazione, le scadenze, i sistemi coinvolti, le decisioni relative alle eccezioni e le diverse versioni della risposta.
Incidenti relativi alla protezione dei dati
Sono rilevanti lo svolgimento dei fatti, la relativa valutazione, la decisione in merito alla segnalazione, le misure che ne derivano e la comunicazione.
Governance dell'IA
Tra questi figurano la descrizione del caso d'uso, la Model Card, la classificazione dei rischi, le condizioni di approvazione, il monitoraggio e le revisioni successive.
Gestione delle misure
I cambiamenti di stato dovrebbero essere tracciabili, Persone responsabili, scadenze, documentazione, procedure di escalation e la relativa decisione finale.
Alla base di tutti i processi vi è lo stesso requisito: l’organizzazione dovrebbe essere in grado, in un momento successivo, di spiegare come sia giunta alla decisione attuale partendo dalle prime informazioni ricevute.
Approvazioni relative alle versioni
Un'autorizzazione deve indicare chiaramente quale contenuto specifico sia stato autorizzato. Se un Elaborazione Se il contenuto viene modificato successivamente senza creare una nuova versione, la condivisione originale potrebbe riferirsi a un contenuto che, al momento della condivisione, non era ancora disponibile in quella forma.
In questo caso non è più possibile stabilire con certezza se l'approvazione comprenda anche lo stato attuale.
È quindi necessario che le approvazioni possano essere associate a una versione specifica. Ciò riguarda, ad esempio:
- la versione di una Elaborazione,
- la versione di una Valutazione d'impatto sulla protezione dei dati,
- la versione di una Model Card,
- la versione di una valutazione dei rischi,
- la versione di una misura,
- la versione di un rapporto.
Se, dopo l'approvazione, viene modificato un campo essenziale, occorre verificare se l'approvazione originaria rimane valida o se è necessaria una nuova revisione.
Audit trail e fiducia dei dirigenti
La direzione non è tenuta a verificare ogni singola modifica apportata a un sistema di gestione della protezione dei dati. Deve tuttavia poter contare sul fatto che le modifiche di rilevante importanza tecnica o giuridica vengano effettuate in modo controllato.
Ciò riguarda in particolare le modifiche relative a:
- Base giuridica,
- Termini di cancellazione,
- Categorie di dati,
- Destinatari,
- trasferimenti internazionali di dati,
- Fornitori di servizi,
- Valutazione dei rischi,
- Condizioni di autorizzazione,
- Responsabilità,
- lo stato delle misure critiche,
- Decisioni relative alla segnalazione di incidenti,
- ai fini dei casi d'uso dell'IA.
Se le modifiche vengono apportate senza un processo tracciabile, la direzione può sì vedere lo stato attuale, ma non è in grado di stabilire se esso derivi da una decisione formalizzata o da un intervento non ulteriormente documentato.
A Audit-Trail rafforza la fiducia dei dirigenti, poiché consente di verificare, all’occorrenza, le modifiche critiche e di ricostruire le decisioni alla base delle stesse.
Requisiti di una piattaforma di governance come Ailance
Per una piattaforma di governance come Ailance, ciò significa che la mappatura funzionale non dovrebbe limitarsi alla memorizzazione dei dati attuali. Le modifiche devono poter essere registrate in modo tale da rendere tracciabili la loro origine, la loro verifica e le loro ripercussioni.
Tra questi figurano in particolare:
- Versioni degli oggetti di governance,
- una cronologia delle modifiche con i valori precedenti e successivi,
- l'assegnazione dei ruoli e delle persone,
- Date e versioni,
- Cambio di stato,
- Autorizzazioni,
- Motivazioni,
- Collegamenti con misure, rischi e prove,
- viste relative a un determinato momento,
- Segnalazioni relative a modifiche critiche,
- Esportazione della cronologia per Audit- e a fini gestionali.
Una voce nel Elenco delle attività di trattamento può essere rappresentato in questo modo come un processo tracciabile. Nel caso di una Valutazione d'impatto sulla protezione dei dati È possibile documentare l'intero processo, dalla prima valutazione fino all'approvazione. Un caso d'uso dell'IA può essere collegato alle varie fasi del suo ciclo di vita, con versioni, revisioni, approvazioni e monitoraggio.
È proprio qui che risiede la differenza organizzativa tra il semplice archiviazione di un record di dati aggiornato e la rappresentazione di un processo di governance.
Differenziazione in base alla criticità di una modifica
Le modifiche possono avere un significato tecnico diverso. La correzione di un errore di battitura nel testo descrittivo non comporta solitamente una procedura analoga a quella necessaria per l’inserimento di una nuova categoria di dati o la modifica di una base giuridica.
Una piattaforma di governance dovrebbe quindi essere in grado di distinguere in base alla criticità di una modifica.
Tra gli aspetti tipicamente considerati particolarmente rilevanti figurano:
- Modifica delle finalità del trattamento,
- Inserimento di nuove categorie di dati,
- Inclusione di nuovi gruppi di persone interessate,
- Aggiungere nuovi destinatari,
- Cambio o assunzione di un fornitore di servizi,
- Registrazione di un trasferimento da un paese terzo,
- Modifica del termine di cancellazione,
- Modifica della base giuridica,
- Modifica della valutazione del rischio,
- Modifica delle condizioni di autorizzazione,
- Cambio di proprietario,
- Conclusione o ripristino delle misure critiche,
- Modifica dello stato di un incidente,
- Modifica dello scopo di un caso d'uso dell'IA,
- Modifica di una Model Card o della supervisione umana prevista.
Tali modifiche dovrebbero almeno essere registrate. A seconda del profilo di rischio specifico, si può inoltre prevedere che venga avviata automaticamente una revisione, un'approvazione o un'escalation.
Protezione della cronologia delle modifiche
Se un Audit-Affinché il trail funga da prova attendibile, non deve essere possibile modificarne arbitrariamente la cronologia a posteriori. In caso contrario, la cronologia perderebbe gran parte del suo valore probatorio.
Ciò non significa che ogni file di log tecnico debba essere immutabile come un atto notarile. Dal punto di vista tecnico, tuttavia, occorre garantire che le modifiche apportate alla cronologia avvengano in modo controllato e rimangano a loro volta tracciabili.
Se viene corretta una voce errata, la cronologia originale non dovrebbe quindi essere cancellata. È invece necessario creare un’ulteriore modifica documentata.
In caso di correzioni significative, dovrebbe rimanere chiaramente riconoscibile in particolare:
- Quale informazione era errata?
- Chi ha effettuato la correzione?
- Per quale motivo è stata necessaria la correzione?
- Quando è avvenuta?
- Da allora quale versione è in vigore?
Una cronologia opportunamente strutturata può contribuire, nella pratica, a evitare successive ambiguità riguardo al contenuto e alla data di una modifica.
Rilevanza per le relazioni sulla protezione dei dati
Controllo delle versioni e Audit-I dati relativi al trail sono rilevanti anche per le relazioni destinate alla direzione. Una relazione sulla protezione dei dati dovrebbe, oltre a riportare gli indicatori attuali, evidenziare quali sviluppi significativi si sono verificati dal periodo di riferimento precedente.
In particolare, potrebbero risultare di interesse le seguenti questioni:
- Quali rischi sono stati recentemente individuati?
- Quali misure sono rimaste in sospeso dall'ultima relazione?
- Quali raccomandazioni sono state attuate?
- Quali modifiche significative sono state apportate nel Elenco delle attività di trattamento?
- Quali autorizzazioni sono state concesse a determinate condizioni?
- Quali episodi hanno portato a modifiche nei processi?
- Quali casi d'uso dell'IA sono stati recentemente approvati o modificati in modo sostanziale?
Senza un sistema di controllo delle versioni, tali sviluppi devono spesso essere ricostruiti sulla base di singole esportazioni, e-mail o registrazioni manuali. Grazie a una cronologia strutturata delle modifiche, è possibile analizzarli in modo sistematico e inserirli nei report gestionali.
Rapporti "punto nel tempo"
Una funzione particolarmente rilevante per gli audit e i rapporti di gestione è il rapporto “Point-in-Time”. Esso consente di illustrare lo stato della protezione dei dati in una data specifica.
Un rapporto di questo tipo può, ad esempio, illustrare lo stato documentato
- il giorno di un audit,
- il giorno in cui si è verificato un incidente,
- il giorno in cui viene presa una decisione a livello dirigenziale,
- il giorno dell'autorizzazione o
- come si presentava alla fine di un esercizio finanziario.
Questa funzione impedisce che le modifiche successive sovrascrivano lo stato precedente. Allo stesso tempo, è possibile documentare quali modifiche sono state apportate in seguito a un determinato evento.
Per gli audit interni, le verifiche esterne, le richieste delle autorità e i rapporti di gestione, questa ricostruzione temporale può avere un notevole utilità pratica.
Requisiti nei bandi di gara e nelle richieste di offerta (RFP)
La questione generale se un sistema disponga di un Audit-Il fatto che un prodotto disponga di un percorso di test spesso non è sufficiente per una valutazione attendibile dello stesso. Poiché molti fornitori risponderanno affermativamente a tale domanda, i requisiti tecnici dovrebbero essere descritti in modo più concreto.
Ecco alcuni esempi di domande appropriate:
- Quali oggetti vengono sottoposti a controllo di versione?
- Quali campi vengono archiviati?
- Vengono salvati i valori precedenti e quelli successivi?
- È possibile associare le autorizzazioni a una versione specifica?
- Esiste una prospettiva legata al tempo?
- I cambiamenti di stato sono tracciabili?
- È possibile analizzare le modifiche apportate ai ruoli e alle autorizzazioni?
- Vengono registrate le motivazioni delle modifiche critiche?
- Le modifiche critiche possono attivare automaticamente delle revisioni?
- È possibile esportare la cronologia?
- Come si fa a... Audit- Il tracciato è protetto da eventuali manomissioni successive?
- Per quanto tempo vengono conservati i dati storici?
Queste domande consentono di distinguere tra una funzione semplicemente indicata e la sua configurazione tecnicamente valida.
Matrice di valutazione delle richieste di offerta
| Domanda di valutazione | Risposta debole | Risposta attendibile |
|---|---|---|
| Esiste un sistema di gestione delle versioni? | Le versioni precedenti vengono salvate. | Le versioni degli oggetti, gli stati, le approvazioni e i periodi di validità sono tracciabili. |
| Esiste un Audit-Trail? | Le modifiche vengono registrate. | Sono visibili: persona, ruolo, data, contenuto della modifica, valori precedenti e successivi, motivazione e variazione dello stato. |
| È possibile assegnare un numero di versione alle autorizzazioni? | L'autorizzazione è indicata sull'oggetto. | L'approvazione si riferisce a una versione specifica e a condizioni documentate. |
| Esistono viste "punto nel tempo"? | Una ricostruzione è possibile, al massimo, attraverso le esportazioni. | È possibile verificare immediatamente la situazione a una data specifica. |
| Vengono rilevate le modifiche critiche? | Le modifiche vengono semplicemente salvate. | Alcune modifiche possono dare luogo a revisioni, attività o escalation. |
| È possibile esportare la cronologia? | Le esportazioni sono possibili solo in parte. | Un’esportazione verificabile contiene la cronologia delle modifiche e la relativa documentazione. |
| Le modifiche ai diritti vengono registrate? | È disponibile solo un log di amministrazione generale. | È possibile tracciare la cronologia dei ruoli, delle autorizzazioni e degli accessi. |
| Se il Audit- Il sentiero è protetto? | Gli amministratori possono gestire o sovrascrivere i log. | La cronologia è controllata; le correzioni generano ulteriori voci tracciabili. |
Le aziende che scelgono una piattaforma di governance dovrebbero tenere conto di questi requisiti, per quanto possibile, già durante il processo di selezione e non solo dopo una prima valutazione.
Esame pratico di un’analisi critica
Per una prima analisi della situazione, può essere utile una valutazione critica Elaborazione vengono selezionati all’interno dell’azienda e valutati sulla base di quattro domande:
- Qual era la versione in vigore sei mesi fa?
- Chi ha apportato modifiche da allora?
- Per quale motivo sono state apportate queste modifiche?
- Quali autorizzazioni sono previste allo stato attuale?
Se è possibile rispondere a queste domande solo sulla base di e-mail, vecchie esportazioni o ricordi personali, manca una documentazione strutturata e attendibile delle modifiche apportate.
Conclusione
Controllo delle versioni e Audit-I trail costituiscono una base fondamentale per la rendicontazione, la verificabilità e la fiducia del management nei processi documentati relativi alla protezione dei dati.
Un’organizzazione che non è in grado di risalire a chi abbia modificato un dato rilevante e a quale verifica sia basata tale modifica, spesso può fornire solo spiegazioni limitate riguardo allo stato attuale della situazione agli auditor, alle autorità di vigilanza o alla propria direzione.
Un sistema di gestione della protezione dei dati dovrebbe quindi essere in grado di rappresentare non solo lo stato attuale, ma anche la sua evoluzione. Ciò comprende la versione vigente, i soggetti responsabili e i revisori, il motivo della modifica, l’approvazione, i rischi noti e lo stato documentato in un determinato momento.
Controllo delle versioni e Audit-Il percorso riguarda quindi questioni fondamentali di governance. Lo stato attuale è particolarmente solido quando la sua genesi è stata documentata in modo trasparente.
Per l'esame pratico rimane quindi fondamentale la seguente domanda: quale modifica critica l'organizzazione non sarebbe in grado di spiegare in modo esauriente oggi?
Domande e risposte
Perché la gestione delle versioni e la traccia di audit sono importanti nei software per la protezione dei dati?
Le decisioni in materia di protezione dei dati devono poter essere spiegate in modo comprensibile in un momento successivo. Gestione delle versioni e Audit-Il trail mostra quale versione era in vigore in un determinato momento, chi ha apportato le modifiche, per quale motivo sono state effettuate e quali verifiche o approvazioni sono state necessarie.
L’audit trail è un obbligo di legge previsto dal GDPR?
Il GDPR non utilizza in genere il termine per indicare i software di protezione dei dati Audit-Trail. La responsabilità richiede tuttavia che Persone responsabili possano dimostrare il rispetto dei requisiti in materia di protezione dei dati. Un Audit- Il “trail” può essere considerato uno strumento pratico per documentare in modo tracciabile le decisioni, le modifiche e la relativa documentazione di supporto.
Qual è la differenza tra gestione delle versioni e audit trail?
Il controllo delle versioni rappresenta le diverse versioni di un oggetto, ad esempio un Elaborazione o uno Valutazione d'impatto sulla protezione dei dati. Il Audit- Il trail documenta la cronologia delle modifiche e mostra chi ha modificato, verificato, approvato o segnalato quali dati e in quale momento.
Quali informazioni dovrebbe contenere una traccia di audit?
Un sistema tecnicamente affidabile Audit-Il percorso dovrebbe includere almeno il personaggio, il suo ruolo, il momento, il colpiti Contenere l'oggetto, i campi modificati, i valori precedenti e successivi, i cambiamenti di stato, le motivazioni, le approvazioni e la documentazione correlata.
Perché lo stato attuale non è sufficiente?
Gli audit e le decisioni gestionali si riferiscono spesso a un determinato momento. In tali casi, ciò che conta non è solo ciò che è documentato oggi, ma quali informazioni erano valide al momento di riferimento e come la situazione sia poi cambiata.
Quali modifiche sono particolarmente critiche?
Particolarmente rilevanti possono essere le modifiche relative alla finalità, alle categorie di dati, Base giuridica, i termini di cancellazione, i destinatari, i fornitori di servizi, i trasferimenti internazionali, le valutazioni dei rischi, le condizioni di autorizzazione, gli incidenti e le descrizioni dei casi d’uso dell’IA.
Perché è necessario gestire le versioni delle condivisioni?
Un’approvazione può essere attribuita in modo univoco solo se è possibile identificare quale versione specifica sia stata verificata e approvata. Se il contenuto viene successivamente modificato in modo sostanziale, occorre verificare se l’approvazione originaria sia ancora valida.
Che cos'è una visione "punto nel tempo"?
Una visione “punto nel tempo” mostra lo stato documentato di un processo in una data specifica, ad esempio al momento di un audit, di un incidente o di una decisione dirigenziale.
In che modo il controllo delle versioni facilita la rendicontazione gestionale?
Mette in evidenza gli sviluppi verificatisi tra le diverse date di riferimento. Tra questi figurano i rischi individuati di recente, le modifiche alle attività di trattamento, le misure in sospeso, le autorizzazioni aggiornate, le modifiche ricorrenti o i miglioramenti apportati a seguito di un incidente.
Quali domande relative alla richiesta di offerta (RFP) è opportuno porre riguardo alla traccia di audit?
In particolare, occorre verificare quali oggetti e campi siano sottoposti a controllo delle versioni, se siano visibili i valori precedenti e successivi, se le approvazioni possano essere associate a versioni specifiche, se siano disponibili viste "puntoin un determinato momento, se le modifiche ai diritti vengono registrate e in che modo la cronologia viene protetta da modifiche successive.
In che modo Ailance supporta la gestione delle versioni e la tracciabilità?
Ailance non dovrebbe trattare gli oggetti di governance esclusivamente come record di dati attuali, ma dovrebbe rappresentare in modo tracciabile le modifiche, le approvazioni, i cambiamenti di stato, le responsabilità, le motivazioni e le prove. In questo modo è possibile creare un percorso documentato delle decisioni e delle modifiche.
Quale modifica critica dovrebbe essere esaminata per prima?
Come punto di partenza è indicata una Elaborazione, in cui sono stati modificati la finalità, le categorie di dati, il termine di conservazione, i fornitori di servizi o la base giuridica. Se non è possibile risalire a chi ha apportato, verificato e approvato la modifica, è opportuno esaminare più approfonditamente il processo sottostante
Riferimenti bibliografici
[1] Comitato europeo per la protezione dei dati sulla responsabilità nell'ambito della GDPR.
[2] Art. 30 GDPR.
German 
English 
Italian 
French