Test dei controlli per la privacy ISO 27701 per il GDPR

L’audit privacy del venerdì che ha messo in luce il vero problema
Sono le 15:40 di un venerdì quando Maria, CISO di una società SaaS in forte crescita, partecipa a una videochiamata con il responsabile acquisti di un importante potenziale cliente aziendale.
Il suo gruppo di lavoro lavora da mesi sul proprio Sistema di gestione delle informazioni sulla privacy. Le politiche sono approvate. Il registro dei trattamenti esiste. L’azienda dispone di un piano di preparazione a ISO 27701. Il DPO ha predisposto i flussi di lavoro per le richieste degli interessati. La funzione legale ha aggiornato gli accordi sul trattamento dei dati. La funzione di ingegneria afferma che l’accesso all’ambiente di produzione è limitato.
Il responsabile acquisti apre la riunione con cortesia, ma in modo diretto.
“Grazie per la documentazione, Maria. Il certificato e il pacchetto di politiche sono un buon punto di partenza. Il nostro gruppo di due diligence sarà presso la vostra sede il mese prossimo. Vorrà vedere il processo DSAR in esercizio, verificare i controlli di minimizzazione dei dati sui nostri account di test, riesaminare i log di accesso all’ambiente di produzione e ispezionare le evidenze che dimostrano che i controlli per la privacy sono testati, non solo documentati.”
Nel giro di pochi minuti, Maria riceve altri due messaggi.
Il DPO chiede se la nuova funzionalità di analisi dei dati sia coperta dal registro dei trattamenti, dalla valutazione della base giuridica, dal piano di conservazione e dagli obblighi a cascata del responsabile del trattamento.
Il responsabile compliance chiede se il riesame dello stato di preparazione a ISO 27701:2025 possa dimostrare l’efficacia operativa dei controlli PIMS.
È in questo momento che molti programmi privacy vacillano. L’organizzazione dispone di documenti privacy, ma non di evidenze privacy. Ha flussi di lavoro, ma non evidenze basate su campioni. Ha contratti, ma registrazioni di monitoraggio deboli. Ha fiducia interna, ma nessuna traccia di audit difendibile.
Questo divario distingue la conformità sulla carta dalla responsabilizzazione dimostrabile.
Il GDPR rende esplicito il problema. Il titolare del trattamento è responsabile del rispetto dei principi di protezione dei dati e deve essere in grado di dimostrarlo. I dati personali devono essere trattati in modo lecito, corretto e trasparente, per finalità determinate, limitati a quanto necessario, esatti, conservati solo per il tempo necessario e protetti mediante misure tecniche e organizzative adeguate.
ISO 27701:2025 fornisce alle organizzazioni la struttura di gestione della privacy. ISO/IEC 27001:2022 fornisce l’ossatura del SGSI per ambito di applicazione, trattamento del rischio, controllo operativo, audit interno, riesame della direzione e miglioramento continuo. Il GDPR introduce l’onere giuridico della responsabilizzazione. NIS2, DORA, NIST CSF 2.0, l’assurance secondo logiche COBIT 2019 e i riesami di sicurezza dei clienti aumentano la pressione a dimostrare che i controlli funzionano.
La posizione di Clarysec è semplice: il test dei controlli per la privacy non deve essere una raccolta annuale affannosa di screenshot. Deve essere un sistema di evidenze PIMS che collega attività di trattamento, controlli applicabili, rischi, campioni, verifiche tecniche, risultanze, CAPA e riesame della direzione in un modello tracciabile.
È qui che il set di politiche PIMS di Clarysec, Zenith Blueprint: An Auditor’s 30-Step Roadmap e Zenith Controls: The Cross-Compliance Guide diventano strumenti operativi, non documenti da archiviare.
Il test dei controlli per la privacy è il ponte tra politica e responsabilizzazione
Un test dei controlli per la privacy risponde a tre domande operative:
- Il controllo è progettato per soddisfare l’obbligo privacy o ridurre il rischio privacy?
- Il controllo è attuato nel processo, sistema, gruppo, fornitore o flusso di lavoro di prodotto pertinente?
- Il controllo opera efficacemente nel tempo, con evidenze idonee a soddisfare un auditor, un cliente, un’autorità di controllo o un comitato del consiglio di amministrazione?
Una società SaaS può affermare di supportare le richieste di cancellazione. Un test del disegno verifica se sono definiti la politica di cancellazione, il processo di verifica dell’identità, il modello di titolarità, il coordinamento con i responsabili del trattamento, le eccezioni alla conservazione e la gestione dei backup. Un test di efficacia operativa campiona richieste di cancellazione completate, confronta le marcature temporali, controlla le approvazioni, riesamina i log di sistema, verifica le notifiche ai responsabili del trattamento nei sistemi a valle e conferma le evidenze di chiusura.
La Politica di monitoraggio, audit e miglioramento del PIMS trasforma questo approccio in un requisito verificabile in sede di audit:
[Entrambi] L’auditor interno / responsabile compliance DEVE testare lo stato di attuazione dei controlli PIMS applicabili rispetto a REG03 durante ciascun audit PIMS.
Dalla sezione “Programma di audit interno del PIMS”, clausola 4.2.5 della politica.
Quell’espressione, “rispetto a REG03”, è centrale. Il test non è un’intervista libera. REG03 funge da riferimento per l’applicabilità e l’attuazione dei controlli PIMS. Mostra che cosa si applica, perché si applica e quali evidenze devono essere disponibili.
La stessa politica aggiunge:
[Entrambi] L’auditor interno / responsabile compliance DEVE registrare in REG12 il campione selezionato di evidenze del trattamento di dati personali durante ciascun audit PIMS.
Dalla sezione “Programma di audit interno del PIMS”, clausola 4.2.6 della politica.
Questo è il nucleo del test dei controlli per la privacy ISO 27701:2025. Un audit PIMS senza campione è una conversazione. Un audit PIMS con evidenze selezionate, mappatura dei controlli, eccezioni, azioni correttive e tracciabilità del riesame della direzione è responsabilizzazione.
Partire da ambito di applicazione, ruolo e realtà dei trattamenti
La maggior parte degli audit privacy deboli fallisce prima ancora dell’avvio dei test. Seleziona controlli generici senza confermare quali dati personali siano trattati, dove risiedano, quali sistemi e fornitori li tocchino e se l’organizzazione agisca come titolare del trattamento, responsabile del trattamento, contitolare del trattamento o sub-responsabile.
Gli obblighi GDPR dipendono fortemente dal ruolo. Un titolare del trattamento che decide perché e come sono trattati i dati personali ha obblighi diversi da un responsabile del trattamento che agisce sulla base di istruzioni documentate del cliente. Anche la sensibilità dei dati è rilevante. Dati dei dipendenti, dati degli account cliente, telemetria, dati finanziari, verifica biometrica, dati relativi alla salute, controlli sulle sanzioni e dati relativi a reati non comportano lo stesso rischio.
Un solido programma di test ISO 27701:2025 inizia da una disciplina rigorosa di definizione dell’ambito.
| Domanda di definizione dell’ambito | Evidenze da esaminare | Perché è rilevante |
|---|---|---|
| Quali attività di trattamento di dati personali rientrano nell’ambito? | Registro dei trattamenti, mappa dei flussi di dati, inventario dei sistemi, registro dei fornitori | Il test deve campionare trattamenti reali, non dichiarazioni astratte di politica |
| Quale ruolo PIMS si applica? | Mappatura di titolare del trattamento, responsabile del trattamento, contitolare del trattamento, sub-responsabile | Gli obblighi GDPR e i controlli PIMS variano in base al ruolo |
| Quali obblighi legali, contrattuali e normativi si applicano? | Valutazione GDPR, DPA dei clienti, regole di settore, valutazioni dei trasferimenti | Il disegno dei controlli deve riflettere gli obblighi effettivi |
| Quali sistemi e fornitori trattano dati personali? | Inventario degli asset, inventario cloud, elenco dei responsabili del trattamento, matrice degli accessi | I test operativi richiedono evidenze tecniche e di terze parti |
| Quali modifiche incidono sul trattamento di dati personali? | Registrazioni delle modifiche di prodotto, trigger DPIA, note di rilascio, riesami dell’architettura | La privacy by design deve essere testata prima del rilascio, non dopo i reclami |
ISO/IEC 27001:2022 supporta questo approccio integrato tramite i requisiti relativi al contesto dell’organizzazione, ai requisiti delle parti interessate, agli obblighi legali e contrattuali, all’ambito del sistema di gestione, alla pianificazione operativa e al trattamento del rischio. Per la privacy, questo significa che il trattamento dei dati personali non può rimanere in un foglio di calcolo scollegato. Deve far parte del modello operativo del SGSI e del PIMS.
La Politica del Sistema di gestione delle informazioni sulla privacy collega direttamente il test privacy alla governance:
[Tutti] L’alta direzione DEVE riesaminare annualmente in REG12 le prestazioni del PIMS, gli obiettivi privacy, i rischi aperti, le non conformità, le azioni correttive e le decisioni di miglioramento.
Dalla sezione “Governance del PIMS”, clausola 6.1.1 della politica.
Se il test identifica una lacuna privacy, non si tratta solo di una nota di audit. È un input del sistema di gestione che deve incidere sul trattamento del rischio, sulle priorità, sulle risorse e sulle decisioni della leadership.
Efficacia del disegno ed efficacia operativa
Quando un cliente chiede se i controlli privacy sono testati, di solito intende l’efficacia operativa. Gli auditor, tuttavia, esamineranno anche l’efficacia del disegno.
Un controllo efficace nel disegno è idoneo a soddisfare il requisito se eseguito come previsto. Un controllo efficace sul piano operativo è effettivamente eseguito con continuità e supportato da evidenze.
| Area di controllo | Test dell’efficacia del disegno | Test dell’efficacia operativa |
|---|---|---|
| Raccolta del consenso | Verificare politica, testo del consenso, regole sulla base giuridica, requisiti dell’interfaccia utente, flusso di lavoro di revoca | Campionare registrazioni del consenso e revoche, confrontare le marcature temporali, verificare la soppressione dopo la revoca |
| Limitazione della finalità | Riesaminare RoPA, informativa privacy, requisiti di prodotto, separazione del consenso, regole di utilizzo dei dati | Campionare registrazioni utente, log, esportazioni e flussi di analytics per confermare che i dati personali non siano riutilizzati per finalità non autorizzate |
| Accesso ai dati personali | Riesaminare politica di accesso, modello dei ruoli, procedura Joiner-Mover-Leaver, flusso di lavoro di approvazione | Campionare utenti con accesso ai dati personali, verificare approvazione, esigenza aziendale, MFA, riesame recente degli accessi |
| Onboarding dei responsabili del trattamento | Riesaminare criteri di due diligence, clausole DPA, regole sui sub-responsabili, misure di protezione per i trasferimenti | Campionare un responsabile del trattamento, esaminare valutazione, contratto, riesame di sicurezza, evidenze di monitoraggio dei sub-responsabili |
| Conservazione e cancellazione | Riesaminare piano di conservazione, regole di eccezione, procedura di cancellazione, capacità del sistema | Campionare registrazioni cancellate o richieste di cancellazione, esaminare log, ticket, conferme dei responsabili del trattamento |
| Gestione delle violazioni | Riesaminare classificazione degli incidenti, escalation privacy, criteri di notifica all’autorità | Campionare registrazioni degli incidenti, verificare triage, motivazione della decisione, notifiche, lezioni apprese |
La Politica di audit e monitoraggio della conformità dichiara direttamente la finalità:
Validare l’efficacia dei controlli di sicurezza e privacy
Dalla sezione “Finalità”, clausola 1.1.1 della politica.
La versione PMI mantiene lo stesso principio di assurance in linguaggio operativo. La Politica di audit e monitoraggio della conformità - PMI afferma:
Questa politica stabilisce l’approccio dell’organizzazione allo svolgimento degli audit interni, dei riesami dei controlli di sicurezza e del monitoraggio della conformità. Assicura che tutti i controlli, le politiche, i sistemi e i fornitori di servizi siano sottoposti a riesame periodico e strutturato.
Dalla sezione “Finalità”, clausola 1.1 della politica.
La preparazione a ISO 27701 non dipende dalla dimensione aziendale. Un responsabile del trattamento SaaS di 30 persone può non avere bisogno degli stessi strumenti di audit di una banca globale, ma deve comunque dimostrare che accesso, cancellazione, escalation degli incidenti, governance dei sub-responsabili e conservazione delle evidenze sono sotto controllo.
La catena delle evidenze Clarysec: REG03, REG12, CAPA e riesame
Clarysec struttura il test dei controlli per la privacy attorno a una semplice catena delle evidenze.
REG03 definisce i controlli PIMS applicabili e lo stato di attuazione. REG12 registra campioni, evidenze, risultanze, lacune di tracciabilità, verifica delle azioni correttive e input per il riesame della direzione. Le registrazioni CAPA trasformano le risultanze in miglioramenti basati sull’analisi della causa radice. L’alta direzione riesamina prestazioni del PIMS, rischi, non conformità, azioni correttive e decisioni di miglioramento.
La Politica sulle informazioni documentate e sulla gestione delle evidenze del PIMS richiede di registrare i problemi di qualità delle evidenze:
[Tutti] L’auditor interno / responsabile compliance DEVE registrare in REG12 le lacune di completezza, accuratezza o tracciabilità delle evidenze durante ciascun audit o riesame di conformità pianificato.
Dalla sezione “Creazione, denominazione e qualità delle evidenze”, clausola 4.3.4 della politica.
Questo è importante perché non ogni risultanza corrisponde a un fallimento totale del controllo. A volte il controllo ha funzionato, ma le evidenze sono incomplete. A volte un ticket di cancellazione è chiuso, ma nessun log di sistema dimostra la cancellazione. A volte il registro dei trattamenti nomina il CRM, ma non include l’esportazione verso il data warehouse. A volte esiste un contratto con il fornitore, ma manca il monitoraggio continuativo.
La Politica di audit e monitoraggio della conformità richiede inoltre audit interni strutturati:
Gli audit interni devono seguire una procedura documentata che includa:
Dalla sezione “Requisiti di applicazione della politica”, clausola 6.1.1 della politica.
E, quando emergono risultanze:
Tutte le risultanze devono tradursi in una CAPA documentata che includa:
Dalla sezione “Requisiti di applicazione della politica”, clausola 6.2.1 della politica.
La Politica di gestione del rischio - PMI rafforza la disciplina di chiusura:
Il completamento e l’efficacia delle azioni di trattamento devono essere verificati.
Dalla sezione “Requisiti di applicazione della politica”, clausola 6.3.2 della politica.
La Politica di monitoraggio, audit e miglioramento del PIMS chiude il ciclo:
[Tutti] L’auditor interno / responsabile compliance DEVE verificare l’efficacia dell’azione correttiva in REG12 entro 30 giorni dalla chiusura dichiarata dell’azione correttiva.
Dalla sezione “Non conformità e azione correttiva”, clausola 4.4.7 della politica.
Questa è la differenza tra chiudere un ticket e migliorare un sistema di gestione.
Test pratico 1: richieste di cancellazione e responsabilizzazione GDPR
Le richieste di cancellazione sono uno dei modi più chiari per testare se la responsabilizzazione privacy funziona nella pratica.
Si consideri una società SaaS mid-market che agisce sia come titolare del trattamento sia come responsabile del trattamento. Controlla dati dei dipendenti, di marketing e di fatturazione. Tratta dati degli utenti finali dei clienti per conto di clienti aziendali. L’organizzazione vuole testare se i controlli di cancellazione sono pronti per un audit ISO 27701:2025 e per l’assurance privacy verso i clienti in ambito GDPR.
Passaggio 1: selezionare l’attività di trattamento da REG03
Scegliere un’attività di trattamento con rischio privacy reale, ad esempio “dati del profilo degli utenti finali del cliente trattati nella piattaforma SaaS”. Confermare se l’organizzazione agisce come titolare del trattamento, responsabile del trattamento o entrambi. Identificare i controlli collegati per la gestione dei diritti, la validazione delle istruzioni del responsabile del trattamento, la conservazione, la cancellazione, il controllo degli accessi, la registrazione degli eventi, la gestione dei backup e il coordinamento con i fornitori.
Passaggio 2: definire un obiettivo di test preciso
Un obiettivo di test utile è specifico e guidato dalle evidenze:
“Verificare che le richieste di cancellazione dei dati del profilo degli utenti finali del cliente siano ricevute, autenticate o validate rispetto alle istruzioni, gestite nel flusso di lavoro definito, registrate, completate tecnicamente nei sistemi di produzione, propagate ai sub-responsabili pertinenti ove richiesto e chiuse con evidenze.”
Passaggio 3: estrarre un campione rappresentativo
Selezionare cinque richieste di cancellazione dell’ultimo trimestre. Includere una richiesta ordinaria, una richiesta che coinvolge un amministratore cliente, una richiesta basata su istruzioni del responsabile del trattamento, una richiesta con eccezione di conservazione e una richiesta che interessa la gestione dei backup.
Il Zenith Blueprint, nella fase Audit, Review & Improvement, Step 26: Audit Execution, evidenzia il campionamento e la raccolta delle evidenze:
✓ Intervistare il personale pertinente: chiedere alle persone responsabili dei processi di spiegare come soddisfano i requisiti. Ad esempio, chiedere al Titolare del rischio informazioni sull’ultima valutazione del rischio, oppure chiedere alle Risorse Umane come i nuovi assunti sono formati sulla sicurezza (per coprire il controllo 6.3 sulla sensibilizzazione).
✓ Riesaminare la documentazione: verificare che documenti e registrazioni esistano e siano aggiornati.
✓ Osservare le pratiche: se possibile, effettuare un’osservazione diretta.
✓ Campionare ed eseguire controlli a campione: non è possibile controllare tutto, quindi utilizzare il campionamento.
Dalla fase Audit, Review & Improvement, Step 26: Audit Execution (Conducting an Internal Audit).
Passaggio 4: esaminare le evidenze per ciascun campione
Per ciascuna richiesta campionata, raccogliere il ticket di acquisizione, la qualificazione del ruolo, la verifica dell’identità o l’autorizzazione del cliente, il log di cancellazione del sistema, la decisione sull’eccezione di conservazione, la spiegazione sulla gestione dei backup, la notifica al sub-responsabile, la comunicazione di chiusura, le marcature temporali e l’approvazione del responsabile del riesame.
Passaggio 5: registrare i risultati in REG12
Registrare in REG12 campione, fonte dell’evidenza, esito del controllo, eccezione e lacuna di tracciabilità. Se la cancellazione è avvenuta ma non esiste alcun log di produzione, il controllo può aver operato, ma l’evidenza è debole. Se la richiesta è stata ritardata perché la responsabilità del fornitore non era chiara, la risultanza può riguardare la governance delle terze parti e gli obblighi contrattuali a cascata.
Passaggio 6: creare la CAPA e verificarne l’efficacia
Se la causa radice è una titolarità poco chiara tra supporto, funzione legale e funzione di ingegneria, la CAPA può includere un flusso di lavoro rivisto, una RACI aggiornata, campi di evidenza obbligatori e controlli mensili a campione sulle cancellazioni.
Il Zenith Blueprint, nella fase Audit, Review & Improvement, Step 29, spiega l’aspettativa di chiusura:
Pianificare come si intende verificare l’efficacia di ciascuna azione correttiva. Ciò può significare programmare un audit o un controllo di follow-up. Ad esempio, se l’azione correttiva consisteva nel formare il personale IT sul controllo degli accessi, si può pianificare il riesame dei nuovi account dopo un mese per verificare che tutti dispongano delle approvazioni appropriate (verifica).
Dalla fase Audit, Review & Improvement, Step 29: Continual Improvement (Corrective Actions & Lessons Learned).
Per la cancellazione, la verifica può consistere nel campionare le cinque richieste di cancellazione successive alla messa in esercizio del flusso di lavoro rivisto. Solo a quel punto la CAPA dovrebbe essere chiusa.
Test pratico 2: limitazione della finalità e minimizzazione dei dati
Un secondo test ad alto valore riguarda la limitazione della finalità. È particolarmente utile prima di due diligence dei clienti, rilasci di funzionalità di analytics, arricchimenti AI, espansioni del data warehouse o modifiche dell’automazione marketing.
La piattaforma SaaS di Maria raccoglie dati degli utenti dei clienti per l’erogazione del servizio. L’obiettivo del controllo è assicurare che i dati personali siano utilizzati solo per finalità determinate e legittime, e non riutilizzati per analytics di marketing salvo che l’utente abbia prestato, ove richiesto, un consenso esplicito e separato.
| Tipo di evidenza | Artifact specifici |
|---|---|
| Documentazione | Politica di protezione dei dati e privacy, RoPA, DPA del cliente, informative privacy, registrazioni della gestione del consenso |
| Configurazione tecnica | Regole di gestione dei dati dell’applicazione, schemi di database, configurazioni API, impostazioni dei job ETL |
| Log e registrazioni | Log di accesso dell’applicazione, log delle query del database, cronologia delle modifiche del consenso, registrazioni delle esportazioni di campagne |
| Evidenze del personale | Interviste con Titolare del prodotto, sviluppatore principale, amministratore di database, responsabile privacy |
Un test operativo robusto non si ferma alla politica. Campiona utenti che hanno aderito al marketing e utenti che non lo hanno fatto. Traccia se lo stato del consenso è correttamente riflesso nei database applicativi core, nelle tabelle del data warehouse, negli strumenti di campagna, nelle dashboard e nelle esportazioni. Se utenti non consenzienti compaiono in un pubblico marketing, l’organizzazione ha una non conformità concreta.
La Politica di audit e monitoraggio della conformità per PMI fornisce l’approccio corretto tramite un esempio di test tecnico:
Verifica dei controlli tecnici (ad es. stato dei backup, configurazione del controllo degli accessi, registrazioni delle patch)
Dalla sezione “Requisiti di applicazione della politica”, clausola 6.1.1.2.
Per la privacy, la verifica dei controlli tecnici include controlli di sincronizzazione del consenso, esportazioni del controllo degli accessi, log di cancellazione, impostazioni di cifratura, test di mascheramento dei dati, avvisi DLP, vincoli sui backup, eventi di monitoraggio ed evidenze dei fornitori.
Mappare i test privacy a ISO/IEC 27001:2022 e alla conformità trasversale Clarysec
I controlli privacy non operano in isolamento. La protezione dei dati personali dipende da inventario degli asset, classificazione, controllo degli accessi, governance cloud, mascheramento dei dati, trasferimento delle informazioni, registrazione degli eventi, monitoraggio, cancellazione, protezione delle registrazioni, supervisione dei fornitori e riesame indipendente.
In Zenith Controls: The Cross-Compliance Guide, il controllo 5.34 dell’Annex A ISO/IEC 27001:2022, Privacy and protection of PII, è mappato come controllo preventivo allineato a riservatezza, integrità e disponibilità, ai concetti di cibersicurezza Identify e Protect e alle capacità operative di Information Protection più Legal and Compliance.
Il suo rapporto con l’inventario è diretto:
Un inventario degli asset informativi (5.9) dovrebbe includere gli insiemi di dati personali detenuti (database clienti, file HR). Ciò supporta il controllo 5.34 assicurando che l’organizzazione sappia quali dati personali possiede e dove si trovano, che è il primo passo per proteggerli.
Da Zenith Controls, Privacy and Protection of PII, controllo 5.34.
Per i test di audit, questo significa che l’auditor privacy non dovrebbe iniziare dalla sola informativa privacy. Dovrebbe partire dall’inventario dei dati personali, dal registro dei trattamenti, dai flussi di dati, dall’inventario degli asset e dall’inventario dei fornitori. Se l’inventario è incompleto, i controlli privacy a valle non possono essere pienamente affidabili.
La guida mappa inoltre il controllo 5.34 dell’Annex A ISO/IEC 27001:2022 a controlli correlati quali 5.9 Inventory of information and other associated assets, 5.12 Classification of information, 5.14 Information transfer, 5.15 Access control, 5.16 Identity management, 5.23 Information security for use of cloud services, 5.33 Protection of records, 8.11 Data masking, 8.12 Data leakage prevention e 8.10 Information deletion.
Due ulteriori controlli dell’Annex A ISO/IEC 27001:2022 sono particolarmente rilevanti:
| Controllo ISO/IEC 27001:2022 | Rilevanza per i test privacy | Esempio di evidenze |
|---|---|---|
| 5.34 Privacy and protection of PII | Conferma che i requisiti di privacy e protezione dei dati personali sono attuati in base a leggi, regolamenti e contratti | Registro dei trattamenti, DPIA, registrazioni della base giuridica, evidenze DSR, log di conservazione |
| 5.35 Independent review of information security | Fornisce una validazione oggettiva del riesame indipendente degli assetti di sicurezza, inclusi i controlli rilevanti per la privacy | Rapporti di audit interno, risultati di riesami esterni, campioni REG12, registrazioni CAPA |
| 5.36 Compliance with policies, rules and standards for information security | Conferma la conformità continuativa a regole e standard interni | Riesami di conformità alle politiche, controlli degli accessi, risultati di monitoraggio, registri delle eccezioni |
La Politica di protezione dei dati e privacy richiede:
Deve essere condotto un audit interno di conformità privacy con cadenza annuale o in occasione di modifiche organizzative o normative rilevanti. L’ambito dell’audit deve includere:
Dalla sezione “Requisiti di governance”, clausola 5.4 della politica.
Include inoltre:
Efficacia delle misure tecniche e organizzative
Dalla sezione “Requisiti di governance”, clausola 5.4.1 della politica.
La Politica di protezione dei dati e privacy - PMI mantiene la stessa aspettativa in forma pratica:
Devono essere svolti e registrati audit privacy o controlli periodici sui controlli
Dalla sezione “Requisiti di governance”, clausola 5.3.3 della politica.
Perché la responsabilizzazione GDPR è ormai una questione di cyber governance
Le evidenze privacy non sono più richieste solo dagli auditor privacy. La stessa prova può essere richiesta da un auditor ISO 27701:2025, da un auditor ISO/IEC 27001:2022, da un revisore GDPR, da un’autorità competente NIS2, da un cliente soggetto a DORA, da un assessor NIST CSF o da un comitato rischi del consiglio di amministrazione.
NIS2 Article 21 richiede ai soggetti essenziali e importanti di attuare misure tecniche, operative e organizzative adeguate e proporzionate per la gestione del rischio di cibersicurezza. Article 21(2)(f) include espressamente politiche e procedure per valutare l’efficacia delle misure di gestione del rischio di cibersicurezza. NIS2 rende inoltre gli organi di gestione responsabili dell’approvazione e della supervisione delle misure di gestione del rischio di cibersicurezza.
DORA si applica dal 17 gennaio 2025 agli enti finanziari e definisce un quadro regolamentare dettagliato per la resilienza operativa digitale. Richiede gestione del rischio ICT, supervisione dell’organo di gestione, audit interno, rimedio delle risultanze critiche, classificazione e segnalazione degli incidenti, test di resilienza, gestione del rischio ICT di terze parti, controlli contrattuali, registri degli accordi sui servizi ICT e strategie di uscita. I fornitori ICT che servono entità finanziarie devono attendersi richieste di evidenze guidate da DORA nell’ambito dell’assurance verso i clienti.
NIST CSF 2.0 fornisce un utile livello di traduzione. La funzione GOVERN richiede alle organizzazioni di comprendere aspettative degli stakeholder, dipendenze e obblighi legali, normativi, contrattuali, privacy e relativi alle libertà civili. L’approccio basato sui Profiles aiuta a confrontare gli esiti attuali con gli esiti target, identificare lacune e prioritizzare i piani d’azione.
| Pressione del requisito | Che cosa deve produrre il test dei controlli privacy | Riferimento Clarysec |
|---|---|---|
| Responsabilizzazione GDPR | Evidenze che principi, base giuridica, diritti, sicurezza, conservazione e obblighi dei responsabili del trattamento sono soddisfatti in modo dimostrabile | Politiche PIMS, REG03, REG12, CAPA |
| Preparazione a ISO 27701:2025 | Controlli PIMS testati, applicabilità basata sui ruoli, qualità delle evidenze, audit interno, riesame della direzione | Politica di monitoraggio, audit e miglioramento del PIMS |
| Assurance ISO/IEC 27001:2022 | Tracciabilità del trattamento del rischio, motivazione SoA, controllo operativo, audit, riesame, miglioramento | Zenith Blueprint, guida alla conformità trasversale Zenith Controls |
| Governance NIS2 | Valutazione dell’efficacia, preparazione agli incidenti, controlli sui fornitori, supervisione della direzione | Mappatura dei controlli 5.35 e 5.36 dell’Annex A ISO/IEC 27001:2022 |
| Assurance DORA | Test dei controlli ICT, test di resilienza, evidenze di terze parti, registrazioni del ciclo di vita degli incidenti | Modello di evidenze di audit mappato trasversalmente |
| NIST CSF 2.0 | Profilo attuale, profilo target, gap analysis, miglioramento prioritizzato | Zenith Blueprint Steps 24, 26, 29 |
Il Zenith Blueprint rafforza la tracciabilità nello Step 24:
La SoA deve essere coerente con il Registro dei rischi e il Piano di trattamento del rischio. Ricontrollare che ogni controllo scelto come trattamento del rischio sia contrassegnato come “Applicabile” nella SoA. Al contrario, se un controllo è contrassegnato come “Applicabile” nella SoA, deve esistere una motivazione: di norma un rischio mappato, un requisito legale/normativo o un’esigenza aziendale.
Dalla fase Audit, Review & Improvement, Step 24: Audit, Review & Improvement.
Per il test dei controlli privacy, lo stesso principio si applica all’applicabilità PIMS. Ogni controllo privacy applicabile deve essere tracciabile a un rischio di trattamento, a un obbligo legale, a un requisito del cliente o a un’esigenza aziendale. Ogni test deve essere ricondotto a quel controllo.
Come auditor diversi valuteranno lo stesso controllo
Un programma robusto di test privacy anticipa la prospettiva dell’auditor. Lo stesso controllo di cancellazione, controllo degli accessi o controllo di onboarding del responsabile del trattamento sarà interpretato in modo diverso a seconda del contesto di riesame.
| Prospettiva dell’auditor | Probabile domanda di audit | Evidenze attese |
|---|---|---|
| Auditor ISO 27701:2025 | I controlli PIMS basati sui ruoli sono attuati, valutati e migliorati? | Applicabilità REG03, campioni REG12, registro dei trattamenti, mappatura delle politiche, risultati di audit |
| Auditor ISO/IEC 27001:2022 | Il controllo relativo alla privacy è integrato nel trattamento del rischio, nella SoA, nel controllo operativo, nell’audit interno e nel riesame della direzione? | Registro dei rischi, motivazione SoA, piano di trattamento, evidenze del controllo, verbali del riesame della direzione |
| Revisore GDPR | Il titolare del trattamento può dimostrare la conformità ai principi e agli obblighi GDPR? | Base giuridica, informative, log DSR, DPIA, contratti, registrazioni delle violazioni, evidenze di conservazione |
| Assessor NIST CSF | L’organizzazione conosce gli obblighi, definisce esiti target, misura le lacune e migliora? | Profilo attuale e target, piano di gap, prioritizzazione dei rischi, registrazioni di governance |
| Cliente o autorità di controllo orientata a DORA | I controlli ICT sono testati, gli incidenti classificati, i fornitori monitorati e i servizi critici resilienti? | Programma di test, registrazioni degli incidenti, registro dei fornitori, contratti, piani di uscita |
| Auditor ISACA o secondo logiche COBIT 2019 | Obiettivi, titolarità, metriche, chiusura degli issue e supervisione della governance sono efficaci? | RACI, KPI, log degli issue, verifica CAPA, reportistica alla direzione |
Per questo REG12 è così prezioso. Converte la conformità privacy in evidenze di governance verificabili in sede di audit.
Risultanze comuni nei test dei controlli PIMS
Clarysec osserva ripetutamente le stesse risultanze di audit privacy nelle organizzazioni che si preparano alla certificazione ISO 27701:2025, all’assurance GDPR verso i clienti o alla due diligence aziendale.
Il registro dei trattamenti non corrisponde alla realtà dei sistemi
Il registro dei trattamenti elenca CRM e piattaforme di supporto, ma gli ingegneri hanno aggiunto esportazioni di analytics, log di osservabilità, strumenti AI e tabelle di data warehouse.
Risposta di test: campionare sistemi dall’inventario degli asset e dall’inventario cloud, quindi riconciliarli con il registro dei trattamenti. Utilizzare il rapporto tra i controlli 5.9 e 5.34 dell’Annex A ISO/IEC 27001:2022 come motivazione di audit.
L’accesso ai dati personali è approvato, ma non riesaminato periodicamente
Le approvazioni iniziali esistono, ma i riesami degli accessi privilegiati non includono strumenti di impersonificazione del supporto, database di produzione, dashboard BI o account di emergenza.
Risposta di test: campionare utenti attivi con accesso ai dati personali e confrontare ruolo, esigenza aziendale, approvazione, stato MFA, ultimo accesso ed evidenze di riesame.
I contratti con i responsabili del trattamento esistono, ma il monitoraggio è debole
Il DPA è firmato, ma il questionario del fornitore è obsoleto. Nessuno ha riesaminato modifiche dei sub-responsabili, localizzazione dei dati, livello di sicurezza o obblighi di notifica degli incidenti.
Risposta di test: campionare responsabili del trattamento critici ed esaminare due diligence, clausole contrattuali, modifiche dei sub-responsabili, misure di protezione per i trasferimenti e registrazioni di monitoraggio. Questo supporta GDPR, le aspettative NIS2 sulla catena di fornitura e le aspettative DORA sul rischio di terze parti.
La risposta agli incidenti esiste, ma la classificazione privacy è incoerente
Gli incidenti di sicurezza sono registrati, ma l’impatto privacy non è sempre valutato. I criteri GDPR per le violazioni non sono documentati in modo coerente. Gli obblighi di notifica ai clienti sono gestiti informalmente.
Risposta di test: campionare incidenti che comportano esposizione dei dati ed esaminare classificazione, escalation privacy, riesame legale, decisioni di notifica, preservazione delle evidenze, causa radice e lezioni apprese.
La CAPA è chiusa senza verifica di efficacia
Una procedura viene aggiornata e la risultanza viene chiusa. Nessuno testa se il campione successivo sia migliorato.
Risposta di test: verificare l’efficacia dell’azione correttiva in REG12 entro 30 giorni dalla chiusura dichiarata, come richiesto dalla Politica di monitoraggio, audit e miglioramento del PIMS.
Uno sprint di 90 giorni per testare i controlli privacy
Per le organizzazioni che avanzano verso la preparazione a ISO 27701:2025, la due diligence dei clienti o il riesame della responsabilizzazione GDPR, Clarysec raccomanda uno sprint mirato di 90 giorni.
| Tempistica | Focus | Output |
|---|---|---|
| Giorni 1-15 | Ambito di applicazione e modello delle evidenze | Ruoli PIMS, registro dei trattamenti, applicabilità REG03, rischi prioritari, obblighi legali, dipendenze dai fornitori, regole di denominazione delle evidenze |
| Giorni 16-35 | Test del disegno | Riesame delle politiche, RACI, informative privacy, base giuridica, trigger DPIA, flusso di lavoro DSR, classificazione degli incidenti, piani di conservazione, controlli sui fornitori |
| Giorni 36-65 | Test operativo | Campioni per accessi, cancellazioni, incidenti, responsabili del trattamento, trasferimenti, conservazione, formazione, monitoraggio tecnico, evidenze REG12 |
| Giorni 66-80 | CAPA e trattamento del rischio | Causa radice, azione correttiva, proprietario, data di scadenza, rischio residuo, metodo di verifica |
| Giorni 81-90 | Preparazione al riesame della direzione | Pacchetto sulle prestazioni del PIMS, obiettivi, rischi aperti, non conformità, azioni correttive, issue dei fornitori, decisioni di miglioramento |
Al termine dello sprint, l’organizzazione dovrebbe essere in grado di rispondere alle domande che gli auditor pongono realmente:
- Quali dati personali trattate?
- In quale ruolo?
- Quali controlli si applicano?
- Perché sono applicabili?
- Quali evidenze dimostrano che sono attuati?
- Quale campione dimostra che operano?
- Quali lacune sono state rilevate?
- Quali azioni correttive sono state adottate?
- Chi ne ha verificato l’efficacia?
- Che cosa ha riesaminato e deciso l’alta direzione?
Dalla privacy sulla carta alla responsabilizzazione dimostrabile
Un certificato ISO 27701 è prezioso, ma non è la destinazione finale. Clienti, autorità di controllo, consigli di amministrazione e auditor si aspettano sempre più spesso evidenze che i controlli privacy siano progettati, attuati, monitorati, corretti e governati.
La conformità privacy fallisce quando è trattata come un progetto documentale. Regge al controllo quando diventa un sistema di evidenze testato.
Clarysec aiuta le organizzazioni a passare dalla conformità dichiarata alla responsabilizzazione dimostrabile collegando politiche PIMS, applicabilità REG03, campioni di evidenze REG12, verifica CAPA, riesame della direzione e mappatura trasversale dei framework tramite Zenith Blueprint: An Auditor’s 30-Step Roadmap e Zenith Controls: The Cross-Compliance Guide.
Se la tua organizzazione si sta preparando alla certificazione ISO 27701:2025, a un riesame della responsabilizzazione GDPR, all’assurance privacy verso i clienti, alle evidenze di governance NIS2 o alla due diligence dei fornitori guidata da DORA, inizia con un workshop mirato sul test dei controlli privacy.
Clarysec può aiutarti a mappare l’applicabilità REG03, costruire campioni di audit REG12, testare i controlli PIMS prioritari, allineare le risultanze alla CAPA e preparare output per il riesame della direzione in grado di reggere al controllo.
Il tuo prossimo audit privacy non dovrebbe essere una corsa agli screenshot. Dovrebbe essere una dimostrazione sicura che la privacy è operativa, supportata da evidenze, riesaminata e migliorata in modo continuo.
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council