Governance delle modifiche ai sub-responsabili del trattamento per SaaS e MSP
Sarah, CISO di un provider SaaS FinTech in rapida crescita, aprì quella che sembrava una normale comunicazione di aggiornamento del servizio inviata da un fornitore di infrastruttura critica. Nascosta sotto la voce “ottimizzazioni del servizio”, una frase le cambiò la settimana:
“Per migliorare le prestazioni delle funzionalità di analytics, i carichi di lavoro relativi al trattamento dei dati saranno migrati al nostro nuovo partner, DataCrunch Analytics, con efficacia tra 30 giorni.”
Trenta giorni. Un nuovo partner per l’analytics. Una verifica rapida mostrò che il provider aveva sede fuori dall’UE.
Il team di ingegneria vedeva un normale miglioramento del fornitore. Gli Acquisti presumevano che l’accordo esistente fosse sufficiente. Il team di gestione clienti non aveva pianificato alcuna campagna di notifica. L’ufficio legale non aveva riesaminato le implicazioni del trasferimento. Sarah vide subito il vero problema: la sua società agiva come responsabile del trattamento per centinaia di istituzioni finanziarie in tutta Europa. Quei clienti erano titolari del trattamento ai sensi del GDPR. Alcuni avevano negoziato un preavviso per i nuovi sub-responsabili del trattamento. Alcuni disponevano di diritti di opposizione. Diversi avevano obblighi di outsourcing e di gestione del rischio ICT di terze parti derivanti da DORA. Alcuni avevano dichiarazioni rigorose sull’ubicazione dei dati che non potevano essere modificate in modo silente.
Questo è il momento in cui molti provider SaaS, MSP, MSSP e fornitori di servizi cloud scoprono che la governance dei sub-responsabili del trattamento non è un’attività amministrativa della funzione privacy. È gestione del rischio fornitori, conformità contrattuale, resilienza operativa, comunicazione ai clienti ed evidenze di audit in un unico flusso operativo.
Una pagina pubblica dei sub-responsabili del trattamento non è sufficiente. Una nota a piè di pagina del fornitore non è sufficiente. Un questionario di sicurezza non è sufficiente. Un processo difendibile deve mostrare chi ha valutato il sub-responsabile del trattamento, quali dati vengono trattati, quali clienti sono interessati, quali accordi richiedono la notifica, se le opposizioni sono state gestite prima dell’utilizzo, come sono state collegate le evidenze relative ai trasferimenti internazionali e dove sono conservate le evidenze finali.
Clarysec tratta questo ambito come un modello di controllo governato, non come una catena di e-mail ad hoc. Il flusso operativo collega gestione privacy, assurance dei fornitori, riesame legale, rischio della catena di fornitura ICT, notifica ai clienti ed evidenze di audit tramite le politiche Clarysec, Zenith Blueprint: roadmap in 30 passaggi per l’auditor e Zenith Controls: guida alla conformità trasversale.
Perché le modifiche ai sub-responsabili del trattamento sono eventi ad alto rischio fornitori
Una modifica ai sub-responsabili del trattamento può alterare da un giorno all’altro il profilo di rischio di un servizio. Può cambiare il luogo in cui sono ospitati i dati personali dei clienti, il luogo da cui vi si accede, chi dispone di accesso privilegiato per il supporto, per quanto tempo vengono conservati i log, come vengono gestiti gli escalation degli incidenti, quali responsabilità di cifratura si applicano e se è necessario un nuovo strumento per i trasferimenti internazionali.
Per i provider SaaS e i fornitori di servizi gestiti, i sub-responsabili del trattamento spesso si collocano all’interno della catena di erogazione del prodotto. Possono includere provider di hosting cloud, piattaforme di ticketing, servizi di invio e-mail, strumenti di analytics basati sull’IA, piattaforme per elaborazioni in background, fornitori di osservabilità, strumenti di supporto, prestatori di servizi di pagamento, fornitori di servizi di sicurezza gestiti e servizi di arricchimento dei dati. Molti di questi provider trattano dati personali dei clienti anche quando i team li descrivono come strumenti di “infrastruttura” o “operativi”.
Ai sensi del GDPR, questo è rilevante perché Article 28 richiede ai responsabili del trattamento di gestire i responsabili a valle sulla base dell’autorizzazione del titolare del trattamento. Se viene utilizzata un’autorizzazione scritta generale, il responsabile del trattamento deve informare il titolare del trattamento delle aggiunte o sostituzioni previste e offrirgli la possibilità di opporsi. Article 28(4) richiede inoltre che al sub-responsabile del trattamento siano imposti obblighi equivalenti in materia di protezione dei dati. Article 5(2) aggiunge il principio di responsabilizzazione, il che significa che l’organizzazione deve essere in grado di dimostrare la conformità, non limitarsi a dichiararla.
DORA innalza il livello di attenzione per i servizi finanziari. Gli enti finanziari devono gestire il rischio ICT di terze parti come parte integrante della gestione del rischio ICT. Devono mantenere registri degli accordi contrattuali, valutare il rischio di concentrazione, comprendere le catene di subappalto, definire misure contrattuali di sicurezza, garantire diritti di audit e accesso, supportare la cooperazione sugli incidenti e pianificare l’uscita. Anche se un provider SaaS non è direttamente un ente finanziario, i suoi clienti finanziari si aspettano evidenze perché devono soddisfare a loro volta i requisiti DORA.
NIS2 amplia la prospettiva alla sicurezza della catena di fornitura e alla responsabilità dell’organo di gestione. Article 21 richiede misure tecniche, operative e organizzative adeguate, incluse sicurezza della catena di fornitura, gestione degli incidenti, continuità operativa, controllo degli accessi, gestione degli asset, acquisizione e manutenzione sicure e valutazione dell’efficacia. Article 20 attribuisce agli organi di gestione la responsabilità di supervisione. Per fornitori di servizi cloud, fornitori di servizi gestiti, fornitori di servizi di sicurezza gestiti, provider di data center, prestatori di servizi fiduciari, marketplace online, motori di ricerca e determinati servizi di comunicazione, la visibilità sui sub-responsabili del trattamento diventa parte della governance della cibersicurezza.
ISO/IEC 27001:2022 e ISO/IEC 27701:2025 rendono operativo questo requisito. ISO/IEC 27001:2022 richiede che il SGSI comprenda il contesto, i requisiti delle parti interessate, i rischi, i piani di trattamento del rischio, i controlli operativi e le informazioni documentate. ISO/IEC 27701:2025 estende tale disciplina di sistema di gestione alla gestione delle informazioni sulla privacy. Un PIMS orientato al ruolo di responsabile del trattamento deve dimostrare che il trattamento a valle dei dati personali dei clienti è compreso, controllato, governato contrattualmente, monitorato e supportato da evidenze.
Il modello Clarysec: censire, valutare, notificare, gestire le opposizioni, contrattualizzare, collegare i trasferimenti, conservare le evidenze
Il modello più solido di governance dei sub-responsabili del trattamento è abbastanza semplice da essere seguito dai team operativi e abbastanza rigoroso da essere verificato dagli auditor. Clarysec usa sette verbi:
- Censire ogni sub-responsabile del trattamento attuale e proposto.
- Valutare i rischi privacy, sicurezza, resilienza e dipendenza prima dell’utilizzo.
- Notificare i clienti secondo l’accordo applicabile.
- Gestire le opposizioni entro la finestra concordata.
- Aggiornare DPA, allegato di sicurezza e obblighi a cascata.
- Collegare hosting, luogo del trattamento ed evidenze di trasferimento internazionale.
- Conservare le evidenze nei registri privacy e fornitori.
Il primo riferimento operativo è la Politica di gestione privacy di responsabili, sub-responsabili e terze parti. Stabilisce:
[Responsabile del trattamento] Il Responsabile del fornitore / degli Acquisti DEVE mantenere in REG08 l’elenco dei sub-responsabili del trattamento e dei subappaltatori utilizzati per trattare dati personali dei clienti prima dell’utilizzo e aggiornare REG08 entro 10 giorni lavorativi dopo una modifica approvata.
Questa clausola trasforma un elenco di sub-responsabili del trattamento in un registro controllato. Rende inoltre esplicita la tempistica: REG08 è aggiornato prima dell’utilizzo e poi aggiornato entro 10 giorni lavorativi dopo una modifica approvata.
La stessa politica rende verificabile in audit la notifica al cliente:
[Responsabile del trattamento] Il Responsabile del fornitore / degli Acquisti DEVE notificare al cliente i nuovi sub-responsabili del trattamento o le sostituzioni previste secondo l’accordo cliente applicabile prima dell’utilizzo e registrare in REG08 la notifica, il periodo di opposizione e l’esito.
Questo è il dettaglio mancante in molti programmi. La questione non è solo se sia stata aggiornata una pagina pubblica. La questione è se i clienti corretti siano stati notificati nel modo richiesto, prima che il sub-responsabile del trattamento trattasse i loro dati personali, con periodo di opposizione ed esito conservati come evidenze.
La politica collega inoltre la governance delle modifiche alla due diligence:
[Tutti] Il Responsabile del fornitore / degli Acquisti DEVE completare in REG08 le evidenze di due diligence privacy prima di selezionare, rinnovare o modificare in modo sostanziale qualsiasi rapporto con un responsabile del trattamento, sub-responsabile del trattamento o terza parte che tratti o acceda a dati personali.
Una modifica sostanziale può includere la sostituzione dell’infrastruttura, l’aggiunta di un provider di analytics a valle, lo spostamento delle regioni di hosting, l’abilitazione dell’accesso per il supporto da un nuovo Paese, l’ampliamento delle categorie di dati o la modifica del comportamento di conservazione di un servizio.
Infine, la politica chiude la lacuna degli obblighi contrattuali a cascata:
[Responsabile del trattamento] Il Responsabile del fornitore / degli Acquisti DEVE assicurare che ogni contratto con un sub-responsabile del trattamento contenga obblighi a cascata in materia di privacy, sicurezza, assistenza, restituzione, cancellazione, interfaccia per gli incidenti e collegamento ai trasferimenti prima che il sub-responsabile del trattamento tratti dati personali.
Questo è importante perché un allegato di sicurezza generico non è sempre sufficiente. Gli obblighi specifici del responsabile del trattamento devono essere trasferiti a valle prima dell’inizio del trattamento.
Dove le politiche Clarysec collegano privacy, fornitori e trasferimenti
La governance dei sub-responsabili del trattamento funziona solo quando privacy, legale, sicurezza dei fornitori e gestione operativa delle modifiche usano la stessa catena di evidenze.
La Politica di conformità legale e normativa - PMI stabilisce la regola precedente alla condivisione:
Le clausole dell’Accordo sul trattamento dei dati (DPA) o termini contrattuali equivalenti devono essere concordati prima della condivisione di dati personali o sensibili.
Per gli ambienti enterprise, la Politica di conformità legale e normativa rende più granulare l’aspettativa sulle evidenze richiedendo:
Comunicazioni relative ai sub-responsabili del trattamento e dichiarazioni sui trasferimenti geografici dei dati
Identifica inoltre eventi di governance relativi a:
Modifiche agli strumenti di trasferimento dei dati, ai sub-responsabili del trattamento o ai flussi di dati transfrontalieri
La Politica di sicurezza delle terze parti e dei fornitori stabilisce:
L’utilizzo di subappaltatori è subordinato al previo consenso scritto
Per le organizzazioni più piccole, la Politica di sicurezza delle terze parti e dei fornitori - PMI fornisce una versione scalabile:
Restrizioni all’ulteriore subappalto senza approvazione
Rende inoltre esplicita la rivalutazione delle modifiche dei fornitori:
Tutte le modifiche dei fornitori, incluse proprietà, tipologia di servizio, luogo di hosting o subappalto, devono essere rivalutate per impatto sul rischio e rilevanza contrattuale.
La Politica di protezione dei dati e privacy include:
Requisiti di approvazione dei sub-responsabili del trattamento
La Politica di gestione del rischio di dipendenza dai fornitori aggiunge la prospettiva della resilienza:
Comunicazione dei subappaltatori: il fornitore deve informarci dei subappaltatori principali e di qualsiasi relativa modifica, in particolare quando tali modifiche creano livelli aggiuntivi di dipendenza.
Insieme, queste politiche creano una regola operativa completa: nessuna condivisione di dati personali senza termini contrattuali, nessun sub-responsabile del trattamento nascosto, nessun subappalto non governato, nessuna modifica di hosting o ubicazione non valutata e nessuna approvazione senza evidenze di trasferimento ove pertinenti.
Come Zenith Controls inquadra l’insieme dei controlli sui fornitori
In Zenith Controls, Clarysec mappa la governance delle modifiche ai sub-responsabili del trattamento principalmente sui controlli ISO/IEC 27002:2022 relativi a fornitori e requisiti legali. Questo è importante perché dimostra che la governance dei sub-responsabili del trattamento non è soltanto un processo privacy. È anche un controllo di sicurezza delle informazioni, gestione dei fornitori, conformità legale e resilienza.
| Controllo ISO/IEC 27002:2022 | Nome del controllo | Ruolo nella governance dei sub-responsabili del trattamento |
|---|---|---|
| 5.19 | Sicurezza delle informazioni nei rapporti con i fornitori | Stabilisce la base di gestione del rischio fornitori per identificare e gestire i provider che accedono a informazioni o sistemi |
| 5.20 | Gestione della sicurezza delle informazioni negli accordi con i fornitori | Assicura che gli accordi includano obblighi di sicurezza, privacy, subappalto, incidente, audit, cancellazione e trasferimento |
| 5.21 | Gestione della sicurezza delle informazioni nella catena di fornitura ICT | Supporta la visibilità sulle dipendenze ICT a valle e sui rischi della catena di fornitura |
| 5.22 | Monitoraggio, riesame e gestione delle modifiche dei servizi dei fornitori | Fornisce il controllo operativo per rivalutare le modifiche dei fornitori, inclusi nuovi sub-responsabili del trattamento e modifiche di hosting |
| 5.23 | Sicurezza delle informazioni per l’utilizzo dei servizi cloud | Si applica quando i sub-responsabili del trattamento forniscono hosting cloud, piattaforme cloud, SaaS o trattamento basato sul cloud |
| 5.31 | Requisiti legali, statutari, normativi e contrattuali | Collega il flusso operativo a GDPR, DORA, NIS2, DPA dei clienti, obblighi di trasferimento e doveri contrattuali di notifica |
Zenith Controls descrive il controllo 5.22, “Monitoraggio, riesame e gestione delle modifiche dei servizi dei fornitori”, come un controllo preventivo a supporto di riservatezza, integrità e disponibilità, allineato al concetto di cibersicurezza Identify e alle capacità operative per la sicurezza dei rapporti con i fornitori e l’assurance della sicurezza delle informazioni. È esattamente ciò che richiede una modifica ai sub-responsabili del trattamento: identificare la modifica, rivalutare il rischio, confermare la copertura contrattuale e conservare le evidenze di assurance.
Per il controllo 5.20, Zenith Controls inquadra gli accordi con i fornitori come controlli preventivi che coprono riservatezza, integrità e disponibilità. È qui che devono essere collocati termini del DPA, allegati di sicurezza, clausole di subappalto, diritti di audit, assistenza sugli incidenti, restituzione e cancellazione, e obblighi di collegamento ai trasferimenti.
Per il controllo 5.21, la prospettiva della catena di fornitura è rilevante perché un sub-responsabile del trattamento può creare una dipendenza di quarta parte. Un fornitore SaaS può dipendere da un provider di infrastruttura, che dipende da un provider di analytics sui dati, che a sua volta dipende da un’altra regione cloud o da un partner di supporto. L’organizzazione deve comprendere la catena a un livello sufficiente per gestire rischio, impegni verso i clienti e opzioni di uscita.
La roadmap in 30 passaggi: trasformare la politica in una procedura operativa
Zenith Blueprint colloca il rischio dei fornitori e dei soggetti a valle nel Passaggio 23, Controlli organizzativi. Spiega che gli accordi con i fornitori in genere disciplinano riservatezza, controllo degli accessi, misure tecniche e organizzative, tempistiche di segnalazione degli incidenti, diritto di audit, controlli sui subappaltatori e disposizioni di fine contratto. Il Blueprint evidenzia un punto critico:
La struttura dell’accordo è importante. Queste clausole possono trovarsi in un Master Services Agreement, in un Accordo sul trattamento dei dati (DPA) dedicato o in un allegato di sicurezza autonomo. Ciò che conta è che esistano e siano comprese e accettate da entrambe le parti.
Il Blueprint indica inoltre ai team come gestire i subappaltatori:
Per ogni fornitore critico, identificare se utilizza subappaltatori (sub-responsabili del trattamento) che possono accedere ai vostri dati o sistemi. Documentare in che modo i vostri requisiti di sicurezza delle informazioni sono trasferiti a tali parti, tramite i termini contrattuali del fornitore o tramite clausole dirette proprie.
Per la governance delle modifiche dei fornitori, l’allineamento operativo corretto è il controllo ISO/IEC 27002:2022 5.22:
Stabilire una procedura semplice e scalabile per valutare le modifiche ai servizi dei fornitori (5.22), come la migrazione al cloud, nuovi sub-responsabili del trattamento o la riprogettazione dell’infrastruttura. Definire gli eventi che richiedono una rivalutazione della sicurezza.
Questo offre a CISO e DPO un percorso pratico. Il Passaggio 23 definisce l’intento del controllo. REG08 acquisisce le evidenze privacy relative a responsabili del trattamento, sub-responsabili del trattamento e terze parti. REG09 acquisisce le evidenze di trasferimento. Contratti con i fornitori, DPA e ticket di modifica collegano il flusso operativo alla realtà operativa.
Un flusso operativo pratico per la notifica delle modifiche ai sub-responsabili del trattamento
Un flusso di modifica dei sub-responsabili del trattamento deve essere ordinario nel senso corretto: ogni fase deve avere un responsabile, evidenze e un punto di controllo che impedisca l’utilizzo prematuro in produzione.
| Fase del flusso operativo | Responsabile | Evidenze | Punto di controllo autorizzativo |
|---|---|---|---|
| Ricezione del sub-responsabile del trattamento proposto | Responsabile del fornitore o degli Acquisti | Richiesta di modifica, descrizione del servizio, categorie di dati, finalità del trattamento | Triage privacy e sicurezza |
| Due diligence privacy e sicurezza | DPO, Sicurezza, Acquisti | Due diligence REG08, certificazioni, questionario, storico degli incidenti, misure tecniche e organizzative (TOM) | Approvazione del Responsabile del rischio |
| Riesame del contratto e del DPA | Legale, Acquisti | Mappatura delle clausole DPA, termini di subappalto, diritti di audit, assistenza sugli incidenti, termini di cancellazione | Approvazione legale |
| Riesame di ubicazione e trasferimento | Privacy, Legale, Sicurezza | Luoghi del trattamento, luoghi di hosting, strumento di trasferimento, collegamento a REG09 | Approvazione del trasferimento |
| Notifica al cliente | Gestione clienti, Legale, Privacy | Copia della notifica, clienti interessati, base dell’accordo, data della notifica, finestra di opposizione | Notifica inviata prima dell’utilizzo |
| Gestione delle opposizioni | Legale, Responsabile dell’account, Responsabile del rischio | Registro delle opposizioni, risposta al rischio, decisione del cliente, blocco tecnico se necessario | Opposizione risolta o eccezione approvata |
| Abilitazione in produzione | Ingegneria, Responsabile delle modifiche | Ticket di modifica, riferimenti di approvazione, data di messa in esercizio | Nessun trattamento prima dell’approvazione |
| Aggiornamento post-modifica | Responsabile del fornitore | REG08 aggiornato, elenco pubblico se utilizzato, repository contrattuale, cadenza di monitoraggio | Riesame delle evidenze entro lo SLA definito |
Il principio chiave è semplice: la notifica al cliente deve avvenire prima dell’utilizzo quando l’accordo lo richiede. Aggiornare una pagina web pubblica dopo l’implementazione può supportare la trasparenza, ma non dimostra la notifica specifica al cliente, l’autorizzazione contrattuale o la gestione delle opposizioni.
Applicazione del flusso operativo alla crisi di Sarah
La notifica del fornitore ricevuta da Sarah su DataCrunch Analytics attiva l’intero processo.
In primo luogo, il Responsabile del fornitore apre una registrazione di modifica REG08. La registrazione identifica CoreStack, DataCrunch Analytics, la finalità del servizio, l’impatto sui tenant dei clienti, il ruolo nel trattamento, le categorie di dati, i luoghi del trattamento, il modello di accesso per il supporto, il periodo di conservazione e l’eventuale presenza di categorie particolari di dati o di dati regolamentati di clienti finanziari.
In secondo luogo, Privacy e Sicurezza svolgono la due diligence. Riesaminano le misure tecniche e organizzative di DataCrunch Analytics, la cifratura, il controllo degli accessi, la registrazione, la notifica degli incidenti, le capacità di cancellazione, l’assurance di audit, l’elenco dei sub-responsabili del trattamento e le certificazioni di sicurezza. Poiché il provider è fuori dall’UE, il riesame di ubicazione e trasferimento è obbligatorio.
In terzo luogo, l’ufficio legale verifica se i DPA dei clienti prevedono autorizzazione specifica o autorizzazione generale con notifica. I clienti vengono segmentati in gruppi di notifica: clienti con preavviso standard di 30 giorni, clienti enterprise con finestre di opposizione di 45 giorni, clienti che richiedono approvazione specifica, clienti soggetti a restrizioni con limiti di ubicazione e clienti non interessati i cui dati non toccano il carico di lavoro di analytics.
In quarto luogo, vengono collegate le evidenze di trasferimento. La Politica di gestione privacy di responsabili, sub-responsabili e terze parti richiede:
[Entrambi] Il Responsabile del fornitore / degli Acquisti DEVE registrare in REG08 i luoghi del trattamento, i luoghi di hosting e gli indicatori di trasferimento internazionale, e collegare a REG09 le evidenze di trasferimento applicabili prima di approvare un responsabile del trattamento, un sub-responsabile del trattamento, una modifica di ubicazione o una modifica del servizio rilevante per i trasferimenti.
In quinto luogo, il team di gestione clienti invia notifiche formali tramite canali approvati. Ogni notifica include il sub-responsabile del trattamento previsto, la finalità, le categorie di dati, il riepilogo dell’ubicazione, la data di efficacia, il termine per l’opposizione e il canale di contatto.
In sesto luogo, le opposizioni vengono gestite. Se un’istituzione finanziaria si oppone perché la modifica incide su una funzione essenziale o importante o su un trasferimento verso un Paese terzo, il team di Sarah valuta alternative: escludere il tenant, mantenere il percorso di trattamento precedente, richiedere supporto solo dall’UE, modificare le misure contrattuali di sicurezza o rinviare la modifica fino alla risoluzione dell’opposizione.
In settimo luogo, Ingegneria riceve l’approvazione solo per i tenant e i carichi di lavoro che hanno superato il punto di controllo. Il ticket di modifica in produzione collega REG08, REG09, approvazione legale, evidenze di notifica ed eventuali esclusioni specifiche per cliente. Dopo la messa in esercizio, vengono aggiornati il registro interno, la pagina pubblica dei sub-responsabili del trattamento e il repository contrattuale.
Questa è la differenza tra gestione reattiva dell’emergenza e governance difendibile.
Mappatura trasversale della conformità per una sola catena di evidenze
Il vantaggio Clarysec è che un unico flusso operativo può soddisfare più quadri di riferimento quando le evidenze sono progettate correttamente fin dall’inizio.
| Area di requisito | Come il flusso operativo la soddisfa |
|---|---|
| GDPR Article 28 e responsabilizzazione | Mantiene evidenze di autorizzazione dei sub-responsabili del trattamento, notifiche ai clienti, esiti delle opposizioni, obblighi DPA a cascata e collegamento ai trasferimenti |
| PIMS ISO/IEC 27701:2025 | Dimostra governance della privacy basata sui ruoli per responsabili del trattamento, controllo del trattamento a valle, conservazione delle evidenze e monitoraggio |
| SGSI ISO/IEC 27001:2022 | Supporta requisiti delle parti interessate, valutazione del rischio, controllo operativo, controlli sui fornitori, requisiti legali e informazioni documentate |
| Controlli ISO/IEC 27002:2022 | Applica controlli su rapporti con i fornitori, accordi con i fornitori, catena di fornitura ICT, modifiche dei fornitori, servizi cloud e requisiti legali |
| Rischio ICT di terze parti DORA | Supporta registri, due diligence, visibilità della catena di subappalto, consapevolezza delle ubicazioni, rischio di concentrazione, diritti di audit, assistenza sugli incidenti e pianificazione dell’uscita |
| Sicurezza della catena di fornitura NIS2 | Supporta la sicurezza della catena di fornitura prevista dall’Article 21, l’analisi del rischio dei fornitori, la gestione degli incidenti, la continuità operativa e la supervisione dell’organo di gestione |
| NIST CSF 2.0 GOVERN e GV.SC | Si allinea a strategia di rischio dei fornitori, criticità dei fornitori, requisiti contrattuali di cibersicurezza, due diligence, monitoraggio, coinvolgimento negli incidenti e pianificazione della cessazione |
| Prospettiva di governance COBIT 2019 | Supporta esigenze degli stakeholder, ottimizzazione del rischio, responsabilità dei fornitori, reportistica alla direzione ed evidenze di assurance |
NIST CSF 2.0 è utile come livello neutrale di organizzazione. La sua funzione GOVERN include comprensione degli obblighi legali, normativi, contrattuali, privacy e relativi alle libertà civili, assegnazione dei ruoli, definizione delle politiche, riesame delle prestazioni e gestione del rischio di cibersicurezza della catena di fornitura. La categoria GV.SC richiede processi di rischio dei fornitori, criticità dei fornitori, requisiti contrattuali di cibersicurezza, due diligence, monitoraggio del ciclo di vita, pianificazione degli incidenti e attività successive alla cessazione del rapporto.
DORA è più prescrittivo per gli enti finanziari. Gli Articles 28 to 30 richiedono gestione del rischio ICT di terze parti, registri contrattuali, qualificazione delle funzioni essenziali o importanti, visibilità della catena di subappalto, consapevolezza delle ubicazioni, misure contrattuali di sicurezza, diritti di audit, cooperazione sugli incidenti e pianificazione dell’uscita. Se la tua piattaforma SaaS supporta clienti finanziari, le evidenze sui sub-responsabili del trattamento diventano parte del loro pacchetto di evidenze DORA.
NIS2 aggiunge la responsabilità dell’organo di gestione. Article 20 richiede agli organi di gestione di approvare le misure di gestione dei rischi di cibersicurezza e supervisionarne l’attuazione. Article 21 richiede sicurezza della catena di fornitura e valutazione delle pratiche di cibersicurezza dei fornitori. Una modifica significativa ai sub-responsabili del trattamento dovrebbe quindi essere visibile nella reportistica sui rischi, non nascosta in una cartella degli Acquisti.
Cosa verificheranno gli auditor
Un processo maturo per i sub-responsabili del trattamento crea una linea diretta dalla politica alle evidenze.
Un auditor ISO/IEC 27001:2022 partirà dall’ambito di applicazione del SGSI, dai requisiti delle parti interessate, dai rischi, dalla Dichiarazione di Applicabilità e dai controlli operativi. Probabilmente testerà rapporti con i fornitori, accordi con i fornitori, catena di fornitura ICT, monitoraggio e gestione delle modifiche dei fornitori, requisiti legali, servizi cloud, protezione della privacy, registrazione e controllo operativo delle modifiche.
Un auditor PIMS ISO/IEC 27701:2025 si concentrerà sulla chiarezza dei ruoli. Siete responsabile del trattamento, titolare del trattamento, contitolare del trattamento o entrambi in servizi diversi? Per le attività da responsabile del trattamento, chiederà elenco dei sub-responsabili del trattamento, base dell’autorizzazione, evidenze di notifica, gestione delle opposizioni, contratti a valle, evidenze di trasferimento, supporto alla cancellazione, interfaccia per gli incidenti e registrazioni di monitoraggio.
Un revisore privacy GDPR verificherà la responsabilizzazione. Chiederà chi tratta i dati personali, per quale finalità, in base a quale accordo, in quale ubicazione, con quali misure di sicurezza e con quale trasparenza verso il cliente. Se un cliente si è opposto, chiederà che cosa è accaduto prima dell’inizio del trattamento.
Un auditor cliente DORA chiederà se il sub-responsabile del trattamento supporta una funzione essenziale o importante, se le catene di subappalto sono visibili, se le ubicazioni dei dati sono documentate, se l’assistenza sugli incidenti è garantita contrattualmente, se i diritti di audit sono trasferiti a valle, se è stato considerato il rischio di concentrazione e se l’uscita è possibile.
Un assessor NIS2 si concentrerà su sicurezza della catena di fornitura, supervisione dell’organo di gestione, preparazione agli incidenti e controlli proporzionati. Potrebbe chiedere come vengono rilevate le modifiche dei fornitori, come sono valutati i fornitori diretti, come vengono considerate le vulnerabilità dei fornitori e come vengono gestiti in escalation gli incidenti che coinvolgono i destinatari dei servizi.
L’insieme di evidenze dovrebbe essere facile da ricostruire:
- Richiesta di modifica dei sub-responsabili del trattamento approvata.
- Registrazione di due diligence REG08.
- Valutazione della categoria di dati e della finalità del trattamento.
- Evidenze del luogo del trattamento e di hosting.
- Evidenze di trasferimento REG09 ove pertinenti.
- Riesame degli obblighi a cascata nel DPA e nel contratto.
- Elenco delle notifiche ai clienti, date, formulazione e prova di consegna.
- Registro delle opposizioni ed evidenze di risoluzione.
- Ticket di modifica in produzione collegato all’approvazione.
- Elenco aggiornato dei sub-responsabili del trattamento e piano di monitoraggio.
- Accettazione del rischio o approvazione dell’eccezione ove necessaria.
Schemi di errore ricorrenti
Il primo errore è considerare la pagina dei sub-responsabili del trattamento come l’intero processo. Una pagina pubblica supporta la trasparenza, ma non dimostra notifica specifica al cliente, gestione delle opposizioni o autorizzazione.
Il secondo errore è separare le evidenze di privacy, sicurezza e Acquisti. Privacy può approvare il DPA, Sicurezza può riesaminare un report SOC 2 e Acquisti può archiviare il contratto, ma nessuna singola registrazione collega la decisione.
Il terzo errore è perdere il collegamento ai trasferimenti. I team registrano il nome del fornitore ma non i luoghi del trattamento, i luoghi di hosting, le ubicazioni del supporto, gli indicatori di trasferimento internazionale o le evidenze REG09.
Il quarto errore è abilitare la produzione prima della chiusura delle finestre di opposizione. Una volta che i dati personali dei clienti sono trattati dal nuovo sub-responsabile del trattamento, l’organizzazione potrebbe avere già violato l’accordo.
Il quinto errore è la debolezza degli obblighi a cascata. Il fornitore diretto accetta termini solidi, ma i suoi provider a valle non sono vincolati a obblighi equivalenti di privacy, sicurezza, assistenza, restituzione, cancellazione, incidente, audit e trasferimento.
Il sesto errore è una rilevazione insufficiente delle modifiche. Un fornitore cambia proprietà, luogo di hosting, tipologia di servizio, modello di supporto o catena di subappalto e nessuno rivaluta il rischio.
Il settimo errore è l’assenza di una traccia di audit. I team ricordano la decisione, ma non possono dimostrare quando è avvenuta, chi l’ha approvata, quali clienti sono stati notificati e come sono state risolte le opposizioni.
Reportistica di direzione per CISO e DPO
La governance dei sub-responsabili del trattamento deve produrre informazioni per la direzione, non solo artefatti di conformità.
| Metrica | Perché è rilevante |
|---|---|
| Sub-responsabili del trattamento attivi per servizio e categoria di dati | Mostra il perimetro del trattamento e l’esposizione privacy |
| Sub-responsabili del trattamento a supporto di servizi critici | Supporta pianificazione della resilienza, assurance DORA e prioritizzazione dei fornitori |
| Sub-responsabili del trattamento con accesso o hosting in Paesi terzi | Supporta riesami dei trasferimenti e dichiarazioni ai clienti |
| Finestre di opposizione imminenti | Previene l’abilitazione prematura in produzione |
| Sub-responsabili del trattamento privi di due diligence aggiornata | Identifica lacune di assurance |
| Contratti privi di clausole di obblighi a cascata | Evidenzia rischio legale e operativo |
| Modifiche dei fornitori in attesa di rivalutazione | Mostra carico di governance e arretrato |
| Opposizioni dei clienti aperte oltre lo SLA | Indica blocchi commerciali, legali o tecnici non risolti |
Questa reportistica si inserisce nel modello di sistema di gestione. ISO/IEC 27001:2022 richiede leadership, controllo operativo, valutazione delle prestazioni e miglioramento continuo. DORA e NIS2 innalzano la responsabilità dell’organo di gestione. La governance dei sub-responsabili del trattamento dovrebbe comparire nelle riunioni del comitato privacy, nei riesami del rischio fornitori, nel riesame della direzione del SGSI e nella reportistica sul rischio ICT ove pertinente.
Costruisci il tuo pacchetto di evidenze sulle modifiche ai sub-responsabili del trattamento
Parti da una modifica recente di un fornitore e verifica se la tua organizzazione sa rispondere a queste domande:
- Il provider è stato identificato come responsabile del trattamento, sub-responsabile del trattamento, fornitore, provider ICT o tutte queste categorie?
- REG08 o un registro equivalente è stato aggiornato prima dell’utilizzo?
- Sono stati registrati i luoghi del trattamento e i luoghi di hosting?
- Sono stati valutati gli indicatori di trasferimento internazionale?
- Le evidenze di trasferimento sono state collegate a REG09 o a un file equivalente?
- Il contratto includeva obblighi a cascata in materia di privacy, sicurezza, assistenza, restituzione, cancellazione, incidente, audit e trasferimento?
- I clienti sono stati notificati secondo i rispettivi accordi prima dell’inizio del trattamento?
- Le finestre di opposizione sono state tracciate e risolte?
- L’abilitazione in produzione è stata bloccata fino all’approvazione?
- Un auditor potrebbe ricostruire la traccia decisionale in meno di 30 minuti?
Se la risposta è no, la lacuna non è solo legale. È operativa, contrattuale, di rischio fornitori, di privacy e di capacità di dimostrare la conformità in audit.
Clarysec aiuta i team a chiudere rapidamente questa lacuna. Usa Zenith Blueprint per collocare la governance dei sub-responsabili del trattamento nella roadmap di implementazione del tuo SGSI e PIMS. Usa Zenith Controls per mappare controlli su rapporti con i fornitori, accordi con i fornitori, catena di fornitura ICT, modifiche dei fornitori, servizi cloud e requisiti legali tra ISO/IEC 27001:2022, ISO/IEC 27701:2025, GDPR, DORA, NIS2, NIST CSF 2.0 e COBIT 2019. Usa la Politica di gestione privacy di responsabili, sub-responsabili e terze parti, la Politica di sicurezza delle terze parti e dei fornitori, la Politica di conformità legale e normativa, la Politica di protezione dei dati e privacy e la Politica di gestione del rischio di dipendenza dai fornitori per trasformare la mappatura in esecuzione quotidiana.
Non attendere la nota a sorpresa in un’e-mail del fornitore. Costruisci ora flusso operativo, pacchetto di evidenze e mappa dei controlli, affinché ogni modifica ai sub-responsabili del trattamento diventi prova di governance matura anziché una crisi di conformità.
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
