Valutazione del rischio privacy per ISO 27701 e GDPR
La riunione del lunedì mattina era una scena familiare per Maria, CISO di un’azienda di tecnologia sanitaria in forte crescita.
Il CEO voleva un cruscotto semplice che mostrasse l’esposizione al rischio GDPR prima del lancio della piattaforma di analisi dei pazienti basata su IA. Il nuovo Responsabile privacy, David, disponeva di un registro delle attività di trattamento (RoPA) di 50 schede. Il team di ingegneria aveva messo in sicurezza l’ambiente cloud. Il prodotto era pronto per il rilascio. Il fornitore descriveva la propria catena di sub-responsabili come “di livello enterprise”.
Ma una domanda bloccò la sala.
“Qual è il nostro rischio effettivo e possiamo dimostrare ai clienti enterprise che lo abbiamo sotto controllo?”
Il RoPA mostrava quali trattamenti effettuava l’azienda. Il registro dei rischi di sicurezza mostrava i rischi infrastrutturali. Alcune DPIA erano archiviate in documenti separati. I riesami dei fornitori erano nelle cartelle dell’approvvigionamento. Nessuno era in grado di mostrare un’unica catena decisionale tracciabile dall’attività di trattamento al rischio privacy, alla decisione sulla DPIA, al piano di trattamento del rischio, alla mappatura dei controlli, all’approvazione del rischio residuo e alla data di riesame.
Questo è il divario che molte organizzazioni incontrano nel percorso verso ISO/IEC 27701:2025 e l’accountability GDPR. Dispongono di informative privacy, questionari per i fornitori, voci RoPA, mappe dei dati, modelli DPIA e controlli ISO/IEC 27001:2022. Spesso manca il livello operativo che collega questi elementi.
Un Sistema di gestione delle informazioni sulla privacy maturo, o PIMS, non tratta la valutazione del rischio privacy come un documento legale separato. La tratta come un processo decisionale ripetibile: identificare il trattamento, effettuare lo screening del rischio, decidere se serve una DPIA, selezionare i controlli, assegnare i responsabili, approvare il rischio residuo, monitorare i trigger e conservare le evidenze.
È qui che i pacchetti di policy Clarysec, Zenith Blueprint e Zenith Controls aiutano i team a passare da fogli di calcolo scollegati a un motore del rischio privacy difendibile.
La valutazione del rischio privacy è il livello operativo mancante
L’accountability GDPR viene spesso ridotta al “disporre di documentazione”. La documentazione è importante, ma Article 5(2) va oltre. Il titolare del trattamento è responsabile del rispetto dei principi di cui all’Article 5(1) e deve essere in grado di dimostrarlo, inclusi liceità, correttezza, trasparenza, limitazione della finalità, minimizzazione dei dati, esattezza, limitazione della conservazione, integrità e riservatezza.
Serve quindi più di un RoPA. L’organizzazione deve poter spiegare perché un’attività di trattamento è accettabile, quali rischi crea per gli interessati, quali controlli riducono tali rischi, chi è responsabile della decisione e quando la decisione deve essere riesaminata.
ISO/IEC 27701:2025 rafforza questa aspettativa integrando la governance privacy in un PIMS gestito. In pratica, la valutazione del rischio privacy deve collegare sei oggetti operativi:
- L’inventario dei trattamenti dei dati personali o RoPA.
- La documentazione della base giuridica e della finalità.
- Lo screening del rischio privacy e la decisione sulla DPIA.
- Il trattamento del rischio e la selezione dei controlli.
- La governance di fornitori, responsabili del trattamento e sub-responsabili.
- Le evidenze conservate nel SGSI e nel PIMS.
Clarysec rende esplicito questo collegamento. Nella Policy di valutazione del rischio privacy e DPIA Enterprise, il trigger interviene prima che il trattamento inizi:
[Entrambi] Il Responsabile del processo / responsabile dell’attività DEVE avviare lo screening del rischio privacy in REG04 prima dell’avvio di un trattamento di dati personali nuovo o modificato in modo sostanziale registrato in REG02.
La stessa disciplina preventiva compare nella Policy sull’inventario dei trattamenti di dati personali e sulla base giuridica Enterprise:
[Entrambi] Il Responsabile del processo / responsabile dell’attività DEVE avviare lo screening del rischio privacy e della DPIA in REG04 prima che un trattamento di dati personali nuovo o modificato in modo sostanziale proceda.
Questo evita un modello di errore comune: il prodotto viene lanciato, il RoPA viene aggiornato dopo, la domanda sulla DPIA arriva troppo tardi e il registro dei rischi non riceve mai lo scenario privacy.
Per i titolari del trattamento, ciò supporta la disciplina della base giuridica prevista dal GDPR Article 6, la protezione dei dati fin dalla progettazione e per impostazione predefinita dell’Article 25, la sicurezza del trattamento dell’Article 32 e l’accountability dell’Article 5. Per i responsabili del trattamento, supporta istruzioni documentate, assurance del cliente, confini contrattuali e trasparenza sui sub-responsabili.
Parti dalla realtà del trattamento, non da un modello vuoto
Una valutazione del rischio privacy fallisce quando inizia da un modulo vuoto e senza contesto operativo. La prima domanda non dovrebbe essere “Serve una DPIA?”. Dovrebbe essere “Quale trattamento sta effettivamente cambiando?”.
Per un’organizzazione SaaS, fintech o di tecnologia sanitaria, il cambiamento può riguardare:
- Una nuova categoria di dati, come dati comportamentali di utilizzo, dati sanitari, segnali biometrici o metadati di pagamento.
- Una nuova finalità, come attribuzione di punteggi antifrode, analisi dei pazienti, supporto assistito da IA, previsione del churn o personalizzazione.
- Un nuovo destinatario, responsabile del trattamento o sub-responsabile.
- Un nuovo flusso di lavoro di supporto o percorso di accesso transfrontaliero.
- Un nuovo periodo di conservazione.
- Un nuovo modello, algoritmo o raccomandazione automatizzata.
- Un nuovo gruppo di interessati, come minori, dipendenti, pazienti o persone finanziariamente vulnerabili.
Le definizioni del GDPR sono ampie. I dati personali includono identificativi, identificativi online, dati relativi all’ubicazione e fattori collegati all’identità. Il trattamento include raccolta, conservazione, consultazione, uso, comunicazione, limitazione, cancellazione e distruzione. Una violazione dei dati personali include distruzione, perdita, modifica, comunicazione non autorizzata o accesso, accidentali o illeciti.
Ciò significa che un processo di gestione del rischio privacy deve acquisire più informazioni del solo fatto che la banca dati sia cifrata. Deve acquisire perché il trattamento esiste, se la finalità è compatibile, se la base giuridica è valida, se sono coinvolti dati appartenenti a categorie particolari, se gli interessati possono comprendere il trattamento e se le misure di sicurezza sono proporzionate.
Per i team più piccoli, la Policy di protezione dei dati e privacy per PMI fornisce il punto di partenza nella clausola 5.2.1:
Il Coordinatore privacy deve mantenere un registro di tutte le attività di trattamento dei dati personali, comprendente categorie di dati, finalità, base giuridica e periodi di conservazione
Quel registro non è burocrazia. È il modello di input per la valutazione del rischio privacy. Senza categorie di dati, finalità, base giuridica e periodi di conservazione, la valutazione non può esaminare in modo affidabile limitazione della finalità, minimizzazione dei dati, limitazione della conservazione, trasparenza o correttezza.
La stessa policy per PMI rende inoltre il riesame del rischio un obbligo ricorrente nella clausola 7.1.1:
Il Coordinatore privacy deve valutare i rischi privacy annualmente e in occasione di modifiche rilevanti ai sistemi
Per le organizzazioni enterprise, la cadenza di governance è più rigorosa. La Policy di protezione dei dati e privacy Enterprise stabilisce:
I registri dei rischi privacy devono essere mantenuti all’interno del SGSI e riesaminati almeno trimestralmente dal Responsabile della protezione dei dati (DPO) e dal CISO.
È qui che l’integrazione tra ISO/IEC 27701:2025 e ISO/IEC 27001:2022 diventa operativa. I rischi privacy non sono sepolti in cartelle legali. Sono riesaminati insieme ai rischi di sicurezza, ai rischi dei fornitori, agli incidenti, alle risultanze di audit, ai piani di trattamento del rischio e alla reportistica direzionale.
Il processo Clarysec da REG02 a REG04
Il processo di valutazione del rischio privacy più efficace è abbastanza semplice per i responsabili dell’attività e abbastanza rigoroso per gli auditor. Il modello Clarysec utilizza REG02 come inventario dei trattamenti dei dati personali e REG04 come registrazione della valutazione del rischio privacy e della DPIA.
| Punto del processo | Domanda pratica | Evidenza creata | Responsabile |
|---|---|---|---|
| Voce di trattamento REG02 | Quali dati personali sono trattati, per quale finalità, da chi e in base a quale base giuridica? | Registrazione dell’inventario dei trattamenti, base giuridica, categorie di dati, periodo di conservazione | Responsabile del processo |
| Screening REG04 | L’attività crea un rischio elevato per gli interessati o attiva criteri DPIA? | Decisione di screening privacy, motivazione, data di riesame | Responsabile privacy o Responsabile del PIMS |
| Decisione DPIA | È richiesta una DPIA completa prima che il trattamento inizi o cambi? | Registrazione DPIA o motivazione documentata dell’assenza di DPIA | DPO o Responsabile privacy |
| Trattamento del rischio | Quali controlli riducono il rischio a un livello accettabile? | Piano di trattamento del rischio, mappatura dei controlli, date di scadenza | Proprietario del rischio |
| Approvazione del rischio residuo | Chi accetta il rischio elevato residuo e a quali condizioni? | Registrazione dell’approvazione, motivazione dell’accettazione | Alta direzione ove richiesto |
| Trigger di riesame | Quali cambiamenti riaprono la valutazione? | Data di riesame, trigger di cambiamento, evidenze di monitoraggio | Responsabile del processo e Responsabile privacy |
La Policy di valutazione del rischio privacy e DPIA definisce le evidenze minime necessarie prima della chiusura di REG04:
[Entrambi] Il Responsabile privacy / Responsabile del PIMS DEVE assicurare che ogni valutazione REG04 registri classificazione del rischio, decisione di trattamento, responsabile, data di scadenza, rischio residuo, stato di approvazione e data di riesame prima della chiusura.
Questa frase è la spina dorsale operativa. Una valutazione del rischio privacy non è chiusa perché qualcuno ha scritto “rischio basso” in un campo commento. È chiusa quando la registrazione include classificazione, decisione di trattamento, responsabile, data di scadenza, rischio residuo, stato di approvazione e data di riesame.
Per le PMI, la stessa disciplina è proporzionata alla dimensione organizzativa. La Policy di gestione del rischio per PMI stabilisce:
Ogni voce di rischio deve includere: descrizione, probabilità, impatto, punteggio, responsabile e piano di trattamento del rischio.
Il principio è la proporzionalità, non l’informalità. Le organizzazioni più piccole possono usare un registro più semplice, ma ogni rischio richiede comunque descrizione, punteggio, responsabile e piano di trattamento del rischio.
Usa il motore di rischio ISO/IEC 27001:2022 per la privacy
Il rischio privacy non dovrebbe vivere al di fuori del metodo di gestione del rischio dell’organizzazione. ISO/IEC 27001:2022 fornisce già il motore del sistema di gestione: contesto, parti interessate, ambito di applicazione, leadership, valutazione del rischio, trattamento, controllo operativo, informazioni documentate, valutazione delle prestazioni e miglioramento continuo.
Le clausole da 4.1 a 4.4 richiedono all’organizzazione di comprendere fattori interni ed esterni, requisiti delle parti interessate, ambito di applicazione del SGSI e processi del SGSI. Per la privacy, le parti interessate includono clienti, interessati, dipendenti, autorità di regolamentazione, responsabili del trattamento, sub-responsabili, autorità di controllo, autorità di vigilanza del settore finanziario ove pertinenti e clienti contrattuali.
La clausola 6.1.2 richiede un processo di valutazione del rischio per la sicurezza delle informazioni. La clausola 6.1.3 richiede il trattamento del rischio per la sicurezza delle informazioni, inclusi la selezione dei controlli, la predisposizione di una Dichiarazione di Applicabilità, la formulazione di un piano di trattamento del rischio e l’ottenimento dell’approvazione del piano e dei rischi residui da parte del proprietario del rischio. Le clausole 8.2 e 8.3 richiedono di eseguire valutazioni e trattamenti del rischio per la sicurezza delle informazioni a intervalli pianificati o quando si verificano cambiamenti significativi, conservando i risultati documentati.
La Policy di gestione del rischio Enterprise di Clarysec si allinea a tale struttura nella clausola 5.1:
Deve essere mantenuto un processo formale di gestione del rischio in conformità a ISO/IEC 27005 e ISO 31000, che copra identificazione, analisi, valutazione, trattamento, monitoraggio e comunicazione del rischio.
Per la privacy, i criteri di rischio devono includere l’impatto sugli interessati, non solo l’impatto aziendale. Una perdita finanziaria contenuta può comunque corrispondere a un impatto privacy elevato se il trattamento riguarda dati appartenenti a categorie particolari, persone vulnerabili, profilazione, opacità, conservazione illecita, impossibilità di esercitare i diritti o danni non materiali.
Zenith Blueprint: una roadmap in 30 passi per auditor di Clarysec lo spiega nella fase di Gestione del rischio, Step 10:
Quando si definisce l’impatto, è opportuno collegare i livelli alla scala specifica della propria attività. Per esempio, “impatto finanziario rilevante = perdita > $100k” (da adattare al proprio contesto). Considerare anche l’impatto normativo: per esempio, una violazione dei dati personali potrebbe essere automaticamente “Rilevante” o “Grave” a causa delle sanzioni GDPR e dei requisiti di notifica, anche se la perdita finanziaria diretta non è chiara.
Questa indicazione è particolarmente importante per analisi basate su IA, dati sanitari, profilazione finanziaria, monitoraggio dei dipendenti e scoring dei clienti. Il danno può essere legale, reputazionale, discriminatorio, operativo, contrattuale o personale.
Un esempio pratico: analisi IA dei pazienti
Torniamo a Maria e David. La loro piattaforma di tecnologia sanitaria tratterà dati sanitari appartenenti a categorie particolari ai sensi del GDPR Article 9. Userà storia clinica del paziente, dati sugli appuntamenti, note dei clinici e output del modello per generare insight di rischio.
Utilizzando Zenith Blueprint, iniziano dallo Step 9, identificando asset, minacce e vulnerabilità:
Per ogni asset, registrare i dettagli chiave: Nome/Descrizione, Proprietario, Ubicazione e Classificazione (sensibilità). Per esempio, un asset potrebbe essere “Database clienti – di proprietà del Dipartimento IT – ospitato su AWS – contiene dati personali e finanziari (sensibilità elevata)”.
Lo stesso passo aggiunge la prospettiva privacy:
Assicurarsi che gli asset contenenti dati personali siano contrassegnati (per la rilevanza GDPR) e che gli asset dei servizi critici siano indicati (per la potenziale applicabilità NIS2 se si opera in un settore regolamentato).
Il team di Maria identifica la piattaforma di analisi IA dei pazienti, la banca dati dei pazienti, il data warehouse, la pipeline di addestramento del modello, la dashboard dei clinici, l’archiviazione cloud, il provider di identità, i log di audit, la piattaforma di ticketing per il supporto e lo strumento di analisi di terze parti. A ogni asset vengono associati proprietario, ubicazione, classificazione e relazione con i dati personali.
Poi definiscono gli scenari di rischio. Uno è l’accesso non autorizzato alle cartelle sanitarie. Un altro è la comunicazione accidentale tramite esportazioni analitiche. Un terzo è il bias del modello IA causato da dati di addestramento sbilanciati, con conseguente attribuzione di punteggi di rischio dei pazienti ingiusta o discriminatoria.
Lo Step 11 di Zenith Blueprint spiega il ruolo del registro dei rischi:
Il Registro dei rischi è in genere un foglio di calcolo (il nostro modello “Risk Register and SoA Builder.xlsx” include un foglio dedicato a questo). Serve da log master dei rischi.
Una voce di rischio privacy per lo scenario di bias del modello IA può apparire così:
| Campo | Voce | Riferimento Clarysec |
|---|---|---|
| ID rischio | PRV-004 | Zenith Blueprint, Step 11 |
| Asset | Piattaforma di analisi IA dei pazienti | Zenith Blueprint, Step 9 |
| Minaccia | Bias del modello IA da dati di addestramento sbilanciati | Zenith Blueprint, Step 9 |
| Vulnerabilità | Assenza di validazione formale del modello e di test di equità | Zenith Blueprint, Step 9 |
| Descrizione del rischio | Il modello potrebbe produrre punteggi di rischio dei pazienti discriminatori, con conseguente trattamento ingiusto e violazione dei diritti degli interessati | Policy di gestione del rischio PMI, clausola 5.1.2 |
| Probabilità | Probabile, 4 su 5 | Zenith Blueprint, Step 10 |
| Impatto | Rilevante, 4 su 5, per la presenza di dati appartenenti a categorie particolari e il potenziale danno agli interessati | Zenith Blueprint, Step 10 |
| Punteggio di rischio | 16, Alto | Zenith Blueprint, Step 10 |
| Proprietario del rischio | Responsabile Data Science | Zenith Blueprint, Step 11 |
| Piano di trattamento del rischio | Attuare validazione del modello, test di equità, riaddestramento rappresentativo, riesame dell’esplicabilità, riesame del DPO e completamento della DPIA | Policy di gestione del rischio PMI, clausola 5.1.2 |
Questa voce fa ciò che il vecchio foglio di calcolo non riusciva a fare. Collega un’attività di trattamento a un asset, una minaccia, una vulnerabilità, un rischio per gli interessati, un responsabile, un punteggio, un piano di trattamento del rischio e una traccia delle evidenze.
Poiché il trattamento è ad alto rischio e coinvolge dati appartenenti a categorie particolari, la DPIA non è un elemento separato aggiunto a posteriori. Diventa la fase di valutazione più approfondita per un rischio già registrato nel sistema. La Policy di protezione dei dati e privacy Enterprise stabilisce:
Tutte le modifiche significative a sistemi o processi che coinvolgono dati personali (PII) devono richiedere una valutazione d’impatto sulla protezione dei dati (DPIA) documentata, riesaminata dal Responsabile della protezione dei dati (DPO).
Per il rischio residuo elevato del titolare del trattamento, la Policy di valutazione del rischio privacy e DPIA aggiunge:
[Titolare del trattamento] L’Alta direzione DEVE approvare l’accettazione del rischio privacy residuo elevato in REG04 prima che il trattamento ad alto rischio del titolare inizi o continui.
La decisione di lancio ora è tracciabile: cosa è cambiato, cosa è stato valutato, quali rischi sono stati identificati, quali controlli sono stati selezionati, chi è responsabile del trattamento del rischio, chi ha approvato il rischio residuo e quando la decisione sarà riesaminata.
Dai rischi ai controlli con Zenith Controls
La valutazione del rischio privacy ha valore solo se porta a decisioni sui controlli. Zenith Controls: la guida alla conformità trasversale di Clarysec è la guida alla conformità trasversale che mappa i controlli ISO/IEC 27001:2022 e ISO/IEC 27002:2022 ai requisiti correlati in diversi framework. Non è un insieme separato di controlli. Aiuta i team a comprendere in che modo le evidenze dei controlli supportano più obblighi.
Per la valutazione del rischio privacy, Zenith Controls evidenzia tre controlli centrali di ISO/IEC 27002:2022:
| Controllo ISO/IEC 27002:2022 | Perché è rilevante per la valutazione del rischio privacy | Esempi di evidenze |
|---|---|---|
| 5.34 Privacy e protezione dei dati personali | Fissa la governance privacy, i requisiti legali, la protezione degli interessati e le misure di sicurezza | Procedure PIMS, registrazioni DPIA, regole di gestione dei dati personali, informative privacy |
| 5.9 Inventario delle informazioni e degli altri asset associati | Assicura che l’organizzazione conosca quali asset informativi esistono, chi ne è proprietario, dove si trovano e quanto sono sensibili | Inventario degli asset, riferimenti RoPA, registrazioni di classificazione |
| 5.19 Sicurezza delle informazioni nei rapporti con i fornitori | Estende il rischio privacy a responsabili del trattamento, sub-responsabili, piattaforme cloud, fornitori di analisi e fornitori di supporto | Valutazioni dei fornitori, contratti, registrazioni di monitoraggio, piani di uscita |
Il controllo 5.34 supporta anche GDPR Article 25 e Article 32, le misure di gestione dei rischi di cibersicurezza del NIS2 Article 21, le aspettative DORA sulla gestione dei rischi ICT e gli outcome NIST CSF 2.0, come GV.OC-03 per obblighi legali, normativi, contrattuali, di privacy e relativi alle libertà civili, oltre a PR.DS-01 per la protezione dei dati a riposo.
Lo Step 13 di Zenith Blueprint collega queste decisioni alla Dichiarazione di Applicabilità:
Riferimenti incrociati alle normative: se determinati controlli sono implementati specificamente per conformarsi a GDPR, NIS2 o DORA, è possibile annotarlo nel Registro dei rischi (come parte della giustificazione dell’impatto del rischio) oppure nelle note della SoA.
È così che una risultanza privacy diventa una decisione sui controlli del SGSI e del PIMS, non solo un commento legale.
Il rischio di fornitori e responsabili del trattamento deve essere valutato prima dell’approvazione
Molte carenze privacy nascono nella governance dei fornitori. Un responsabile del trattamento aggiunge un nuovo sub-responsabile. Un fornitore di supporto ottiene accesso all’ambiente di produzione. Una piattaforma di analisi archivia dati sugli eventi in una nuova regione. L’approvvigionamento firma il contratto prima che la funzione privacy valuti il rischio.
La Policy di gestione privacy di responsabili, sub-responsabili e terze parti Enterprise di Clarysec lo previene collegando riesame dei fornitori, REG04 e registro delle terze parti:
[Entrambi] Il Responsabile privacy / Responsabile del PIMS DEVE attivare lo screening del rischio privacy e della DPIA in REG04 per rapporti con responsabili del trattamento ad alto rischio e modifiche sostanziali privacy relative a terze parti prima dell’approvazione, con il riferimento REG04 registrato in REG08.
Per le PMI, la Policy di sicurezza di terze parti e fornitori stabilisce il requisito di riesame prima dell’incarico:
Prima dell’incarico, ogni fornitore deve essere riesaminato per i potenziali rischi. Tale riesame deve includere:
Il messaggio operativo è chiaro. Il rischio del fornitore viene valutato prima dell’approvazione, non dopo la firma.
Questo supporta anche NIS2 e DORA. NIS2 Article 21 richiede la sicurezza della catena di fornitura come parte delle misure di gestione dei rischi di cibersicurezza. DORA Articles 28 to 30 richiedono agli enti finanziari di gestire il rischio ICT di terze parti, effettuare valutazioni precontrattuali, mantenere misure di sicurezza contrattuali, comprendere il rischio di subappalto, monitorare le dipendenze e pianificare l’uscita per funzioni essenziali o importanti.
Se un fornitore tratta dati personali o supporta un trattamento critico per la privacy, la registrazione del rischio privacy dovrebbe mostrare fornitore, ruolo nel trattamento, ubicazione dei dati, dipendenza da sub-responsabili, misure contrattuali, impegni sugli incidenti, regole di conservazione, approccio di monitoraggio e piano di uscita.
Un processo, molti esiti di conformità
Il vantaggio di un processo PIMS integrato è che le stesse evidenze supportano più framework senza duplicare il lavoro.
| Area di obbligo | Cosa dovrebbe mostrare il processo del rischio privacy | Ancora Clarysec |
|---|---|---|
| Accountability GDPR | Finalità del trattamento, base giuridica, categorie di dati, rischio per gli interessati, decisione DPIA, controlli, approvazione del rischio residuo | REG02, REG04, Policy di protezione dei dati e privacy |
| PIMS ISO/IEC 27701:2025 | Governance privacy sensibile ai ruoli per contesti di titolare del trattamento, responsabile del trattamento, contitolare del trattamento e sub-responsabile | Policy di valutazione del rischio privacy e DPIA |
| SGSI ISO/IEC 27001:2022 | Criteri di rischio, valutazione del rischio, piano di trattamento del rischio, Dichiarazione di Applicabilità, evidenze conservate | Policy di gestione del rischio, Risk Register and SoA Builder |
| NIS2 | Gestione del rischio di cibersicurezza, sicurezza della catena di fornitura, gestione degli incidenti, responsabilità della direzione | Mappature Zenith Controls verso 5.34, 5.9, 5.19 e controlli dell’Allegato A correlati |
| DORA | Gestione del rischio ICT, registro delle terze parti, mappatura delle dipendenze critiche, processo di gestione degli incidenti, pianificazione dell’uscita | Policy di gestione privacy di responsabili, sub-responsabili e terze parti |
| NIST CSF 2.0 | Profili attuali e target, outcome di governance, registro dei rischi o POA&M, outcome del rischio dei fornitori | Passi di gestione del rischio di Zenith Blueprint |
| COBIT 19 e assurance ISACA | Titolarità della governance, progettazione dei controlli, monitoraggio delle prestazioni, reportistica direzionale, remediation degli issue | Riesame trimestrale ed evidenze di audit interno privacy |
NIST CSF 2.0 è particolarmente utile per la comunicazione con la direzione esecutiva. La sua funzione GOVERN copre contesto organizzativo, strategia di gestione del rischio, policy, ruoli, supervisione e rischio della catena di fornitura. I suoi Profili organizzativi aiutano a tradurre outcome attuali e target in un piano d’azione prioritizzato, come un registro dei rischi o un piano d’azione e milestone.
Per le organizzazioni soggette a NIS2, DORA o regole settoriali, le evidenze del rischio privacy supportano anche governance della cibersicurezza, vigilanza sui fornitori, preparazione agli incidenti e reportistica sulla resilienza.
Il trattamento del rischio privacy va oltre la cifratura
La cifratura è importante, ma non può correggere una base giuridica non valida, una raccolta eccessiva, una profilazione non comunicata, un trattamento scorretto, una conservazione illecita o un responsabile del trattamento che opera al di fuori delle istruzioni.
La Policy di protezione dei dati e privacy per PMI stabilisce:
Devono essere implementati controlli per ridurre i rischi identificati, inclusi cifratura, anonimizzazione, smaltimento sicuro e restrizioni di accesso
Sono esempi validi, ma il trattamento deve essere coerente con lo scenario. Un piano di trattamento del rischio privacy può includere il restringimento della finalità del trattamento, la rimozione di categorie di dati non necessarie, l’aggregazione o la pseudonimizzazione dei dati, l’aggiornamento delle informative, la modifica della base giuridica ove opportuno, la limitazione della conservazione, la restrizione degli accessi, l’aggiunta di registrazione, l’aggiornamento dei contratti, il completamento di una DPIA, il rinvio del lancio o il rifiuto di un trattamento che resta inaccettabile.
La Policy di gestione del rischio Enterprise rafforza la pianificazione del trattamento per i rischi oltre la tolleranza:
Tutti i rischi classificati al di sopra del livello di tolleranza devono avere un Piano di trattamento del rischio associato che specifichi:
In pratica, ciò significa che un rischio privacy elevato non può essere accettato per silenzio. Deve essere trattato, trasferito ove appropriato, evitato oppure formalmente accettato dal responsabile ultimo appropriato.
I trigger di riesame mantengono viva la valutazione
Una valutazione del rischio privacy mai riesaminata diventa evidenza obsoleta. Le clausole 8.2 e 8.3 di ISO/IEC 27001:2022 richiedono valutazione e trattamento del rischio a intervalli pianificati o quando si verificano cambiamenti significativi. L’accountability GDPR richiede decisioni aggiornate. ISO/IEC 27701:2025 dipende da monitoraggio e miglioramento continuo.
Una valutazione REG04 dovrebbe essere riaperta quando cambia la finalità, vengono aggiunte nuove categorie di dati, sono coinvolti dati appartenenti a categorie particolari, cambia la base giuridica, cambia un responsabile del trattamento o sub-responsabile, l’archiviazione si sposta in una nuova regione, cambiano i periodi di conservazione, cambia la logica di profilazione, si verifica una violazione o un near miss, cambiano i contratti con i clienti oppure si applica un nuovo obbligo NIS2, DORA o settoriale.
I processi di gestione degli incidenti dovrebbero rialimentare il processo del rischio privacy. NIS2 Article 23 stabilisce una segnalazione per fasi degli incidenti significativi. DORA Articles 17 to 20 richiedono registrazione, classificazione, escalation, comunicazione, analisi della causa radice e miglioramento per gli incidenti connessi alle ICT. Possono attivarsi anche gli obblighi GDPR relativi alle violazioni dei dati personali. Se un incidente rivela controlli di accesso deboli, conservazione eccessiva, notifica dei fornitori non chiara o istruzioni del cliente carenti, REG04 deve essere aggiornato.
Cosa si aspettano di vedere gli auditor
Un solido processo di gestione del rischio privacy dovrebbe resistere a più prospettive di assurance.
| Prospettiva dell’auditor | Richiesta probabile di evidenze | Aspetto atteso |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | Ambito di applicazione del SGSI, metodo di rischio, registro dei rischi, SoA, piani di trattamento del rischio, evidenze operative | I rischi privacy usano criteri approvati, sono collegati ai controlli dell’Allegato A, hanno responsabili e sono riesaminati dopo i cambiamenti |
| Auditor PIMS ISO/IEC 27701:2025 | Inventario dei dati personali, contesto dei ruoli, screening privacy, registrazioni DPIA, evidenze del titolare e del responsabile del trattamento | REG02 e REG04 mostrano come il trattamento viene sottoposto a screening, classificato, trattato, approvato e riesaminato |
| Revisore focalizzato sul GDPR | Base giuridica, trasparenza, motivazione DPIA, contratti con i responsabili del trattamento, decisioni sulle violazioni, impatto sui diritti degli interessati | L’organizzazione può dimostrare un trattamento lecito, corretto, necessario, proporzionato e controllato |
| Valutatore NIST CSF | Profili attuali e target, outcome di governance, registro dei rischi, outcome del rischio dei fornitori | I rischi privacy e cyber sono comunicati attraverso il linguaggio del rischio aziendale e piani prioritizzati |
| Team di assurance DORA | Quadro di riferimento del rischio ICT, registro delle terze parti, mappatura delle funzioni critiche, processo di gestione degli incidenti, strategie di uscita | Le dipendenze ICT rilevanti per la privacy sono visibili, contrattualizzate, monitorate, testate e collegate alla resilienza |
| Auditor COBIT 19 o ISACA | Titolarità della governance, progettazione dei controlli, reportistica, remediation degli issue | Le decisioni sul rischio privacy sono di competenza dell’attività e degli organi di gestione, non nascoste in silos legali o IT |
La Policy di protezione dei dati e privacy Enterprise richiede anche attività di audit interno:
Un audit interno di conformità privacy deve essere svolto annualmente o in occasione di modifiche organizzative o normative rilevanti. L’ambito dell’audit deve includere:
Questo crea un ciclo di feedback per la direzione. Le registrazioni REG02 sono complete? Gli screening REG04 sono tempestivi? Le DPIA sono svolte quando richiesto? I rischi residui elevati sono approvati? Le modifiche dei fornitori sono acquisite? I piani di trattamento del rischio sono chiusi? Le informative sono allineate al trattamento effettivo?
Checklist per la prossima riunione sui cambiamenti privacy
Usa questa checklist prima che una nuova attività di trattamento, funzionalità di prodotto, fornitore, modello o processo di supporto entri in esercizio.
| Domanda | Se la risposta è sì, registra questo |
|---|---|
| Si tratta di un trattamento di dati personali nuovo o modificato in modo sostanziale? | Apri o aggiorna REG02 e attiva lo screening REG04 |
| Cambiano finalità, base giuridica, categoria di dati, conservazione o destinatario? | Aggiorna l’inventario dei trattamenti e le evidenze della base giuridica |
| Il trattamento potrebbe creare un rischio elevato per gli interessati? | Classifica il rischio privacy intrinseco e documenta la motivazione |
| Sono coinvolti profilazione, monitoraggio su larga scala, dati appartenenti a categorie particolari o persone vulnerabili? | Valuta se è richiesta una DPIA |
| È coinvolto un nuovo responsabile del trattamento, sub-responsabile, servizio cloud o fornitore di supporto? | Attiva il riesame privacy e sicurezza del fornitore |
| Sono richiesti controlli prima del lancio? | Crea un piano di trattamento del rischio con responsabile e data di scadenza |
| Il rischio residuo resta oltre la tolleranza? | Effettua l’escalation per l’approvazione prima che il trattamento inizi o continui |
| Cambieranno informative privacy, contratti o istruzioni del cliente? | Assegna gli aggiornamenti legali e rivolti al cliente |
| Cosa attiverà la rivalutazione? | Imposta data di riesame e trigger di cambiamento in REG04 |
Questa checklist non sostituisce la policy. È un modo pratico per rendere operativa la policy nelle riunioni di prodotto, approvvigionamento, ingegneria, compliance, legale e leadership.
Trasforma l’accountability privacy in un sistema operativo
ISO/IEC 27701:2025 e l’accountability GDPR richiedono più di documenti. Richiedono un sistema operativo che colleghi registrazioni dei trattamenti, base giuridica, rischio privacy, decisioni DPIA, fornitori, controlli, responsabili, approvazioni ed evidenze.
Parti dalla fase di Gestione del rischio di Zenith Blueprint, in particolare dagli Step 9 a 13. Usa il Risk Register and SoA Builder per collegare asset, minacce, vulnerabilità, rischi privacy, decisioni di trattamento del rischio e riferimenti ai controlli. Poi usa Zenith Controls per mappare protezione dei dati personali, inventario degli asset e sicurezza dei fornitori su aspettative di assurance GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 e COBIT 19.
Allinea le policy operative che rendono applicabile il processo: Policy di valutazione del rischio privacy e DPIA, Policy sull’inventario dei trattamenti di dati personali e sulla base giuridica, Policy di gestione privacy di responsabili, sub-responsabili e terze parti, Policy di gestione del rischio e Policy di protezione dei dati e privacy. I team più piccoli possono usare anche le policy PMI di Clarysec, mentre le organizzazioni più grandi possono strutturare la governance tramite le policy Enterprise.
Se il tuo team sta lanciando un nuovo trattamento, cambiando fornitori, preparandosi a ISO/IEC 27701:2025 o cercando di rendere ripetibili le evidenze di accountability GDPR, inizia da una singola attività di trattamento in esercizio. Apri REG02, esegui lo screening REG04, mappa i rischi sui controlli, assegna i responsabili del trattamento del rischio e riesamina il rischio residuo con il decisore appropriato.
Quel singolo processo è il punto in cui la governance privacy diventa operativa.
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