Applicabilità dei controlli ISO 27701 in funzione dei ruoli GDPR
Sono le 08:40 di un martedì e Maria, CISO di una società SaaS di tecnologia sanitaria in rapida crescita, sta esaminando quattro e-mail di clienti che sembrano quasi identiche, ma hanno implicazioni molto diverse.
Un grande cliente aziendale chiede evidenze del fatto che la società possa agire come responsabile del trattamento ai sensi del GDPR, in conformità all’Article 28. Un secondo cliente chiede se la piattaforma sia anche titolare del trattamento per la telemetria e le analisi di prodotto. Un terzo chiede l’elenco aggiornato dei sub-responsabili e la prova che le clausole dell’accordo sul trattamento dei dati (DPA) siano trasferite a cascata. Un quarto, un cliente fintech che si sta preparando ai riesami dei fornitori DORA, chiede se gli stessi controlli privacy siano mappati su resilienza operativa, segnalazione degli incidenti e rischio ICT di terze parti.
La società di Maria non è negligente. Dispone di un SGSI allineato a ISO/IEC 27001:2022, policy privacy, un registro dei trattamenti, MFA, cifratura, riesami degli accessi e formazione sulla protezione dei dati fin dalla progettazione. Tuttavia, la richiesta fa emergere la domanda più difficile, quella che auditor e clienti verificano davvero:
La società può dimostrare che i controlli del PIMS ISO 27701 corretti si applicano al ruolo GDPR corretto, per l’attività di trattamento corretta, con il titolare interno, le evidenze e la giustificazione corretti?
È qui che molti programmi privacy falliscono. Trattano ISO 27701 come una checklist, mentre organismi di certificazione, auditor dei clienti e Responsabili della protezione dei dati si aspettano una decisione motivata sull’applicabilità dei controlli. La risposta non è “abbiamo controlli privacy”. La risposta è “per questa attività di trattamento siamo titolare del trattamento, responsabile del trattamento, contitolare del trattamento o sub-responsabile, e questi sono i motivi per cui tali controlli si applicano o non si applicano”.
Perché l’applicabilità dei controlli ISO 27701 è il livello PIMS mancante
I ruoli GDPR si basano sul potere decisionale. Un titolare del trattamento determina le finalità e i mezzi del trattamento. Un responsabile del trattamento agisce per conto di un titolare del trattamento. I contitolari del trattamento determinano congiuntamente finalità e mezzi. Un sub-responsabile è incaricato da un responsabile del trattamento di trattare ulteriormente dati personali a valle.
Negli ambienti SaaS reali, questi ruoli raramente restano netti a livello aziendale. L’organizzazione di Maria è responsabile del trattamento quando ospita dati sul benessere forniti dai clienti, titolare del trattamento per la gestione paghe dei dipendenti e i contatti marketing, possibile titolare del trattamento per la telemetria di prodotto in base a finalità e condizioni contrattuali, e contitolare del trattamento in una campagna a marchio condiviso. Se un fornitore di servizi gestiti più grande rivende la sua piattaforma, la società può diventare anche sub-responsabile in quella catena.
L’applicabilità dei controlli ISO 27701 è la disciplina che impedisce a questi ruoli di ridursi a dichiarazioni generiche. Pone le seguenti domande:
- Quale attività di trattamento rientra nell’ambito di applicazione?
- Quale ruolo GDPR svolge l’organizzazione per tale attività?
- Quali controlli PIMS si applicano in ragione di quel ruolo?
- Quali controlli sono esclusi e perché?
- Quali evidenze dimostrano l’attuazione?
- Quale requisito legale, contrattuale, di rischio o di ambito ha determinato la decisione?
La Privacy Information Management System Policy di Clarysec rende la classificazione dei ruoli il punto di partenza:
“[Entrambi] Il Responsabile del processo / Titolare dell’attività DEVE classificare il ruolo PIMS dell’organizzazione per ciascuna attività di trattamento di PII in REG02 prima dell’avvio dell’attività di trattamento.”
Dalla sezione “Determinazione del ruolo PIMS”, clausola della policy 4.2.1.
La stessa policy collega la decisione sul ruolo all’applicabilità dei controlli:
“[Entrambi] Il Responsabile privacy / Responsabile del PIMS DEVE mantenere REG03 con controlli inclusi, controlli esclusi, stato di attuazione e giustificazione con cadenza annuale ed entro 30 giorni da ogni modifica del trattamento del rischio privacy.”
Dalla sezione “Policy privacy, obiettivi e applicabilità dei controlli”, clausola della policy 4.3.3.
REG02 risponde a quali trattamenti esistono e quale ruolo si applica. REG03 risponde a quali controlli si applicano, cosa è escluso, quali evidenze esistono e perché la decisione è sostenibile.
Costruire il PIMS sulla logica della SoA ISO/IEC 27001:2022
Un PIMS basato sui ruoli funziona al meglio quando è costruito su un SGSI maturo. ISO/IEC 27001:2022 richiede già definizione dell’ambito di applicazione, analisi delle parti interessate, valutazione del rischio, trattamento del rischio, selezione dei controlli e una Dichiarazione di Applicabilità. ISO 27701 estende tale logica del sistema di gestione alla privacy.
La Information Security Policy di Clarysec stabilisce:
“Il SGSI deve includere confini dell’ambito di applicazione definiti, una metodologia di valutazione del rischio, obiettivi misurabili e controlli documentati giustificati nella Dichiarazione di Applicabilità (SoA).”
Dalla sezione “Requisiti di applicazione della policy”, clausola della policy 6.1.2.
La Risk Management Policy rafforza la stessa disciplina delle evidenze:
“Una Dichiarazione di Applicabilità (SoA) deve riflettere tutte le decisioni di trattamento e deve essere aggiornata ogni volta che la copertura dei controlli viene modificata.”
Dalla sezione “Requisiti di governance”, clausola della policy 5.4.
Per la privacy, REG03 diventa il registro di applicabilità dei controlli PIMS che rispecchia la disciplina della SoA. Non sostituisce la SoA ISO/IEC 27001:2022. La arricchisce aggiungendo decisioni privacy specifiche per ruolo GDPR relative a titolari del trattamento, responsabili del trattamento, contitolari del trattamento e sub-responsabili.
La PII Processing Inventory and Lawful Basis Policy rende esplicito tale collegamento:
“[Entrambi] Il Responsabile privacy / Responsabile del PIMS DEVE collegare le attività di trattamento REG02 applicabili alle registrazioni di applicabilità dei controlli REG03 prima del riesame della preparazione alla certificazione.”
Dalla sezione “Gestione dell’inventario dei trattamenti”, clausola della policy 7.1.5.
Un auditor deve poter selezionare una singola attività di trattamento in REG02, identificare il ruolo GDPR, tracciare i controlli applicabili in REG03, riesaminare i controlli ISO/IEC 27001:2022 pertinenti nella SoA e ispezionare evidenze quali accordi sul trattamento dei dati (DPA), registrazione della base giuridica, riesame degli accessi, approvazione del sub-responsabile, procedura di gestione degli incidenti o log di cancellazione.
Il modello di applicabilità dei controlli basato sui ruoli
Il modo più rapido per rendere ISO 27701 utilizzabile è decidere l’applicabilità a livello di attività di trattamento, non a livello aziendale.
Un fornitore SaaS dovrebbe evitare di dire “siamo un responsabile del trattamento”. Dovrebbe dire: “per le registrazioni utente caricate dai clienti nella piattaforma di produzione, siamo responsabile del trattamento. Per la gestione paghe, siamo titolare del trattamento. Per le analisi di prodotto, il nostro ruolo dipende dal fatto che le analisi siano usate solo per erogare i servizi contrattualizzati o per nostre finalità autonome. Per il fornitore di ticketing che supporta i dati dei clienti, il fornitore è un sub-responsabile”.
| Ruolo GDPR/PIMS | Focus dell’applicabilità dei controlli | Evidenze tipiche nell’implementazione Clarysec |
|---|---|---|
| Titolare del trattamento | Base giuridica, trasparenza, diritti degli interessati, conservazione, DPIA, protezione dei dati fin dalla progettazione, selezione dei responsabili del trattamento e decisione sulla violazione | Attività di trattamento REG02, registrazione della base giuridica, informativa privacy, regola di conservazione, DPIA ove richiesta, controlli applicabili REG03, due diligence sui responsabili del trattamento |
| Responsabile del trattamento | Istruzioni documentate, misure di sicurezza, riservatezza, assistenza al titolare del trattamento, notifica della violazione al titolare del trattamento, restituzione o cancellazione, approvazione dei sub-responsabili | DPA, registro delle istruzioni del cliente, log degli accessi, procedura di escalation degli incidenti, registro dei sub-responsabili, certificato di cancellazione, controlli REG03 per responsabili del trattamento |
| Contitolare del trattamento | Accordo di contitolarità, ripartizione delle responsabilità, trasparenza verso gli interessati, flusso di lavoro condiviso per violazioni e diritti | Accordo tra contitolari del trattamento, matrice delle responsabilità, testo dell’informativa privacy, flusso di escalation, controlli REG03 per contitolari |
| Sub-responsabile | Obblighi a cascata, trattamento secondo le condizioni del responsabile del trattamento o del cliente, sicurezza e riservatezza, supporto agli audit, gestione della cessazione | Accordo con il sub-responsabile, checklist delle clausole a cascata, evidenze di assurance del fornitore, riesame degli accessi, evidenze di restituzione o distruzione dei dati |
Questa vista basata sui ruoli è allineata alla responsabilizzazione prevista dal GDPR. I titolari del trattamento devono dimostrare la conformità a principi quali liceità, correttezza, trasparenza, limitazione della finalità, minimizzazione, esattezza, limitazione della conservazione, integrità, riservatezza e responsabilizzazione. I responsabili del trattamento devono trattare solo su istruzioni documentate, applicare misure di sicurezza adeguate, assistere i titolari del trattamento, gestire i sub-responsabili e supportare restituzione o cancellazione.
La scorciatoia pericolosa consiste nel presumere che ogni controllo privacy si applichi ovunque. Un responsabile del trattamento di norma non determina la base giuridica per i dati degli utenti finali del cliente, ma deve dimostrare di trattarli solo secondo le istruzioni del cliente. Un titolare del trattamento può non aver bisogno dell’approvazione dei sub-responsabili da parte del cliente per il trattamento HR interno, ma deve svolgere la due diligence sul responsabile del trattamento che fornisce il servizio di gestione paghe.
Classificare prima dell’approvazione del contratto o dell’avvio del trattamento
La risultanza più comune nella preparazione del PIMS è la classificazione tardiva dei ruoli. Il contratto è firmato, la piattaforma è in esercizio, i fornitori sono integrati e nessuno ha deciso se l’organizzazione sia titolare del trattamento, responsabile del trattamento, contitolare del trattamento o sub-responsabile per ciascun flusso di dati.
Questo ritardo genera problemi a valle. Viene usato il DPA sbagliato. I sub-responsabili non sono comunicati. Le DPIA vengono omesse. La conservazione non è chiara. Il supporto clienti non sa quale tempistica di notifica della violazione si applichi. L’approvvigionamento tratta un fornitore con impatto privacy come “solo uno strumento”.
La Processor, Subprocessor and Third-Party Privacy Management Policy disciplina direttamente la tempistica:
“[Entrambi] Il Responsabile privacy / Responsabile del PIMS DEVE classificare ogni rapporto 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’avvio del trattamento di PII, a seconda di quale evento si verifichi per primo.”
Dalla sezione “Identificazione e classificazione delle relazioni”, clausola della policy 4.1.3.
La classificazione REG08 dei fornitori e delle relazioni con terze parti alimenta REG03. Se un fornitore è responsabile del trattamento, i controlli applicabili includono condizioni DPA, riservatezza, misure di sicurezza, diritto di audit, assistenza per le richieste di esercizio dei diritti, supporto in caso di violazione, restituzione o cancellazione e controlli sui sub-responsabili. Se un fornitore è un titolare del trattamento autonomo, il focus si sposta su base giuridica, governance delle comunicazioni di dati personali, trasferimenti, trasparenza e responsabilizzazione.
Per le organizzazioni più piccole, la Third-Party and Supplier Security Policy - SME richiede ai team di considerare:
“Esposizione normativa (ad es., ruolo di responsabile del trattamento GDPR, obblighi del settore finanziario ai sensi di DORA)”
Dalla sezione “Requisiti di governance”, clausola della policy 5.2.4.
Stabilisce inoltre un chiaro requisito prima della condivisione:
“Le clausole dell’accordo sul trattamento dei dati (DPA) o condizioni contrattuali equivalenti devono essere concordate prima della condivisione di qualsiasi dato personale o sensibile.”
Dalla sezione “Requisiti di applicazione della policy”, clausola della policy 6.3.2.
Questa è la differenza tra avere contratti con i fornitori e disporre di una governance dei ruoli privacy verificabile in audit.
Mappare i controlli su ruolo, rischio, legge e contratto
Lo Zenith Blueprint, fase Gestione del rischio, Step 13: Pianificazione del trattamento del rischio e Dichiarazione di Applicabilità, spiega la logica centrale dell’applicabilità. I controlli sono applicabili in ragione di decisioni di trattamento del rischio, requisiti legali o contrattuali, pertinenza dell’ambito e contesto organizzativo. Le esclusioni richiedono motivazioni chiare e i controlli applicabili dovrebbero essere tracciati fino a un rischio o a un requisito.
Nello Step 13, Zenith Blueprint afferma:
“Assicurare l’allineamento con il registro dei rischi: ogni controllo di mitigazione indicato nel Piano di trattamento del rischio deve corrispondere a un controllo dell’Allegato A contrassegnato come ‘Applicabile’. Viceversa, se un controllo è contrassegnato come applicabile, deve esserci un rischio o un requisito che ne determina l’applicazione.”
Per ISO 27701, lo stesso metodo si applica ai controlli privacy. Un controllo può essere applicabile perché:
- Il GDPR lo richiede per il ruolo dell’organizzazione.
- Un contratto cliente, un DPA o un accordo tra contitolari del trattamento lo richiede.
- Un trattamento del rischio privacy lo richiede.
- Il trattamento coinvolge categorie particolari di dati personali, dati personali di minori, monitoraggio su larga scala, profilazione sensibile o dati personali ad alto impatto.
- Il rischio connesso a fornitore, cloud, sub-responsabile o trasferimento transfrontaliero rende necessario il controllo.
- Il controllo supporta l’ambito di certificazione, la preparazione agli audit o obiettivi privacy approvati.
La Legal and Regulatory Compliance Policy rafforza questa disciplina di mappatura:
“Quando una normativa si applica a più aree (ad es., il GDPR si applica a conservazione, sicurezza e privacy), ciò deve essere chiaramente mappato nel Registro di conformità e nei materiali formativi.”
Dalla sezione “Requisiti di governance”, clausola della policy 5.2.2.
La stessa Legal and Regulatory Compliance Policy è esplicita per l’integrazione nel SGSI aziendale:
“Tutti gli obblighi legali e normativi devono essere mappati a policy, controlli e titolari specifici all’interno del Sistema di gestione della sicurezza delle informazioni (SGSI).”
Dalla sezione “Requisiti di applicazione della policy”, clausola della policy 6.2.1.
REG03 non dovrebbe quindi mai essere un foglio di calcolo privacy separato. Deve collegare attività di trattamento, obblighi legali, trattamenti del rischio, contratti, controlli ISO/IEC 27001:2022 e titolari delle evidenze.
Esempio pratico: un flusso di supporto SaaS
Consideriamo un flusso di supporto nella piattaforma SaaS di Maria. I clienti inviano ticket che possono contenere nomi, e-mail, ID account, screenshot e, occasionalmente, contesto aziendale sensibile. Gli agenti di supporto accedono a registrazioni limitate. Un fornitore cloud di ticketing ospita i dati e utilizza propri sub-responsabili.
Step 1: registrare l’attività in REG02
Il Responsabile privacy registra:
- Nome dell’attività: gestione dei ticket di supporto clienti
- Categorie di PII: identificativi utente, recapiti, screenshot, metadati account
- Interessati: amministratori dei clienti e utenti finali
- Finalità: supporto e risoluzione dei problemi del servizio
- Ruolo: responsabile del trattamento per PII degli utenti finali forniti dal cliente, titolare del trattamento per la gestione dei contatti commerciali diretti se usati per comunicazioni relative all’account
- Conservazione: periodo definito di conservazione per supporto e audit
- Destinatari: personale interno di supporto, fornitore di ticketing, sub-responsabili approvati
- Classificazione di sicurezza: riservato, PII
La Data Protection and Privacy Policy - SME supporta questa base di riferimento:
“Il Coordinatore privacy deve mantenere un registro di tutte le attività di trattamento dei dati personali, incluse categorie di dati, finalità, base giuridica e periodi di conservazione”
Dalla sezione “Requisiti di governance”, clausola della policy 5.2.1.
Step 2: classificare il fornitore in REG08
Se la società di Maria è responsabile del trattamento per i dati dei clienti, il fornitore di ticketing è in genere un sub-responsabile per tali dati. REG08 dovrebbe registrare tipo di relazione, stato contrattuale, categorie di dati, ubicazioni dei dati, sub-responsabili a valle ed evidenze di assurance.
Step 3: registrare l’applicabilità in REG03
| Tema del controllo | Applicabile? | Perché | Evidenze |
|---|---|---|---|
| Determinazione del ruolo nel trattamento | Sì | Richiesta prima dell’avvio del trattamento e necessaria per distinguere obblighi del titolare del trattamento e del responsabile del trattamento | Campo ruolo in REG02, registrazione della relazione REG08 |
| Documentazione della base giuridica | Parzialmente | Si applica al trattamento dei contatti commerciali lato titolare del trattamento, non al trattamento degli utenti finali del cliente svolto su istruzione | Registrazione della base giuridica, informativa privacy |
| Trattamento su istruzioni documentate | Sì | Si applica all’attività di responsabile del trattamento per i dati degli utenti finali del cliente | DPA, condizioni di supporto, flusso di gestione delle istruzioni del cliente |
| Protezione dei dati fin dalla progettazione e per impostazione predefinita | Sì | Il flusso di supporto può esporre screenshot, identificativi e informazioni riservate del cliente | Minimizzazione nel modulo di acquisizione, indicazioni sul mascheramento, restrizioni di accesso |
| Gestione dei sub-responsabili | Sì | La piattaforma di ticketing e i fornitori a valle accedono a PII | Elenco dei sub-responsabili, flusso di approvazione, obblighi contrattuali a cascata |
| Assistenza per richieste degli interessati | Sì | Il responsabile del trattamento deve supportare il cliente titolare del trattamento ove applicabile | Procedura di assistenza per l’esercizio dei diritti, evidenze di instradamento dei ticket |
| Supporto alla notifica della violazione | Sì | Una violazione dei dati personali negli strumenti di supporto deve essere oggetto di escalation | Procedura di gestione degli incidenti, termini di notifica nel DPA |
| Restituzione o cancellazione | Sì | Richiesta alla cessazione del contratto e alla scadenza della conservazione | Piano di conservazione, log di cancellazione, certificato di cancellazione del fornitore |
| DPIA | Condizionale | Richiesta se il processo di supporto si estende a monitoraggio ad alto rischio o dati sensibili su larga scala | Registrazione dello screening DPIA |
La Data Protection and Privacy Policy aziendale aggiunge un trigger di alto rischio:
“La modellazione delle minacce e le valutazioni d’impatto sulla protezione dei dati (DPIA) sono obbligatorie per i sistemi di trattamento ad alto rischio.”
Dalla sezione “Requisiti di applicazione della policy”, clausola della policy 6.3.4.
La Data Protection and Privacy Policy - SME integra l’aspettativa di progettazione:
“La protezione dei dati fin dalla progettazione e per impostazione predefinita deve essere applicata in tutti i nuovi sistemi e servizi”
Dalla sezione “Requisiti di governance”, clausola della policy 5.3.1.
Step 4: allineare ai controlli ISO/IEC 27001:2022
Se la piattaforma di supporto rientra nell’ambito di applicazione del SGSI, la SoA dovrebbe includere controlli ISO/IEC 27002:2022 di supporto quali relazioni con i fornitori, accordi con i fornitori, gestione della catena di fornitura ICT, controllo degli accessi, gestione delle identità, trasferimento delle informazioni, servizi cloud, gestione degli incidenti, logging e monitoraggio, gestione delle modifiche, conformità legale e tutela della privacy.
Zenith Blueprint, fase Gestione del rischio, Step 14: Policy di trattamento del rischio e riferimenti normativi incrociati, raccomanda di referenziare in modo incrociato GDPR, NIS2 e DORA rispetto a policy e controlli, in particolare per protezione dei dati personali, risposta agli incidenti, controllo degli accessi, continuità operativa e rischio ICT di terze parti.
Il risultato è un insieme di evidenze riutilizzabile, non fogli di calcolo separati per GDPR, DORA, NIS2 e certificazione.
Cosa aggiunge Zenith Controls all’applicabilità del PIMS
Zenith Controls è la guida di Clarysec per la mappatura trasversale della conformità, utile a comprendere le relazioni tra i controlli ISO/IEC 27001:2022 e ISO/IEC 27002:2022, i metodi di audit e altri quadri di riferimento. Non è un set di controlli separato. Per questo tema, i controlli ISO/IEC 27002:2022 centrali sono:
- 5.34 Privacy e protezione delle PII
- 5.19 Sicurezza delle informazioni nelle relazioni con i fornitori
- 5.20 Gestione della sicurezza delle informazioni negli accordi con i fornitori
- 5.21 Gestione della sicurezza delle informazioni nella catena di fornitura ICT
- 5.22 Monitoraggio, riesame e gestione delle modifiche dei servizi dei fornitori
Per 5.34, Zenith Controls classifica il controllo come preventivo, mappato a riservatezza, integrità e disponibilità, allineato a Identify e Protect, e associato alle capacità di protezione delle informazioni, legali e di conformità.
La relativa mappatura GDPR afferma:
“L’attuazione di 5.34 costituisce evidenza diretta della capacità di un’organizzazione di soddisfare i requisiti di responsabilizzazione del GDPR.”
Da Zenith Controls, Privacy and Protection of PII, mappatura incrociata GDPR.
Questa frase è importante perché trasforma 5.34 da una dichiarazione privacy generica in evidenza di audit. Dovrebbe essere supportata da inventari PII, classificazione, controllo degli accessi, mascheramento, trasferimento sicuro, governance cloud, DPIA, informative privacy, flussi per l’esercizio dei diritti degli interessati e gestione delle violazioni.
| Controllo di supporto ISO/IEC 27002:2022 | Perché è rilevante per l’applicabilità del PIMS |
|---|---|
| 5.9 Inventario delle informazioni e degli altri asset associati | Le raccolte di PII devono essere note prima che i controlli privacy possano essere selezionati o testati |
| 5.12 Classificazione delle informazioni | Le PII dovrebbero essere classificate affinché si applichino regole di gestione più rigorose |
| 5.14 Trasferimento delle informazioni | I trasferimenti di PII richiedono canali sicuri, condivisione lecita e controlli contrattuali |
| 5.15 Controllo degli accessi | L’accesso secondo il principio della necessità di conoscere supporta riservatezza e prevenzione delle violazioni |
| 5.16 Gestione delle identità | Identità affidabili sono necessarie prima che l’accesso possa essere autorizzato e riesaminato |
| 5.23 Sicurezza delle informazioni per l’uso dei servizi cloud | Le PII in cloud richiedono due diligence sul fornitore, consapevolezza della localizzazione dei dati e pianificazione dell’uscita |
| 5.8 Sicurezza delle informazioni nella gestione dei progetti | I requisiti privacy e di sicurezza dovrebbero essere integrati nei nuovi sistemi e nelle modifiche sostanziali |
| 8.11 Mascheramento dei dati | Il mascheramento riduce l’esposizione delle PII nei flussi di supporto, test e analisi |
| 8.32 Gestione delle modifiche | Le modifiche con impatto privacy dovrebbero essere riesaminate prima del rilascio in produzione |
Zenith Controls collega inoltre privacy e protezione delle PII a standard correlati come ISO/IEC 27018 per il trattamento di PII nel cloud pubblico, ISO/IEC 29100 per i principi privacy e ISO/IEC 29151 per le pratiche di protezione delle PII. La governance privacy dei fornitori è supportata dalla famiglia ISO/IEC 27036 per le relazioni con i fornitori e la sicurezza della catena di fornitura ICT, e da ISO/IEC 27017 per le responsabilità condivise nella sicurezza cloud.
Le evidenze su fornitori e sub-responsabili sono il punto in cui i ruoli convergono
Gli obblighi di titolare del trattamento e responsabile del trattamento spesso si incontrano al confine con il fornitore.
Se la società di Maria è titolare del trattamento, il GDPR si aspetta che utilizzi responsabili del trattamento in grado di fornire garanzie sufficienti. Se è responsabile del trattamento, i clienti si aspettano che gestisca i sub-responsabili, trasferisca gli obblighi a cascata e fornisca assurance. Se è sub-responsabile, eredita obblighi lungo la catena.
Questo rende i controlli ISO/IEC 27002:2022 5.19 e 5.20 centrali per l’applicabilità dei controlli ISO 27701.
Per 5.19, Zenith Controls enfatizza la sicurezza delle relazioni con i fornitori nei domini di governance, ecosistema e protezione. Il controllo è direttamente collegato a 5.20 accordi con i fornitori, 5.21 sicurezza della catena di fornitura ICT, 5.14 trasferimento delle informazioni, 5.36 conformità a policy, regole e standard per la sicurezza delle informazioni, e 5.10 uso accettabile delle informazioni e degli altri asset associati.
Per 5.20, Zenith Controls enfatizza la formalizzazione contrattuale. Gli accordi con i fornitori dovrebbero definire riservatezza, notifica delle violazioni, diritto di audit, approvazione dei subappaltatori, trasferimento sicuro, restituzione o distruzione dei dati, obblighi di conformità e monitoraggio.
Zenith Blueprint, fase Controlli in azione, Step 23: Controlli organizzativi, fornisce un’indicazione pratica per i sub-responsabili:
“Per ogni fornitore critico, identificare se utilizza subappaltatori (sub-responsabili) che possono accedere ai vostri dati o sistemi. Documentare in che modo i vostri requisiti di sicurezza delle informazioni sono trasferiti a cascata a tali parti, tramite le condizioni contrattuali del fornitore o tramite vostre clausole dirette.”
Gli auditor non si fermeranno a “avete un DPA?”. Chiederanno se i fornitori sono responsabili del trattamento, sub-responsabili, titolari del trattamento autonomi o contitolari del trattamento, se le approvazioni dei sub-responsabili sono documentate, se gli obblighi sono trasferiti a cascata, se le tempistiche di violazione sono chiare, se il monitoraggio viene svolto e se è possibile ottenere evidenze di cancellazione o restituzione.
Mappatura trasversale della conformità senza sistemi di controllo duplicati
L’applicabilità dei controlli ISO 27701 diventa più preziosa quando supporta conversazioni di assurance su GDPR, NIS2, DORA, NIST CSF 2.0 e COBIT 2019 a partire dalla stessa base di evidenze.
Il GDPR determina obblighi privacy basati sui ruoli: responsabilizzazione del titolare del trattamento, doveri del responsabile del trattamento, base giuridica, diritti degli interessati, sicurezza, governance delle violazioni e contratti.
NIS2 aggiunge gestione dei rischi di cibersicurezza, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, sviluppo sicuro, processo di gestione delle vulnerabilità, controllo degli accessi, crittografia, MFA e formazione per soggetti essenziali e importanti.
DORA si applica dal 17 gennaio 2025 alle entità finanziarie in ambito e richiede gestione del rischio ICT, segnalazione degli incidenti, test di resilienza e gestione del rischio ICT di terze parti. Ai fornitori SaaS e ICT che servono entità finanziarie viene spesso chiesto di fornire evidenze su privacy, sicurezza, resilienza, diritto di audit ed exit in un unico pacchetto di assurance.
NIST CSF 2.0 fornisce un livello di governance tramite la Funzione GOVERN, inclusi obblighi legali, normativi, contrattuali e privacy, ruoli, propensione al rischio, vigilanza sulle policy e governance della catena di fornitura.
COBIT 2019 aggiunge pratiche di governance e gestione. Per la privacy, Zenith Controls mappa 5.34 su COBIT DSS06.02, DSS06.08 e APO13.01. Per i fornitori, 5.19 e 5.20 supportano pratiche di rischio dei fornitori e accordi con i fornitori.
| Driver del requisito | Impatto sull’applicabilità dei controlli | Evidenze da riutilizzare |
|---|---|---|
| Responsabilizzazione del titolare del trattamento GDPR | Base giuridica, trasparenza, conservazione e vigilanza sui responsabili del trattamento si applicano quando la società determina finalità e mezzi | REG02, registrazione della base giuridica, informativa privacy, piano di conservazione, DPA |
| Obblighi del responsabile del trattamento GDPR | Istruzioni documentate, riservatezza, sicurezza, assistenza, supporto in caso di violazione e cancellazione si applicano ai dati dei clienti | DPA, flusso delle istruzioni, escalation degli incidenti, log di cancellazione |
| Temi NIS2 Article 21 | Gestione del rischio, gestione degli incidenti, sicurezza della catena di fornitura, controllo degli accessi, crittografia e continuità rafforzano la protezione delle PII | SoA, registro dei rischi, piano di risposta agli incidenti, riesami dei fornitori, riesame degli accessi |
| Rischio ICT di terze parti DORA | I clienti finanziari si aspettano clausole contrattuali, diritto di audit, resilienza, exit e cooperazione sugli incidenti | Registro dei fornitori ICT, checklist delle clausole contrattuali, strategia di uscita, test di resilienza |
| NIST CSF 2.0 GOVERN e GV.SC | Obblighi legali, ruoli, rischio dei fornitori, contratti e monitoraggio diventano risultati del profilo | Profilo CSF, registro dei rischi dei fornitori, POA&M |
| Governance privacy e fornitori COBIT 2019 | Vengono testati supervisione del consiglio di amministrazione, gestione del programma privacy e monitoraggio degli accordi con i fornitori | Verbali di governance, valutazione del rischio privacy, evidenze di monitoraggio contrattuale |
Il punto strategico è semplice. REG03 dovrebbe essere più di un artefatto ISO 27701. Dovrebbe essere una mappa riutilizzabile dell’applicabilità dei controlli per audit dei clienti, riesami normativi e assurance a livello di consiglio di amministrazione.
Come gli auditor verificano l’applicabilità dei controlli ISO 27701
Auditor diversi partono da angolazioni diverse, ma di solito convergono sulla stessa traccia delle evidenze.
Un auditor di sistemi di gestione ISO parte da ambito di applicazione, parti interessate, obblighi, valutazione del rischio, allineamento della SoA, audit interno, riesame della direzione e miglioramento continuo. Verificherà se REG02, REG03 e la SoA ISO/IEC 27001:2022 sono coerenti.
Un auditor focalizzato sul GDPR o un revisore del Responsabile della protezione dei dati verifica la logica dei ruoli. Campionerà attività, riesaminerà base giuridica, informative privacy, DPA, sub-responsabili, DPIA, gestione delle richieste di esercizio dei diritti, conservazione e decisioni sulle violazioni.
Un valutatore orientato a NIST ricerca risultati di governance, categorizzazione del rischio, inventari dei dati, controlli degli accessi, protezione dei dati a riposo e in transito, monitoraggio, risposta agli incidenti, rischio dei fornitori e piani di miglioramento.
Un auditor COBIT 2019 o ISACA guarda alla titolarità della governance, alla capacità dei processi, al disegno dei controlli e all’efficacia operativa. Verificherà se i controlli privacy sono integrati in approvvigionamento, gestione delle modifiche, gestione degli incidenti e monitoraggio dei fornitori.
| Area di focus dell’audit | Cosa chiederà l’auditor | Percorso delle evidenze Clarysec |
|---|---|---|
| Classificazione dei ruoli PIMS | Mostrare l’inventario dei trattamenti e spiegare come è stato determinato ogni ruolo di titolare del trattamento, responsabile del trattamento, contitolare del trattamento o sub-responsabile | REG02 nell’ambito della Privacy Information Management System Policy |
| Applicabilità dei controlli PIMS | Giustificare controlli privacy inclusi ed esclusi per le attività campionate | REG03 collegato a REG02 e alle decisioni di trattamento del rischio secondo Zenith Blueprint |
| Obblighi del responsabile del trattamento | Mostrare DPA, istruzioni del cliente, controlli di riservatezza ed elenco dei sub-responsabili | DPA, flusso delle istruzioni, riesame degli accessi, REG08, registro dei fornitori |
| Obblighi del titolare del trattamento | Mostrare base giuridica, informativa privacy, conservazione e gestione dei diritti degli interessati | REG02, registrazione della base giuridica, informativa privacy, procedura per l’esercizio dei diritti, piano di conservazione |
| Valutazione dei fornitori | Mostrare due diligence, clausole contrattuali, monitoraggio ed evidenze di uscita per responsabili del trattamento ad alto rischio | REG08, valutazione del rischio dei fornitori, evidenze 5.19 e 5.20, certificato di cancellazione |
Per 5.34, Zenith Controls descrive gli auditor che riesaminano policy privacy, inventari dei dati, DPIA, log di formazione, misure tecniche di sicurezza, campioni di richieste di esercizio dei diritti, incidenti relativi alle PII ed evidenze di protezione dei dati fin dalla progettazione. Per 5.19 e 5.20, gli auditor richiedono inventari dei fornitori, classificazioni del rischio, registrazioni di due diligence, contratti, termini sulle violazioni, diritto di audit, approvazione dei subappaltatori, evidenze di uscita e prova del riesame dei report dei fornitori.
La distinzione è critica. La preparazione agli audit non è “abbiamo una clausola”. È “abbiamo usato la clausola, l’abbiamo monitorata, abbiamo riesaminato le evidenze e siamo intervenuti quando il rischio è cambiato”.
Errori comuni nell’applicabilità per titolari e responsabili del trattamento
Clarysec osserva ripetutamente cinque errori evitabili.
Primo, le organizzazioni classificano l’intera società come un unico ruolo GDPR. Questo non funziona per SaaS, fintech, HR tech, tecnologia sanitaria, servizi gestiti o provider cloud con flussi di dati misti.
Secondo, trattano i controlli ISO 27701 come universalmente applicabili senza giustificazione basata sul ruolo. Questo crea requisiti di evidenza eccessivi ed esclusioni deboli.
Terzo, escludono controlli senza documentare il motivo. Nella logica della SoA ISO/IEC 27001:2022 e nella logica di applicabilità del PIMS, le esclusioni devono essere consapevoli, motivate e supportate da analisi di ambito, ruolo, rischio o legge.
Quarto, dimenticano i sub-responsabili. La storia di assurance di un responsabile del trattamento è solida solo quanto la sua catena a valle. Registri dei sub-responsabili, meccanismi di approvazione, clausole a cascata ed evidenze di cancellazione sono essenziali.
Quinto, non collegano i controlli privacy alle operazioni di sicurezza. La protezione dei dati fin dalla progettazione non è solo un modello DPIA. Dovrebbe influenzare controlli degli accessi, logging, sviluppo sicuro, configurazione cloud, due diligence sui fornitori, automazione della conservazione e risposta agli incidenti.
Checklist Clarysec-ready per l’applicabilità dei controlli REG03
Usa questa checklist prima dei riesami di preparazione ISO 27701, dell’assurance clienti GDPR o delle valutazioni dei fornitori guidate da DORA:
- Creare o aggiornare REG02 per ogni attività di trattamento che coinvolge PII.
- Classificare il ruolo PIMS per ciascuna attività prima dell’avvio del trattamento.
- Classificare ogni relazione con terze parti in REG08 prima dell’approvazione del contratto o del trattamento di PII.
- Identificare gli obblighi in base al ruolo: titolare del trattamento, responsabile del trattamento, contitolare del trattamento o sub-responsabile.
- Registrare i controlli PIMS applicabili in REG03 con titolare, stato di attuazione ed evidenze.
- Registrare i controlli esclusi con una giustificazione chiara.
- Collegare le decisioni REG03 a rischi, obblighi legali, contratti o razionale di ambito.
- Allineare REG03 alla SoA ISO/IEC 27001:2022 quando i controlli di sicurezza supportano la privacy.
- Mappare i controlli privacy su ISO/IEC 27002:2022 5.34 dove è richiesta la protezione delle PII.
- Mappare i requisiti di fornitori e sub-responsabili su 5.19, 5.20, 5.21 e 5.22.
- Aggiungere riferimenti di mappatura trasversale della conformità per GDPR, NIS2, DORA, NIST CSF 2.0 e COBIT 2019 ove pertinenti.
- Testare la traccia delle evidenze con un campione di audit interno prima del riesame della preparazione alla certificazione.
- Ottenere l’approvazione dell’alta direzione quando cambiano l’ambito di applicazione del PIMS o l’applicabilità dei controlli.
La Privacy Information Management System Policy chiude questo ciclo di governance:
“[Entrambi] L’alta direzione DEVE approvare le modifiche all’ambito di applicazione del PIMS e all’applicabilità dei controlli in REG01 e REG03 prima che siano sottoposte modifiche all’ambito di certificazione.”
Dalla sezione “Governance del PIMS”, clausola della policy 6.1.3.
Questo è il tipo di evidenza di governance di cui gli auditor si fidano.
Trasformare le decisioni sui ruoli GDPR in evidenze sostenibili
L’applicabilità dei controlli ISO 27701 è il punto in cui la teoria dei ruoli GDPR diventa realtà operativa. Un titolare del trattamento ha bisogno di evidenze per base giuridica, trasparenza, conservazione, DPIA, gestione dei diritti e vigilanza sui responsabili del trattamento. Un responsabile del trattamento ha bisogno di evidenze per istruzioni documentate, riservatezza, sicurezza, assistenza, sub-responsabili, supporto in caso di violazione e cancellazione. Un contitolare del trattamento necessita di un accordo trasparente sulle responsabilità. Un sub-responsabile necessita di obblighi a cascata e supporto di assurance.
Clarysec aiuta le organizzazioni a costruire questo livello di evidenze tramite:
- Inventario dei trattamenti REG02 e struttura della base giuridica.
- Registrazioni REG03 di applicabilità dei controlli PIMS.
- Classificazione REG08 delle relazioni privacy con terze parti.
- Allineamento alla SoA ISO/IEC 27001:2022.
- Clausole di policy che assegnano titolari, tempistiche e requisiti di approvazione.
- Mappatura trasversale della conformità tramite Zenith Controls.
- Sequenza di implementazione tramite Zenith Blueprint.
Se la tua organizzazione si sta preparando a un PIMS ISO 27701, all’assurance clienti GDPR, ai riesami dei fornitori DORA o a una governance della sicurezza allineata a NIS2, inizia da una singola attività di trattamento ad alto rischio. Classifica il ruolo. Mappa i controlli applicabili. Collega le evidenze. Poi ripeti il processo finché il tuo programma privacy non è solo conforme sulla carta, ma spiegabile in sede di audit.
Scarica la suite di policy PIMS Clarysec, esplora Zenith Blueprint o prenota una valutazione dello stato di preparazione Clarysec per trasformare le decisioni su titolare del trattamento, responsabile del trattamento, contitolare del trattamento e sub-responsabile in un registro delle evidenze privacy pronto per la certificazione.
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
