Governance degli accordi di condivisione dei dati per GDPR e ISO 27701

Sono le 16:00 di un martedì e Sarah, CISO di una FinTech in rapida crescita, sta esaminando un accordo di condivisione dei dati proposto da un partner strategico di analisi basata su IA. Il team commerciale è entusiasta. Il partner promette migliori insight sui clienti, maggiore personalizzazione e una previsione del churn più rapida. La funzione legale è prudente. L’accordo contiene formulazioni vaghe come “sicurezza commercialmente ragionevole” e dice poco o nulla su tempi di risposta agli incidenti, gestione dei diritti degli interessati, conservazione, cancellazione, diritto di audit o pianificazione dell’uscita.

Sarah individua subito il rischio. Il partner opera come responsabile del trattamento, come titolare autonomo o come contitolare del trattamento? Chi valida la base giuridica ai sensi del GDPR? Se un cliente presenta una richiesta di cancellazione, quale processo assicura che i dati siano eliminati dall’ambiente del partner, dai set di dati derivati e, ove applicabile, dalle pipeline di addestramento dell’IA? Se il partner subisce una violazione, chi informa chi, quando e con quali evidenze?

Non si tratta di un singolo contratto carente. È il modello operativo che non sta funzionando.

Le aziende moderne SaaS, FinTech, healthtech, di servizi gestiti e di piattaforma condividono dati continuamente tramite API, integrazioni, partnership di analisi dati, strumenti di supporto, piattaforme cloud, affiliate, richieste del settore pubblico e servizi di IA. Il linguaggio commerciale spesso procede più rapidamente della governance. Viene firmato un contratto, viene emessa una chiave API e i dati personali iniziano a fluire prima che privacy, sicurezza, acquisti, ingegneria e DPO abbiano concordato gli elementi di base.

Ai sensi del GDPR, un accordo di condivisione dei dati non è solo un documento legale. È evidenza di liceità, correttezza, trasparenza, limitazione della finalità, minimizzazione, limitazione della conservazione, integrità, riservatezza e responsabilizzazione. Ai sensi di ISO/IEC 27701:2025, diventa parte di un Sistema di gestione delle informazioni sulla privacy, o PIMS, con cui l’organizzazione può dimostrare che le informazioni personali sono raccolte, utilizzate, comunicate, condivise, conservate, protette e smaltite attraverso processi governati.

Clarysec considera la governance della condivisione dei dati come un sistema di controllo interfunzionale, non come un esercizio di compilazione di un modello contrattuale. Utilizzando Zenith Blueprint, Zenith Controls e il set di politiche PIMS di Clarysec, le organizzazioni possono passare da riesami ad hoc degli accordi a un ciclo di vita idoneo all’audit che collega clausole legali, registri, decisioni di rischio, controlli tecnici ed evidenze di conformità.

Perché gli accordi di condivisione dei dati falliscono negli audit reali

La maggior parte delle organizzazioni non fallisce perché non ha mai redatto un contratto. Fallisce perché il contratto è scollegato dalla realtà operativa.

Un auditor privacy chiede il registro di condivisione dei dati. La funzione legale invia l’accordo firmato. L’auditor chiede quindi la base giuridica, la finalità della comunicazione, il ruolo del destinatario, le categorie di PII, la regola di conservazione, il luogo del trattamento, il metodo di trasferimento, l’instradamento delle richieste degli interessati, le misure tecniche di sicurezza e le evidenze di riesame. Improvvisamente, l’accordo firmato è solo un elemento del quadro complessivo.

GDPR Article 5 richiede che il trattamento dei dati personali rispetti liceità, correttezza, trasparenza, limitazione della finalità, minimizzazione dei dati, esattezza, limitazione della conservazione, integrità e riservatezza. Article 5(2) aggiunge la responsabilizzazione, cioè l’obbligo del titolare del trattamento di poter dimostrare la conformità. Article 6 richiede una base giuridica valida. Article 9 innalza il livello dei requisiti per le categorie particolari di dati personali, inclusi dati relativi alla salute, biometrici, genetici, politici, religiosi e altre categorie sensibili.

In pratica, un processo di governance degli accordi di condivisione dei dati deve rispondere a queste domande prima che inizi una condivisione esterna ricorrente:

• Chi è il destinatario e qual è il suo ruolo privacy?
• Quali dati personali vengono condivisi e per quale finalità?
• Quale base giuridica supporta la comunicazione?
• La nuova finalità è compatibile con la finalità originaria della raccolta?
• Gli interessati sono stati informati tramite un’informativa privacy o un altro meccanismo di trasparenza?
• Quali registri, approvazioni e decisioni di rischio documentano la condivisione?
• Come sono instradati tra le parti i diritti degli interessati?
• Quali obblighi di conservazione, cancellazione, restituzione e cessazione si applicano?
• Quali misure di sicurezza proteggono trasferimento, archiviazione, accesso, registrazione, comunicazioni successive e verificabilità?
• Che cosa accade se il partner modifica finalità, ubicazione, subappaltatori o categorie di dati?

Lo Zenith Blueprint, fase Controls in Action, Step 23, coglie con chiarezza la realtà dell’audit:

Il fondamento di questo controllo è la consapevolezza dei dati. L’organizzazione deve sapere quali PII raccoglie, dove risiedono, perché vengono trattate e chi può accedervi. Senza questa baseline, qualsiasi promessa sulla privacy è vuota. Classificazione ed etichettatura (5.12–5.13) diventano essenziali in questo punto, perché le PII non possono essere protette se non sono identificate.

Se l’accordo non è collegato a inventario, classificazione, conservazione, controlli di sicurezza e processo per l’esercizio dei diritti, non è governance. È un documento in un repository.

La condivisione dei dati non equivale al trattamento per conto di un cliente

Un errore frequente consiste nel trattare ogni relazione con terze parti che coinvolge dati personali come uno scenario di responsabile del trattamento. Il GDPR richiede un’analisi dei ruoli. Un responsabile del trattamento agisce per conto di un titolare del trattamento. Un titolare del trattamento determina finalità e mezzi. I contitolari del trattamento determinano congiuntamente finalità e mezzi. Alcuni destinatari sono titolari autonomi che ricevono dati per finalità proprie.

Questa distinzione modifica il modello di accordo.

Un accordo con un responsabile del trattamento si concentra su istruzioni documentate, riservatezza, sub-responsabili, assistenza, sicurezza, notifica delle violazioni, cancellazione o restituzione e supporto all’audit. Un accordo di condivisione dei dati tra titolari del trattamento pone maggiore enfasi su base giuridica, finalità, trasparenza, autonomia del destinatario, limiti alle comunicazioni successive, coordinamento delle DSR, conservazione, misure di sicurezza e ripartizione delle responsabilità. Un accordo tra contitolari del trattamento richiede una ripartizione trasparente degli obblighi e chiarezza sul processo decisionale condiviso.

Le politiche PIMS di Clarysec rendono questa classificazione un gate obbligatorio. La Politica di gestione privacy di responsabili, sub-responsabili e terze parti Enterprise stabilisce:

[Entrambi] Il Responsabile privacy / Responsabile del PIMS DEVE classificare ogni relazione privacy con terze parti come titolare del trattamento, contitolare del trattamento, responsabile del trattamento, sub-responsabile o altra relazione con terze parti in REG08 prima dell’approvazione del contratto o prima dell’inizio del trattamento delle PII, se precedente.

Per le PMI, lo stesso principio è espresso in modo più semplice. La Politica di protezione dei dati e privacy - PMI, Requisiti di governance 5.2.2, richiede:

I contratti con terze parti che trattano dati personali devono includere clausole sulla protezione dei dati e devono essere riesaminati dal Direttore generale o dal consulente legale.

La lezione è pratica: prima di redigere le clausole, classificare la relazione. Il ruolo determina accordo, approvazioni, misure di sicurezza, responsabilità ed evidenze.

Il ciclo di vita della governance della condivisione dei dati

Un flusso maturo per gli accordi di condivisione dei dati deve essere percepito come un processo aziendale controllato, non come un’escalation legale d’emergenza. Clarysec lo implementa generalmente attraverso sette gate collegati.

La Politica di raccolta, uso, comunicazione e condivisione delle PII Enterprise esplicita il requisito lato titolare del trattamento:

[Titolare del trattamento] Il Responsabile fornitori / Approvvigionamenti DEVE registrare identità del destinatario, ruolo del destinatario, finalità della comunicazione, categorie di PII, frequenza della condivisione, luogo del trattamento e fonte dell’autorità in REG08 prima dell’inizio della condivisione esterna ricorrente.

REG08 è il registro dei destinatari e delle relazioni privacy con terze parti. Non deve esistere separatamente dall’inventario dei trattamenti. La Politica sull’inventario dei trattamenti PII e sulla base giuridica Enterprise richiede:

[Entrambi] Il Responsabile fornitori / Approvvigionamenti DEVE verificare che le voci relative a destinatari esterni, responsabili del trattamento, sub-responsabili e condivisioni di dati in REG02 siano allineate con REG08 prima dell’approvazione dell’accordo o di una modifica sostanziale della relazione.

Questo chiude una lacuna di audit ricorrente. REG02 può indicare “analisi del prodotto per miglioramento interno”, mentre REG08 indica “partner di analytics per benchmarking”. Se finalità, destinatario, base giuridica, categorie di dati o regole di conservazione non sono allineati, l’organizzazione presenta una carenza di responsabilizzazione.

Che cosa deve contenere ogni accordo di condivisione dei dati

Un accordo di condivisione dei dati ai sensi di GDPR e ISO 27701:2025 non deve basarsi su clausole generiche di riservatezza. Deve riflettere il flusso di dati reale, la qualificazione dei ruoli, il profilo di rischio e le interfacce operative.

Lo Zenith Blueprint, fase Controls in Action, Step 23, offre la prospettiva degli accordi con i fornitori:

Le aree principali normalmente trattate negli accordi con i fornitori includono:

✓ obblighi di riservatezza, inclusi ambito, durata e restrizioni alla comunicazione a terze parti; ✓ responsabilità di controllo degli accessi, ad esempio chi può accedere ai vostri dati, come sono gestite le credenziali e quale monitoraggio è in essere; ✓ misure tecniche e organizzative per protezione dei dati, cifratura, trasmissione sicura, backup e impegni di disponibilità; ✓ tempistiche e protocolli di segnalazione degli incidenti, spesso con tempi definiti (ad es., “notifica entro 24 ore”); ✓ diritto di audit, inclusi frequenza, ambito e accesso alle evidenze rilevanti (ad es., rapporti di test di penetrazione, SoA, certificazioni); ✓ controlli sui subappaltatori, che richiedono al fornitore di trasferire obblighi di sicurezza equivalenti ai propri partner a valle; ✓ disposizioni di fine contratto, quali restituzione o distruzione dei dati, ripristino degli asset e disattivazione degli account.

La governance legale Enterprise rafforza il punto. La Politica di conformità legale e normativa, Requisiti di governance 5.3.1.2, identifica i contratti che coinvolgono:

Contratti relativi a condivisione dei dati, diritti di proprietà intellettuale, limitazioni di responsabilità o clausole di audit.

Questo colloca la governance della condivisione dei dati all’intersezione tra privacy, funzione legale, rischio commerciale, assurance dei fornitori e operazioni di sicurezza.

Classificazione e trasferimento sicuro sono il collegamento mancante

Molti fallimenti nella condivisione dei dati iniziano da una classificazione inadeguata. Se il responsabile dell’attività non è in grado di indicare se il set di dati è pubblico, a uso interno, riservato, ad accesso ristretto o contiene PII regolamentate, l’accordo sarà vago e i controlli tecnici saranno incoerenti.

La Politica di classificazione ed etichettatura dei dati - PMI di Clarysec stabilisce:

Gli accordi di condivisione dei dati o gli accordi di riservatezza devono richiamare i requisiti di gestione basati sulla classificazione.

Per gli ambienti Enterprise, la Politica di classificazione ed etichettatura dei dati richiede che determinati dati:

Possano essere condivisi esternamente solo sulla base di un accordo di riservatezza o di misure contrattuali equivalenti.

L’etichetta di classificazione deve comparire nell’accordo o nell’allegato di sicurezza. Se la cronologia dei ticket di supporto è classificata come riservata e contiene PII, l’accordo deve definire destinatari consentiti, metodi di trasferimento approvati, luoghi di archiviazione, controlli di accesso, monitoraggio, aspettative di cancellazione ed evidenze di assurance.

Lo Zenith Blueprint, fase Controls in Action, Step 22, spiega il lato operativo del trasferimento delle informazioni:

Nella sostanza, questo controllo richiede che l’organizzazione:

✓ definisca come le informazioni possono essere trasferite, sia internamente sia esternamente; ✓ determini quali metodi sono consentiti (ad es., e-mail cifrata, portali sicuri, SFTP, API, consegna fisica con cifratura); ✓ allinei i metodi di trasferimento alla classificazione delle informazioni (come definita in 5.12 e resa visibile tramite 5.13); ✓ e assicuri che tutte le parti coinvolte nel trasferimento comprendano i propri ruoli, responsabilità e obblighi.

Per le PMI, la Politica di sicurezza delle terze parti e dei fornitori - PMI rende l’aspettativa diretta:

Tutti i dati condivisi con i fornitori devono essere protetti tramite cifratura e trasmessi utilizzando protocolli sicuri (ad es., HTTPS, SFTP).

La governance Enterprise dei fornitori aggiunge maggiore dettaglio. La Politica di sicurezza delle terze parti e dei fornitori richiede requisiti di gestione dei dati, tra cui:

Requisiti di gestione dei dati, inclusi luogo di archiviazione, controlli di accesso e clausole di restituzione o distruzione.

Questi requisiti non devono essere sepolti in un questionario. Devono essere termini contrattuali applicabili e tracciabili a REG08, alla configurazione tecnica e alle evidenze di audit.

Esempio: approvare il partner di analisi IA di Sarah

La FinTech di Sarah vuole condividere ID cliente pseudonimizzati, schemi di transazione, metriche di utilizzo e informazioni sul livello di supporto con un partner di analisi IA per personalizzazione e previsione del churn. Il partner può combinare i dati con i propri modelli analitici e restituire insight alla FinTech.

Un flusso governato sarebbe il seguente.

In primo luogo, il Responsabile fornitori o Approvvigionamenti crea la voce REG08. Il Responsabile privacy o il Responsabile del PIMS classifica la relazione. Se il partner determina finalità analitiche e progettazione del modello oltre le istruzioni di Sarah, il ruolo può essere quello di titolare autonomo o contitolare del trattamento, anziché responsabile del trattamento.

In secondo luogo, REG02 viene riconciliato. Se l’inventario dei trattamenti descrive solo “analisi interna del prodotto”, deve essere aggiornato prima che inizi la condivisione esterna. La base giuridica deve essere documentata e, se la finalità è cambiata, può essere necessaria una valutazione di compatibilità o una valutazione del legittimo interesse.

In terzo luogo, il titolare dei dati applica classificazione e minimizzazione. I domini e-mail degli amministratori potrebbero non essere necessari. Gli ID account possono essere sostituiti con ID pseudonimi specifici del partner. Il livello di supporto può essere conservato solo se richiesto per la finalità approvata.

In quarto luogo, funzione legale, privacy e sicurezza negoziano l’accordo di condivisione dei dati e l’allegato di sicurezza. L’accordo vieta la reidentificazione, limita le comunicazioni successive, definisce la conservazione, richiede evidenze di cancellazione, specifica le tempistiche di notifica degli incidenti, include diritti di audit o assurance e definisce le fasi di uscita.

In quinto luogo, l’informativa privacy e il flusso DSR vengono aggiornati. La Politica di gestione dei diritti degli interessati PII Enterprise richiede:

[Entrambi] Il Responsabile fornitori / Approvvigionamenti DEVE tracciare in REG08 la presa d’atto da parte di terze parti delle notifiche relative ai diritti prima che la relativa richiesta REG06 sia chiusa.

Per le PMI, la Politica di protezione dei dati e privacy - PMI fornisce un’aspettativa pratica sul livello di servizio:

Il Coordinatore privacy deve confermare la ricezione delle richieste entro 3 giorni lavorativi e rispondere entro 30 giorni.

Infine, l’ingegneria applica l’accordo. Le credenziali API sono limitate per ambito. I trasferimenti utilizzano HTTPS. I log acquisiscono le estrazioni dei dati. Gli avvisi rilevano attività anomale. Gli accessi sono riesaminati. La conservazione è automatizzata ove possibile. L’accordo diventa un sistema di controllo vivo, non un PDF.

Mappatura trasversale della conformità per GDPR, ISO 27701, DORA, NIS2, NIST e COBIT 19

La governance della condivisione dei dati raramente appartiene a un solo quadro di riferimento. Tocca la responsabilizzazione GDPR, le operazioni privacy ISO/IEC 27701:2025, i requisiti del sistema di gestione ISO/IEC 27001:2022, i controlli di sicurezza ISO/IEC 27002:2022, il rischio di terze parti DORA, la sicurezza della catena di fornitura NIS2, gli outcome NIST CSF 2.0 e le aspettative di governance COBIT 19.

La clausola 4.2 di ISO/IEC 27001:2022 richiede alle organizzazioni di comprendere le parti interessate e i relativi requisiti pertinenti. La clausola 5.1 richiede alla leadership di integrare i requisiti di sicurezza delle informazioni nei processi aziendali. Per la condivisione dei dati, questo significa che dipendenze dai partner, requisiti contrattuali, obblighi normativi e decisioni di rischio devono rientrare nel SGSI e nel PIMS, non restarne all’esterno.

I controlli ISO/IEC 27002:2022 più rilevanti sono:

• 5.14 Information transfer
• 5.20 Addressing information security within supplier agreements
• 5.34 Privacy and protection of PII

Zenith Controls aiuta le organizzazioni a utilizzare questi controlli come ancoraggi di mappatura. Collega il controllo ISO/IEC 27002:2022 5.14 alla protezione dei dati in transito e ai requisiti contrattuali, inclusi NIST CSF 2.0 PR.DS-02 e GV.SC-05, DORA Article 30(2)(d) e GDPR Article 46 quando sono pertinenti le misure di sicurezza per i trasferimenti internazionali. Collega il controllo 5.20 alla governance degli accordi con i fornitori, inclusi NIS2 Article 21(2)(d) sulla sicurezza della catena di fornitura e DORA Chapter V sul rischio ICT di terze parti. Collega il controllo 5.34 alla privacy e alla protezione delle PII, inclusi GDPR Article 5(2) sulla responsabilizzazione e controlli di supporto quali cifratura, cancellazione, gestione dei fornitori e limitazione della finalità.

L’obiettivo non è creare sette programmi di conformità. L’obiettivo è un unico ciclo di vita governato della condivisione dei dati che produca evidenze riutilizzabili.

Come gli auditor testeranno i tuoi accordi di condivisione dei dati

Un processo di governance solido deve resistere al campionamento. Gli auditor non si fermeranno all’accordo firmato. Testeranno il ciclo di vita.

Un auditor ISO/IEC 27001:2022 e ISO/IEC 27701:2025 chiederà se l’ambito del SGSI e del PIMS include la condivisione esterna, se la valutazione del rischio copre la relazione, se i controlli sono stati selezionati e operati e se la direzione riesamina il rischio privacy e sicurezza delle terze parti.

Un revisore GDPR o un’autorità di controllo si concentrerà sulla responsabilizzazione. Chiederà quali dati personali sono stati condivisi, perché, su quale base giuridica, se gli interessati sono stati informati, per quanto tempo i dati sono stati conservati, se erano coinvolte categorie particolari di dati personali, se i trasferimenti internazionali sono stati valutati e se le richieste relative ai diritti sono state instradate e documentate.

Un revisore DORA, soprattutto nei servizi finanziari, chiederà se l’accordo supporta una funzione essenziale o importante, se è incluso nel registro contrattuale ICT, se il contratto include assistenza per gli incidenti, diritto di audit, localizzazione dei dati, condizioni di subappalto, diritti di cessazione e pianificazione dell’uscita testata.

Un valutatore NIST CSF 2.0 cercherà outcome GOVERN nella gestione del rischio dei fornitori, outcome PROTECT nei controlli sui dati in transito, outcome RESPOND nelle interfacce per gli incidenti e outcome RECOVER nella pianificazione dell’uscita e della continuità.

Un auditor COBIT 19 o in stile ISACA si concentrerà su diritti decisionali, propensione al rischio, realizzazione dei benefici, ottimizzazione delle risorse, obblighi di conformità, metriche, eccezioni e miglioramento continuo.

Se il tuo team non riesce ad assemblare rapidamente queste evidenze, il processo dipende troppo dalla memoria delle persone.

Errori ricorrenti nella governance della condivisione dei dati

Clarysec osserva ripetutamente cinque schemi di fallimento.

Il primo è confondere un DPA con un accordo di condivisione dei dati. Le clausole per responsabili del trattamento non risolvono la responsabilizzazione nei rapporti tra titolari del trattamento o tra contitolari del trattamento.

Il secondo è una scarsa igiene dei registri. REG02 e REG08 non coincidono. L’informativa privacy fa riferimento in modo generico a “partner commerciali”, ma l’inventario dei trattamenti non contiene una finalità di comunicazione corrispondente.

Il terzo è un instradamento DSR insufficiente. Un interessato chiede la cancellazione, ma nessuno sa quali destinatari debbano essere notificati o come debba essere tracciata la presa d’atto.

Il quarto è un linguaggio di sicurezza generico. “Sicurezza adeguata” non basta. L’accordo deve specificare metodi di trasferimento, cifratura, controlli di accesso, registrazione, luogo di archiviazione, tempistiche sugli incidenti, cancellazione e assurance.

Il quinto è ignorare le comunicazioni successive. Gli ecosistemi SaaS moderni includono piattaforme cloud, servizi di IA, fornitori di analytics, strumenti di supporto, fornitori gestiti, affiliate ed enti pubblici. La governance della condivisione dei dati deve controllare le comunicazioni a valle quando incidono sulla responsabilizzazione.

La Politica di gestione privacy di responsabili, sub-responsabili e terze parti coglie il collegamento operativo per le relazioni con responsabili e sub-responsabili del trattamento:

[Entrambi] Il Responsabile fornitori / Approvvigionamenti DEVE assicurare che i contratti con responsabili del trattamento e sub-responsabili includano assistenza privacy, assurance della sicurezza, interfaccia per gli incidenti tramite PII15, restituzione o cancellazione tramite PII10, collegamento ai trasferimenti tramite PII13 e cooperazione per audit o assurance prima dell’approvazione.

Anche quando la relazione è tra titolari del trattamento, la logica di governance rimane valida: assistenza privacy, assurance della sicurezza, interfaccia per gli incidenti, collegamento ai trasferimenti, restituzione o cancellazione e cooperazione all’audit devono essere progettati in modo intenzionale.

Checklist pratica per il tuo prossimo accordo di condivisione dei dati

Utilizza questa checklist prima di approvare una condivisione esterna ricorrente di dati personali.

• Confermare in REG08 il ruolo privacy del destinatario.
• Confermare l’allineamento tra REG02 e REG08 prima dell’approvazione.
• Documentare la finalità della comunicazione e la base giuridica.
• Verificare se una nuova finalità richiede una valutazione di compatibilità.
• Identificare categorie di PII, categorie di interessati e categorie particolari di dati personali.
• Applicare la minimizzazione dei dati e rimuovere i campi non necessari.
• Richiamare nell’accordo i requisiti di gestione basati sulla classificazione.
• Definire metodi di trasferimento approvati e requisiti di cifratura.
• Specificare aspettative su controllo degli accessi, registrazione, monitoraggio e luogo di archiviazione.
• Ripartire le responsabilità di trasparenza e aggiornamento dell’informativa privacy.
• Definire instradamento DSR, presa d’atto, tracciamento ed evidenze di chiusura.
• Definire conservazione, cancellazione, restituzione ed evidenze di cessazione.
• Limitare le comunicazioni successive e richiedere la notifica delle modifiche.
• Includere tempistiche di notifica degli incidenti e requisiti di cooperazione.
• Includere diritti di audit, assurance o riesame delle evidenze.
• Pianificare riesami periodici e trigger di rivalutazione.

Dove si inserisce Clarysec

Il valore di Clarysec non risiede solo nei modelli. Risiede nel collegamento tra politica, registri, evidenze, logica di audit e mappatura trasversale della conformità.

Lo Zenith Blueprint fornisce ai team di implementazione una roadmap in 30 step per trasformare i requisiti di controllo in pratiche operative. Per la condivisione dei dati, lo Step 22 aiuta i team a progettare regole di trasferimento delle informazioni, mentre lo Step 23 collega privacy, accordi con i fornitori, requisiti legali, protezione delle PII e obblighi contrattuali.

Zenith Controls offre la bussola per la conformità trasversale. Per questo tema, collega i controlli ISO/IEC 27002:2022 5.34, 5.14 e 5.20 alla più ampia storia di audit: protezione della privacy, trasferimento delle informazioni e governance degli accordi con i fornitori. Aiuta CISO, DPO, responsabili della conformità, team acquisti e auditor a parlare lo stesso linguaggio quando mappano le aspettative di GDPR, ISO/IEC 27701:2025, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 e COBIT 19.

Il set di politiche PIMS di Clarysec fornisce quindi alle organizzazioni le regole operative: classificare le relazioni privacy, mantenere registri dei trattamenti e dei destinatari, verificare l’allineamento tra registri, definire la base giuridica, gestire i diritti degli interessati, controllare le clausole di fornitori e terze parti, applicare la gestione basata sulla classificazione e conservare le evidenze.

Se la tua organizzazione condivide dati personali con partner, piattaforme, affiliate, enti pubblici, fornitori di analytics, servizi di IA o partecipanti all’ecosistema SaaS, non iniziare dal contratto. Inizia dalla governance.

Utilizza Zenith Blueprint: roadmap in 30 step di un auditor per inserire la condivisione dei dati nel piano di implementazione del tuo SGSI e PIMS. Utilizza Zenith Controls: la guida alla conformità trasversale per mappare i controlli ISO/IEC 27002:2022 5.34, 5.14 e 5.20 rispetto alle aspettative di assurance di GDPR, NIS2, DORA, NIST e COBIT. Implementa quindi le politiche PIMS di Clarysec, incluse la Politica di raccolta, uso, comunicazione e condivisione delle PII, la Politica sull’inventario dei trattamenti PII e sulla base giuridica e la Politica di gestione privacy di responsabili, sub-responsabili e terze parti, affinché ogni accordo sia supportato da registri, flussi di lavoro, misure di sicurezza ed evidenze.

La prossima azione pratica è semplice: seleziona le tre relazioni di condivisione esterna dei dati a più alto rischio e testale rispetto a REG02, REG08, base giuridica, instradamento DSR, controlli sui trasferimenti, conservazione ed evidenze di audit. Se la catena delle evidenze si interrompe, Clarysec può aiutarti a ricostruirla in un modello di governance della condivisione dei dati idoneo all’audit.