Marcus Belke
CEO di 2B Advice GmbH, che guida l'innovazione nella privacy conformità e di gestione del rischio e di guidare lo sviluppo di Ailance, la nuova generazione di prodotti per la salute. conformità piattaforma.
Una buona preparazione dell'audit significa molto di più di una relazione di audit completa. Documentazione da fornire. Richiede responsabilità chiare, prove strutturate e processi trasparenti. Le aziende che stabiliscono queste strutture in una fase iniziale evitano lo stress durante l'audit e rafforzano allo stesso tempo la loro governance. In questo articolo scoprirete come ragionano gli auditor, quali sono i punti deboli che si verificano frequentemente negli audit sulla protezione dei dati e come potete prepararvi a un audit in modo strutturato.
Cosa si aspettano di solito i revisori
Gli organismi di revisione (Autorità di vigilanza, audit interno, revisore esterno, cliente/partner) possono differire nel tono, ma raramente nelle loro affermazioni fondamentali. I revisori cercano risposte affidabili a tre domande chiave:
- L'organizzazione conosce il suo Elaborazione?
„Cosa trattiamo, perché, per quanto tempo, con chi, dove?“. (VVT come prova principale). - Le misure di protezione scelte sono in linea con il rischio e sono efficaci?
I TOM non sono solo „sulla carta“, ma sono stati implementati e rivisti in modo comprensibile. - Sono Diritti degli interessati e obblighi resi operativi?
Informazioni/Cancellazione, gestione degli incidenti, Obbligo di informazione, I processi per la revoca del consenso devono essere definiti come veri e propri processi con scadenze e responsabilità.
È inoltre fondamentale per le autorità di vigilanza che Persone responsabili e gli elaboratori cooperano su richiesta. Il comportamento di cooperazione può anche essere soggetto a multe (criterio di riduzione/valutazione).
Metodi di test che dovreste realisticamente pianificare
In pratica, si ricorre a una combinazione di esami documentali, questionari strutturati, interviste e controlli a campione. Il fatto che le autorità di controllo possano effettuare verifiche sulla protezione dei dati e richiedere informazioni, tra le altre cose, è sancito dal quadro giuridico di autorizzazione.
Il questionario BayLDA, ad esempio, fornisce una prospettiva molto „audit-related“: chiede esplicitamente la governance della protezione dei dati, il coinvolgimento del responsabile della protezione dei dati, la VVT, la privacy by design, i processori/contratti, Obbligo di informazione, diritti degli interessati, prova del consenso e gestione della protezione dei dati. Si tratta praticamente di un catalogo di aspettative.
Metodologia di test | Come gli ispettori riconoscono la maturità | Prove tipiche |
Esame dei documenti („DeskAudit“) | Coerenza: VVT ↔ TOM ↔ DSFA ↔ Contratti ↔ Periodi di cancellazione ↔Obbligo di informazione | VVT, concetto/mappatura TOM, contratti AV,Concetto di cancellazione, DPIA/analisi dei rischi, prova del consenso |
Questionario (audit ufficiale/partner) | Capacità di rispondere senza „invenzioni ad hoc“; chiare responsabilità | Questionari compilati, indice di verifica per domanda (link al voucher) |
Interviste/workshop | I dipendenti conoscono il processo, l'escalation, le scadenze; non ci sono dichiarazioni contraddittorie. | Matrice dei ruoli, certificati di formazione, manuali dei processi, esempi di ticket/flussi di lavoro |
Campioni/passeggiata | „Mostrami“: informazioni,Cancellazione, Autorizzazione, risposta agli incidenti effettivamente realizzabile | 1-3 fascicoli per processo (ticket DSAR, corse per la cancellazione, revisione delle autorizzazioni, runbook degli incidenti) |
Prove tecniche (demo/log) | Efficacia e tracciabilità (ad es. ruoli/diritti, 2FA, test di backup) | Concetti di autorizzazione, protocolli, protocolli di test di backup, prove di rollout MFA |
Suggerimento per il collegamento:Questionario GDPR LDA Baviera
Domande tipiche del test e criteri di valutazione
I seguenti esempi sono formulati in modo tale da essere adatti sia agli audit delle autorità che a quelli dei clienti e delle certificazioni. Riflettono le domande tipiche delle autorità (ad esempio il questionario BayLDA) e del sistema DSK (VVT/DSFA/Diritti degli interessati).
| Blocco tematico | Domanda tipica del test | Criterio di valutazione (cosa significa „buono“) | Prove tipiche |
|---|---|---|---|
| La governance | „È Protezione dei dati Una questione che riguarda il capo, le responsabilità sono regolamentate?“.“ | Le responsabilità sono documentate ed efficaci nella vita quotidiana | Linee guida per la protezione dei dati, ruoli/RACI, concetto di integrazione del DPO |
| Trasparenza di elaborazione | „Esiste un VVT, è completo e aggiornato?“.“ | Il VVT copre le operazioni di elaborazione reali, compresi i destinatari, i periodi di cancellazione, la descrizione del TOM. | VVT + processo di modifica/protocollo di revisione |
| Elaborazione dell'ordine | „Sono stati registrati tutti i responsabili del trattamento e sono stati stipulati i contratti GDPR art. 28?“.“ | Elenco completo dei fornitori; contratti AV con contenuti minimi; meccanismo di controllo | Registro dei fornitori, contratti AV, controllo TOM Fornitore di servizi |
| Diritti degli interessati | „Siete in grado di fornire informazioni entro la scadenza?“.“ | Processo e organizzazione assicurano informazioni tempestive e comprensibili. | Processo DSAR, esempi di risposte, esempi di ticket |
| Cancellazione | „Come garantite i periodi di cancellazione per ogni tipo di dati?“.“ | Concetto di cancellazione dei dati per ogni tipo di dati; scadenze giustificate; esecuzione documentata della cancellazione. | Concetto di cancellazione, registri di cancellazione, regole di eccezione/blocco |
| Rischio/DSFA | „Per quali processi eseguite una DPIA?“.“ | DPIA prima dell'inizio; decisione per processo documentata; misure derivate | Rapporti DSFA, analisi del valore soglia, piano d'azione |
| Consensi | „Può fornire la prova del consenso e Revoca renderlo possibile?“.“ | Verificabilità, informazione, meccanismo di cancellazione | Registro dei consensi, schermate dell'interfaccia utente, registri |
Frequenti carenze negli audit
I punti deboli che seguono non sono „errori teorici“, ma lacune tipiche tra la conformità cartacea e la vita quotidiana. Gli esempi sono volutamente basati sulle domande delle ispezioni ufficiali e sui cataloghi di buone pratiche (ad esempio, le liste di controllo TOM), poiché gli ispettori pongono domande proprio nei casi in cui l'attuazione è spesso incompleta.
Difetti tecnici
Un risultato frequente dell'audit non è „nessuna TOM“, ma una TOM senza riferimento all'efficacia: sebbene ci sia un PDF con parole chiave, non ci sono prove affidabili che le misure siano state implementate, testate e selezionate in base al rischio. Sebbene il parametro „riesaminare/valutare regolarmente“ sia esplicitamente affrontato, è praticamente impossibile da soddisfare senza una descrizione concreta.
Esempi tecnici concreti e spesso criticati:
- Debole AutenticazioneMancato (o incoerente) utilizzo di 2FA in aree ad alto rischio, mancanza di blocco in caso di tentativi falliti, password condivise/scritte, standard inadeguati per le password degli amministratori.
- Concetto di ruolo/diritto immaturo: mancanza di profili di ruolo, assenza di controlli regolari, „caselle di posta elettronica delle funzioni“ e conti collettivi senza responsabilità.
- Backup/ripristino come punto cieco: nessun concetto di backup scritto, nessun test di ripristino, nessuna strategia 3-2-1, potenzialmente compromesso da Ransomware Backup criptati, piano di emergenza mancante o non testato.
- Rischi mobili/remoti: mancanza di crittografia completa dei dispositivi, mancanza di MDM, fonti di app non sicure, assenza di una chiara catena di perdita.
Carenze organizzative
In questo caso, le organizzazioni spesso falliscono a causa delle responsabilità e del controllo, non a causa delle conoscenze giuridiche.
- La funzione DPO/protezione dei dati viene integrata troppo tardi. I progetti iniziano e i sistemi entrano in funzione mentre la protezione dei dati viene „trascinata“. Tuttavia, ciò si scontra con l'aspettativa che le questioni relative alla protezione dei dati siano prese in considerazione fin dall'inizio o quando i processi vengono modificati (privacy by design nella logica della domanda di audit).
- Non esiste un solido sistema di gestione della protezione dei dati, ma solo singole misure non riunite in un sistema che ne strutturi l'attuazione, la verifica e l'aggiornamento. È proprio questa capacità di „garantire e fornire prove“ (basata sul rischio) il cuore della logica della responsabilità.
- La gestione dei fornitori di servizi è formale, ma non sostanziale: esistono contratti AV, ma non c'è una panoramica completa dei fornitori di servizi, non c'è un'analisi dei dati. Trasparenza attraverso i subprocessori e nessun audit ricorrente delle misure tecniche e organizzative. I revisori chiedono proprio una „panoramica“ e un „contenuto minimo art. 28“.
Frequenti carenze negli audit
Lo stress da audit è raramente causato da singole domande, ma soprattutto da ricerche disorganizzate, dichiarazioni contraddittorie e una ripartizione dei ruoli poco chiara. Evitare lo stress è quindi innanzitutto una questione di organizzazione.
Prima dell'audit
Una leva efficace è la „mappatura delle evidenze“: a ogni requisito di prova vengono fornite in anticipo evidenze chiare („singola fonte di verità“) e una responsabile ruolo. In questo modo si eviterà una raccolta frenetica durante l'esame.
Come standard minimo, prima dell'appuntamento è necessario assicurarsi di quanto segue:
- Un unico punto di contatto (SPoC) per la comunicazione con gli ispettori (evita le chat parallele e le dichiarazioni divergenti).
- Chiarimento dei ruoli: chi risponde a „Policy“, chi a „Dettagli IT“, chi a „Processi HR“, chi a „Legale/Contratti“.
- Eseguire un audit simulato con cinque-dieci domande chiave (VVT, DSAR), Cancellazione, AV, TOM, DSFA) come prova generale.
Il fatto che la cooperazione e un approccio strutturato non siano solo „soft skills“ è dimostrato dal fatto che il comportamento cooperativo può essere preso in considerazione nelle misure di vigilanza e nella valutazione delle ammende.
Durante l'audit
La regola collaudata della comunicazione è: „Risposta + prova + contesto“.
- La risposta deve essere breve, concreta e verificabile.
- Il documento deve essere immediatamente linkabile nella cartella di audit (non „invia a qualcuno“ come modalità predefinita).
- Contesto: Delimitazione se l'ambito non è applicabile (ad esempio, „si applica solo al sistema X, non a Y“).
Per i contatti con le autorità, è importante anche che Persone responsabili e processori su richiesta.
Dopo l'audit
La fase successiva determina se il Audit „diventa “costoso":
- Triage dei reperti (alto/medio/basso) in base al rischio di Parti interessate e probabilità di accadimento; contenuto coerente con i requisiti basati sul rischio e la logica della DPIA.
- Viene redatto un piano d'azione con una persona responsabile, una scadenza e una forma di verifica. Il DSK raccomanda espressamente di adottare un approccio coordinato per i progetti di attuazione e di informare la direzione come punto di partenza.
- Prove di chiusura: Ogni misura non termina con „implementato“, ma con „dimostrato che è stato implementato“ (ad esempio, screenshot, log, report di test).
Il controllo di audit in un colpo d'occhio
Punti di controllo | Persone responsabili Ruolo | Forma di prova | Priorità |
Ambito dell'audit, sistemi, sedi, periodo definito | Gestione / Coordinamento della protezione dei dati | Documento di audit readme + scope | Alto |
Punto di contatto unico (SPoC) + regole di comunicazione definite | Coordinamento della protezione dei dati | Scheda di ruolo + piano di comunicazione | Alto |
Ruoli di protezione dei dati/RACI, compreso il coinvolgimento del DPO, sono chiari. | Gestione / DPO | RACI, organigramma, processo di integrazione | Alto |
VVT completo, aggiornato, in versione | Proprietari dei processi + DPO | Master VVT + registro delle modifiche | Alto |
Il VVT contiene periodi/criteri di cancellazione per categoria di dati. | Proprietario del processo | Campi VVT + riferimenti a Concetto di cancellazione | Alto |
Il VVT contiene riferimenti al TOM / descrizione generale del TOM | Sicurezza informatica + DPO | Voce VVT + link al documento TOM | Alto |
Verifica del TOM: mappatura del rischio→misura disponibile | Sicurezza informatica + DPO | Matrice/mappatura TOM | Alto |
AutenticazionePolitica delle password + 2FA per il rischio elevato | Sicurezza informatica | Politica + impostazioni/rapporti di sistema | Alto |
Concetto di ruolo/diritto documentato e verificato | Sicurezza IT / Operazioni IT | Modello di ruolo + protocollo di revisione | Alto |
Concetto di backup scritto + test di ripristino | Operazioni IT / BCM | Concetto di backup + protocolli di test | Alto |
Piano di emergenza/BCM in atto e praticato | BCM / IT Ops | Piano di emergenza e protocolli di esercitazione | Medio |
Registro fornitori completo (tutti i processori) | Gestione degli acquisti/dei fornitori + DSB | Elenco dei fornitori di servizi | Alto |
Contratti AV con contenuto minimo (art. 28) per tutti gli AV | Legale + DPO | Contratti AV + allegato | Alto |
Trasparenza del sottoprocessore + processo di rilascio | Gestione dei fornitori + Legale | Elenco dei sottoprocessori + release | Medio |
Testi informativi obbligatori (art. 13/14) per processo centrale | Legale/Marketing + DSB | Informazioni sulla protezione dei dati + versioning | Alto |
Processo DSAR (Intake, Ident, Ricerca dati, Risposta) | Servizio clienti / DPO | Descrizione del processo + esempi di ticket | Alto |
Scadenze informative/monitoraggio delle scadenze reso operativo | DPO / Dipartimenti | Scadenza SLA + flusso di lavoro | Alto |
Concetto di cancellazione per tipo di dati (scopo, durata, requisiti) | Gestione dei registri / DSB | Concetto di estinzione | Alto |
Cancellare le corse verificabili (registri/rapporti) | IT Ops / reparti specializzati | Registri di cancellazione | Alto |
Procedura per le richieste di cancellazione ai sensi dell'Art. 17 | DPO / Servizio | Processo + fascicolo | Alto |
Analisi del valore di soglia: DSFA sì/no per processo ad alto rischio | DSB + proprietario del processo | Documento di analisi delle soglie | Alto |
DSFA effettuato prima della messa in servizio (dove richiesto) | DPO + gestione del progetto | Relazione DSFA + piano d'azione | Alto |
Prova del consenso + meccanismo di revoca | Marketing/Prodotto + DSB | Registro dei consensi + registri/UI | Alto |
Formazione/sensibilizzazione (Phishing, trasferimento dati) | Risorse umane + sicurezza informatica | Piano di formazione + registri delle presenze | Medio |
Registro di richiesta per Audit (Domande, risposte, documenti di supporto, scadenze) | Audit SPoC | Registro di audit (ad es. tavolo/biglietto) | Alto |
Piano d'azione secondo Audit (Proprietario, data, ricevuta) | Gestione / DPO | Piano d'azione + prova di chiusura | Alto |
Pronti per l'audit con 2B Advice e Ailance
La capacità di audit non si manifesta solo quando viene annunciato un audit. È il risultato di strutture chiare, processi trasparenti e prove comprensibili nella protezione dei dati.
Le aziende che organizzano la protezione dei dati in modo strategico traggono un doppio vantaggio: superano gli audit con maggiore sicurezza e allo stesso tempo rafforzano la loro governance e la fiducia di clienti e partner.
Se volete sapere quanto la vostra azienda sia preparata ad affrontare un audit sulla protezione dei dati, vale la pena di esaminare in modo strutturato i vostri processi.
Scoprite le nostre soluzioni per la protezione dei dati e la gestione della conformità con Ailance e contattate i nostri esperti.
Marcus Belke è CEO di 2B Advice e avvocato ed esperto di informatica per la protezione dei dati e la digitalizzazione. Conformità. Scrive regolarmente di governance dell'IA, conformità al GDPR e gestione del rischio. Potete trovare maggiori informazioni su di lui sul sito Pagina del profilo dell'autore.
German 
English 
Italian 
French