Richieste di comunicazione di dati personali ai sensi del GDPR e di ISO 27701
La richiesta arriva alle 16:47 di un venerdì
Un responsabile della relazione con il cliente inoltra al team legale un’e-mail con oggetto: “RICHIESTA URGENTE DELLA POLIZIA”. In allegato c’è una lettera scansionata che richiede dettagli dell’account, cronologia degli accessi, indirizzi IP, registrazioni dei pagamenti e “qualsiasi altra informazione pertinente” relativa a una persona identificata. Il mittente dichiara di appartenere a un’unità di contrasto alla criminalità informatica. L’e-mail chiede la comunicazione entro 24 ore e richiede che l’organizzazione “non informi l’interessato”.
Nello stesso momento, il team delle operazioni di sicurezza sta indagando attività anomale sul medesimo account cliente. Il DPO si trova in un altro fuso orario. Il CISO chiede se si tratti di un incidente, di una richiesta legale, di una comunicazione ai sensi del GDPR o di tutte e tre le cose. Il team commerciale vuole “collaborare pienamente”. Il supporto chiede se può esportare il profilo del cliente. Qualcuno propone di inviare l’intera registrazione CRM perché “le autorità hanno chiesto tutto”.
Questa è la lacuna di governance.
La maggior parte delle organizzazioni dispone di un’informativa privacy, di un piano di risposta agli incidenti e di un processo per le richieste di accesso degli interessati. Molte sanno gestire la due diligence sui fornitori, la corrispondenza con le autorità di vigilanza e la notifica delle violazioni. Molto meno frequenti sono invece flussi di lavoro ripetibili per richieste obbligatorie o ufficiali di comunicazione di dati personali provenienti da forze dell’ordine, autorità di vigilanza, tribunali, autorità fiscali, autorità di vigilanza finanziaria, autorità delle telecomunicazioni, unità cybercrime o autorità pubbliche estere.
Questa lacuna è pericolosa. Dare seguito a una richiesta fraudolenta può causare una violazione dei dati personali. Rifiutare una richiesta legittima può creare esposizioni legali. Rispondere senza un processo controllato può determinare comunicazioni eccessive, compromissione della catena di custodia, scadenze non rispettate, trasferimenti internazionali illeciti e rilievi in sede di audit.
Ai sensi di GDPR, ISO 27701:2025 e ISO/IEC 27001:2022, una richiesta ufficiale di comunicazione di dati personali non è solo una questione da casella di posta del team legale. Coinvolge base giuridica, responsabilizzazione, limitazione della finalità, minimizzazione dei dati, riservatezza, approvazione basata sui ruoli, governance dei trasferimenti internazionali, istruzioni al responsabile del trattamento, conservazione delle evidenze, trasferimento sicuro e tracce di audit.
La verifica pratica è semplice: quando arriva la richiesta, la tua organizzazione può dimostrare di aver validato il richiedente, valutato l’autorità legale, minimizzato la comunicazione, ottenuto le approvazioni corrette, protetto le evidenze, registrato la decisione e conservato una traccia verificabile in audit?
La posizione di Clarysec è chiara. Le richieste di comunicazione di dati personali provenienti da forze dell’ordine e autorità di vigilanza devono essere trattate come un flusso di lavoro controllato di privacy e sicurezza delle informazioni, non come una risposta e-mail improvvisata.
Perché le richieste ufficiali di comunicazione di dati personali sono diverse
Un normale accordo di condivisione esterna dei dati parte di solito da una finalità aziendale. Un fornitore ha bisogno dei dati dei dipendenti per la gestione delle paghe. Un fornitore SaaS tratta identificativi dei clienti. Un partner riceve dati di transazione in base a un contratto. Lo schema di governance è noto: due diligence, accordo sul trattamento dei dati (DPA), requisiti di sicurezza, valutazione del trasferimento, termini di conservazione e monitoraggio continuo.
Le richieste di comunicazione di dati personali provenienti da forze dell’ordine e autorità di vigilanza sono diverse. Sono determinate da eventi, soggette a scadenze ravvicinate, spesso riservate e talvolta giuridicamente vincolanti. Possono arrivare al di fuori dei canali di approvvigionamento. Possono richiedere ampie categorie di dati personali. Possono vietare la notifica. Possono coinvolgere autorità estere. Possono arrivare durante un incidente, un’indagine su frodi, una conservazione legale, un’ispezione regolamentare o un’indagine di criminalità informatica.
Ne derivano tre requisiti immediati di governance.
Primo, l’organizzazione deve sapere chi può rispondere. Un dipendente di front office non deve decidere se una richiesta della polizia è valida, se la formulazione di un’autorità di vigilanza è vincolante o se la notifica al cliente è vietata.
Secondo, la collaborazione deve essere separata dalla comunicazione eccessiva. Il GDPR non impedisce la collaborazione lecita con le autorità, ma richiede comunque una base giuridica valida, correttezza, trasparenza ove applicabile, limitazione della finalità, minimizzazione dei dati, integrità, riservatezza e responsabilizzazione.
Terzo, le evidenze devono essere preservate. Se la richiesta riguarda un incidente, un evento fraudolento, una controversia o una richiesta di un’autorità di controllo, cancellare log, modificare registrazioni o esportare dati senza tracciabilità può compromettere sia la conformità sia la sostenibilità giuridica.
Il modello operativo più solido integra governance della privacy, approvazione legale, gestione delle evidenze, risposta agli incidenti, trasmissione sicura e contatto con le autorità in un unico flusso di lavoro.
Il cluster di controlli Clarysec: autorità, privacy ed evidenze
In Zenith Controls: The Cross-Compliance Guide, Clarysec tratta la governance delle comunicazioni a forze dell’ordine e autorità di vigilanza come un cluster di controlli connessi, non come un’attività privacy isolata. I controlli centrali ISO/IEC 27002:2022 sono 5.5 Contatto con le autorità, 5.28 Raccolta di evidenze e 5.34 Privacy e protezione dei dati personali. Le relazioni di controllo di supporto includono classificazione ed etichettatura, controllo degli accessi, rapporti con i fornitori, gestione degli incidenti, registrazione degli eventi, sincronizzazione dell’orario, crittografia, mascheramento, cancellazione e trasferimento delle informazioni.
Questo è rilevante perché le richieste ufficiali di comunicazione possono fallire in più punti. Un team privacy può validare la base giuridica ma non preservare le evidenze. Un SOC può preservare i log ma comunicare troppi dati personali. Il team legale può approvare una risposta ma dimenticare di aggiornare il registro delle comunicazioni. Un responsabile del trattamento può rispondere direttamente a un’autorità quando avrebbe dovuto instradare la richiesta al titolare del trattamento.
Zenith Blueprint: An Auditor’s 30-Step Roadmap rafforza questo collegamento operativo nella fase Controlli in azione, Passaggio 22, in relazione al Contatto con le autorità:
Il controllo 5.5 assicura che un’organizzazione sia pronta a interagire con le autorità esterne quando necessario, non in modo reattivo o sotto pressione, ma attraverso canali predefiniti, strutturati e compresi.
La stessa sezione inquadra le domande a cui occorre rispondere prima che arrivi una richiesta reale:
Il principio è semplice: se la tua organizzazione fosse colpita da un attacco informatico, coinvolta in una violazione dei dati o sottoposta a indagine, chi chiamerebbe le autorità? Come saprebbe cosa dire? A quali condizioni verrebbe avviato tale contatto? A queste domande occorre rispondere in anticipo, non a posteriori.
Per la protezione dei dati personali, Zenith Blueprint, nella fase Controlli in azione, Passaggio 23, inquadra la privacy come obbligo lungo il ciclo di vita:
Il controllo 5.34 richiede alle organizzazioni di proteggere la privacy degli individui applicando misure adeguate per la gestione dei dati personali lungo l’intero ciclo di vita.
Per le evidenze, la stessa fase e lo stesso passaggio spiegano perché la gestione informale è rischiosa:
Il controllo 5.28 riconosce che, dopo un incidente, ciò che puoi dimostrare conta tanto quanto ciò che è effettivamente accaduto.
Insieme, questi tre principi definiscono il modello di governance: sapere chi parla con le autorità, proteggere i dati personali lungo l’intero ciclo di vita della comunicazione e preservare le evidenze in modo difendibile.
La prospettiva di GDPR e ISO 27701:2025 sulle comunicazioni obbligatorie
ISO 27701:2025 rafforza l’esigenza di disciplina del Sistema di gestione delle informazioni sulla privacy. Un PIMS deve definire come i titolari del trattamento e i responsabili del trattamento gestiscono le richieste ufficiali di comunicazione, inclusi ricezione, validazione, riesame legale, autorizzazione, registrazione, minimizzazione, trasmissione sicura, conservazione e riesame successivo alla risposta.
Per un titolare del trattamento, la domanda centrale è se l’organizzazione determini finalità e mezzi del trattamento e debba quindi decidere se e come la comunicazione sia lecita. Per un responsabile del trattamento, la domanda è se possa comunicare dati senza istruzioni del titolare del trattamento, salvo obbligo legale. Per un sub-responsabile, l’instradamento e gli obblighi a cascata diventano ancora più sensibili.
Il GDPR conferma gli stessi requisiti operativi. Una comunicazione a un’autorità pubblica è comunque un trattamento. L’organizzazione deve disporre di una base giuridica ai sensi dell’Article 6, di una finalità documentata, di misure di sicurezza adeguate, della minimizzazione dei dati ai sensi dell’Article 5(1)(c) e di evidenze di responsabilizzazione ai sensi dell’Article 5(2). In molti casi, la base giuridica sarà l’Article 6(1)(c), ossia il trattamento necessario per adempiere un obbligo legale, ma solo dopo che il team legale avrà validato la richiesta e la giurisdizione.
Quando la richiesta proviene da un’autorità pubblica estera, la governance del trasferimento e il riesame del DPO diventano essenziali. Quando la richiesta coinvolge un responsabile del trattamento, occorre verificare le regole contrattuali di notifica e di istruzione. Quando la richiesta riguarda un incidente di cibersicurezza, la risposta deve allinearsi ai requisiti di trattamento dell’incidente e di raccolta delle evidenze.
Il set di policy Clarysec traduce questi requisiti in regole operative.
La policy enterprise P17 Data Protection and Privacy Policy, clausola 6.1.1, stabilisce:
Tutti i trattamenti devono basarsi su una base giuridica valida, ad esempio consenso, contratto od obbligo legale.
La stessa policy, clausola 6.2.1, aggiunge il riferimento alla minimizzazione:
Possono essere raccolti e trattati solo i dati necessari per una finalità aziendale specifica e legittima.
Per le PMI, P17S Data Protection and Privacy Policy - SME, clausola 6.2.1, stabilisce:
Devono essere raccolti e conservati solo i dati personali minimi necessari.
Queste clausole sono rilevanti quando la richiesta chiede “tutte le informazioni”, la “cronologia completa” o “qualsiasi registrazione correlata”. La risposta corretta non consiste nell’esportare ogni campo. La risposta corretta consiste nel validare la richiesta, identificare l’ambito giuridicamente necessario, comunicare solo i dati personali necessari, documentare la decisione e conservare le evidenze.
Dal panico via e-mail a una comunicazione controllata
Un flusso di lavoro maturo deve essere abbastanza semplice da essere seguito dai dipendenti di front office e abbastanza rigoroso per auditor, autorità di vigilanza e tribunali. Clarysec raccomanda un modello in sette fasi.
| Fase | Obiettivo di controllo | Responsabile primario | Evidenze create |
|---|---|---|---|
| 1. Ricezione e quarantena | Prevenire risposte informali o comunicazioni accidentali | Service desk, canale di ricezione legale, Privacy Lead | Ticket della richiesta, messaggio originale, allegati, marcatura temporale |
| 2. Validazione dell’autenticità | Confermare identità del richiedente, autorità, giurisdizione e strumento legale | Team legale, DPO, compliance | Note di validazione, verifica del contatto dell’autorità, valutazione della base giuridica |
| 3. Determinazione del ruolo | Stabilire se l’organizzazione agisce come titolare del trattamento, responsabile del trattamento, contitolare del trattamento o sub-responsabile | Privacy Lead, responsabile del contratto | Valutazione del ruolo PIMS, registrazione dell’istruzione del cliente se responsabile del trattamento |
| 4. Minimizzazione dell’ambito | Tradurre la richiesta in specifiche categorie di dati personali e intervalli temporali | Proprietario del processo, sicurezza, team legale | Estratto della mappatura dei dati, decisione di minimizzazione, note di oscuramento |
| 5. Approvazione | Assicurare una decisione autorizzata prima della comunicazione | DPO, team legale, CISO, titolare dell’attività | Registrazione dell’approvazione, registrazione dell’eccezione se urgente |
| 6. Comunicazione sicura | Trasmettere solo i dati approvati tramite canali controllati | Sicurezza, operazioni legali | Log di trasferimento, evidenze di cifratura, conferma del destinatario |
| 7. Registrazione e riesame | Conservare evidenze di responsabilizzazione e lezioni apprese | Responsabile del PIMS, compliance | Voce REG08, REG09 o REG12, traccia di audit, riesame di chiusura |
La prima regola è l’instradamento. Ogni dipendente deve sapere che le richieste ufficiali relative a dati personali devono seguire un percorso di ricezione definito. Nessuno deve rispondere da una casella personale. Nessuno deve chiamare il richiedente utilizzando un numero di telefono stampato in una lettera non verificata. Nessuno deve esportare dati dei clienti prima che team legale e privacy abbiano riesaminato la richiesta.
La policy enterprise P30 Incident Response Policy, clausola 6.5.5, supporta questa disciplina di instradamento:
Qualsiasi interazione con le forze dell’ordine o con fornitori di servizi forensi deve essere coordinata tramite il team legale e il CISO.
Questa clausola è particolarmente importante quando la richiesta di comunicazione è collegata a frode, cybercrime, compromissione dell’account, ransomware, minaccia interna o indagine su una violazione. Team legale e sicurezza devono coordinarsi, non operare in parallelo.
La policy enterprise P37 Legal and Regulatory Compliance Policy, clausola 7.3.1.2, controlla le dichiarazioni esterne:
Qualsiasi dichiarazione verbale o scritta alle autorità di regolamentazione deve essere pre-approvata.
La clausola 7.3.1.3 aggiunge disciplina su scadenze ed evidenze:
Le scadenze di risposta devono essere tracciate e i log delle evidenze mantenuti.
Queste regole non sono attrito burocratico. Prevengono ammissioni accidentali, comunicazioni non controllate, scadenze mancate ed evidenze deboli.
Disciplina delle approvazioni e dei registri: le evidenze di audit che molti team trascurano
Molte organizzazioni sanno mostrare l’e-mail originale della richiesta. Meno organizzazioni sanno mostrare chi ha approvato la comunicazione, quale base giuridica è stata utilizzata, perché alcuni campi sono stati inclusi o esclusi, come è stato validato il richiedente, se l’interessato è stato informato o legittimamente non informato, e dove è stata registrata la risposta.
È qui che i registri PIMS di Clarysec diventano centrali.
Per i titolari del trattamento, la policy enterprise PII09 PII Collection, Use, Disclosure and Sharing Policy, clausola 4.4.1, richiede:
[Titolare del trattamento] Il Proprietario del processo / titolare dell’attività DEVE registrare in REG08 l’esito del riesame del Privacy Lead / Responsabile del PIMS prima dell’avvio di qualsiasi nuova comunicazione esterna o accordo di condivisione dei dati.
La clausola 4.4.2 specifica cosa deve essere acquisito per le condivisioni ricorrenti:
[Titolare del trattamento] Il responsabile fornitori / acquisti DEVE registrare in REG08 identità del destinatario, ruolo del destinatario, finalità della comunicazione, categorie di dati personali, frequenza della condivisione, luogo del trattamento e fonte dell’autorità prima dell’avvio della condivisione esterna ricorrente.
Per i responsabili del trattamento, la policy enterprise PII12 Processor, Subprocessor and Third-Party Privacy Management Policy, clausola 4.5.3, prevede una regola specifica per richieste giuridicamente vincolanti e autorizzate dal cliente:
[Responsabile del trattamento] Il responsabile fornitori / acquisti DEVE registrare in REG08 le richieste di comunicazione di terze parti, le richieste di comunicazione giuridicamente vincolanti o le richieste di comunicazione autorizzate dal cliente prima della comunicazione oppure entro due giorni lavorativi quando la registrazione preventiva non è consentita o non è operativamente possibile.
Per le richieste di autorità pubbliche estere, la policy enterprise PII13 International PII Transfer Policy, clausola 4.4.3, è più specifica:
[Entrambi] Il Privacy Lead / Responsabile del PIMS DEVE registrare le richieste di comunicazione provenienti da autorità pubbliche estere in REG09 o REG12 prima della comunicazione, ove praticabile, oppure entro un giorno lavorativo quando la registrazione preventiva non è praticabile.
La clausola 4.4.4 aggiunge disciplina di riesame:
[Entrambi] Il Responsabile della protezione dei dati / Privacy Advisor DEVE riesaminare in REG09 o REG12, ove praticabile prima della risposta, le richieste di comunicazione provenienti da autorità pubbliche estere con impatto significativo sulla privacy.
Un registro delle comunicazioni è il sistema di registrazione autorevole dell’organizzazione. Non deve essere sostituito da e-mail sparse, discussioni private in chat o fogli di calcolo ad hoc.
| Campo del registro | Cosa dimostra |
|---|---|
| ID richiesta | La richiesta è stata tracciata in modo univoco |
| Fonte della richiesta | L’autorità o il richiedente sono stati identificati |
| Fonte dell’autorità legale | Lo strumento legale o l’autorità sono stati valutati |
| Ruolo PIMS | Sono stati considerati gli obblighi di titolare del trattamento, responsabile del trattamento, contitolare del trattamento o sub-responsabile |
| Categorie di dati personali richieste | L’ambito originario della richiesta è stato acquisito |
| Categorie di dati personali approvate | La comunicazione finale è stata controllata |
| Dati personali esclusi | La minimizzazione dei dati è stata applicata attivamente |
| Catena di approvazione | Le approvazioni di team legale, DPO, CISO e funzione aziendale sono state registrate |
| Metodo di trasmissione | Sono stati usati controlli di trasferimento sicuro |
| Decisione di notifica | Sono state considerate restrizioni o differimenti della trasparenza |
| Conservazione e chiusura | Le evidenze sono state conservate e la pratica è stata chiusa |
Esempio operativo: una richiesta di un’autorità di vigilanza in REG08
Immagina che una fintech regolamentata riceva una richiesta scritta da un’autorità nazionale di vigilanza finanziaria che richiede dati personali relativi a transazioni sospette di un cliente per un periodo di 90 giorni. La richiesta riguarda registrazioni di verifica dell’identità, log delle transazioni, identificativi dei dispositivi, ticket di supporto e note interne sul rischio.
Utilizzando il toolkit Clarysec, il Privacy Lead apre una registrazione di comunicazione in REG08.
| Campo REG08 | Esempio di voce |
|---|---|
| ID richiesta | REG08-2026-041 |
| Fonte della richiesta | Autorità nazionale di vigilanza finanziaria, verificata tramite elenco ufficiale dei contatti di vigilanza |
| Tipo di richiesta | Richiesta di comunicazione di dati personali da parte di un’autorità di vigilanza |
| Ruolo PIMS | Titolare del trattamento |
| Fonte dell’autorità legale | Richiesta legale di informazioni di vigilanza, riferimento FIN-REQ-7781 |
| Finalità | Indagine su transazioni sospette relative al cliente identificato |
| Categorie di dati personali richieste | Dati di verifica dell’identità, log delle transazioni, identificativi dei dispositivi, comunicazioni di supporto, note sul rischio |
| Categorie di dati personali approvate | Log delle transazioni, identificativi dei dispositivi, campi pertinenti di verifica dell’identità, due ticket di supporto compresi nell’intervallo temporale |
| Dati personali esclusi | Cronologia di supporto non pertinente, opinioni interne degli analisti fuori intervallo temporale, riferimenti a clienti terzi |
| Motivazione della minimizzazione | Ambito limitato al cliente identificato, periodo di 90 giorni, registrazioni pertinenti alle transazioni indicate nella richiesta |
| Riesame del DPO | Approvato con istruzioni di oscuramento |
| Approvazione legale | Approvato, testo della risposta riesaminato |
| Riesame del CISO | Approvati esportazione sicura e metodo di trasferimento |
| Metodo di trasmissione | Archivio cifrato tramite portale sicuro dell’autorità di vigilanza |
| Notifica all’interessato | Differita per restrizione legale contenuta nella richiesta, fissata data di riesame |
| Conservazione | Registrazione della richiesta e pacchetto di comunicazione conservati secondo il piano di conservazione legale |
| Evidenze di chiusura | Ricevuta di invio del portale, hash del pacchetto di comunicazione, catena di approvazione |
Questa è la differenza tra “abbiamo adempiuto” e “possiamo dimostrare di aver adempiuto in modo lecito e proporzionato”. Se il cliente presenta successivamente un reclamo, se l’autorità pone domande di follow-up o se un auditor campiona la comunicazione, la registrazione mostra la logica di governance.
Preservazione delle evidenze: non danneggiare i fatti mentre si cerca di collaborare
Quando una richiesta delle forze dell’ordine o di un’autorità di vigilanza è collegata a un’indagine, la governance della privacy si interseca con l’analisi forense e la conservazione legale. I dati comunicati sono spesso evidenze, e l’atto di raccoglierli deve preservarne l’integrità.
La Legal and Regulatory Compliance Policy - SME, clausola 6.4.1, definisce il contesto:
In caso di controversia, indagine o richiesta legale:
La clausola 6.4.1.2 fornisce un’istruzione chiara:
I dipendenti non devono cancellare o alterare materiali che potrebbero far parte di un’indagine.
La P31S Evidence Collection and Forensics Policy - SME, clausola 2.2.5, include esplicitamente:
Richieste di autorità di regolamentazione o delle forze dell’ordine
La clausola 5.2.1 stabilisce la disciplina di registrazione:
Ogni elemento di evidenza digitale deve essere registrato con:
In termini operativi, il log delle evidenze deve acquisire un identificativo univoco, data e ora di raccolta, nome del soggetto che ha effettuato la raccolta, posizione della fonte e hash crittografico ove appropriato. Il punto è la tracciabilità. Se i log vengono esportati manualmente, i nomi dei file vengono modificati, le marcature temporali non sono chiare o non viene conservato alcun hash, l’organizzazione può avere difficoltà a dimostrare l’integrità in seguito.
Un flusso di lavoro solido per le evidenze limita anche l’accesso. I pacchetti di comunicazione devono essere conservati in posizioni ad accesso ristretto, cifrati in transito, tracciati tramite log di trasferimento e conservati secondo i requisiti di conservazione legale e di retention. Se una richiesta di comunicazione si sovrappone a una risposta agli incidenti, il team deve sapere quando passare dalla modalità di remediation alla postura investigativa.
Mappatura trasversale della conformità: un flusso di lavoro, molti obblighi
Un flusso di lavoro ben progettato per le richieste di comunicazione di dati personali può soddisfare più quadri di riferimento senza duplicare il lavoro. Zenith Controls aiuta le organizzazioni a mappare le stesse evidenze operative tra aspettative di privacy, cibersicurezza, resilienza operativa e governance.
| Quadro di riferimento | Cosa si aspetta l’auditor o l’autorità di vigilanza | Come il flusso di lavoro Clarysec lo supporta |
|---|---|---|
| ISO 27701:2025 | Ruoli PIMS, governance delle comunicazioni lecite, istruzioni al responsabile del trattamento, registrazioni delle comunicazioni di dati personali, trattamento del rischio privacy | Determinazione del ruolo, REG08, REG09, REG12, riesame del DPO, motivazione della minimizzazione |
| GDPR | Base giuridica, responsabilizzazione, minimizzazione dei dati, sicurezza, decisioni sulla trasparenza, governance dei responsabili del trattamento e dei trasferimenti | Valutazione dell’autorità legale, catena di approvazione, pacchetto di comunicazione limitato, evidenze di trasferimento sicuro |
| ISO/IEC 27001:2022 e ISO/IEC 27002:2022 | Contatto con le autorità, raccolta delle evidenze, protezione dei dati personali, controllo degli accessi, registrazione degli eventi, crittografia, cancellazione | Matrice dei contatti con le autorità, log delle evidenze, esportazione sicura, registrazione dell’hash, decisione di conservazione |
| NIS2 | Disciplina della segnalazione degli incidenti, cooperazione con le autorità competenti, responsabilizzazione della governance, consapevolezza della catena di fornitura | Coordinamento tra team legale e CISO, scadenze di risposta, registro dei contatti con le autorità, collegamento con l’incidente |
| DORA | Governance degli incidenti ICT degli enti finanziari, interazione con le autorità di vigilanza, disponibilità delle evidenze, rischio ICT di terze parti | Instradamento delle richieste delle autorità di vigilanza, registrazioni sicure delle comunicazioni, preservazione delle evidenze dell’incidente, interfaccia con i fornitori |
| NIST Cybersecurity Framework | Esiti di governance, identificazione, protezione, rilevamento, risposta e ripristino per gli eventi di cibersicurezza | Titolarità della policy, inventario dei dati, controlli di accesso, registrazione degli eventi, flusso di lavoro di risposta, riesame post-risposta |
| COBIT 2019 | Obiettivi di governance per conformità, rischio, sicurezza, gestione delle informazioni e assurance | Diritti decisionali, titolarità del processo, registrazioni di audit, supervisione della direzione, miglioramento continuo |
Anche gli standard ISO di supporto sono rilevanti. ISO/IEC 27035 aiuta a strutturare la gestione degli incidenti quando la richiesta è correlata a un incidente. ISO/IEC 27037 supporta identificazione, raccolta, acquisizione e preservazione delle evidenze digitali. ISO/IEC 27018 è utile quando responsabili del trattamento in cloud pubblico trattano dati personali. ISO/IEC 27017 supporta le responsabilità di sicurezza cloud. ISO 22301 diventa rilevante se il contatto con le autorità e gli obblighi di comunicazione devono proseguire in condizioni di crisi. ISO/IEC 27006-1:2024 rileva indirettamente perché gli auditor di certificazione si aspettano un’applicazione coerente e verificabile dei controlli del sistema di gestione compresi nell’ambito.
L’obiettivo non è costruire un processo di conformità separato per ogni quadro di riferimento. L’obiettivo è progettare un unico flusso di lavoro difendibile che produca evidenze riutilizzabili.
Come auditor diversi testeranno il flusso di lavoro
Un auditor ISO/IEC 27001:2022 partirà di norma dall’integrazione nel sistema di gestione. Chiederà se l’organizzazione ha determinato parti interessate, requisiti legali e normativi, rischi, obiettivi di controllo, procedure documentate, responsabilità assegnate ed evidenze conservate. Per le richieste di comunicazione, potrebbe campionare incidenti, corrispondenza con autorità di vigilanza, elenchi dei contatti con le autorità, log delle evidenze e registrazioni privacy. Probabilmente testerà i controlli dell’Annex A A.5.5 Contatto con le autorità, A.5.28 Raccolta di evidenze e A.5.34 Privacy e protezione dei dati personali.
Un valutatore ISO 27701:2025 si concentrerà sulla chiarezza dei ruoli PIMS. Eravate titolare del trattamento, responsabile del trattamento, contitolare del trattamento o sub-responsabile? Se titolare del trattamento, dov’è la base giuridica e la registrazione della comunicazione? Se responsabile del trattamento, avete agito su istruzioni del titolare del trattamento salvo obbligo legale contrario? Il cliente è stato informato quando richiesto o quando previsto contrattualmente? Le richieste di autorità pubbliche estere sono state registrate e riesaminate?
Un’autorità GDPR si concentrerà sulla responsabilizzazione. La domanda non sarà semplicemente “avevate un obbligo legale?”. Sarà “perché è stata comunicata questa quantità di dati, chi l’ha approvata, come è stato validato il richiedente, quale sicurezza ha protetto il trasferimento, come avete valutato la trasparenza e dove si trova la registrazione?”.
Un valutatore orientato a NIST esaminerà gli esiti di governance e risposta. Chiederà se i ruoli sono stati definiti, se i log sono stati preservati, se l’accesso ai pacchetti di comunicazione è stato ristretto, se le attività di risposta sono state documentate e se le lezioni apprese hanno migliorato il programma.
Un auditor COBIT 2019 o ISACA testerà la governance dei diritti decisionali. Potrebbe chiedere se la direzione ha definito il proprietario del processo, se le responsabilità di team legale, privacy, sicurezza e funzioni aziendali sono separate, se le eccezioni sono approvate, se le metriche sono riportate e se l’assurance può fare affidamento sulle evidenze.
Un’autorità di vigilanza, un auditor, un CISO e un DPO possono interpretare la stessa registrazione in modo diverso. Un professionista privacy vede una registrazione di comunicazione lecita. Un auditor di sicurezza vede preservazione delle evidenze e trasferimento sicuro. Un auditor di governance vede responsabilizzazione e diritti decisionali. L’organizzazione deve poter rispondere a tutti partendo dalle stesse evidenze di controllo.
Schemi ricorrenti di fallimento
Clarysec osserva ripetutamente gli stessi fallimenti prevenibili.
Il primo è il contatto informale con l’autorità. Un agente di polizia chiama il supporto, il supporto vuole essere collaborativo e il dipendente conferma verbalmente dettagli dell’account. Nessuna validazione, nessuna approvazione, nessuna registrazione.
Il secondo è la comunicazione eccessiva. L’organizzazione invia l’intero fascicolo cliente invece delle specifiche registrazioni e dell’intervallo temporale richiesti. Questo crea un rischio GDPR evitabile e indebolisce la fiducia.
Il terzo è lo sconfinamento del responsabile del trattamento. Un fornitore SaaS riceve una richiesta delle forze dell’ordine relativa a dati personali controllati dal cliente e risponde senza informare o coinvolgere il cliente, anche se il contratto e il ruolo PIMS richiedono l’instradamento, salvo divieto legale.
Il quarto è l’assenza di riesame delle autorità estere. Una richiesta proveniente da un’autorità pubblica non nazionale viene trattata come una comunicazione ordinaria, senza valutazione del trasferimento, riesame del DPO o voce REG09 o REG12.
Il quinto è una gestione debole delle evidenze. I log vengono esportati manualmente, le marcature temporali non sono chiare, i nomi dei file vengono modificati e non esiste alcun hash o registro della catena di custodia.
Il sesto è la riservatezza non gestita. Troppi dipendenti sono messi in copia nella richiesta, incluse persone prive di necessità di conoscere. Dettagli sensibili dell’indagine si diffondono tramite canali di chat.
Il settimo è la confusione sulle scadenze. L’organizzazione manca una data di risposta giuridicamente rilevante perché la richiesta resta in una casella di posta invece che in un flusso di lavoro tracciato.
Ogni fallimento è prevenibile con canali predefiniti, registri, approvazioni e standard sulle evidenze.
Ruoli e diritti decisionali
Un modello pratico di governance definisce i diritti decisionali prima che arrivi la prima richiesta.
| Ruolo | Responsabilità nel flusso di lavoro di comunicazione |
|---|---|
| Dipendente di front office | Inoltrare la richiesta al canale di ricezione approvato, non rispondere nel merito, non comunicare dati personali |
| Team legale | Validare strumento legale, giurisdizione, autorità, restrizione di riservatezza e formulazione della risposta |
| DPO o Privacy Advisor | Valutare implicazioni GDPR e ISO 27701:2025, minimizzazione, trasparenza, ruolo PIMS e aspetti di trasferimento |
| CISO | Approvare raccolta sicura delle evidenze, esportazione sicura, metodo di trasferimento e collegamento con incidenti |
| Proprietario del processo | Identificare sistemi e categorie di dati pertinenti, confermare il contesto aziendale |
| Responsabile del PIMS | Mantenere REG08, REG09 o REG12, tracciare l’esito del riesame, conservare evidenze di audit |
| Approvatore esecutivo | Approvare comunicazioni ad alto rischio, estere, strategiche o sensibili sotto il profilo reputazionale |
| Responsabile fornitori o acquisti | Coordinare registrazioni delle richieste e obblighi contrattuali relativi a terze parti o responsabili del trattamento |
Questo modello deve essere integrato nella formazione e sensibilizzazione. I dipendenti non devono conoscere ogni sfumatura legale, ma devono conoscere la regola: le richieste ufficiali passano dal canale definito e i dati personali non vengono comunicati senza autorizzazione.
Checklist di preparazione per la prossima esercitazione tabletop
Usa questa checklist in un workshop di governance della privacy, in un audit interno o in un’esercitazione tabletop.
- Disponiamo di un unico canale di ricezione per le richieste di comunicazione di dati personali provenienti da forze dell’ordine e autorità di vigilanza?
- I dipendenti sanno che non devono rispondere in modo informale?
- Validiamo l’identità del richiedente utilizzando fonti di contatto indipendenti?
- Distinguiamo richieste di autorità di vigilanza, ordini del tribunale, richieste delle forze dell’ordine, richieste autorizzate dal cliente e richieste di autorità pubbliche estere?
- Determiniamo se siamo titolare del trattamento, responsabile del trattamento, contitolare del trattamento o sub-responsabile prima di rispondere?
- Documentiamo base giuridica, autorità legale, giurisdizione e restrizioni di riservatezza?
- Applichiamo la minimizzazione dei dati e oscuriamo i dati personali non pertinenti?
- Richiediamo il riesame del DPO o del Privacy Advisor per le richieste con impatto significativo sulla privacy?
- Richiediamo il coordinamento tra team legale e CISO quando sono coinvolti aspetti di law enforcement o forensi?
- Registriamo le comunicazioni del titolare del trattamento in REG08?
- Registriamo le richieste di autorità pubbliche estere in REG09 o REG12?
- Tracciamo le scadenze di risposta e manteniamo log delle evidenze?
- Preserviamo i materiali potenzialmente pertinenti e impediamo cancellazioni o alterazioni?
- Proteggiamo i pacchetti di comunicazione con cifratura, controllo degli accessi e registrazione dei trasferimenti?
- Eseguiamo un riesame post-risposta per le richieste ad alto rischio?
- Riportiamo metriche e lezioni apprese alla direzione?
Se la risposta a una di queste domande è “di solito lo gestiamo via e-mail”, il processo non è ancora verificabile in audit.
Integrare il flusso di lavoro nell’ISMS e nel PIMS
Il miglior modello di governance non risiede solo nel team legale. Fa parte dell’ISMS e del PIMS.
In Zenith Blueprint, la fase Fondamenti e leadership dell’ISMS, Passaggio 5, raccomanda di pianificare la comunicazione esterna e identificare chi comunica con autorità di vigilanza, clienti, partner e pubblico. Osserva che il consulente legale può essere coinvolto nella formulazione delle comunicazioni alle autorità di vigilanza. Questo principio si applica direttamente alle richieste ufficiali di comunicazione di dati personali.
La fase Controlli in azione rende poi operativo il flusso di lavoro tramite contatto con le autorità, protezione dei dati personali e raccolta delle evidenze. Per questo la guida in 30 passaggi di Clarysec non tratta privacy, sicurezza e conformità come flussi di lavoro scollegati. Una richiesta reale attraversa tutti e tre.
Per i titolari dell’attività, il beneficio è la riduzione del caos. Per i CISO, chiarisce quando le evidenze di sicurezza possono essere raccolte, comunicate o preservate. Per i DPO, crea responsabilizzazione dimostrabile ai fini di GDPR e ISO 27701:2025. Per i responsabili della conformità, produce registri e tracce di audit. Per gli auditor, crea un percorso chiaro dal requisito di policy all’evidenza operativa.
Prossimi passi con Clarysec
Una richiesta di un’autorità di vigilanza o delle forze dell’ordine non è il momento per inventare il tuo processo di governance della privacy. È il momento in cui il processo viene messo alla prova.
Inizia con un’esercitazione tabletop. Usa una richiesta realistica proveniente da cybercrime, da un’autorità di vigilanza o da un’autorità pubblica estera. Chiedi al team legale, al DPO, al CISO, al supporto e al pertinente proprietario del processo di attraversare ricezione, validazione, determinazione del ruolo, minimizzazione, approvazione, trasferimento sicuro, registrazione nel registro, preservazione delle evidenze e riesame di chiusura.
Poi confronta le risposte con il modello operativo Clarysec:
- Usa Zenith Blueprint: An Auditor’s 30-Step Roadmap per inserire contatto con le autorità, comunicazione esterna, protezione dei dati personali e raccolta delle evidenze nel piano di implementazione di ISMS e PIMS.
- Usa Zenith Controls: The Cross-Compliance Guide per mappare le aspettative di ISO 27701:2025, GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST e COBIT 2019 in un’unica narrativa di controllo verificabile in audit.
- Usa le policy Clarysec su protezione dei dati e privacy, risposta agli incidenti, conformità legale e normativa, raccolta delle evidenze e analisi forense, comunicazione di dati personali, gestione dei responsabili del trattamento e trasferimenti internazionali per definire regole di flusso di lavoro, registri, approvazioni e requisiti di evidenza.
Clarysec aiuta i team a passare dal panico reattivo all’esecuzione controllata. Scarica i toolkit Clarysec pertinenti, esegui l’esercitazione tabletop e prenota una valutazione della governance delle comunicazioni per assicurarti che la prossima risposta sia lecita, minima, approvata, registrata, sicura e verificabile in audit.
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