Governance dei dati personali per ISO 27701:2025 e GDPR

La richiesta è arrivata nella casella del CISO con un’apparente semplicità: “Project Wellness”. Una fintech in forte crescita voleva analizzare i dati transazionali esistenti dei clienti per fornire consigli personalizzati sul risparmio, raccomandazioni di prodotto e insight sul rischio di abbandono. Il marketing vedeva opportunità di coinvolgimento dei clienti. Il team di prodotto vedeva innovazione. La leadership vedeva un vantaggio competitivo.

Il CISO vedeva una criticità di governance.

I dati transazionali erano stati raccolti per l’elaborazione dei pagamenti nell’ambito di una finalità e di una base giuridica definite. Ora l’azienda voleva riutilizzarli per analisi di benessere finanziario, personalizzazione delle campagne e attribuzione di punteggi predittivi. Per accelerare la consegna, il team voleva anche inviare un dataset pseudonimizzato a un fornitore terzo di analisi basata su IA.

Nessun attaccante era nella rete. Nessun database era stato esposto. Nessun ticket di incidente lampeggiava in rosso.

Eppure è proprio qui che iniziano molte carenze di responsabilizzazione ai sensi del GDPR.

Il problema non è se l’organizzazione disponga di un’informativa privacy, di un Responsabile della protezione dei dati, di un registro delle basi giuridiche o di un piano di conservazione. La domanda più profonda è operativa: chi approva una nuova raccolta di dati personali, chi conferma la necessità, chi definisce gli usi interni consentiti, chi decide se l’uso secondario è compatibile, chi autorizza la comunicazione a un fornitore e chi può dimostrare la decisione in seguito?

Questa è la lacuna di controllo che le implementazioni del sistema di gestione delle informazioni sulla privacy ISO/IEC 27701:2025, o PIMS, devono colmare. GDPR Article 5 richiede che i dati personali siano trattati in modo lecito, corretto e trasparente, raccolti per finalità determinate, esplicite e legittime, limitati a quanto necessario, esatti, conservati solo per il tempo necessario, protetti in modo adeguato e gestiti secondo la responsabilizzazione del titolare del trattamento. GDPR Article 6 aggiunge la logica della base giuridica e della compatibilità per il trattamento ulteriore. Tuttavia, questi principi diventano difendibili solo quando sono tradotti in flussi di lavoro, registri, approvazioni, regole di accesso, controlli sui fornitori, monitoraggio ed evidenze.

L’approccio di Clarysec è semplice: trattare la governance della raccolta, dell’uso e della comunicazione dei dati personali come un modello operativo controllato, non come un parere legale. Il modello si innesta sulla dorsale del SGSI ISO/IEC 27001:2022, si estende nei ruoli PIMS ISO/IEC 27701:2025 ed è dimostrato attraverso politiche, registri, Zenith Blueprint: la roadmap in 30 passaggi per l’auditor e Zenith Controls: la guida alla conformità trasversale di Clarysec.

Perché la governance dei dati personali fallisce anche quando esistono documenti privacy

La maggior parte dei programmi privacy non fallisce perché qualcuno ignora l’esistenza del GDPR. Fallisce perché le decisioni privacy vengono prese all’interno di ticket di prodotto, e-mail di onboarding dei fornitori, esportazioni in fogli di calcolo, esperimenti su dashboard e piloti di IA senza un punto di controllo ripetibile.

Uno schema tipico è familiare:

1. Un team aggiunge un nuovo campo a un modulo di registrazione perché migliora la segmentazione.
2. Nessuno registra perché quello specifico campo sia necessario.
3. Un altro team riutilizza successivamente i dati per una finalità diversa.
4. Un fornitore riceve un’esportazione sulla base di un accordo di servizi generico.
5. Il registro dei trattamenti viene aggiornato dopo il lancio, se viene aggiornato.
6. Durante l’audit, l’organizzazione può mostrare un’informativa privacy ma non può mostrare evidenze decisionali.

GDPR Articles 4 and 5 definiscono il trattamento in senso ampio. Raccolta, registrazione, archiviazione, uso, comunicazione, cancellazione e distruzione rientrano tutti nel perimetro. Article 5 rende inoltre esplicita la responsabilizzazione. I titolari del trattamento devono poter dimostrare la conformità ai principi.

Ciò significa che la domanda di audit non è solo: “Avete una politica?” È: “Mostratemi come questo specifico elemento di dati è stato approvato, perché era necessario, come è stato utilizzato, chi lo ha ricevuto e quali controlli ne hanno impedito l’uso improprio.”

Clarysec P17 Politica di protezione dei dati e privacy definisce chiaramente l’aspettativa lungo il ciclo di vita:

Formalizza le responsabilità dell’impresa ai sensi degli standard internazionali e dei quadri normativi, assicurando che le informazioni personali (PII) siano raccolte, trattate, conservate, condivise e smaltite in modo lecito, sicuro e trasparente.

Per le PMI, Clarysec Politica di protezione dei dati e privacy - PMI traduce lo stesso principio in una regola operativa pragmatica:

I dati personali possono essere raccolti solo quando necessario per una finalità legittima, lecita o contrattuale.

E, per la minimizzazione:

Devono essere raccolti e conservati solo i dati personali minimi necessari.

Queste affermazioni sono efficaci solo se applicate prima dell’avvio del trattamento. In caso contrario, restano formulazioni privacy prive di prova operativa.

L’obiettivo di controllo: fermare il trattamento non controllato in tre punti di controllo

Un PIMS solido deve governare le decisioni sui dati personali in tre momenti: prima della raccolta, prima dell’uso e prima della comunicazione.

Prima della raccolta, l’organizzazione deve sapere cosa intende raccogliere, da chi, tramite quale canale, per quale finalità, sulla base di quale base giuridica e perché ciascun campo è necessario.

Prima dell’uso, l’organizzazione deve definire le regole di uso interno consentito. Supporto, customer success, marketing, antifrode, finanza e ingegneria raramente necessitano della stessa visibilità o della stessa autorizzazione ad agire sui dati personali.

Prima della comunicazione, l’organizzazione deve sapere chi è il destinatario, quale ruolo svolge, perché la comunicazione è necessaria, dove avviene il trattamento, quali categorie di dati personali sono condivise, con quale frequenza avviene la condivisione e quale fonte autorizza la condivisione.

Clarysec PII09 Politica di raccolta, uso, comunicazione e condivisione dei dati personali è progettata per questo livello di governance. Utilizza l’etichettatura dei ruoli PIMS, in particolare il ruolo di titolare del trattamento, perché le decisioni di raccolta, uso e comunicazione ricadono di norma sull’organizzazione che determina finalità e mezzi.

Per la limitazione della raccolta, PII09 Politica di raccolta, uso, comunicazione e condivisione dei dati personali richiede:

[Titolare del trattamento] Il Responsabile di processo / Responsabile dell’attività DEVE registrare in REG02 la finalità della raccolta, la fonte o il canale, le categorie di dati personali, le categorie di interessati e gli elementi minimi di dati prima dell’avvio di qualsiasi nuova attività di raccolta o modifica sostanziale della raccolta.

Rende quindi verificabile la minimizzazione:

[Titolare del trattamento] Il Responsabile di processo / Responsabile dell’attività DEVE registrare in REG02 una giustificazione di necessità per ciascun elemento di dati personali prima che tale elemento sia raccolto.

Il requisito “ciascun elemento di dati personali” è ciò che distingue un inventario dei trattamenti generico da evidenze di responsabilizzazione a livello di campo.

Per l’uso interno, la stessa politica richiede:

[Titolare del trattamento] Il Responsabile di processo / Responsabile dell’attività DEVE registrare in REG02 le regole di uso interno approvate per ciascuna attività di trattamento prima dell’inizio dell’uso.

Per l’uso secondario:

[Titolare del trattamento] Il Responsabile di processo / Responsabile dell’attività DEVE registrare in REG02 una verifica di compatibilità dell’uso secondario prima che i dati personali siano utilizzati per una finalità non già approvata per l’attività di trattamento.

E per la comunicazione esterna:

[Titolare del trattamento] Il Responsabile fornitori / Responsabile acquisti DEVE registrare in REG08 l’identità del destinatario, il ruolo del destinatario, la finalità della comunicazione, le categorie di dati personali, la frequenza della condivisione, il luogo del trattamento e la fonte dell’autorizzazione prima dell’avvio di una condivisione esterna ricorrente.

Queste clausole forniscono una risposta chiara quando la leadership chiede se l’azienda possa innovare rapidamente: sì, se la decisione supera un flusso di governance documentato e i controlli corrispondono all’approvazione.

REG02 e REG08: la catena Clarysec dalla politica al controllo

Nelle implementazioni Clarysec, REG02 non è un inventario dei trattamenti passivo. È la registrazione decisionale per finalità della raccolta, base giuridica, categorie di dati personali, necessità, regole di uso interno, allineamento alla conservazione e compatibilità dell’uso secondario.

REG08 è il registro di controllo per comunicazione e condivisione. È particolarmente importante per fornitori, partner, società del gruppo, autorità, sub-responsabili, integrazioni ed esportazioni ricorrenti.

Insieme, creano una catena dalla politica al controllo verificabile dai team privacy, sicurezza, acquisti e audit.

Questo modello si allinea naturalmente a ISO/IEC 27001:2022. Le clausole da 4 a 10 richiedono all’organizzazione di comprendere il contesto, i requisiti delle parti interessate, l’ambito di applicazione, le responsabilità di leadership, la valutazione del rischio, il trattamento del rischio, il controllo operativo, la valutazione delle prestazioni e il miglioramento. Gli obblighi privacy previsti dal GDPR e da ISO/IEC 27701:2025 diventano parte del sistema di gestione, invece di restare un’isola privacy separata.

Anche ISO/IEC 27002:2022 supporta il modello operativo. Il controllo 5.31, Requisiti legali, statutari, regolamentari e contrattuali, ancora il GDPR e gli obblighi settoriali. Il controllo 5.34, Privacy e protezione dei dati personali, riguarda la protezione specifica per la privacy. Il controllo 5.9, Inventario delle informazioni e degli altri asset associati, supporta la consapevolezza sui dati. I controlli 5.12 e 5.13 supportano classificazione ed etichettatura. Il controllo 5.14 disciplina il trasferimento delle informazioni. I controlli da 5.19 a 5.23 coprono rapporti con i fornitori, accordi con i fornitori, catena di fornitura ICT, monitoraggio dei servizi dei fornitori e servizi cloud. Il controllo 8.11 supporta il Mascheramento dei dati, 8.12 supporta la Prevenzione della perdita di dati, 8.15 il Logging, 8.16 le Attività di monitoraggio e 8.24 l’Uso della crittografia.

Zenith Blueprint colloca questi controlli in un percorso di implementazione. Nella fase Controlli in azione, il passaggio 23 copre i controlli organizzativi da 5.19 a 5.37, incluso il controllo 5.34 relativo a Privacy e protezione dei dati personali. Il Blueprint spiega:

Nell’attuale mondo guidato dai dati, le informazioni personali identificabili non sono solo un altro tipo di dato: sono una rappresentazione profondamente sensibile della fiducia. Nomi, indirizzi, documenti identificativi, cartelle sanitarie, dettagli finanziari: questi dati raccontano una storia su persone reali.

Definisce poi la baseline operativa:

Il fondamento di questo controllo è la consapevolezza sui dati. L’organizzazione deve sapere quali dati personali raccoglie, dove risiedono, perché sono trattati e chi può accedervi.

È ciò che REG02 e REG08 forniscono quando sono trattati come registrazioni di governance vive.

Esempio pratico: approvare Project Wellness senza perdere il controllo

Torniamo allo scenario fintech. L’azienda vuole analizzare i dati transazionali dei clienti per formulare raccomandazioni personalizzate di benessere finanziario. Il marketing vuole usare gli output per le campagne. Il team di prodotto vuole costruire punteggi di abbandono e coinvolgimento. Una piattaforma terza di analisi basata su IA tratterà parte del dataset.

Ecco come Clarysec governerebbe la richiesta.

Passaggio 1: creare o aggiornare l’attività di trattamento REG02

Il Responsabile di processo apre REG02 e registra l’attività di trattamento prima dell’inizio dei lavori.

Il punto importante è la tempistica. REG02 viene aggiornato prima dell’avvio del nuovo trattamento, non dopo che la funzionalità è già in esercizio.

Passaggio 2: registrare le giustificazioni di necessità a livello di campo

Inizialmente il marketing chiede cinque anni di cronologia transazionale completa, inclusi nomi degli esercenti, timestamp esatti, metadati delle carte e attributi del profilo cliente. Il team di governance contesta ciascun campo.

Questa è minimizzazione dei dati come evidenza, non come aspirazione. L’azienda riceve comunque analisi utili, ma il dataset viene ristretto a ciò che è necessario per la finalità approvata.

Passaggio 3: classificare ed etichettare il dataset

Il dataset è classificato secondo la Politica di classificazione ed etichettatura dei dati di Clarysec. La versione per PMI richiede:

La condivisione esterna deve essere esplicitamente autorizzata e registrata.

La Politica di classificazione ed etichettatura dei dati enterprise aggiunge una misura di sicurezza per le informazioni sensibili:

Possono essere condivise esternamente solo sulla base di un accordo di riservatezza o di misure di sicurezza contrattuali equivalenti.

In pratica, il dataset Project Wellness non può essere esportato informalmente verso una piattaforma di IA. Richiede una registrazione della comunicazione approvata, misure contrattuali, controlli tecnici di trasferimento e log.

Zenith Blueprint, nel passaggio 22 per il controllo 5.12 Classificazione delle informazioni, spiega perché questo aspetto è rilevante:

Ogni controllo di sicurezza delle informazioni mai scritto — restrizione degli accessi, cifratura, backup, monitoraggio o smaltimento — presuppone una cosa: che l’organizzazione sappia che cosa sta proteggendo.

Senza classificazione, restrizioni di accesso, cifratura, DLP e regole di conservazione diventano congetture.

Passaggio 4: definire le regole di uso interno prima del rilascio in produzione

Il Responsabile di processo registra in REG02 le regole di uso interno approvate. È qui che spesso si arresta la deriva delle finalità.

Un insieme difendibile di regole potrebbe stabilire che:

• Il team di prodotto può utilizzare metriche aggregate sulle prestazioni delle raccomandazioni.
• L’assistenza clienti può vedere se una raccomandazione è stata mostrata a un cliente durante la gestione di una richiesta di supporto.
• Il marketing non può utilizzare punteggi di benessere a livello individuale per la segmentazione delle campagne, salvo completamento di una verifica di compatibilità dell’uso secondario.
• La finanza non può accedere ad analisi dettagliate sul benessere salvo esistenza di una finalità separata approvata.
• Gli sviluppatori non devono utilizzare dati personali di produzione negli ambienti di test.
• La valutazione dei modelli di IA deve utilizzare, ove possibile, dataset mascherati, pseudonimizzati o aggregati.

Le ultime due regole si collegano al controllo 8.11 ISO/IEC 27002:2022, Mascheramento dei dati. Zenith Blueprint, passaggio 19, descrive il Mascheramento dei dati come un metodo pratico per prevenire esposizioni non necessarie negli ambienti di test, nei dataset di training, nelle piattaforme di analisi, nelle integrazioni di terze parti e nelle pipeline di test CI/CD.

Passaggio 5: eseguire la verifica di compatibilità dell’uso secondario

Successivamente il marketing chiede di usare i punteggi di benessere per campagne mirate. Si tratta di una nuova finalità. Ai sensi della clausola 4.3.1 della PII09 Politica di raccolta, uso, comunicazione e condivisione dei dati personali, il Responsabile dell’attività deve registrare in REG02 una verifica di compatibilità prima dell’inizio del nuovo uso.

La verifica deve valutare:

• Se il marketing sul benessere finanziario sia compatibile con la finalità originaria del trattamento.
• Che cosa è stato comunicato ai clienti al momento della raccolta e nell’informativa privacy.
• Se le inferenze derivate dalle transazioni possano essere sensibili o inattese.
• Se il nuovo uso possa generare pressione, esclusione o profilazione scorretta.
• Se misure di sicurezza quali aggregazione, opt-out, pseudonimizzazione o segmentazione a livello di account riducano il rischio.
• Se la base giuridica rimanga valida.
• Se siano necessari aggiornamenti della trasparenza o meccanismi di consenso.

L’esito può essere approvazione, approvazione con misure di sicurezza o rigetto. Il valore sta nel fatto che la decisione viene documentata prima dell’inizio dell’uso.

Passaggio 6: approvare la comunicazione esterna tramite REG08

Se il fornitore di analisi basata su IA riceverà dati, il Responsabile fornitori o il Responsabile acquisti registra in REG08:

Clarysec Politica di sicurezza delle terze parti e dei fornitori - PMI rafforza l’accesso minimizzato dei fornitori:

Ai fornitori deve essere concesso accesso solo ai sistemi e ai dati minimi necessari per svolgere la propria funzione.

Questa è minimizzazione privacy applicata all’accesso dei fornitori e alla comunicazione.

Passaggio 7: aggiungere l’applicazione tecnica

Le registrazioni di governance devono essere supportate da controlli tecnici. Per Project Wellness, Clarysec raccomanderebbe tipicamente regole DLP per le esportazioni, restrizioni di controllo degli accessi basato sui ruoli, logging degli eventi di accesso e trasferimento, dataset mascherati per lo sviluppo, cifratura per trasferimento e archiviazione, riesami degli accessi dei fornitori, due diligence di sicurezza cloud e campionamento periodico di REG02 e REG08 rispetto al comportamento effettivo dei sistemi.

È così che ISO/IEC 27701:2025 e la responsabilizzazione prevista dal GDPR diventano evidenza operativa.

Mappatura dei controlli: dalla decisione privacy all’applicazione della sicurezza

La governance dei dati personali non è un singolo controllo isolato. È una relazione tra requisiti privacy, controlli di sicurezza, governance dei fornitori ed evidenze di audit.

Zenith Controls tratta il controllo 5.34 ISO/IEC 27002:2022, Privacy e protezione dei dati personali, come controllo preventivo a supporto di riservatezza, integrità e disponibilità, con i concetti di cibersicurezza Identify e Protect e capacità operative nella protezione delle informazioni, oltre che nell’area legale e di conformità.

Per 5.34, Zenith Controls mappa l’ecosistema di controlli circostante, inclusi inventario, classificazione, trasferimento, accesso, identità, cloud, sicurezza dei fornitori, mascheramento, prevenzione della perdita di dati, logging, monitoraggio e crittografia.

Per il mascheramento, Zenith Controls afferma:

Il Mascheramento dei dati (8.11) è una tecnica spesso utilizzata per proteggere i dati personali in ambienti non di produzione o nella condivisione dei dati. Supporta direttamente 5.34 riducendo l’esposizione dei dati personali reali e, quindi, abbassando il rischio privacy.

Per la prevenzione della perdita di dati, la guida spiega il confine operativo:

La DLP svolge un ruolo diretto nella protezione dei dati personali. Il controllo 8.12 applica confini su come i dati personali possono essere consultati, condivisi o spostati, assicurando che non possano essere esposti tramite canali non autorizzati.

Un auditor che verifica la governance delle comunicazioni può quindi richiedere non solo REG08, ma anche politiche DLP, log dei trasferimenti bloccati, controlli sulla posta elettronica in uscita, restrizioni alla condivisione cloud, requisiti di cifratura, registrazioni degli accessi dei fornitori ed evidenze delle eccezioni approvate.

Valore di conformità trasversale: GDPR, ISO 27701, NIS2, DORA, NIST e COBIT

La governance della raccolta, dell’uso e della comunicazione dei dati personali è guidata dalla privacy, ma le sue evidenze supportano obblighi più ampi di cibersicurezza, resilienza e governance.

GDPR Articles 2 and 3 definiscono un ampio ambito materiale e territoriale, che può includere SaaS, fintech e fornitori di servizi digitali fuori dall’UE quando offrono servizi a persone nell’UE o ne monitorano il comportamento. Article 5 richiede limitazione della finalità, minimizzazione dei dati, esattezza, limitazione della conservazione, integrità, riservatezza e responsabilizzazione. Article 6 richiede base giuridica e valutazione di compatibilità per il trattamento ulteriore. Article 9 aggiunge condizioni più rigorose per le categorie particolari di dati, rilevanti quando sono coinvolti profilazione, dati assimilabili alla salute, onboarding biometrico o attributi sensibili.

NIS2 Article 21 richiede agli enti essenziali e importanti di applicare misure tecniche, operative e organizzative proporzionate di gestione del rischio. Le aree minime includono analisi dei rischi, politiche di sicurezza dei sistemi informativi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, sviluppo sicuro, efficacia dei controlli, formazione, crittografia, sicurezza delle risorse umane, controllo degli accessi, gestione degli asset e autenticazione.

DORA richiede alle entità finanziarie di mantenere un quadro per la gestione del rischio ICT, responsabilizzazione dell’organo di gestione, identificazione degli asset e delle dipendenze ICT, controlli di protezione e prevenzione, rilevazione, risposta, ripristino, backup, apprendimento, gestione degli incidenti, test e gestione del rischio ICT di terze parti. Richiede inoltre registri delle informazioni per i contratti di servizi ICT, due diligence, diritto di audit, requisiti di sicurezza e strategie di uscita.

NIST Cybersecurity Framework 2.0 offre un linguaggio di governance integrato. La funzione GOVERN prevede che i requisiti legali, regolamentari e contrattuali, inclusi gli obblighi privacy, siano compresi e gestiti. Copre inoltre strategia di rischio, ruoli, politiche, supervisione e gestione del rischio dei fornitori.

Gli auditor COBIT 2019 cercano obiettivi di governance, diritti decisionali, responsabilizzazione, titolarità dei processi, indicatori di prestazione ed evidenze di assurance. Per la governance dei dati personali, ciò significa che i requisiti privacy devono essere incorporati nella governance aziendale, non gestiti come processo laterale.

Come gli auditor verificano lo stesso livello di governance

Una solida implementazione PIMS deve reggere diversi stili di audit.

Un auditor ISO/IEC 27001:2022 e ISO/IEC 27701:2025 partirà da ambito di applicazione, parti interessate, requisiti legali e contrattuali, valutazione del rischio, Dichiarazione di applicabilità, pianificazione operativa ed evidenze documentate. Potrebbe campionare attività di trattamento da REG02 e verificare se controlli quali 5.34, 5.12, 5.14, da 5.19 a 5.23, 8.11, 8.12, 8.15, 8.16 e 8.24 siano implementati e monitorati.

Un auditor o un’autorità di regolamentazione focalizzati sul GDPR verificheranno la responsabilizzazione. Potrebbero partire da un’informativa privacy, un reclamo, una richiesta dell’interessato o una comunicazione a un fornitore, e poi risalire a ritroso. Perché questi dati sono stati raccolti? Quale base giuridica si applicava? La finalità era specificata? L’uso successivo era compatibile? Il destinatario era autorizzato? Gli interessati erano informati? Le registrazioni sono state aggiornate prima dell’avvio del trattamento?

Un supervisore DORA, ove applicabile, si concentrerà sulle funzioni aziendali supportate da ICT, sui fornitori terzi di servizi ICT, sulle clausole contrattuali, sui diritti di audit, sulla protezione dei dati, sulla comunicazione degli incidenti, sui test di resilienza e sulla pianificazione dell’uscita. Se dati personali dei clienti sono condivisi con un fornitore critico di analisi o cloud, REG08, due diligence sui fornitori e controlli contrattuali diventano evidenze centrali.

Un valutatore NIST CSF inquadrerà il tema attraverso gli esiti di governance. I requisiti legali e regolamentari sono gestiti? Ruoli e responsabilità sono chiari? Le politiche sono mantenute e applicate? I rischi dei fornitori sono governati? Gli esiti di protezione dei dati, monitoraggio e risposta sono operativi?

Un auditor in stile COBIT o ISACA chiederà se i diritti decisionali siano definiti, se i responsabili dell’attività accettino il rischio privacy, se le prestazioni dei controlli siano misurate, se le eccezioni siano tracciate e se la direzione riceva reporting significativo.

Errori comuni che Clarysec riscontra nelle implementazioni

Il primo errore è trattare l’inventario dei trattamenti come un esercizio documentale anziché come un punto di approvazione. Se REG02 viene aggiornato dopo il lancio, non può dimostrare la governance preventiva.

Il secondo è l’uso di formulazioni vaghe della finalità. “Analytics”, “miglioramento del servizio” o “customer insight” raramente sono abbastanza specifici da controllare l’uso interno o l’uso secondario.

Il terzo è l’assenza di necessità a livello di campo. La minimizzazione dei dati non può essere dimostrata affermando che ogni campo è utile. L’azienda deve spiegare perché ciascun campo è necessario per la finalità approvata.

Il quarto è l’uso secondario non controllato. I dati raccolti per l’amministrazione dell’account diventano silenziosamente intelligence commerciale, poi segmentazione marketing, poi addestramento di IA. Ogni modifica della finalità richiede un’analisi di compatibilità e, in alcuni casi, una nuova base giuridica o un aggiornamento della trasparenza.

Il quinto è una governance debole delle comunicazioni. Gli elenchi dei fornitori non equivalgono alle registrazioni delle comunicazioni. REG08 collega destinatario, ruolo, finalità, categorie di dati personali, luogo, frequenza e fonte dell’autorizzazione in un’unica traccia di approvazione.

Il sesto è l’assenza di applicazione tecnica. Le politiche possono dire che i dati personali non devono uscire dai canali approvati, ma e-mail, esportazioni, unità condivise e strumenti di analisi spesso lo consentono. È qui che i controlli ISO/IEC 27002:2022 5.14, 8.12, 8.15, 8.16 e 8.24 diventano essenziali.

Un piano pratico di avvio in 30 giorni

Le organizzazioni non devono risolvere tutto in una volta. È opportuno partire da una singola attività di trattamento ad alto rischio, preferibilmente una che coinvolga profilazione dei clienti, analisi basata su IA, attributi sensibili, trasferimento transfrontaliero o una piattaforma di terze parti.

Nella prima settimana, identificare l’attività di trattamento, il responsabile, le categorie di dati personali, i sistemi, i fornitori e la finalità attuale. Confermare se l’attività è già rappresentata in REG02 e se la comunicazione è rappresentata in REG08.

Nella seconda settimana, completare le giustificazioni di necessità a livello di campo. Contestare gli elementi di dati eccessivi. Confermare classificazione ed etichettatura. Identificare se mascheramento, aggregazione o pseudonimizzazione possono ridurre il rischio.

Nella terza settimana, definire le regole di uso interno ed eseguire eventuali verifiche di compatibilità dell’uso secondario. Decidere se informative privacy, valutazioni della base giuridica o controlli per gli interessati richiedono aggiornamenti.

Nella quarta settimana, validare le registrazioni delle comunicazioni esterne, l’accesso dei fornitori, le misure contrattuali, le condizioni del DPA, i controlli di trasferimento, il logging, la DLP e gli obblighi di cancellazione. Quindi campionare il comportamento effettivo dei sistemi rispetto alle approvazioni.

Al termine dei 30 giorni, la direzione dovrebbe disporre di un pacchetto di evidenze concreto: REG02, REG08, registrazioni di classificazione, matrici di accesso, evidenze DLP e di logging, due diligence sui fornitori, misure contrattuali, verifiche di compatibilità e azioni di rimedio aperte.

Dalla politica alla prova

La governance della raccolta, dell’uso e della comunicazione dei dati personali è il punto in cui la privacy diventa reale. È la differenza tra affermare “siamo conformi al GDPR” e dimostrare che ogni decisione di raccolta, uso, riutilizzo e comunicazione è stata controllata prima che il trattamento avvenisse.

Il toolkit di Clarysec offre ai team privacy, sicurezza e conformità un percorso pratico:

• Usa PII09 Politica di raccolta, uso, comunicazione e condivisione dei dati personali per definire punti di approvazione obbligatori.
• Usa P17 Politica di protezione dei dati e privacy o Politica di protezione dei dati e privacy - PMI per ancorare un trattamento lecito, corretto, trasparente e minimizzato.
• Usa Politica di classificazione ed etichettatura dei dati e Politica di sicurezza delle terze parti e dei fornitori - PMI per governare classificazione, condivisione e accesso dei fornitori.
• Segui Zenith Blueprint: la roadmap in 30 passaggi per l’auditor per implementare l’ambiente di controllo nella sequenza corretta.
• Usa Zenith Controls: la guida alla conformità trasversale per comprendere come i controlli ISO/IEC 27002:2022 quali 5.34, 5.12, 5.14, 8.11 e 8.12 supportano GDPR, NIS2, DORA, NIST e le aspettative di audit.

Se il prossimo audit, la prossima richiesta di due diligence del cliente o il prossimo riesame del consiglio di amministrazione chiede come controllate quali dati personali sono raccolti, come sono utilizzati e quando sono comunicati, non affidatevi alle sole dichiarazioni di policy.

Partite da un’attività ad alto rischio. Costruite la registrazione REG02. Giustificate ciascun elemento di dati. Definite le regole di uso interno. Eseguite la verifica di compatibilità dell’uso secondario. Create la registrazione della comunicazione in REG08. Quindi verificate se accesso, DLP, mascheramento, logging, cifratura e controlli sui fornitori corrispondono alla decisione.

È così che ISO/IEC 27701:2025 e la responsabilizzazione prevista dal GDPR diventano evidenza.

Esplora il toolkit Clarysec PIMS, inizia dalla PII09 Politica di raccolta, uso, comunicazione e condivisione dei dati personali e usa Zenith Blueprint per trasformare la governance privacy da intento di policy in prova idonea all’audit.