Governance dei contitolari del trattamento: guida all’audit dell’Articolo 26 GDPR
La chiamata arrivò un martedì mattina. Per il CISO di CareConnect, fornitore SaaS MedTech in forte crescita, fu il momento in cui il terreno iniziò a muoversi.
Dall’altra parte c’era la Responsabile Compliance di MetroHealth, il principale partner ospedaliero. Un paziente che utilizzava la piattaforma di monitoraggio remoto gestita congiuntamente aveva presentato una richiesta di accesso ai dati personali un mese prima. Nessuna delle due organizzazioni aveva risposto in modo completo. Ciascuna riteneva che la responsabilità fosse dell’altra.
Poi l’ufficio legale inoltrò un secondo messaggio. Uno sviluppatore junior di CareConnect aveva esposto accidentalmente un endpoint API non critico che includeva un numero limitato di identificativi dei pazienti. Il problema sembrava contenibile e il termine di 72 ore per la notifica della violazione dei dati personali previsto dal GDPR non era ancora scaduto. Ma la stessa domanda bloccò entrambi i team.
Chi informa l’autorità di controllo? Chi comunica con i pazienti? Chi è responsabile dell’informativa privacy? Chi valida la richiesta dell’interessato? Chi registra la decisione?
L’accordo commerciale era dettagliato su crediti di servizio, fatturazione, limitazioni di responsabilità e milestone della roadmap di prodotto. Era quasi muto sulla realtà operativa della governance dei contitolari del trattamento ai sensi dell’Articolo 26 GDPR.
È qui che molte partnership falliscono. Il problema non è che i team privacy, legale, sicurezza e acquisti non abbiano mai sentito l’espressione “accordo tra contitolari del trattamento”. Il problema è che nessuno è in grado di dimostrare, prima dell’avvio del trattamento, chi sia responsabile di trasparenza, base giuridica, diritti degli interessati, escalation delle violazioni dei dati personali, obblighi a cascata verso i fornitori, trasferimenti, conservazione, evidenze e comunicazioni con le autorità competenti.
Il GDPR definisce l’obbligo. ISO/IEC 27701:2025 offre ai team privacy una struttura di sistema di gestione. Le politiche PIMS di Clarysec, il Zenith Blueprint: roadmap in 30 passaggi per l’auditor e Zenith Controls: la guida alla mappatura trasversale della conformità trasformano l’Articolo 26 in evidenze operative idonee all’audit.
Perché la governance dei contitolari del trattamento fallisce prima che qualcuno se ne accorga
Un rapporto di contitolarità del trattamento sussiste quando due o più parti determinano congiuntamente le finalità e i mezzi del trattamento dei dati personali. Il presupposto non è la formulazione del contratto. È il potere decisionale.
Nell’esempio di CareConnect e MetroHealth, CareConnect fornisce la piattaforma, le analisi, l’architettura tecnica, l’interfaccia utente e i flussi di dati. MetroHealth fornisce la relazione con il paziente, il contesto clinico, il modello di servizio e i dati dei pazienti. Entrambe influenzano il motivo per cui i dati personali sono trattati e il modo in cui il trattamento funziona. È una situazione molto diversa da quella di un fornitore che si limita a ospitare una banca dati o a inviare messaggi sulla base di istruzioni documentate.
Lo stesso schema si presenta in campagne di benessere finanziario, partnership assicurative embedded, marketplace online, consorzi per il rilevamento delle frodi, piattaforme sanitarie connesse, programmi fedeltà, ecosistemi di verifica dell’identità e collaborazioni di analytics. Una banca, un assicuratore e una piattaforma SaaS potrebbero decidere congiuntamente segmenti target, regole di profilazione, metriche di conversione e canali di marketing. Un accordo sul trattamento dei dati per responsabili del trattamento non risolve il problema se le parti sono in realtà contitolari del trattamento.
Le criticità operative sono prevedibili:
- L’informativa privacy dice poco più di “potremmo condividere dati con partner”.
- L’inventario dei trattamenti identifica le parti, ma non la ripartizione degli obblighi.
- Il flusso operativo per i diritti degli interessati non prevede un percorso per inoltrare, validare o rispondere alle richieste.
- Il piano di risposta agli incidenti dice “notificare al Legale”, ma non indica quale contitolare del trattamento guida la comunicazione esterna.
- Il contratto è trattato come documentazione commerciale, non come evidenza di responsabilizzazione.
- Le clausole di cessazione non coprono restituzione dei dati, cancellazione, anonimizzazione, rimozione degli accessi o conservazione delle evidenze.
L’Articolo 5 GDPR rende queste carenze rilevanti ai fini dell’audit, perché i titolari del trattamento non devono soltanto rispettare principi quali liceità, correttezza, trasparenza, limitazione delle finalità, minimizzazione, esattezza, limitazione della conservazione, integrità, riservatezza e responsabilizzazione. Devono anche essere in grado di dimostrare la conformità. L’Articolo 6 aggiunge il requisito della base giuridica. L’Articolo 3 può portare nel perimetro SaaS, fintech, health-tech e fornitori di analytics non UE quando offrono servizi a persone fisiche nell’UE o ne monitorano il comportamento.
La lezione per CISO e responsabili della conformità è diretta: la governance dei contitolari del trattamento non è “solo Legale”. È un sistema di controllo interfunzionale che coinvolge privacy, sicurezza, acquisti, prodotto, ingegneria, supporto, risposta agli incidenti, marketing e supervisione esecutiva.
Il principio PIMS di ISO/IEC 27701:2025: decidere prima dell’avvio del trattamento
Un Sistema di gestione delle informazioni sulla privacy ISO/IEC 27701:2025 funziona solo se i ruoli privacy sono definiti prima dell’inizio del trattamento. È la disciplina operativa che impedisce all’Articolo 26 di diventare un esercizio di ricostruzione post-incidente.
La Politica del Sistema di gestione delle informazioni sulla privacy di Clarysec, clausola 4.2.2, stabilisce:
[Contitolare del trattamento] Il Responsabile del fornitore / degli Acquisti DEVE documentare in REG08 l’allocazione delle responsabilità tra contitolari del trattamento prima dell’avvio del trattamento congiunto.
L’espressione “prima dell’avvio del trattamento congiunto” è il punto di controllo. Significa prima della messa in esercizio dell’integrazione della piattaforma, prima dell’abilitazione della dashboard condivisa, prima dell’avvio della sincronizzazione CRM, prima dell’attivazione dei destinatari della campagna e prima che inizino ad arrivare richieste degli interessati.
L’obbligo di inventario a supporto compare nella Politica sull’inventario dei trattamenti di dati personali e sulla base giuridica, clausola 4.3.5:
[Contitolare del trattamento] Il Responsabile del fornitore / degli Acquisti DEVE registrare in REG02 e REG08 la finalità del trattamento in contitolarità e il riferimento all’allocazione delle responsabilità prima dell’avvio del trattamento in contitolarità.
Nel loro insieme, queste clausole creano la catena delle evidenze attesa dagli auditor:
- REG02 registra l’attività di trattamento, la finalità, le categorie di dati, la base giuridica, la conservazione, i sistemi, i destinatari, i trasferimenti e il riferimento alla contitolarità del trattamento.
- REG08 registra l’accordo tra contitolari del trattamento e l’allocazione delle responsabilità.
- REG07 registra la sintesi pubblica di trasparenza.
- REG06 può registrare presa in carico, instradamento, validazione, scadenze ed evidenze di risposta per le richieste di esercizio dei diritti.
- REG10 registra le decisioni di valutazione relative a incidenti e violazioni dei dati personali.
Questa catena trasforma l’Articolo 26 da dichiarazione legale a processo di sistema di gestione.
Partire da ambito, parti interessate e RACI
Il Zenith Blueprint parte da ambito e parti interessate perché la governance dei contitolari del trattamento fallisce quando parti interessate e requisiti sono identificati troppo tardi.
Nella fase ISMS Foundation & Leadership, Step 2, Esigenze delle parti interessate e campo di applicazione del SGSI, il Zenith Blueprint raccomanda un’analisi delle parti interessate che raccolga requisiti espliciti e impliciti:
Come identificare esigenze e aspettative: per ciascun gruppo di parti interessate identificato, elencare ciò che richiede
rispetto alla sicurezza delle informazioni. Alcuni requisiti sono espliciti (leggi, contratti,
SLA), mentre altri sono impliciti (aspettative o buone pratiche generali). È utile:✓ riesaminare i requisiti legali e normativi applicabili al proprio contesto (dall’analisi
del contesto dello Step 1). Predisporre un elenco di clausole o obblighi specifici relativi alla sicurezza
delle informazioni o alla privacy.
✓ riesaminare contratti e accordi: molti contratti commerciali contengono allegati sulla riservatezza o
sulla sicurezza. Estrarre tali requisiti.
✓ svolgere interviste o workshop con le parti interessate: coinvolgere rappresentanti di
ciascun gruppo (ad esempio, un responsabile HR per la prospettiva dei dipendenti, un responsabile vendite per le
aspettative dei clienti) per comprendere preoccupazioni o esigenze.
✓ considerare norme di settore o codici di buona pratica che le parti interessate si aspettano che l’organizzazione
segua.
Per un accordo tra contitolari del trattamento ai sensi dell’Articolo 26 GDPR verificabile in sede di audit, l’analisi delle parti interessate dovrebbe includere clienti, pazienti, utenti, autorità di controllo, gli altri titolari del trattamento, responsabili del trattamento, sub-responsabili, assicuratori, provider cloud, dipartimenti interni, autorità competenti e organi di gestione.
Lo Step 4, Ruoli e responsabilità nel SGSI, trasforma poi tale analisi in titolarità operativa. Il Zenith Blueprint evidenzia il valore di un modello RACI:
✓ Responsabilizzazione vs. responsabilità operativa: uno strumento utile è la matrice RACI (Responsible,
Accountable, Consulted, Informed). Per ciascun processo o controllo principale del SGSI, identificare
chi è Responsible (esegue il lavoro), chi è Accountable (risponde in ultima istanza, spesso un
manager), chi è Consulted (fornisce input) e chi è Informed.
Per i contitolari del trattamento, nella pratica la RACI non è facoltativa. Senza di essa, il Legale presume che Privacy risponda alla richiesta, Privacy presume che Supporto gestisca la coda di presa in carico, Supporto presume che il partner risponda e il termine legale continua a decorrere.
Il modello Clarysec delle evidenze per i contitolari del trattamento
Un accordo maturo tra contitolari del trattamento dovrebbe essere comprensibile in una pagina e dimostrabile in dieci minuti. L’obiettivo non è sommergere i team di documentazione legale. L’obiettivo è rendere le responsabilità visibili, accettate e testabili.
| Elemento di evidenza | Che cosa dimostra | Posizione nel toolkit Clarysec | Titolare |
|---|---|---|---|
| Registrazione della determinazione dei ruoli | Perché le parti sono contitolari del trattamento e non responsabili del trattamento o titolari autonomi | Determinazione dei ruoli PIMS, REG08 | Responsabile privacy o Responsabile del fornitore |
| Voce dell’inventario dei trattamenti | Finalità, categorie di dati personali, base giuridica, conservazione, sistemi, destinatari e trasferimenti | REG02 | Responsabile privacy o Legale |
| Allocazione delle responsabilità | Chi gestisce informative, diritti, coordinamento delle violazioni dei dati personali, conservazione, trasferimenti, contatti di sicurezza e supporto all’audit | REG08 | Responsabile del fornitore o degli Acquisti |
| Sintesi pubblica | Come gli interessati sono informati dell’essenza dell’accordo e del punto di contatto | REG07 | Responsabile privacy o Responsabile PIMS |
| Flusso operativo per i diritti degli interessati | Presa in carico, validazione, instradamento, supporto del partner, responsabile della risposta, scadenze ed evidenze | REG06 o registro delle richieste degli interessati | Responsabile privacy e Supporto |
| Registrazione del coordinamento delle violazioni dei dati personali | Soggetto che guida la notifica, responsabile delle comunicazioni, registro decisionale, classificazione dell’incidente ed evidenze | REG10 | Responsabile degli incidenti e Responsabile privacy |
| Clausole contrattuali | Condivisione dei dati, responsabilità, audit, riservatezza, sicurezza, trasferimenti, cessazione e regole sui subcontraenti | Registro dei contratti | Legale e Acquisti |
Le politiche privacy di Clarysec rafforzano ciascun livello.
La Politica sulle informative privacy e sulla trasparenza, clausola 4.1.5, stabilisce:
[Contitolare del trattamento] Il Responsabile privacy / Responsabile PIMS DEVE registrare in REG07 la sintesi pubblica delle responsabilità dei contitolari del trattamento e il punto di contatto prima dell’avvio del trattamento in contitolarità o di una sua modifica sostanziale.
La Politica di gestione dei diritti degli interessati, clausola 6.1.5, stabilisce:
[Contitolare del trattamento] Il Responsabile privacy / Responsabile PIMS DEVE documentare in REG02, REG06 o REG08 le responsabilità per la gestione dei diritti e i canali di contatto prima dell’avvio del trattamento in contitolarità.
La Politica di gestione degli incidenti e delle violazioni dei dati personali, clausola 4.2.5, aggiunge:
[Contitolare del trattamento] Il Responsabile privacy / Responsabile PIMS DEVE verificare la responsabilità concordata per la violazione dei dati personali, la responsabilità primaria della comunicazione e l’assetto di coordinamento prima di qualsiasi notifica o comunicazione esterna da parte di un contitolare del trattamento, e DEVE registrare la decisione in REG08 e REG10.
È qui che ISO/IEC 27701:2025 e GDPR diventano operativi. L’organizzazione non si limita ad affermare che le responsabilità sono allocate. Mostra dove sono registrate, chi le ha approvate, quando sono state testate e come vengono utilizzate.
Esempio pratico: REG08 per una piattaforma di monitoraggio remoto
Si ipotizzi che CareConnect e MetroHealth gestiscano congiuntamente una piattaforma di monitoraggio remoto. Entrambe decidono perché i dati dei pazienti sono trattati, quali dati sono raccolti, come sono configurati gli alert di monitoraggio, come vengono utilizzate le analisi e come i pazienti interagiscono con il servizio.
In primo luogo, REG02 dovrebbe registrare l’attività di trattamento:
- Nome del trattamento: servizio di monitoraggio remoto dei pazienti
- Ruolo del titolare: contitolare del trattamento
- Parti: CareConnect e MetroHealth
- Finalità: monitoraggio dei pazienti, coordinamento delle cure, miglioramento del servizio, analytics della piattaforma
- Categorie di dati personali: dati di contatto, identificativi degli account, osservazioni cliniche, eventi dei dispositivi, interazioni con il supporto
- Verifica delle categorie particolari: sono trattati dati relativi alla salute e sono richieste misure di sicurezza rafforzate
- Base giuridica: documentata per ciascuna parte e finalità
- Conservazione: definita in base a requisiti clinici, di piattaforma, legali e operativi
- Sistemi: app mobile, piattaforma di monitoraggio, strumento di supporto, data warehouse di analytics, provider di identità
- Destinatari: parti contitolari del trattamento, provider di hosting, fornitori di supporto, provider di notifiche
- Trasferimenti: accesso remoto e trattamento fuori SEE valutati
- Riferimento REG08: JC-2026-004
In secondo luogo, REG08 dovrebbe allocare le responsabilità in modo comprensibile per gli operatori.
| Area di responsabilità | CareConnect | MetroHealth | Evidenza |
|---|---|---|---|
| Redazione dell’informativa privacy | Fornisce i dettagli tecnici del trattamento | Guida la formulazione rivolta ai pazienti e la pubblicazione | Registrazione dell’informativa in REG07 |
| Registrazione della base giuridica | Documenta la base per gli analytics della piattaforma | Documenta la base per l’erogazione delle cure e la relazione con il paziente | Voce della base giuridica in REG02 |
| Richieste di accesso ai dati personali | Fornisce esportazioni dei dati della piattaforma entro lo SLA concordato | Guida presa in carico, validazione, verifiche di identità e risposta | Flusso operativo REG06 |
| Richieste di rettifica e cancellazione | Esegue le modifiche approvate nei sistemi della piattaforma | Determina la gestione della cartella clinica e la comunicazione con il paziente | Log delle evidenze delle richieste degli interessati |
| Valutazione della violazione dei dati personali | Rileva, contiene e classifica gli incidenti della piattaforma | Valuta l’impatto sui pazienti e la comunicazione regolatoria | Registrazione della violazione in REG10 |
| Notifica esterna | Guida gli incidenti originati dalla piattaforma ove concordato | Guida il contatto con pazienti e autorità ove concordato | REG08 e procedure di risposta agli incidenti |
| Misure di sicurezza | Mantiene controlli di piattaforma, logging, accessi e sicurezza cloud | Mantiene gli accessi e i controlli operativi lato ospedale | SoA ed evidenze dei controlli |
| Gestione dei responsabili del trattamento | Gestisce sub-responsabili cloud e SaaS | Gestisce responsabili del trattamento dell’ospedale e destinatari a valle | Registro dei fornitori |
| Conservazione e cancellazione | Cancella o anonimizza le registrazioni della piattaforma secondo il piano | Conferma le regole di conservazione clinica e cancellazione a valle | Registro di conservazione |
| Evidenze di audit | Fornisce log, politiche, risultati dei test e attestazioni | Fornisce approvazioni di governance e registrazioni dei diritti | Tracker delle richieste di audit |
In terzo luogo, REG07 dovrebbe registrare la sintesi pubblica. L’informativa deve spiegare in linguaggio chiaro l’essenza dell’accordo congiunto, identificare i contitolari del trattamento, descrivere le rispettive responsabilità e fornire un punto di contatto utilizzabile. Non deve obbligare pazienti o utenti a decodificare la complessità operativa interna.
In quarto luogo, il flusso operativo deve essere testato prima del lancio. Inviare una richiesta di accesso simulata al punto di contatto pubblicato. Confermare che il Supporto la identifichi come richiesta di esercizio dei diritti dell’interessato, la instradi a Privacy, verifichi REG08, richieda input al partner, registri le azioni in REG06 e produca un pacchetto di risposta. Eseguire quindi un’esercitazione tabletop su una violazione dei dati personali usando uno scenario come “un endpoint API espone identificativi dei pazienti a utenti non autorizzati” oppure “utenti con cancellazione sospesa vengono accidentalmente inclusi in una campagna di engagement”.
Questi test fanno emergere le vere lacune: caselle di posta senza proprietario, SLA dei partner non chiari, testo dell’informativa non approvato, registrazioni incomplete della base giuridica, verifiche mancanti sulle categorie particolari e procedure di risposta agli incidenti che non indicano il responsabile della comunicazione esterna.
Mappare l’Articolo 26 ai controlli ISO/IEC 27002:2022 tramite Zenith Controls
Un accordo tra contitolari del trattamento non è soltanto un artefatto legale. Deve essere supportato da controlli tecnici e organizzativi. Zenith Controls aiuta i team a mappare le aspettative dei controlli ISO/IEC 27001:2022 e ISO/IEC 27002:2022 alle evidenze privacy, fornitori, incidenti, cloud e governance.
Tre controlli ISO/IEC 27002:2022 sono particolarmente rilevanti.
Controllo 5.2, Ruoli e responsabilità per la sicurezza delle informazioni, supporta il modello operativo. Si collega alla clausola 5.3 di ISO/IEC 27001:2022, ruoli, responsabilità e autorità nell’organizzazione. Supporta anche la preparazione agli incidenti, perché ruoli non chiari compromettono il Controllo 5.24 di ISO/IEC 27002:2022, Pianificazione e preparazione della gestione degli incidenti di sicurezza delle informazioni. Nella governance dei contitolari del trattamento, il Controllo 5.2 è il punto in cui RACI, proprietari REG08, gestori delle richieste degli interessati, responsabili delle violazioni dei dati personali e contatti di escalation diventano evidenze di audit.
Controllo 5.31, Requisiti legali, statutari, regolamentari e contrattuali, è il punto in cui l’Articolo 26 GDPR entra nel SGSI invece di restare una questione solo legale. Supporta l’identificazione e la gestione della responsabilizzazione prevista dall’Articolo 5 GDPR, della base giuridica dell’Articolo 6, dell’allocazione delle responsabilità dell’Articolo 26, della sicurezza dell’Articolo 32, della notifica all’autorità di controllo dell’Articolo 33 e della comunicazione agli interessati dell’Articolo 34. Si collega inoltre alla clausola 4.2 di ISO/IEC 27001:2022, comprensione delle esigenze e aspettative delle parti interessate, e alla clausola 6.1.3, trattamento dei rischi per la sicurezza delle informazioni.
Controllo 5.34, Privacy e protezione dei dati personali, integra la protezione dei dati personali nel modello operativo di sicurezza. È particolarmente importante quando l’accordo utilizza analytics cloud, dashboard condivise, data clean room, piattaforme di monitoraggio, automazione marketing o strumenti di supporto. Le misure di sicurezza correlate possono includere il Controllo 5.23 di ISO/IEC 27002:2022, Sicurezza delle informazioni per l’uso dei servizi cloud, e il Controllo 8.11, Mascheramento dei dati.
Anche l’ecosistema ISO di supporto è rilevante. ISO/IEC 27018 supporta i casi in cui i servizi cloud pubblici trattano dati personali. ISO/IEC 29100 fornisce principi privacy quali trasparenza, consenso, finalità legittima, limitazione della raccolta, minimizzazione dei dati, limitazione dell’uso, esattezza, misure di sicurezza e responsabilizzazione. ISO/IEC 27001:2022 fornisce la dorsale del sistema di gestione tramite contesto, parti interessate, campo di applicazione, leadership, valutazione del rischio, trattamento del rischio, Dichiarazione di Applicabilità, audit interno, riesame della direzione e miglioramento continuo.
I contratti devono rispecchiare il modello operativo
Un accordo tra contitolari del trattamento non può vivere solo in un’informativa privacy. Deve riflettersi in contratti, allegati, procedure operative, procedure di risposta agli incidenti, percorsi di escalation e clausole di cessazione.
La Politica di conformità legale e normativa di Clarysec, clausola 5.3.1.2, include esplicitamente nella governance le tipologie contrattuali, tra cui:
Contratti che comportano condivisione dei dati, diritti di proprietà intellettuale, limitazioni di responsabilità o clausole di audit
La Politica di protezione dei dati e privacy, clausola 5.1, stabilisce il fondamento aziendale:
L’organizzazione deve mantenere un quadro formale di governance della privacy integrato nel Sistema di gestione della sicurezza delle informazioni (SGSI) per applicare questa politica.
Per le PMI, lo stesso principio è proporzionato alla realtà operativa. La Politica di protezione dei dati e privacy per PMI, clausola 5.2.1, stabilisce:
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
La clausola 5.2.2 aggiunge:
I contratti con terze parti che trattano dati personali devono includere clausole di protezione dei dati e devono essere riesaminati dal Direttore generale o dal consulente legale
Questa è governance proporzionata. Una multinazionale può disporre di team distinti per legale, privacy, acquisti, sicurezza, rischio e conformità. Una PMI può fare affidamento su un Coordinatore privacy, un Direttore generale e un consulente legale esterno. L’aspettativa sulle evidenze resta la stessa: attività di trattamento, responsabilità, base giuridica, informative, gestione dei diritti, escalation degli incidenti e obblighi di cessazione devono essere documentati e riesaminabili.
Il Zenith Blueprint, Step 23, Controlli organizzativi, supporta la disciplina degli accordi con i fornitori tramite riservatezza, responsabilità di controllo degli accessi, misure tecniche e organizzative, tempistiche di segnalazione degli incidenti, diritti di audit, controlli sui subcontraenti e clausole di fine contratto. Nei rapporti di contitolarità del trattamento, tali clausole devono essere adattate alla condivisione dei dati e all’allocazione delle responsabilità, invece di essere copiate da un modello per responsabili del trattamento.
Governance degli incidenti e delle violazioni dei dati personali: decidere il responsabile prima della violazione
Le violazioni dei dati personali in contitolarità diventano caotiche quando i team aspettano l’incidente per decidere chi comunica all’esterno.
Il GDPR definisce una violazione dei dati personali come una violazione di sicurezza che comporta accidentalmente o in modo illecito la distruzione, la perdita, la modifica, la divulgazione non autorizzata o l’accesso ai dati personali. Ove richiesta, la notifica all’autorità di controllo deve avvenire senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui si è venuti a conoscenza della violazione. NIS2 e DORA possono aggiungere ulteriori aspettative in materia di segnalazione degli incidenti cyber e comunicazione ai clienti.
La Politica di risposta agli incidenti per PMI di Clarysec, clausola 5.3.2, coglie la disciplina temporale:
Le tempistiche di risposta, inclusi il ripristino dei dati e gli obblighi di notifica, devono essere documentate e allineate ai requisiti legali, come il requisito GDPR di notifica delle violazioni dei dati personali entro 72 ore.
Il Zenith Blueprint, Step 5, Comunicazione, sensibilizzazione e competenza, sottolinea la pianificazione delle comunicazioni esterne, incluse quelle verso clienti, autorità competenti, partner e pubblico. Per i contitolari del trattamento, la matrice degli incidenti dovrebbe identificare chi esegue la classificazione iniziale della violazione dei dati personali, chi contatta l’altro titolare, chi determina se sono coinvolti dati personali, chi valuta le soglie di notifica, chi redige le notifiche all’autorità, chi comunica con gli interessati, chi coordina le segnalazioni NIS2 o DORA, chi approva le dichiarazioni pubbliche e chi registra le evidenze in REG10.
Se l’accordo coinvolge un’entità finanziaria soggetta a DORA, il processo di gestione degli incidenti dovrebbe supportare anche la classificazione degli incidenti gravi connessi alle ICT, l’escalation all’alta direzione, gli aggiornamenti intermedi, la relazione finale e la comunicazione ai clienti quando sono interessati interessi finanziari. Se l’organizzazione rientra nell’ambito di applicazione di NIS2, la segnalazione degli incidenti significativi può richiedere notifiche per fasi e comunicazioni ai destinatari del servizio.
La prassi più sicura è un’esercitazione tabletop congiunta prima del lancio. Un buono scenario obbliga i team a usare REG08, REG10, la procedura di risposta agli incidenti, i contatti dei partner, i modelli di notifica, gli alberi di escalation e i log delle evidenze sotto pressione temporale.
Mappatura trasversale della conformità: l’Articolo 26 raramente vive da solo
Gli accordi tra contitolari del trattamento si collocano spesso in ecosistemi regolamentati più ampi. Una campagna fintech, una piattaforma sanitaria connessa, un rapporto di servizio gestito, un’integrazione con un marketplace cloud o una partnership di infrastruttura digitale possono attivare obblighi oltre il GDPR.
NIS2 può applicarsi a entità essenziali o importanti, medie e grandi, in settori quali infrastruttura digitale, cloud computing, data center, fornitori di servizi gestiti, fornitori di servizi di sicurezza gestiti, marketplace online, motori di ricerca e piattaforme di social networking. L’Articolo 20 NIS2 attribuisce agli organi di gestione la supervisione della gestione dei rischi di cibersicurezza. L’Articolo 21 richiede misure tecniche, operative e organizzative, incluse analisi dei rischi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, sviluppo sicuro, gestione delle vulnerabilità, formazione, cifratura, sicurezza HR, controllo degli accessi, gestione degli asset e autenticazione. L’Articolo 23 introduce la segnalazione per fasi degli incidenti significativi.
DORA si applica dal 17 gennaio 2025 a molte entità finanziarie. Copre gestione del rischio ICT, segnalazione degli incidenti gravi connessi alle ICT, test della resilienza operativa digitale, rischio ICT di terze parti, accordi contrattuali con fornitori ICT e supervisione dei fornitori terzi critici di servizi ICT. L’Articolo 5 DORA colloca la governance del rischio ICT a livello di organo di gestione. Gli Articoli da 8 a 14 coprono identificazione degli asset, protezione, rilevazione, continuità, backup, ripristino, lezioni apprese, formazione e comunicazioni di crisi. Gli Articoli da 17 a 20 definiscono ciclo di vita e segnalazione degli incidenti. Gli Articoli da 28 a 30 rendono obblighi centrali il rischio ICT di terze parti, le clausole contrattuali, i registri, il rischio di concentrazione, i diritti di audit e la pianificazione dell’uscita.
NIST CSF 2.0 fornisce un livello pratico di integrazione. La sua Funzione GOVERN include obblighi legali, normativi, contrattuali, privacy e relativi alle libertà civili, responsabilizzazione della leadership, propensione al rischio, politiche, supervisione e rischio dei fornitori. Outcome come GV.OC-03 e GV.SC-02 si allineano naturalmente alle evidenze dell’Articolo 26 perché richiedono che obblighi legali e ruoli dei partner siano compresi, gestiti, comunicati e coordinati.
| Prospettiva di conformità | Che cosa richiede in un accordo tra contitolari del trattamento | Evidenze Clarysec |
|---|---|---|
| GDPR | Chi determina finalità e mezzi, come sono allocate le responsabilità, come sono informati gli interessati e come sono gestiti diritti e violazioni dei dati personali | REG02, REG07, REG08, REG10, log delle richieste degli interessati |
| ISO/IEC 27701:2025 PIMS | Se ruoli privacy, registri dei trattamenti, base giuridica, trasparenza, flussi operativi per i diritti, gestione degli incidenti ed evidenze di responsabilizzazione sono gestiti sistematicamente | Politiche PIMS, registri, evidenze del riesame della direzione |
| ISO/IEC 27001:2022 | Se requisiti legali, obblighi privacy, dipendenze dai fornitori, uso del cloud, ruoli negli incidenti e trattamento del rischio sono inclusi nel SGSI | Campo di applicazione, registro delle parti interessate, Registro dei rischi, SoA, evidenze dell’Annex A |
| NIS2 | Se governance, gestione degli incidenti, catena di fornitura, controllo degli accessi, continuità, formazione e segnalazione sono integrati | Piano di risposta agli incidenti, Registro dei fornitori, registrazioni della formazione, test di continuità |
| DORA | Se rischio ICT di terze parti, segnalazione degli incidenti, test di resilienza, protezione dei dati e controlli contrattuali sono governati per i servizi finanziari | Registro ICT, clausole contrattuali, classificazione degli incidenti, strategie di uscita |
| NIST CSF 2.0 | Se gli esiti di governance attuali e target, il rischio dei fornitori, la risposta agli incidenti e il ripristino sono definiti e misurabili | Profilo CSF, piano di gap, POA&M, Registro dei rischi |
| COBIT 2019 | Se obiettivi di governance, responsabilizzazione, misurazione delle prestazioni ed evidenze di assurance sono tracciabili agli obiettivi aziendali | RACI, metriche dei controlli, reportistica alla direzione, pacchetto di evidenze di audit |
Il vantaggio del modello Clarysec è il riutilizzo delle evidenze. REG08 non è solo una registrazione GDPR. Supporta la responsabilizzazione ISO/IEC 27701:2025, la governance ISO/IEC 27001:2022, la chiarezza dei ruoli dei fornitori in NIST CSF 2.0, la governance delle terze parti DORA quando sono coinvolti servizi finanziari e la supervisione della direzione NIS2 quando l’entità rientra nell’ambito di applicazione.
Che cosa testeranno auditor e autorità competenti
Valutatori diversi affronteranno la governance dei contitolari del trattamento da prospettive diverse, ma convergeranno sulla stessa domanda centrale: l’organizzazione può dimostrare che la responsabilizzazione funziona?
| Prospettiva dell’auditor | Probabile domanda di audit | Evidenze da predisporre |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | I requisiti legali, normativi, contrattuali, privacy, dei fornitori, degli incidenti e del cloud sono identificati e inclusi nell’ambito del SGSI e nel trattamento del rischio? | Campo di applicazione, registro delle parti interessate, Registro di conformità, Valutazione del rischio, SoA, controlli sui fornitori |
| Auditor PIMS ISO/IEC 27701:2025 | I ruoli PIMS sono determinati e le responsabilità dei contitolari del trattamento sono documentate prima dell’avvio del trattamento? | REG02, REG07, REG08, flussi operativi per i diritti, registrazioni delle violazioni dei dati personali, riesame della direzione |
| Auditor focalizzato su GDPR o revisore DPO | L’organizzazione può dimostrare la responsabilizzazione dell’Articolo 5 e l’allocazione delle responsabilità dell’Articolo 26? | Accordo tra contitolari del trattamento, sintesi dell’informativa, registrazioni della base giuridica, log delle richieste degli interessati, log decisionali sulle violazioni dei dati personali |
| Valutatore NIST CSF 2.0 | Gli esiti privacy, legali, dei fornitori, degli incidenti e del ripristino sono rappresentati nei Current e Target Profile con un piano di rimedio? | Profilo CSF, gap analysis, Registro dei rischi, POA&M, monitoraggio dei fornitori |
| Revisore DORA | Le dipendenze ICT da terze parti, la segnalazione degli incidenti, la resilienza, i diritti contrattuali e le strategie di uscita sono governati quando sono coinvolti servizi finanziari? | Registro dei contratti ICT, classificazione degli incidenti, test di resilienza, diritti di audit, strategia di uscita |
| Supervisore NIS2 | La direzione ha approvato e supervisionato misure di rischio, sicurezza dei fornitori, gestione degli incidenti, continuità, controlli di accesso e formazione? | Verbali del consiglio di amministrazione, politiche, piano di risposta agli incidenti, test di continuità, registrazioni della formazione, riesami del rischio dei fornitori |
| Auditor COBIT 2019 o ISACA | La responsabilizzazione è assegnata, monitorata, misurata e rendicontata attraverso le strutture di governance? | RACI, KPI, test dei controlli, reportistica alla direzione, rimedio degli issue |
La postura di audit più solida è la tracciabilità. Si parte dal requisito legale, lo si collega alla politica PIMS, si indica la voce di registro, si mostra il flusso operativo e poi si mostrano evidenze di test o la registrazione di un caso reale.
Ad esempio, l’Articolo 26 GDPR richiede l’allocazione delle responsabilità dei contitolari del trattamento. La Politica del Sistema di gestione delle informazioni sulla privacy richiede REG08 prima dell’avvio del trattamento. REG08 mostra l’allocazione delle responsabilità per informative, diritti, violazioni dei dati personali, conservazione, gestione dei fornitori e contatti. REG07 mostra la sintesi pubblica. Una simulazione di richiesta di esercizio dei diritti dimostra che il flusso operativo funziona. I verbali del riesame della direzione mostrano eccezioni, decisioni e miglioramenti.
Questa è governance verificabile in sede di audit.
Il riesame della direzione trasforma il rischio privacy in responsabilizzazione esecutiva
La governance dei contitolari del trattamento non dovrebbe essere nascosta in una cartella privacy. Appartiene al riesame della direzione perché incide su esposizione regolatoria, fiducia dei clienti, fiducia dei pazienti, preparazione agli incidenti, rischio dei fornitori, responsabilità contrattuale e resilienza operativa.
ISO/IEC 27001:2022 richiede impegno della leadership, ruoli, risorse, allineamento delle politiche, pianificazione basata sul rischio, valutazione delle prestazioni e miglioramento continuo. NIS2 attribuisce obblighi di supervisione della cibersicurezza agli organi di gestione. DORA attribuisce all’organo di gestione la responsabilità ultima del rischio ICT per le entità finanziarie.
La Politica sui ruoli e sulle responsabilità di governance per PMI di Clarysec, clausola 5.5, stabilisce:
Tutte le decisioni, eccezioni ed escalation significative in materia di sicurezza devono essere registrate e tracciabili.
Per le organizzazioni enterprise, la Politica sui ruoli e sulle responsabilità di governance, clausola 5.2, richiede:
Deve essere mantenuto un Registro dei ruoli e delle responsabilità che deve includere:
Quel registro dovrebbe includere i ruoli di governance privacy quando incidono su sicurezza, risposta agli incidenti, assurance dei fornitori, resilienza operativa e reporting esecutivo. Le eccezioni relative ai contitolari del trattamento dovrebbero essere sottoposte a escalation prima del lancio, non scoperte dopo un reclamo.
Un pacchetto pratico di riesame della direzione dovrebbe includere:
- Accordi nuovi e modificati tra contitolari del trattamento
- Stato di completamento di REG08
- Attività di trattamento ad alto rischio e stato DPIA, ove applicabile
- Questioni aperte su base giuridica o trasparenza
- Prestazioni nella gestione delle richieste degli interessati e azioni dei partner scadute
- Risultati delle esercitazioni tabletop sulle violazioni dei dati personali e lacune irrisolte
- Dipendenze da fornitori, sub-responsabili, cloud e trasferimenti
- Eccezioni relative a conservazione e cessazione
- Risultanze dell’audit e stato delle azioni di rimedio
- Impatto sul reporting GDPR, NIS2, DORA, NIST CSF 2.0 e COBIT 2019
Un approccio Clarysec in cinque passaggi per rendere l’Articolo 26 verificabile in sede di audit
Se la tua organizzazione condivide con un’altra parte il potere decisionale sul trattamento dei dati personali, non attendere un reclamo, un audit, una violazione dei dati personali o una controversia con il partner per chiarire le responsabilità.
Usa questo approccio in cinque passaggi:
- Usa lo Step 2 di Zenith Blueprint per identificare parti interessate, requisiti legali, aspettative dei partner, obblighi privacy e ambito normativo.
- Usa lo Step 4 di Zenith Blueprint per costruire una RACI su informative, base giuridica, diritti, comunicazione delle violazioni dei dati personali, conservazione, trasferimenti, fornitori, evidenze di audit e cessazione.
- Registra l’attività di trattamento in REG02 e l’allocazione delle responsabilità tra contitolari del trattamento in REG08 usando il set di politiche PIMS di Clarysec.
- Mappa l’accordo tramite Zenith Controls, in particolare ISO/IEC 27002:2022 Controllo 5.2, Controllo 5.31 e Controllo 5.34.
- Testa l’accordo con una simulazione di richiesta di esercizio dei diritti degli interessati e un’esercitazione tabletop su una violazione dei dati personali prima dell’avvio del trattamento.
CareConnect e MetroHealth non avevano bisogno di ulteriore allineamento informale. Avevano bisogno di un’allocazione documentata delle responsabilità, una sintesi pubblica, un flusso operativo per i diritti, una registrazione del coordinamento delle violazioni dei dati personali, clausole contrattuali ed evidenze del riesame della direzione.
Questa è la differenza tra “pensavamo se ne occupasse il partner” e “ecco l’accordo approvato, l’informativa, il flusso operativo, le evidenze di test e la registrazione decisionale sulla violazione dei dati personali”.
Clarysec può aiutarti ad applicare la governance PIMS ISO/IEC 27701:2025, allinearla all’Articolo 26 GDPR, integrarla nel tuo SGSI ISO/IEC 27001:2022 e produrre evidenze idonee all’audit rispetto alle aspettative di GDPR, NIS2, DORA, NIST CSF 2.0 e COBIT 2019.
Vuoi sostituire l’ambiguità della contitolarità del trattamento con evidenze idonee all’audit? Esplora il Zenith Blueprint: roadmap in 30 passaggi per l’auditor, usa Zenith Controls: la guida alla mappatura trasversale della conformità oppure contatta Clarysec per una valutazione PIMS e SGSI che trasformi l’Articolo 26 in un sistema di controllo operativo prima che la tua prossima partnership vada in esercizio.
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
