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 Audit-La preparazione significa molto più che una semplice Documentazione da mettere a disposizione. Ciò richiede responsabilità ben definite, documentazione strutturata e processi trasparenti. Le aziende che mettono in atto queste strutture in anticipo evitano lo stress durante l’audit e rafforzano al contempo la propria governance. In questo articolo scoprirete come ragionano i revisori, quali sono i punti deboli che si riscontrano spesso negli audit sulla protezione dei dati e come potete prepararvi in modo strutturato a un audit.
Cosa si aspettano in genere gli esaminatori
Gli organismi di controllo (Autorità di vigilanza, revisione interna, revisore esterno, cliente/partner) possono differire nel tono, ma raramente nei concetti fondamentali. I revisori cercano risposte attendibili a tre domande fondamentali:
- L'organizzazione conosce il suo Elaborazione?
„Quali dati trattiamo, perché, per quanto tempo, con chi, dove?“ (VVT come prova principale). - Le misure di protezione sono adeguate al rischio e efficaci?
I TOM non sono solo „sulla carta“, ma sono stati implementati e verificati in modo trasparente. - Sono Diritti degli interessati e obblighi resi operativi?
Informazioni/Cancellazione, gestione degli incidenti, Obbligo di informazione, La revoca del consenso deve essere definita come una procedura vera e propria, con scadenze e responsabilità ben precise.
Per le autorità di vigilanza è inoltre fondamentale che Persone responsabili e i responsabili del trattamento collaborano su richiesta. Il comportamento in materia di collaborazione può anche influire sull’ammontare dell’ammenda (criterio di riduzione/determinazione).
Metodi di verifica che dovreste prevedere in modo realistico
Nella pratica si ricorre a una combinazione di verifica dei documenti, questionari strutturati, colloqui e controlli a campione. Il fatto che le autorità di vigilanza possano, tra l’altro, effettuare verifiche in materia di protezione dei dati e richiedere informazioni è sancito dal quadro normativo.
Una prospettiva molto „orientata all’audit“ è offerta, ad esempio, dal questionario del BayLDA: esso pone domande esplicite sulla governance della protezione dei dati, sul coinvolgimento del responsabile della protezione dei dati, sul VVT, sul “Privacy by Design”, sui responsabili del trattamento e sui contratti di incarico, 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 prova | Come gli esaminatori riconoscono la maturità | Prove tipiche |
Revisione dei documenti („Desk Audit“) | Coerenza: VVT ↔ TOM ↔ DSFA ↔ contratti ↔ termini di cancellazione ↔ Obbligo di informazione | VVT, Concetto TOM/Mapping, Contratti AV, Piano di estinzione, DPIA/analisi dei rischi, prova del consenso |
Questionario (amministrativo/audit dei partner) | Capacità di risposta senza „soluzioni improvvisate“; responsabilità ben definite | Questionari compilati, indice delle prove per ciascuna domanda (link alla documentazione) |
Interviste/dibattiti in laboratorio | I collaboratori conoscono la procedura, le modalità di escalation e le scadenze; non ci sono affermazioni contraddittorie | Matrice dei ruoli, attestati di formazione, manuali di processo, esempi di ticket e flussi di lavoro |
Campioni a campione/Ispezione a campione | „Show me“: informazioni, Cancellazione, autorizzazione, effettiva fattibilità della risposta agli incidenti | 1–3 fascicoli per ogni processo (richieste DSAR, procedure di cancellazione, revisione delle autorizzazioni, manuale di gestione degli incidenti) |
Prove tecniche (demo/log) | Efficacia e tracciabilità (ad es. ruoli/diritti, 2FA, test di backup) | Modelli di autorizzazione, registri, registri dei test di backup, documentazione relativa all'implementazione dell'autenticazione a più fattori (MFA) |
Suggerimento per il collegamento: Questionario GDPR LDA Baviera
Domande tipiche d'esame e criteri di valutazione
Gli esempi che seguono sono formulati in modo tale da essere adatti sia agli audit delle autorità che a quelli dei clienti o di certificazione. Essi riflettono le tipiche domande poste dalle autorità (ad es. il questionario del BayLDA) nonché la sistematica DSK (VVT/DSFA/Diritti degli interessati).
| Blocco tematico | Domanda tipica d'esame | Criterio di valutazione (cosa significa „buono“) | Prove tipiche |
|---|---|---|---|
| La governance | „È Protezione dei dati “È una questione di cui si occupa il capo: le responsabilità sono ben definite?" | Le competenze sono documentate e applicate efficacemente nella pratica 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 i processi effettivi, compresi i destinatari, i termini di cancellazione e la descrizione del TOM | VVT + Processo di modifica/Verbale di revisione |
| Elaborazione dell'ordine | „Sono stati registrati tutti i responsabili del trattamento e sono stati stipulati i contratti ai sensi dell'articolo 28 del GDPR?“ | Elenco completo dei fornitori; contratti di assistenza tecnica con requisiti minimi; meccanismo di controllo | Registro dei fornitori, contratti AV, verifica TOM dei fornitori di servizi |
| Diritti degli interessati | „Potete fornire le informazioni entro il termine previsto?“ | Processo e organizzazione assicurano informazioni tempestive e comprensibili. | Procedura DSAR, risposte tipo, esempi di ticket |
| Cancellazione | „Come garantite il rispetto dei termini di cancellazione per ogni tipo di dati?“ | Piano di cancellazione dei dati per ciascuna tipologia di dati; termini motivati; procedure di cancellazione documentate | Piano di estinzione, registri di cancellazione, regole di eccezione/blocco |
| Rischio/DSFA | „In quali casi effettua una DSFA?“ | DSFA prima dell'avvio; la decisione relativa a ciascuna operazione è documentata; le misure ne derivano | Relazioni DSFA, analisi dei valori 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 |
Punti deboli ricorrenti negli audit
I seguenti punti deboli non sono „errori teorici“, bensì tipici punti di rottura tra la teoria e la praticaConformità e nella vita quotidiana. Gli esempi si basano volutamente sulle domande di verifica delle autorità e sui cataloghi di buone pratiche (ad es. le checklist TOM), poiché i verificatori approfondiscono proprio quei punti in cui l’attuazione è spesso lacunosa.
Difetti tecnici
Un frequente Audit-Il risultato non è „assenza di TOM“, bensì TOM senza riferimento all’efficacia: sebbene esista un PDF con parole chiave, non vi sono prove attendibili che dimostrino che le misure siano state attuate, testate e selezionate in base al rischio. Il criterio „verificare/valutare regolarmente“ è sì esplicitamente menzionato, ma in assenza di una descrizione concreta è praticamente impossibile da soddisfare.
Esempi tecnici concreti e spesso criticati:
- Debole Autenticazione: nessun utilizzo (o utilizzo incoerente) dell'autenticazione a due fattori (2FA) in aree ad alto rischio, assenza di blocchi in caso di tentativi falliti, condivisione o annotazione delle password, standard insufficienti per le password amministrative.
- Concetto di ruoli e responsabilità non ben definito: mancanza di profili di ruolo, assenza di verifiche periodiche, „caselle di posta funzionali“ e account collettivi senza obbligo di rendicontazione.
- 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 legati ai dispositivi mobili/all'accesso remoto: assenza di crittografia completa dei dispositivi, gestione MDM insufficiente, fonti di app non sicure, mancanza di una procedura chiara in caso di smarrimento.
Carenze organizzative
In questo ambito, le organizzazioni spesso incontrano difficoltà a causa delle competenze e dei meccanismi di gestione, non per mancanza di conoscenze giuridiche.
- La funzione DSB/protezione dei dati viene integrata troppo tardi. I progetti vengono avviati e i sistemi entrano in funzione, mentre la protezione dei dati viene „aggiunta in un secondo momento“. Ciò è tuttavia in contrasto con l’aspettativa che le questioni relative alla protezione dei dati vengano prese in considerazione sin dall’inizio o in caso di modifiche ai processi (Privacy by Design nella logica delle domande di audit).
- Non esiste una gestione della protezione dei dati solida, ma solo misure isolate che non sono integrate in un sistema in grado di strutturarne l'attuazione, la verifica e l'aggiornamento. È proprio questa capacità di „garantire e fornire prova“ (in base al rischio) il fulcro 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“.
Organizzazione dell'audit: niente stress
Audit-Lo stress raramente deriva da singole questioni, ma il più delle volte da ricerche disordinate, affermazioni contraddittorie e una ripartizione poco chiara dei ruoli. Prevenire lo stress è quindi innanzitutto una questione di organizzazione.
Prima dell'audit
Uno strumento efficace è il cosiddetto „evidence mapping“: a ogni requisito di verifica viene assegnata in anticipo una prova chiara („single source of truth“) e una responsabile Elenco. In questo modo eviterete di dover mettere insieme tutto all'ultimo minuto durante l'esame.
Come standard minimo, prima dell'appuntamento è necessario assicurarsi di quanto segue:
- Punto di contatto unico (SPoC) per la comunicazione con i revisori (evita chat parallele e dichiarazioni discordanti).
- Chiarimento dei ruoli: chi si occupa delle „politiche“, chi dei „dettagli IT“, chi dei „processi HR“ e chi degli „aspetti legali/contrattuali“.
- Eseguire un mock-Audit con da cinque a 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 l’atteggiamento collaborativo può essere preso in considerazione nell’ambito delle misure di vigilanza e nella determinazione dell’ammontare delle sanzioni amministrative.
Durante l'audit
La regola di comunicazione collaudata nella pratica recita: „Risposta + prova + contesto“.
- La risposta dovrebbe essere breve, oggettiva e verificabile.
- Il documento deve essere immediatamente collegabile nel Audit-cartella (non „passa a qualcuno“ come modalità predefinita).
- Contesto: precisazione nel caso in cui l’ambito di applicazione non sia valido (ad es. „vale solo per il sistema X, non per Y“).
Per i contatti con le autorità è inoltre importante 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 che indichi il responsabile, la scadenza e la forma di rendicontazione. La DSK raccomanda espressamente, per i progetti di attuazione, un approccio coordinato e di informare la direzione come primo passo.
- Prova di completamento: ogni azione non si conclude con la dicitura „attuata“, bensì con „attuata in modo dimostrabile“ (ad es. screenshot, verbale, rapporto di prova).
Panoramica dell’Audit-Check
Punti da verificare | Persone responsabili Ruolo | Forma di prova | Priorità |
Audit‑Ambito, sistemi, sedi, periodo definiti | Gestione / Coordinamento della protezione dei dati | Audit- Documento "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 in materia di protezione dei dati/RACI, compreso il coinvolgimento del responsabile della protezione dei dati (DSB), chiaramente definiti | Gestione / DPO | RACI, organigramma, processo di integrazione | Alto |
VVT completo, aggiornato, con numero di versione | Proprietari dei processi + DPO | Master-VVT + Registro delle modifiche | Alto |
Il VVT prevede termini e criteri di cancellazione per ciascuna categoria di dati | Proprietario del processo | Campi VVT + riferimenti a Piano di estinzione | Alto |
VVT contiene riferimenti al TOM / descrizione generale del TOM | Sicurezza informatica + Responsabile della protezione dei dati | Voce VVT + link al documento TOM | Alto |
Certificazione TOM: mappatura rischio→misura disponibile | Sicurezza informatica + Responsabile della protezione dei dati | Matrice TOM/Mappatura | Alto |
Autenticazione: Criteri di sicurezza delle password + autenticazione a due fattori (2FA) per i profili ad alto rischio | Sicurezza informatica | Politiche + Impostazioni di sistema/Report | Alto |
Il modello dei ruoli e delle autorizzazioni è stato documentato e verificato | Sicurezza informatica / Operazioni IT | Modello di ruolo + verbale di revisione | Alto |
Piano di backup per iscritto + test di ripristino | IT-Ops / BCM | Piano di backup + verbali di prova | Alto |
Piano di emergenza/BCM disponibile e testato | BCM / Operazioni IT | Piano di emergenza + verbali delle esercitazioni | Medio |
Registro dei fornitori completo (tutti i responsabili del trattamento) | Gestione degli acquisti/dei fornitori + DSB | Elenco dei fornitori di servizi | Alto |
Contratti di lavoro con contenuti minimi (art. 28) per tutti i contratti di lavoro | Legale + DPO | Contratti AV + Allegati | Alto |
Sottoprocessore‑Trasparenza + Processo di approvazione | Gestione dei fornitori + Legale | Elenco dei sottoprocessori + release | Medio |
Testi relativi agli obblighi di informazione (artt. 13/14) per ciascun processo chiave | Legale/Marketing + DSB | Informazioni sulla protezione dei dati + versioning | Alto |
Processo DSAR (accoglienza, identificazione, ricerca dei dati, risposta) | Servizio clienti / DPO | Descrizione del processo + esempi di ticket | Alto |
Scadenze informative/monitoraggio delle scadenze reso operativo | DPO / Dipartimenti | Scadenze – SLA + Flusso di lavoro | Alto |
Piano di estinzione per tipo di dati (scopo, durata, requisiti) | Gestione dei registri / DSB | Piano antincendio | Alto |
Operazioni di cancellazione documentabili (protocolli/report) | IT-Ops / Dipartimenti specialistici | Registri delle cancellazioni | Alto |
Procedura relativa alle richieste di cancellazione ai sensi dell'art. 17 | DPO / Servizio | Processo + fascicolo | Alto |
Analisi dei valori soglia: DSFA sì/no per ciascuna operazione ad alto rischio | DSB + proprietario del processo | Documento di analisi dei valori soglia | Alto |
DSFA eseguita prima della messa in servizio (ove necessario) | DPO + gestione del progetto | Relazione DSFA + piano d'azione | Alto |
Prova del consenso + meccanismo di revoca | Marketing/Prodotto + DSB | Registro dei consensi + Registri/Prova dell'interfaccia utente | 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 | Audit-Registro (ad es. tabella/ticket) | Alto |
Piano d'azione secondo Audit (Proprietario, data, ricevuta) | Gestione / DPO | Piano d'azione + documentazione relativa alla chiusura | Alto |
Pronti per l'audit con 2B Advice e Ailance
Audit-La competenza non nasce solo quando viene annunciato un controllo. È il risultato di strutture chiare, processi trasparenti e documentazione comprensibile in materia di protezione dei dati.
Le aziende che organizzano la protezione dei dati in modo strategico ne traggono un doppio vantaggio: superano gli audit con maggiore sicurezza e, al contempo, rafforzano la propria governance e la fiducia di clienti e partner.
Se volete sapere in che misura la vostra azienda è preparata ad affrontare una violazione dei datiAudit una volta che ci si è preparati, vale la pena dare uno sguardo strutturato ai propri processi.
Scoprite di più sulle nostre soluzioni per la protezione dei dati e Conformità-Gestione con Ailance: 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, GDPR-Conformità e la gestione dei rischi. Per saperne di più su di lui, visitate il suo Pagina del profilo dell'autore.
German 
English 
Italian 
French