Governance delle DPIA per ISO 27001, NIS2 e DORA
Sono le 17:40 di un giovedì e a Maria, CISO di una fintech in rapida crescita, viene chiesto di approvare un rilascio prima della chiusura del trimestre.
Il team di prodotto lo presenta come un salto di qualità: una funzionalità di autenticazione dei pagamenti basata su biometria e analisi comportamentale, progettata per rendere più fluido l’accesso dei clienti e ridurre le frodi. Il team di sviluppo sostiene che non verrà creato alcun nuovo database principale. Il team commerciale segnala che un cliente finanziario regolamentato è in attesa. Il responsabile del rilascio ha già classificato il ticket come modifica standard.
Poi il DPO pone tre domande.
La funzionalità combinerà dati biometrici o comportamentali con attributi dell’account? Un sub-responsabile cloud riceverà telemetria o segnali di autenticazione? Qualcuno ha valutato se la modifica genera un rischio elevato per le persone fisiche?
La sala resta in silenzio.
Maria dispone di un registro dei rischi ISO/IEC 27001:2022. Legal ha un registro delle attività di trattamento GDPR. Procurement ha un questionario fornitore. Il team cloud ha un riesame di sicurezza del provider. Il responsabile delle modifiche ha un ticket. Il consiglio di amministrazione è appena stato informato sulle aspettative di accountability NIS2 e di resilienza operativa DORA.
Nessuna di queste registrazioni, da sola, racconta l’intera storia.
Questo è il problema della governance delle DPIA nel 2026. Le valutazioni d’impatto sulla protezione dei dati non possono rimanere in una cartella privacy in attesa di un’autorità di controllo. Devono diventare registrazioni decisionali che collegano gli articoli 25, 30, 32, 35 e 36 del GDPR con le evidenze di rischio ISO/IEC 27001:2022, le misure di gestione dei rischi di cibersicurezza NIS2, la governance delle modifiche ICT DORA, l’assurance sui fornitori e l’accountability a livello di consiglio di amministrazione.
Le organizzazioni in difficoltà di norma non stanno ignorando la conformità. Stanno svolgendo separatamente il riesame privacy, il riesame di sicurezza, il riesame cloud e il riesame delle modifiche. Le organizzazioni efficaci creano un unico flusso di governance tracciabile, in cui criteri di attivazione della DPIA, valutazione del rischio, due diligence sui fornitori, mappatura dei controlli, test e approvazione del rischio residuo formano un’unica catena di evidenze.
Perché le DPIA isolate non funzionano nel 2026
Il GDPR ha introdotto la DPIA come meccanismo formale per valutare trattamenti che possono presentare un rischio elevato per le persone fisiche. In molte aziende è diventata un’attività legale o privacy: un modulo compilato quando un progetto appariva sensibile.
Quel modello non è più difendibile.
Una modifica del trattamento di dati personali raramente è solo un evento privacy. È anche:
- Un evento di rischio per la sicurezza delle informazioni ai sensi di ISO/IEC 27001:2022.
- Un evento di governance della cibersicurezza ai sensi di NIS2, se sono interessati sistemi informativi e di rete, fornitori o controlli di sicurezza.
- Un evento di modifica ICT e resilienza ai sensi di DORA per entità finanziarie e fornitori di servizi ICT rilevanti.
- Un evento di rischio fornitori e cloud quando sono coinvolti responsabili del trattamento, sub-responsabili, API, SDK o servizi ospitati.
Quando queste valutazioni avvengono separatamente, le lacune diventano pericolose. Un team privacy può approvare una DPIA senza comprendere le vulnerabilità di un SDK biometrico. Un team IT può rilasciare una modifica senza rendersi conto che coinvolge categorie particolari di dati o monitoraggio comportamentale. Un team di sicurezza può riesaminare un servizio cloud senza collegarlo agli specifici rischi per i diritti e le libertà individuati nella DPIA.
La risposta non è produrre più documenti. La risposta è una governance integrata.
Una DPIA deve essere trattata come il criterio di attivazione di un flusso coordinato di gestione del rischio tra privacy, sicurezza, cloud, fornitori, sviluppo, legal e direzione.
La base GDPR: la governance delle DPIA parte dalla consapevolezza del trattamento
Una DPIA non può essere credibile se l’organizzazione non sa spiegare quali dati tratta, perché li tratta, chi li riceve e per quanto tempo vengono conservati.
L’accountability GDPR richiede più di una dichiarazione d’intenti. L’articolo 5 stabilisce principi fondamentali quali liceità, correttezza, trasparenza, limitazione delle finalità, minimizzazione dei dati, esattezza, limitazione della conservazione, integrità e riservatezza. Richiede inoltre al titolare del trattamento di dimostrare la conformità. L’articolo 25 richiede privacy by design e privacy by default. L’articolo 30 richiede registri delle attività di trattamento. L’articolo 32 richiede la sicurezza del trattamento. L’articolo 35 richiede una DPIA quando il trattamento può presentare un rischio elevato. L’articolo 36 richiede la consultazione preventiva quando il rischio elevato permane in assenza di misure di mitigazione sufficienti.
Per organizzazioni SaaS, fintech, cloud e di servizi gestiti, ciò significa che ogni modifica sostanziale deve essere sottoposta a una valutazione preliminare dell’impatto privacy. Il criterio di attivazione non è che un progetto sia etichettato come “privacy”. Il criterio di attivazione è che la modifica riguardi dati personali, finalità del trattamento, base giuridica, destinatari, conservazione, diritti di accesso, fornitori, localizzazioni cloud o rischio residuo.
La Data Protection and Privacy Policy - SME di Clarysec trasforma questo principio in un requisito operativo:
“Il coordinatore privacy deve mantenere un registro di tutte le attività di trattamento dei dati personali, incluse categorie di dati, finalità, base giuridica e periodi di conservazione.”
Dalla sezione “Requisiti di governance”, clausola 5.2.1 della policy.
La stessa policy SME integra la privacy nello sviluppo e nel rilascio:
“Privacy by design e privacy by default devono essere applicate in tutti i nuovi sistemi e servizi.”
Dalla sezione “Requisiti di governance”, clausola 5.3.1 della policy.
Per gli ambienti enterprise, la Data Protection and Privacy Policy di Clarysec rende esplicito il punto di controllo DPIA:
“Tutte le modifiche significative a sistemi o processi che coinvolgono informazioni personali (PII) devono richiedere una valutazione d’impatto sulla protezione dei dati (DPIA) documentata, riesaminata dal Responsabile della protezione dei dati (DPO).”
Dalla sezione “Requisiti di governance”, clausola 5.6 della policy.
Questa clausola è il ponte tra accountability GDPR e controllo operativo. Sposta la DPIA da un ripensamento legale alla governance di progetto e all’approvazione delle modifiche.
Collegare la DPIA alle evidenze di rischio ISO/IEC 27001:2022
ISO/IEC 27001:2022 fornisce la struttura del sistema di gestione necessaria alla governance delle DPIA.
Le clausole da 4.1 a 4.4 richiedono all’organizzazione di comprendere il proprio contesto, le parti interessate, i requisiti, il campo di applicazione del SGSI e i processi interagenti. Normative privacy, contratti con i clienti, obblighi NIS2, requisiti DORA, responsabilità dei responsabili del trattamento e dipendenze dai fornitori rientrano tutti in tale contesto.
Le clausole da 5.1 a 5.3 richiedono leadership, allineamento delle policy, risorse, ruoli e responsabilità. È qui che molte DPIA falliscono. Un DPO può individuare un rischio elevato, ma senza titolari del rischio, regole di escalation e criteri di accettazione sostenuti dalla direzione, la DPIA diventa un documento invece di una decisione.
Le clausole da 6.1.1 a 6.1.3 richiedono pianificazione basata sul rischio, un processo documentato di valutazione dei rischi per la sicurezza delle informazioni, criteri di accettazione del rischio, titolari del rischio, pianificazione del trattamento, selezione dei controlli, una Dichiarazione di Applicabilità e approvazione del rischio residuo. Questa è la struttura che una DPIA dovrebbe utilizzare.
Una DPIA può identificare impatti negativi quali rischio di profilazione, divulgazione non autorizzata, uso secondario illecito, frode d’identità, discriminazione o conservazione eccessiva. Il SGSI traduce tali impatti in scenari di rischio, analisi di probabilità e impatto, azioni di trattamento, controlli dell’Annex A e approvazioni del rischio residuo.
La Risk Management Policy - SME di Clarysec definisce la disciplina minima:
“Ogni voce di rischio deve includere: descrizione, probabilità, impatto, punteggio, titolare e piano di trattamento del rischio.”
Dalla sezione “Requisiti di governance”, clausola 5.1.2 della policy.
Per gli ambienti enterprise, la Risk Management Policy di Clarysec collega la pianificazione del trattamento alle evidenze ISO/IEC 27001:2022:
“Il responsabile del rischio deve assicurare che i trattamenti siano realistici, limitati nel tempo e mappati ai controlli dell’Annex A di ISO/IEC 27001.”
Dalla sezione “Requisiti di applicazione della policy”, clausola 6.4.2 della policy.
La Zenith Blueprint: una roadmap in 30 passi per auditor, fase Gestione del rischio, Step 13, Pianificazione del trattamento del rischio e Dichiarazione di Applicabilità, spiega chiaramente il ruolo della SoA:
“La SoA è di fatto un documento ponte: collega la valutazione/trattamento del rischio ai controlli effettivi di cui disponete.”
Questo è il modello di DPIA idoneo all’audit. Una risultanza DPIA non dovrebbe concludersi con “rischio accettato”. Dovrebbe essere mappata al registro dei rischi, al piano di trattamento del rischio, alla Dichiarazione di Applicabilità, al riesame del fornitore, alla due diligence cloud, al ticket di modifica, alle evidenze di test e alla decisione della direzione.
Una registrazione decisionale, molteplici output di conformità
Un flusso maturo di governance delle DPIA non duplica ogni normativa. Raccoglie le evidenze una sola volta e le riutilizza in modo intelligente.
| Domanda di governance DPIA | Evidenza creata | Evidenza ISO/IEC 27001:2022 | Valore per l’accountability GDPR | Valore NIS2 o DORA |
|---|---|---|---|---|
| Quale trattamento sta cambiando? | Aggiornamento del registro delle attività di trattamento e richiesta iniziale DPIA | Evidenze su ambito, contesto, asset e processo | Supporta i registri delle attività di trattamento e la privacy by design | Dimostra consapevolezza del rischio operativo |
| Che cosa potrebbe danneggiare le persone fisiche? | Scenario di rischio privacy e valutazione d’impatto | Esito della valutazione del rischio e titolare del rischio | Supporta il razionale della DPIA e l’accountability | Si allinea alla governance della cibersicurezza basata sul rischio |
| Quali controlli riducono il rischio? | Misure di sicurezza, TOM e piano di trattamento del rischio | SoA, piano di trattamento del rischio e stato di attuazione dell’Annex A | Supporta la sicurezza del trattamento e la privacy by default | Supporta misure di cibersicurezza e rischio ICT |
| Chi altro tratta o accede ai dati? | Riesame di fornitore, responsabile del trattamento e cloud | Evidenze dei controlli su fornitori e cloud | Supporta vigilanza sui responsabili del trattamento e governance dei trasferimenti | Supporta rischio della catena di fornitura e rischio ICT di terze parti |
| Che cosa è cambiato in produzione? | Registrazione della modifica, evidenze di test e approvazione | Evidenze di gestione delle modifiche e controllo operativo | Dimostra che i controlli sono stati considerati prima del rilascio | Supporta rischio di modifica e aspettative di resilienza |
| Chi ha accettato il rischio residuo? | Approvazione di DPO, titolare del rischio e direzione | Accettazione del rischio residuo e input per il riesame della direzione | Dimostra un processo decisionale responsabile | Supporta la vigilanza del consiglio o dell’organo di gestione |
Questa catena di evidenze si allinea direttamente alla clausola 8.1 di ISO/IEC 27001:2022, che richiede processi operativi pianificati e controllati, evidenze documentate, controllo delle modifiche pianificate e riesame delle modifiche non intenzionali. La clausola 8.2 richiede valutazioni del rischio a intervalli pianificati o quando vengono proposte o si verificano modifiche significative. La clausola 8.3 richiede l’attuazione del piano di trattamento del rischio. La clausola 9 trasforma poi le evidenze in assurance attraverso monitoraggio, misurazione, audit interno e riesame della direzione.
La Data Protection and Privacy Policy - SME rende esplicita la tempistica:
“Il coordinatore privacy deve valutare i rischi privacy annualmente e in occasione di modifiche rilevanti ai sistemi.”
Dalla sezione “Trattamento del rischio ed eccezioni”, clausola 7.1.1 della policy.
Se una modifica rilevante relativa a dati personali non attiva la valutazione preliminare DPIA e una rivalutazione del SGSI, il processo di governance è incompleto.
NIS2: la governance delle DPIA diventa responsabilità della direzione
NIS2 aumenta la pressione di governance sulle organizzazioni nei settori essenziali e importanti. Si applica a molte entità pubbliche e private nei settori elencati che soddisfano le soglie dimensionali rilevanti e può applicarsi indipendentemente dalla dimensione in casi specifici, quali servizi fiduciari, DNS, registri TLD, servizi pubblici di comunicazione elettronica, fornitori unici di servizi essenziali o entità con ruoli di rischio sistemico.
Per la governance delle DPIA, il punto chiave non è solo l’ambito di applicazione. È la responsabilità della direzione.
L’articolo 20 di NIS2 richiede agli organi di gestione delle entità essenziali e importanti di approvare le misure di gestione dei rischi di cibersicurezza, supervisionarne l’attuazione e seguire formazione. L’articolo 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate, basate su esposizione al rischio, dimensione, probabilità, gravità, impatto sociale ed economico, stato dell’arte e standard pertinenti.
L’articolo 21(2) include domini che spesso si sovrappongono agli esiti della DPIA, tra cui:
- Analisi dei rischi e policy di sicurezza dei sistemi informativi.
- Gestione degli incidenti.
- Continuità operativa e gestione delle crisi.
- Sicurezza della catena di fornitura.
- Sicurezza nell’acquisizione, sviluppo e manutenzione dei sistemi informativi e di rete.
- Gestione e divulgazione delle vulnerabilità.
- Policy per valutare l’efficacia delle misure di gestione dei rischi di cibersicurezza.
- Igiene cyber e formazione.
- Crittografia e cifratura.
- Sicurezza delle risorse umane, controllo degli accessi e gestione degli asset.
- MFA, autenticazione continua, comunicazioni sicure e comunicazioni di emergenza protette.
Una DPIA per una nuova attività di trattamento biometrico, di analisi comportamentale o basata su cloud dovrebbe quindi porre domande rilevanti per NIS2. Il trattamento dipende da un nuovo fornitore? Introduce una nuova API, un SDK, un flusso di identità o un modello di accesso? Modifica l’impatto degli incidenti? Richiede cifratura, logging più robusto, controlli di sviluppo sicuro o approvazione della direzione?
La domanda pratica per la direzione diventa semplice: l’organizzazione può dimostrare che una modifica con impatto privacy è stata considerata nell’ambito della gestione dei rischi di cibersicurezza prima dell’attuazione?
Questa evidenza dovrebbe essere visibile nella richiesta iniziale DPIA, nel registro delle attività di trattamento aggiornato, nel registro dei rischi, nel piano di trattamento del rischio, nella Dichiarazione di Applicabilità, nella due diligence sui fornitori, nelle evidenze dei test di sicurezza, nell’approvazione della modifica e nell’accettazione del rischio residuo.
DORA: le evidenze su modifiche ICT e terze parti sono imprescindibili
DORA si applica dal 17 gennaio 2025 e crea un quadro uniforme dell’UE per la gestione dei rischi ICT, la segnalazione dei gravi incidenti connessi all’ICT, i test di resilienza operativa digitale, la condivisione di informazioni su minacce informatiche e vulnerabilità, la gestione del rischio ICT di terze parti e la vigilanza sui fornitori terzi critici di servizi ICT.
Per le entità finanziarie, DORA opera generalmente come atto giuridico dell’Unione settoriale per la gestione dei rischi ICT e gli obblighi di segnalazione degli incidenti, mentre NIS2 resta rilevante per il coordinamento più ampio dell’ecosistema e per le entità non soggette a DORA.
La governance delle DPIA rileva ai fini DORA perché il trattamento dei dati personali di norma risiede all’interno di sistemi ICT, servizi di terze parti, ambienti cloud e flussi operativi.
L’articolo 5 di DORA richiede quadri interni di governance e controllo per la gestione dei rischi ICT, con responsabilità dell’organo di gestione. L’articolo 6 richiede un quadro di gestione dei rischi ICT documentato e integrato nella gestione complessiva del rischio. Gli articoli da 8 a 14 coprono identificazione di asset e dipendenze, protezione e prevenzione, rilevazione, continuità, backup, ripristino, lezioni apprese e comunicazioni di crisi.
L’articolo 28 di DORA richiede alle entità finanziarie di gestire il rischio ICT di terze parti come parte integrante della gestione dei rischi ICT e di restare responsabili quando utilizzano servizi ICT. Richiede registri dei contratti di servizi ICT, valutazioni precontrattuali, due diligence, valutazione del rischio di concentrazione, pianificazione di audit e ispezioni, diritti di risoluzione e strategie di uscita. L’articolo 30 richiede contratti scritti con descrizioni chiare dei servizi, localizzazione dei dati, protezioni di riservatezza, integrità e disponibilità, ripristino e restituzione dei dati, assistenza sugli incidenti, cooperazione con le autorità, diritti di risoluzione e ulteriori misure di sicurezza per funzioni critiche o importanti.
Per una DPIA, questo cambia la domanda sul fornitore. “Abbiamo un DPA?” non basta. La domanda migliore è: possiamo dimostrare che dipendenza ICT, localizzazione dei dati, subappalto, standard di sicurezza, resilienza, diritti di audit, supporto sugli incidenti e strategia di uscita sono stati valutati prima dell’approvazione del trattamento?
La Cloud Usage Policy di Clarysec rende esplicito questo controllo pre-attivazione:
“Ogni uso del cloud deve essere sottoposto a due diligence basata sul rischio prima dell’attivazione, incluse valutazione del provider, validazione della conformità legale e convalida dei controlli.”
Dalla sezione “Requisiti di governance”, clausola 5.2 della policy.
Una DPIA non dovrebbe approvare un nuovo responsabile del trattamento per analytics, un provider di identità, un SDK biometrico o una piattaforma di telemetria cloud, salvo che la due diligence cloud, la validazione legale e la convalida dei controlli siano completate o esplicitamente tracciate come azioni di trattamento.
Gli ancoraggi ISO/IEC 27002:2022: privacy, progetti e modifiche
La Zenith Controls: la guida cross-compliance di Clarysec tratta i controlli ISO/IEC 27002:2022 come ancoraggi cross-compliance. Per la governance delle DPIA, tre controlli sono particolarmente importanti.
| Controllo ISO/IEC 27002:2022 | Perché conta per la governance delle DPIA | Valore cross-compliance |
|---|---|---|
| 5.34 Privacy e protezione delle PII | Richiede consapevolezza e protezione dei dati personali lungo il relativo ciclo di vita | Supporta accountability GDPR, Annex A ISO/IEC 27001:2022, misure di rischio NIS2 e aspettative DORA di protezione dei dati |
| 5.8 Sicurezza delle informazioni nella gestione dei progetti | Integra il ragionamento su sicurezza e impatto privacy nella progettazione dei progetti | Supporta privacy by design, sviluppo sicuro, misure NIS2 di acquisizione e sviluppo |
| 8.32 Gestione delle modifiche | Assicura che le modifiche siano valutate, autorizzate, testate, attuate e riesaminate | Supporta il controllo operativo ISO, la governance delle modifiche ICT DORA e la tracciabilità di audit |
La voce Zenith Controls per 5.34, Privacy e protezione delle PII, la classifica come preventiva, associata a riservatezza, integrità e disponibilità, allineata ai concetti di cibersicurezza Identify e Protect e collegata alla protezione delle informazioni oltre che alle capacità legali e di conformità.
La Zenith Blueprint, fase Controlli in azione, Step 23, chiarisce il punto pratico:
“La base di questo controllo è la consapevolezza dei dati. L’organizzazione deve sapere quali PII raccoglie, dove risiedono, perché vengono trattate e chi può accedervi.”
La voce Zenith Controls per 5.8, Sicurezza delle informazioni nella gestione dei progetti, la classifica come preventiva, associata a riservatezza, integrità e disponibilità, allineata a Identify e Protect e collocata nei domini governance, ecosistema e protezione.
La Zenith Blueprint, fase Controlli in azione, Step 22, afferma:
“L’obiettivo di questo controllo non è appesantire i progetti con burocrazia. È assicurare che la sicurezza sia trattata come input di progettazione, non come fase di test.”
La privacy deve essere trattata nello stesso modo. Una DPIA dopo la messa in esercizio è spesso un rapporto sui danni. Una DPIA durante la progettazione è prevenzione del rischio.
La voce Zenith Controls per 8.32, Gestione delle modifiche, la classifica come preventiva, associata a riservatezza, integrità e disponibilità, allineata a Protect e collegata alle capacità di sicurezza delle applicazioni e di sicurezza di sistemi e reti.
La Zenith Blueprint, fase Controlli in azione, Step 21, è diretta:
“Il cambiamento è inevitabile, ma in cibersicurezza una modifica non controllata è pericolosa.”
La Change Management Policy - SME di Clarysec descrive il criterio di attivazione:
“Se una modifica coinvolge dati sensibili, diritti di accesso ai sistemi o integrazioni esterne, è richiesto un riesame dell’impatto sulla sicurezza. Il referente designato per sicurezza o conformità deve valutare se la modifica introduce rischi aggiuntivi e raccomandare ulteriori misure di sicurezza.”
Dalla sezione “Trattamento del rischio ed eccezioni”, clausola 7.5.1 della policy.
Per gli ambienti enterprise, la Change Management Policy di Clarysec definisce l’aspettativa del Change Advisory Board:
“Valutare le modifiche per rischi di sicurezza e conformità prima dell’approvazione del Change Advisory Board.”
Dalla sezione “Ruoli e responsabilità”, clausola 4.6.1 della policy.
Esempio pratico: approvare una funzionalità di analytics biometrica
Maria non ha bisogno di tre progetti di governance separati. Ha bisogno di un’unica richiesta iniziale di progetto integrata e di un flusso di gestione del rischio.
Il team di prodotto propone l’autenticazione biometrica dei pagamenti con analisi comportamentale. La funzionalità raccoglie template biometrici, metadati del dispositivo, attributi dell’account, indirizzi IP, eventi di autenticazione e segnali antifrode. Utilizza un provider cloud di analytics e un SDK biometrico di terze parti. I team di customer success riceveranno accesso aggregato a una dashboard.
Il ticket di modifica dovrebbe attivare una valutazione preliminare DPIA e una valutazione del rischio prima dell’allocazione delle risorse o dell’approvazione del CAB.
| Campo della richiesta iniziale | Risposta di esempio |
|---|---|
| Dati personali coinvolti | Template biometrico, ID utente, indirizzo IP, metadati del dispositivo, ruolo dell’account, eventi di autenticazione |
| Finalità del trattamento | Autenticazione dei pagamenti, rilevamento delle frodi e analytics per customer success |
| Base giuridica da confermare | Necessità contrattuale, legittimo interesse o consenso esplicito, soggetti a riesame del DPO |
| Nuovo fornitore o servizio cloud | Provider di SDK biometrico e responsabile del trattamento cloud analytics in regione UE |
| Dati sensibili o categorie particolari di dati | I dati biometrici richiedono un riesame ad alto rischio quando utilizzati per l’identificazione univoca |
| Modifica del modello di accesso | Il team customer success riceve accesso aggregato alla dashboard |
| Modifica della conservazione | Log degli eventi conservati per 180 giorni, template biometrici conservati secondo le condizioni del servizio |
| DPIA richiesta | Sì, trattamento biometrico, monitoraggio e nuova dipendenza da fornitore richiedono riesame |
La valutazione integrata dovrebbe quindi produrre un unico dossier di rischio.
| Sezione della valutazione | Quadro di riferimento principale | Domande a cui rispondere | Evidenza o output |
|---|---|---|---|
| Descrizione del trattamento | GDPR articolo 35 | Quali dati sono trattati, perché, da chi e per quanto tempo? | Flusso di dati, aggiornamento RoPA, richiesta iniziale DPIA |
| Necessità e proporzionalità | GDPR articolo 35 | Il trattamento è necessario ed è l’approccio praticabile meno invasivo? | Riesame del DPO e giustificazione |
| Rischio per le persone fisiche | GDPR articolo 35 | Le persone fisiche potrebbero subire furto d’identità, discriminazione, profilazione, esclusione o danno finanziario? | Analisi del rischio DPIA e voce nel registro dei rischi ISO |
| Valutazione del rischio di sicurezza | ISO/IEC 27001:2022 clausola 6.1.2 | Quali minacce a riservatezza, integrità e disponibilità esistono? | Voci nel registro dei rischi con probabilità, impatto, titolare e trattamento |
| Analisi dell’impatto NIS2 | NIS2 articolo 21 | La modifica incide su fornitori, sviluppo sicuro, controllo degli accessi, gestione degli incidenti o continuità? | Valutazione del fornitore, checklist di sviluppo sicuro, evidenze della direzione |
| Analisi della resilienza DORA | DORA articoli 8, 9, 24 e 30 | Si tratta di una modifica ICT che incide su resilienza, test o obblighi contrattuali? | Registrazione della modifica, piano di test, riesame contrattuale ed evidenze di uscita |
| Trattamento del rischio e controlli | ISO/IEC 27001:2022 clausola 6.1.3 | Quali TOM e controlli dell’Annex A riducono il rischio? | Piano di trattamento del rischio e Dichiarazione di Applicabilità aggiornata |
Esempi di voci di rischio potrebbero essere i seguenti:
| Scenario di rischio | Probabilità | Impatto | Esempi di trattamento | Mappatura dei controlli |
|---|---|---|---|---|
| Raccolta eccessiva oltre la finalità dichiarata | Media | Alto | Riesame della minimizzazione dei dati, approvazione dello schema eventi, limite di conservazione | 5.34, 5.31, 8.10 |
| Accesso non autorizzato alla dashboard biometrica o comportamentale | Media | Alto | Accesso basato sui ruoli, MFA, logging, riesame trimestrale degli accessi | 5.15, 5.18, 8.15, 8.16 |
| Errata configurazione del responsabile cloud che espone la telemetria | Bassa | Alto | Due diligence cloud, cifratura, baseline di configurazione, monitoraggio | 5.23, 8.9, 8.24, 8.16 |
| Vulnerabilità dell’SDK biometrico che compromette i dati di autenticazione | Media | Alto | Due diligence sui fornitori, riesame dello sviluppo sicuro, test di sicurezza | 5.21, 8.25, 8.28, 8.29 |
| Profilazione che genera impatti non equi sui clienti | Media | Alto | Riesame del DPO, informativa trasparente, gestione dell’opposizione ove applicabile | 5.34, 5.8 |
Prima del rilascio, la registrazione della modifica dovrebbe contenere il completamento della DPIA o un piano di trattamento del rischio approvato dal DPO, il registro delle attività di trattamento aggiornato, la due diligence su fornitori e cloud, il riesame dell’impatto sulla sicurezza, i risultati dei test, il piano di rollback, il piano di monitoraggio e l’approvazione del rischio residuo.
Dopo il rilascio, il titolare dovrebbe verificare log, allerte, ruoli di accesso, dashboard, regole di conservazione e flussi di cancellazione. Ciò chiude il ciclo della modifica pianificata ai sensi della clausola 8.1 di ISO/IEC 27001:2022 e supporta la disciplina di resilienza operativa in stile DORA.
Che cosa chiederanno gli auditor
Una DPIA unificata offre ai diversi auditor un’unica traccia di evidenze coerente.
| Prospettiva dell’auditor | Probabile focus dell’audit | Evidenze che dovrebbero esistere |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | Se modifiche significative hanno attivato valutazione del rischio, trattamento, aggiornamenti SoA e controllo operativo | Richiesta iniziale DPIA, registro dei rischi, piano di trattamento del rischio, note SoA, registrazione della modifica, traccia di audit interno |
| Revisore privacy GDPR | Se il trattamento ad alto rischio è stato valutato prima del deployment e le misure di sicurezza sono state documentate | DPIA, registro delle attività di trattamento, analisi della base giuridica, riesame del DPO, evidenze di trasparenza e conservazione |
| Auditor orientato a NIS2 | Se le misure di rischio approvate dalla direzione coprono policy di sicurezza, catena di fornitura, gestione degli incidenti, continuità, accessi, cifratura e gestione delle vulnerabilità | Registrazioni del consiglio o del riesame della direzione, mappatura dei controlli, riesame del fornitore, collegamento con incidenti e continuità |
| Auditor orientato a DORA | Se modifica ICT, dipendenza da terze parti, resilienza, test ed evidenze contrattuali sono integrati nella governance dei rischi ICT | Valutazione del rischio ICT, registro dei provider, clausole contrattuali, evidenze di test, piano di uscita, evidenze di supporto agli incidenti |
| Valutatore NIST CSF | Se governance, rischio, asset, fornitore, protezione, rilevazione, risposta e ripristino sono collegati | Profilo attuale e target, piano delle lacune, inventario degli asset, registrazioni del rischio dei fornitori, evidenze di monitoraggio e risposta |
| Auditor COBIT 2019 o ISACA | Se abilitazione delle modifiche, gestione del rischio, servizi di sicurezza e pratiche di assurance sono controllati | Registrazioni CAB, analisi d’impatto, approvazioni, test, segregazione dei compiti, riesame post-modifica |
NIST CSF 2.0 è utile come livello di comunicazione perché la sua funzione GOVERN pone al centro strategia, aspettative, policy, ruoli, vigilanza e gestione del rischio della catena di fornitura. COBIT 2019 aggiunge assurance di processo, in particolare su abilitazione strutturata delle modifiche, analisi d’impatto, approvazioni, test e valutazione post-modifica.
Un’autorità GDPR può partire dai diritti e dalle libertà delle persone fisiche. Un auditor ISO può partire dalla valutazione del rischio documentata e dall’attuazione dei controlli. Un revisore DORA può partire dalla dipendenza ICT e dalla resilienza. Un revisore NIS2 può partire dalla vigilanza della direzione e da misure di cibersicurezza proporzionate.
La stessa catena di evidenze DPIA dovrebbe soddisfarli tutti.
Le decisioni DPIA devono reggere agli incidenti
Una DPIA non è solo un artefatto di approvazione pre-rilascio. Dovrebbe migliorare la preparazione a violazioni e incidenti.
Il GDPR definisce una violazione dei dati personali come una violazione della sicurezza che comporta accidentalmente o in modo illecito la distruzione, perdita, modifica, divulgazione non autorizzata o accesso non autorizzato ai dati personali. NIS2 richiede la notifica degli incidenti significativi senza indebito ritardo, inclusi un allarme precoce entro 24 ore, una notifica entro 72 ore e un rapporto finale non oltre un mese dalla notifica dell’incidente. DORA richiede alle entità finanziarie di rilevare, gestire, registrare, classificare, segnalare tramite escalation e notificare i gravi incidenti connessi all’ICT mediante segnalazioni iniziali, intermedie e finali, con notifica ai clienti quando sono interessati gli interessi finanziari.
Se la DPIA ha registrato flussi di dati, responsabili del trattamento, controlli di accesso, conservazione, logging, cifratura, pseudonimizzazione e responsabilità sugli incidenti, il team di risposta agli incidenti può rispondere più rapidamente a domande critiche. Quali dati personali sono stati coinvolti? Quali sistemi e fornitori sono stati interessati? Quali persone fisiche o clienti potrebbero subire un impatto? La cifratura era attiva? Quali log sono disponibili? Quali termini di segnalazione si applicano? Quali comunicazioni a clienti o autorità di controllo sono richieste?
Per questo la governance delle DPIA dovrebbe collegarsi ai controlli sugli incidenti ISO/IEC 27001:2022, ai controlli di continuità operativa e ai controlli di prontezza ICT per la continuità operativa, oltre che alle aspettative NIS2 e DORA sul ciclo di vita degli incidenti.
Errori comuni nella governance delle DPIA
Gli errori sono di norma causati da flussi scollegati, non da mancanza di impegno.
| Errore | Perché crea rischio | Pratica migliore |
|---|---|---|
| Registro delle attività di trattamento aggiornato dopo la messa in esercizio | Il registro diventa un inventario storico invece di un controllo di progettazione | Aggiornare il RoPA prima dell’approvazione |
| Valutazione preliminare DPIA assente dalla richiesta iniziale di modifica | Il rischio privacy viene scoperto troppo tardi | Aggiungere domande obbligatorie su dati personali, fornitore, accesso e conservazione |
| I rischi DPIA restano in una cartella privacy | Il trattamento di sicurezza e l’approvazione del rischio residuo non sono tracciabili | Convertire le risultanze DPIA in voci del registro dei rischi del SGSI |
| I riesami dei fornitori si concentrano solo sui questionari | Finalità del trattamento, localizzazione dei dati, sub-responsabili, diritti di audit e uscita possono essere trascurati | Combinare due diligence di sicurezza, privacy, legale e resilienza |
| La SoA non contiene razionale privacy e cloud | Gli auditor vedono i controlli ma non la logica di rischio | Mappare i controlli alle risultanze DPIA e agli obblighi GDPR, NIS2 e DORA |
| Il rischio residuo è accettato informalmente | L’accountability della direzione non è dimostrabile | Registrare approvazione di DPO, titolare del rischio e direzione con condizioni |
Checklist per la governance delle DPIA
Utilizzare questa checklist per integrare le DPIA nel SGSI, nella preparazione a NIS2 e nella governance delle modifiche ICT DORA.
| Attività di governance | Titolare | Evidenza minima |
|---|---|---|
| Valutazione preliminare DPIA integrata nella richiesta iniziale di progetto e modifica | Responsabile delle modifiche e DPO | Modulo di richiesta iniziale, decisione sul criterio di attivazione e razionale |
| Registro delle attività di trattamento aggiornato prima dell’approvazione | Coordinatore privacy o DPO | Finalità, base giuridica, categorie di dati, conservazione e destinatari |
| Rischi privacy tradotti in rischi del SGSI | Responsabile del rischio e proprietario del sistema | Voci di rischio con probabilità, impatto, titolare e piano di trattamento del rischio |
| Controlli mappati alla SoA | Responsabile del SGSI | Controlli Annex A applicabili, giustificazione e stato di attuazione |
| Due diligence su fornitori e cloud completata | Procurement, sicurezza e legal | Valutazione del provider, clausole contrattuali, localizzazione dei dati ed evidenze di uscita |
| Test di sicurezza e privacy completati | Sviluppo e sicurezza | Risultati dei test, riesame degli accessi, convalida del logging ed evidenze di vulnerabilità |
| Rischio residuo accettato | Titolare del rischio, DPO e direzione ove richiesto | Registrazione dell’approvazione, condizioni e data di riesame |
| Riesame post-modifica eseguito | Responsabile della modifica e proprietario del servizio | Note di riesame, incidenti, metriche e azioni correttive |
Questa non è burocrazia. È accountability operativa. Aiuta il CISO a dimostrare che la sicurezza è stata considerata, il DPO a dimostrare che il rischio privacy è stato valutato, il Compliance Manager a dimostrare che i controlli sono mappati tra quadri di riferimento e il titolare dell’attività a dimostrare che l’innovazione è stata governata responsabilmente.
Come aiuta Clarysec
L’approccio di Clarysec è progettato per organizzazioni che affrontano obblighi 2026 sovrapposti ed evidenze frammentate.
Il toolkit di policy fornisce il linguaggio di governance. La Data Protection and Privacy Policy definisce quando le DPIA sono richieste e chi le riesamina. La Risk Management Policy definisce come le voci di rischio devono essere strutturate e mappate. La Change Management Policy assicura che gli impatti privacy e sicurezza siano valutati prima dell’approvazione. La Cloud Usage Policy richiede due diligence prima dell’attivazione cloud.
La Zenith Blueprint fornisce la roadmap di attuazione. Lo Step 13 trasforma il trattamento del rischio e la Dichiarazione di Applicabilità in un ponte cross-compliance. Lo Step 22 integra la sicurezza nella gestione dei progetti. Lo Step 21 rende il cambiamento intenzionale, giustificato e verificabile. Lo Step 23 trasforma la protezione delle PII in un controllo di ciclo di vita basato su consapevolezza dei dati, uso lecito, restrizione degli accessi, vigilanza sui fornitori e processi operativi privacy.
La guida Zenith Controls fornisce la bussola cross-compliance. Per la governance delle DPIA, i controlli ISO/IEC 27002:2022 5.34, 5.8 e 8.32 collegano protezione privacy, governance di progetto e controllo delle modifiche ad accountability GDPR, misure di cibersicurezza NIS2, governance dei rischi ICT DORA, outcome NIST CSF e assurance COBIT 2019.
Se la vostra organizzazione si sta preparando a riesami di accountability GDPR, certificazione ISO/IEC 27001:2022, preparazione a NIS2 o resilienza operativa DORA, iniziate integrando i criteri di attivazione DPIA nella richiesta iniziale di progetto e modifica. Collegate le risultanze DPIA al registro dei rischi. Mappate i trattamenti nella SoA. Validate fornitori e servizi cloud prima dell’attivazione. Conservate un’unica registrazione decisionale che direzione, auditor e autorità di controllo possano seguire.
La migliore DPIA non è quella scritta dopo che un’autorità di controllo la richiede. È quella che ha modellato il sistema prima che clienti, auditor o incidenti lo mettessero alla prova.
Riesaminate il vostro attuale processo DPIA rispetto al toolkit di policy Clarysec, utilizzate la Zenith Blueprint per costruire una tracciabilità idonea all’audit e usate Zenith Controls per mappare un unico quadro di controlli attraverso GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF e COBIT 2019. Trasformate quindi la prossima modifica con impatto privacy in una decisione di rilascio governata e supportata da evidenze, invece che in una corsa alla conformità dell’ultimo minuto.
Frequently Asked Questions
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
