Evidenze PIMS ISO 27701:2025 per gli audit GDPR
Sono le 08:40 di un giovedì e Ava, Compliance Manager di FinScale, ha appena aperto l’e-mail che, prima o poi, ogni azienda B2B SaaS in forte crescita riceve.
Un grande cliente enterprise tedesco ha inviato un questionario di due diligence GDPR con una scadenza di 48 ore. Non sta chiedendo una privacy policy. Non si accontenta di un certificato. Chiede evidenze.
Fornite il vostro registro delle attività di trattamento per i nostri dati. Mostrate le evidenze della due diligence svolta in fase di onboarding dei sub-responsabili. Spiegate come documentate gli obblighi previsti dal GDPR Article 28. Indicate se la vostra piattaforma opera come titolare del trattamento, responsabile del trattamento, contitolare del trattamento o sub-responsabile per ciascun flusso di lavoro. Dimostrate che la base giuridica è stata validata per la vostra funzionalità di supporto assistita dall’AI. Mostrate obblighi di cancellazione, diritto di audit, supporto agli incidenti e controlli contrattuali.
Ava sa che FinScale dispone degli elementi necessari. La funzione Legale ha l’Accordo sul trattamento dei dati (DPA). La Sicurezza ha la Dichiarazione di applicabilità ISO/IEC 27001:2022. Il Prodotto ha le checklist di rilascio. L’Approvvigionamento ha i contratti con i fornitori. La funzione Conformità ha un registro dei trattamenti, anche se alcune voci sono obsolete. Il problema non è l’assenza di evidenze. Il problema è che le evidenze sono disperse, l’ambiguità dei ruoli non è risolta e nessuno riesce a ricostruire rapidamente un’attività di trattamento dalla finalità alla base giuridica, dalla decisione di rischio al controllo sul fornitore, dal controllo di sicurezza alla registrazione di audit e al riesame della direzione.
Questo è il vero divario di responsabilizzazione.
ISO 27701:2025 diventa efficace quando colma questo divario. Un Sistema di gestione delle informazioni sulla privacy, o PIMS, non è soltanto un raccoglitore di policy per la certificazione privacy. È un modello operativo per produrre evidenze affidabili. Per CISO, responsabili della conformità, responsabili privacy, auditor e responsabili delle attività, l’obiettivo è semplice: costruire un PIMS che dimostri la responsabilizzazione GDPR per titolari e responsabili del trattamento, supportando al contempo le aspettative di ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 e COBIT 2019.
La responsabilizzazione GDPR è un problema di evidenze
La responsabilizzazione GDPR viene spesso fraintesa come un requisito meramente documentale. È molto più impegnativa.
Il GDPR Article 5 definisce i principi fondamentali del trattamento dei dati personali, tra cui liceità, correttezza, trasparenza, limitazione delle finalità, minimizzazione dei dati, esattezza, limitazione della conservazione, integrità e riservatezza. L’Article 5(2) rende il titolare del trattamento responsabile di poter dimostrare la conformità. L’Article 4 definisce il vocabolario di dati personali, trattamento, titolare del trattamento, responsabile del trattamento, pseudonimizzazione e violazione dei dati personali. L’Article 6 richiede una base giuridica per ciascuna attività di trattamento svolta in qualità di titolare. L’Article 9 aggiunge condizioni più rigorose per le categorie particolari di dati personali. L’Article 28 disciplina gli obblighi del responsabile del trattamento e le clausole contrattuali.
Questi obblighi non sono soddisfatti da una singola informativa privacy pubblica. Richiedono evidenze a livello di attività di trattamento.
Un modello pratico di evidenze PIMS ISO 27701:2025 deve rispondere a queste domande:
- Quali PII sono trattate?
- Perché sono trattate?
- L’organizzazione agisce come titolare del trattamento, responsabile del trattamento, contitolare del trattamento o sub-responsabile?
- Quale base giuridica si applica quando l’organizzazione è titolare del trattamento?
- Quale istruzione documentata si applica quando l’organizzazione è responsabile del trattamento?
- Quali sistemi, fornitori, sub-responsabili e sedi sono coinvolti?
- Quale screening del rischio privacy o quale decisione DPIA è stata effettuata?
- Quali controlli di sicurezza proteggono le PII?
- Quale evidenza dimostra che il controllo ha operato?
- Chi ha approvato rischio residuo, eccezioni e azioni correttive?
L’approccio di Clarysec trasforma queste domande in obblighi di policy, registri ed elementi di evidenza tracciabili. Il risultato è un PIMS in grado di sostenere la due diligence dei clienti, il riesame dell’autorità di controllo, l’audit interno, l’audit ISO, la valutazione DORA e il controllo del consiglio di amministrazione.
Iniziare dalla chiarezza dei ruoli: titolare, responsabile o entrambi
Il modo più rapido per fallire un audit PIMS è trattare allo stesso modo tutte le attività di trattamento.
Secondo il GDPR, un titolare del trattamento determina finalità e mezzi del trattamento. Un responsabile del trattamento tratta dati personali per conto di un titolare del trattamento. Molte aziende SaaS e tecnologiche svolgono entrambi i ruoli. FinScale è responsabile del trattamento quando ospita dati degli utenti finali dei clienti secondo le istruzioni del cliente. È titolare del trattamento per i dati dei dipendenti, i contatti commerciali, i contatti di fatturazione, i dati di selezione del personale e alcune analisi di prodotto.
Questa distinzione determina i requisiti di evidenza.
La Privacy Information Management System Policy di Clarysec rende la classificazione dei ruoli un requisito operativo:
[Entrambi] Il Proprietario del processo / responsabile dell’attività DEVE classificare il ruolo PIMS dell’organizzazione per ciascuna attività di trattamento di PII in REG02 prima dell’inizio dell’attività di trattamento.
Questo singolo obbligo cambia il modello operativo della privacy. Il riesame legale non è più un’attività successiva al rilascio. Ogni proprietario del processo deve classificare il ruolo PIMS prima dell’avvio del trattamento. Tale classificazione determina la catena di evidenze a valle.
Per le attività svolte come titolare del trattamento, la PII Processing Inventory and Lawful Basis Policy di Clarysec richiede la validazione della base giuridica:
[Titolare del trattamento] Il Responsabile privacy / Responsabile PIMS DEVE validare la base giuridica registrata in REG02 prima dell’avvio del trattamento in qualità di titolare e prima che qualsiasi modifica della finalità produca effetti.
Dalla sezione “Registrazioni delle finalità e della base giuridica del titolare del trattamento”, clausola di policy 4.2.2.
Per le attività svolte come responsabile del trattamento, il focus delle evidenze si sposta su istruzioni documentate, controlli contrattuali, governance dei sub-responsabili, misure di sicurezza, obblighi di assistenza, supporto agli incidenti e restituzione o cancellazione alla cessazione. Qui REG08 diventa essenziale.
La Processor, Subprocessor and Third-Party Privacy Management Policy di Clarysec richiede:
[Titolare del trattamento] Il Responsabile privacy / Responsabile PIMS DEVE verificare che i campi di controllo contrattuale del responsabile del trattamento in REG08 coprano ambito del trattamento, durata, finalità, categorie di PII, categorie di interessati, riservatezza, sicurezza, autorizzazione dei sub-responsabili, assistenza, audit o assurance, restituzione, cancellazione e cessazione prima dell’approvazione.
Dalla sezione “Controlli contrattuali e istruzioni documentate”, clausola di policy 4.3.2.
REG02 definisce l’attività di trattamento e il ruolo. REG04 esegue lo screening del rischio privacy. REG08 valida i controlli relativi a responsabili, sub-responsabili e fornitori. REG12 indicizza le evidenze. Insieme creano la catena delle evidenze PIMS.
La catena delle evidenze PIMS attesa dagli auditor
Un PIMS solido non chiede ai team di mantenere fogli di calcolo scollegati. Definisce elementi di evidenza, proprietari, tempistiche, cicli di riesame e tracce di audit.
La PIMS Documented Information and Evidence Management Policy di Clarysec stabilisce:
[Tutti] Il Responsabile privacy / Responsabile PIMS DEVE mantenere un indice delle informazioni documentate del PIMS in REG12 prima della pubblicazione iniziale del PIMS e successivamente con frequenza trimestrale.
REG12 impedisce al programma privacy di diventare una cartella di PDF obsoleti. Indica all’auditor quali evidenze esistono, dove sono archiviate, chi ne è proprietario, quando sono state riesaminate l’ultima volta e quali attività di trattamento, rischi, obblighi o controlli supportano.
| Elemento di evidenza | Domanda principale a cui risponde | Proprietario tipico | Valore per l’audit |
|---|---|---|---|
| REG02 Inventario dei trattamenti di PII | Quali PII sono trattate, perché, con quale ruolo e in base a quale base giuridica o istruzione? | Proprietario del processo, Responsabile privacy | Dimostra visibilità sui trattamenti e classificazione dei ruoli |
| REG04 Registrazione dello screening del rischio privacy o della DPIA | Il rischio privacy è stato valutato prima del rilascio o di una modifica sostanziale? | Responsabile dell’attività, Responsabile privacy, Sicurezza | Dimostra privacy by design e processo decisionale basato sul rischio |
| REG08 Registro dei responsabili e sub-responsabili | Quali terze parti trattano PII e in base a quali controlli? | Approvvigionamento, Legale, Responsabile privacy | Dimostra governance dei responsabili del trattamento ai sensi dell’Article 28 e supervisione dei fornitori |
| REG12 Indice delle informazioni documentate del PIMS | Dove si trovano le evidenze autorevoli e quando sono state riesaminate? | Responsabile PIMS | Dimostra controllo delle evidenze, aggiornamento e preparazione agli audit |
| Registro della base giuridica | Quale base giuridica supporta il trattamento come titolare? | Legale, Responsabile privacy | Dimostra la responsabilizzazione ai sensi del GDPR Article 6 |
| Registro degli audit | Quali audit privacy sono stati svolti e quali rilievi restano aperti? | Audit interno, Conformità | Supporta monitoraggio, azione correttiva e riesame della direzione |
Questa catena delle evidenze si allinea naturalmente ai requisiti ISO/IEC 27001:2022 relativi a contesto, parti interessate, pianificazione del rischio, controllo operativo, informazioni documentate, valutazione delle prestazioni, audit interno, riesame della direzione e miglioramento continuo. Si collega inoltre ai controlli ISO/IEC 27002:2022 quali 5.2 Ruoli e responsabilità per la sicurezza delle informazioni, 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.34 Privacy e protezione delle PII e 8.10 Cancellazione delle informazioni.
Le evidenze del titolare e del responsabile non sono le stesse
Il cliente tedesco di Ava non sta chiedendo soltanto se FinScale abbia policy privacy. Vuole la prova che FinScale comprenda quale ruolo svolge per ciascun flusso di dati.
| Ruolo PIMS | Obbligo chiave | Elementi di evidenza principali | Riferimento alla policy Clarysec |
|---|---|---|---|
| Titolare del trattamento delle PII | Liceità del trattamento | REG02, Registro della base giuridica | PII Processing Inventory and Lawful Basis Policy |
| Titolare del trattamento delle PII | Trasparenza e diritti | Informativa privacy, procedura DSAR, log DSAR | P17 Data Protection and Privacy Policy |
| Titolare del trattamento delle PII | Gestione del rischio privacy | REG04, rapporto DPIA, decisione di rischio | Privacy Risk Assessment and DPIA Policy |
| Responsabile del trattamento delle PII | Trattamento disciplinato contrattualmente | DPA firmato, istruzioni documentate, REG08 | Processor, Subprocessor and Third-Party Privacy Management Policy |
| Responsabile del trattamento delle PII | Sicurezza del trattamento | Dichiarazione di applicabilità del SGSI, riesami degli accessi, monitoraggio, evidenze di penetration test | P33 Audit and Compliance Monitoring Policy |
| Responsabile del trattamento delle PII | Governance dei sub-responsabili | Elenco dei sub-responsabili, evidenze di autorizzazione, contratti con obblighi a cascata | Third-Party and Supplier Security Policy-sme |
Quando agisce come titolare del trattamento, FinScale deve giustificare perché tratta i dati. Ad esempio, il trattamento delle retribuzioni dei dipendenti può basarsi sulla necessità contrattuale e su un obbligo legale. Il marketing può basarsi sul consenso o sul legittimo interesse, a seconda del contesto e della giurisdizione. La selezione del personale può richiedere limiti di conservazione, trasparenza e controllo degli accessi. L’evidenza non è solo la base giuridica selezionata: è la registrazione validata, l’informativa, la regola di conservazione, la procedura per l’esercizio dei diritti e la decisione di rischio.
Quando agisce come responsabile del trattamento, FinScale deve dimostrare di operare secondo istruzioni documentate del cliente. Le evidenze includono il DPA, la configurazione del prodotto, i log di sistema, i controlli di sicurezza, le autorizzazioni dei sub-responsabili, le procedure di assistenza, il processo di supporto in caso di violazione, il diritto di audit e le evidenze di cancellazione o restituzione.
La P17 Data Protection and Privacy Policy di Clarysec rafforza l’integrazione della privacy nel SGSI:
L’organizzazione DEVE mantenere un quadro formale di governance della privacy integrato nel Sistema di gestione della sicurezza delle informazioni (SGSI) per applicare questa policy.
Dalla sezione “Requisiti di governance”, clausola di policy 5.1.
La versione SME, Data Protection and Privacy Policy-sme, mantiene la stessa disciplina delle evidenze:
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.
Richiede inoltre:
La base giuridica (ad es. consenso, contratto, obbligo legale) DEVE essere documentata nel registro dei trattamenti.
Per i programmi enterprise, la P17 Data Protection and Privacy Policy aggiunge la titolarità:
Il Dipartimento Legale DEVE mantenere e aggiornare il Registro della base giuridica.
Esempio pratico: rilascio delle analisi di prodotto
Consideriamo una funzionalità di analisi di prodotto che traccia navigazione degli utenti, adozione delle funzionalità, metadati di sessione, ID dell’organizzazione, ruolo dell’utente e informazioni sul dispositivo. Il Prodotto vuole informazioni sull’utilizzo. Le Vendite vogliono metriche di adozione. Il Customer Success vuole segnali di churn. Il Legale chiede se FinScale sia titolare o responsabile del trattamento. La Sicurezza chiede se i log contengano dati personali. L’Approvvigionamento segnala che il fornitore di analytics utilizza sub-responsabili.
Un PIMS solido trasforma tutto questo in un flusso di lavoro ripetibile.
1. Creare o aggiornare REG02 prima dell’inizio del trattamento
Il responsabile dell’attività registra l’attività in REG02. La registrazione dovrebbe includere finalità, categorie di PII, categorie di interessati, sistemi, periodo di conservazione, trasferimenti, misure di sicurezza, classificazione del ruolo e base giuridica o istruzione documentata.
Se le analisi sono utilizzate per finalità proprie di miglioramento del prodotto di FinScale, FinScale può essere titolare del trattamento per tale attività. Se le analisi sono svolte solo secondo impostazioni configurate dal cliente e per conto del cliente, FinScale può essere responsabile del trattamento. In molti ambienti SaaS, entrambi i ruoli possono coesistere in una singola funzionalità, in base al flusso dei dati e alla finalità.
2. Validare la base giuridica o l’istruzione documentata
Se FinScale è titolare del trattamento, il Responsabile privacy o il Legale valida la base giuridica in REG02 prima dell’inizio del trattamento. Se sono coinvolte categorie particolari di dati, il team deve identificare anche la condizione pertinente prevista dal GDPR Article 9 e le misure di sicurezza aggiuntive.
Se FinScale è responsabile del trattamento, le evidenze devono rinviare all’istruzione documentata del cliente. La domanda diventa: dove si trova l’istruzione, quale trattamento è consentito e come dimostra FinScale di averla rispettata?
3. Attivare lo screening del rischio privacy in REG04
La Privacy Risk Assessment and DPIA Policy di Clarysec richiede:
[Entrambi] Il Proprietario del processo / responsabile dell’attività DEVE avviare lo screening del rischio privacy in REG04 prima che inizi un trattamento di PII nuovo o modificato in modo sostanziale registrato in REG02.
Dalla sezione “Screening del rischio privacy”, clausola di policy 4.1.1.
Lo screening dovrebbe valutare sensibilità, scala, implicazioni del monitoraggio, aspettative dell’interessato, profilazione, decisioni automatizzate, trasferimenti transfrontalieri di dati, accesso dei fornitori, conservazione ed efficacia dei controlli. Se il rischio è elevato, il PIMS dovrebbe attivare una DPIA e registrare la decisione.
4. Aggiornare REG08 per fornitori e sub-responsabili
Se un fornitore terzo di analytics riceve PII, Approvvigionamento, Legale e Privacy aggiornano REG08. I campi contrattuali dovrebbero coprire ambito, durata, finalità, categorie di PII, riservatezza, sicurezza, autorizzazione dei sub-responsabili, assistenza, audit o assurance, restituzione, cancellazione e cessazione.
La Third-Party and Supplier Security Policy-sme supporta questa disciplina operativa richiedendo:
Verifica delle pratiche di gestione dei dati o della conformità alla protezione dei dati quando sono coinvolti dati personali identificabili (PII).
Anche la P17 Data Protection and Privacy Policy richiede:
I team Approvvigionamento, Legale e Conformità DEVONO verificare la conformità all’Article 28 del GDPR e richiedere la rivalutazione annuale di tutti i fornitori ad alto rischio.
5. Indicizzare le evidenze in REG12
Infine, il Responsabile PIMS aggiorna REG12 con collegamenti a REG02, validazione della base giuridica, istruzione documentata, screening REG04, DPIA se richiesta, registrazione del fornitore in REG08, DPA, riesame di sicurezza, decisione di conservazione, approvazione del prodotto ed evidenze di monitoraggio.
Questo trasforma la privacy by design in evidenze pronte per l’audit.
Usare Zenith Blueprint per costruire la tracciabilità
Sapere quali evidenze raccogliere è solo metà della sfida. La parte più difficile è costruire un sistema che le produca in modo affidabile.
La Zenith Blueprint: An Auditor’s 30-Step Roadmap inquadra questo aspetto nella fase ISMS Foundation & Leadership, Step 2: Stakeholder Needs and ISMS Scope. La guida mostra come le aspettative degli stakeholder diventino controlli pianificati:
Clienti
(B2B SaaS)
Riservatezza dei dati, disponibilità secondo
SLA, notifica della violazione entro
24h
Implementare controlli degli accessi, cifratura;
il piano di risposta agli incidenti include
procedure di notifica.
Include inoltre:
Action Item 4.2: Compilare un elenco di tutte le parti interessate significative e annotare i loro requisiti relativi alla sicurezza delle informazioni.
Per ISO 27701:2025, estendere questa attività alla privacy. Le parti interessate includono clienti, interessati, autorità di regolamentazione, responsabili del trattamento, sub-responsabili, dipendenti, team di prodotto, audit interno, direzione, clienti del settore finanziario e autorità di settore ove si applichino NIS2 o DORA.
| Parte interessata | Aspettativa privacy | Risposta delle evidenze PIMS |
|---|---|---|
| Cliente B2B come titolare del trattamento | Il responsabile del trattamento opera solo su istruzioni documentate e supporta gli audit | Registrazione dei controlli contrattuali in REG08, DPA, rapporti di assurance |
| Autorità di regolamentazione UE | Il titolare del trattamento dimostra base giuridica, trasparenza, gestione dei diritti e gestione delle violazioni | REG02, Registro della base giuridica, registrazioni DSAR, registrazioni degli incidenti |
| Interessato | Il trattamento è corretto, trasparente, limitato, sicuro e rispettoso dei diritti | Informativa privacy, regole di conservazione, controlli degli accessi, evidenze di cancellazione |
| Consiglio di amministrazione o organo di gestione | Il rischio privacy è governato, dotato di risorse e riesaminato | Obiettivi PIMS, report sui rischi, verbali del riesame della direzione |
| Audit interno | I controlli operano e le evidenze sono affidabili | Indice delle evidenze REG12, piano di audit, rilievi, azioni correttive |
Nella fase Risk Management, Step 13: Risk Treatment Planning and Statement of Applicability, la Zenith Blueprint raccomanda la tracciabilità:
Collegare le normative: se alcuni controlli sono implementati specificamente per conformarsi a GDPR, NIS2 o DORA, è possibile annotarlo nel Registro dei rischi (come parte della giustificazione dell’impatto del rischio) oppure nelle note della SoA.
Questo crea il filo conduttore che gli auditor cercano: requisito, rischio, controllo, proprietario, evidenza, risultato del test e azione di miglioramento.
Dove si colloca Zenith Controls nel modello PIMS
La Zenith Controls: The Cross-Compliance Guide di Clarysec aiuta i team a evitare programmi di conformità duplicati mappando i temi dei controlli ISO/IEC 27001:2022 e ISO/IEC 27002:2022 su altri standard, aspettative di audit e modelli di evidenza.
Per le evidenze PIMS ISO 27701:2025, quattro controlli ISO/IEC 27002:2022 sono particolarmente importanti:
- 5.2 Ruoli e responsabilità per la sicurezza delle informazioni
- 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.34 Privacy e protezione delle PII
Il controllo 5.2 supporta la chiarezza dei ruoli. Un PIMS richiede responsabilità definite per Responsabile PIMS, Responsabile privacy, Proprietario del processo, responsabile dell’attività, Legale, Approvvigionamento, Sicurezza, Audit interno e alta direzione.
Il controllo 5.34 supporta l’obbligo privacy fondamentale. La Zenith Blueprint, fase Controls in Action, Step 23, spiega l’aspettativa di audit:
Dal punto di vista dell’audit, questo controllo è sempre più al centro dell’attenzione. Auditor, autorità di regolamentazione e clienti vogliono vedere:
✓ Dove risiedono le PII,
✓ Quale base giuridica ne governa il trattamento,
✓ Come è limitato l’accesso,
✓ Come sono segnalati gli incidenti,
✓ E come l’organizzazione rispetta i diritti e mantiene la trasparenza.
La Zenith Blueprint prosegue:
Il controllo 5.34 non è solo una casella da spuntare. È una dichiarazione di responsabilità etica nella custodia dei dati.
I controlli 5.20 e 5.21 collegano le evidenze PIMS alla governance dei fornitori e della catena di fornitura ICT. La Zenith Blueprint, fase Controls in Action, Step 23, elenca i temi degli accordi con i fornitori:
Le aree chiave generalmente trattate negli accordi con i fornitori includono:
✓ Obblighi di riservatezza, inclusi ambito, durata e restrizioni alla comunicazione a terze parti;
✓ Responsabilità di controllo degli accessi, come chi può accedere ai vostri dati, come sono gestite le credenziali e quale monitoraggio è in atto;
✓ Misure tecniche e organizzative per protezione dei dati, cifratura, trasmissione sicura, backup e impegni di disponibilità;
✓ Tempistiche e protocolli di segnalazione degli incidenti, spesso con tempi definiti (ad es. “notifica entro 24 ore”);
✓ Diritto di audit, inclusi frequenza, ambito e accesso alle evidenze pertinenti (ad es. rapporti di penetration test, SoA, certificazioni);
✓ Controlli sui subappaltatori, che richiedono al fornitore di trasferire obblighi di sicurezza equivalenti ai partner a valle;
✓ Previsioni di fine contratto, come restituzione o distruzione dei dati, ripristino degli asset e disattivazione degli account.
Questo è il ponte tra responsabilizzazione GDPR ed evidenze del SGSI.
Mappare le evidenze PIMS tra GDPR, NIS2, DORA, NIST e COBIT 2019
Le evidenze privacy raramente servono un solo quadro di riferimento. Un elemento di evidenza PIMS ben progettato può rispondere a più domande di audit.
Il GDPR fonda la responsabilizzazione privacy su base giuridica, chiarezza dei ruoli, contratti con i responsabili del trattamento, diritti, gestione delle violazioni e capacità di dimostrare la conformità.
NIS2 è rilevante per soggetti essenziali e importanti, inclusi alcuni fornitori cloud, fornitori di servizi gestiti, prestatori di Managed Security Services, fornitori di data center e organizzazioni di infrastruttura digitale. NIS2 Article 20 attribuisce agli organi di gestione la responsabilità della governance della cibersicurezza. L’Article 21 richiede misure tecniche, operative e organizzative adeguate, tra cui analisi dei rischi, trattamento degli incidenti, continuità operativa, sicurezza della catena di fornitura, sviluppo sicuro, valutazione dell’efficacia, formazione, crittografia, sicurezza HR, controllo degli accessi, gestione degli asset e MFA o autenticazione continua ove appropriato. L’Article 23 introduce aspettative di segnalazione degli incidenti significativi, incluso preallarme entro 24 ore e notifica dell’incidente entro 72 ore.
DORA è rilevante per gli enti finanziari e i fornitori terzi di servizi ICT negli ecosistemi finanziari. Gli Articles 5 e 6 di DORA richiedono governance del rischio ICT, policy, strategia, test e miglioramento continuo. Gli Articles 17 to 19 riguardano rilevazione, classificazione, escalation, segnalazione, analisi della causa radice e lezioni apprese per gli incidenti ICT. Gli Articles 28 to 30 richiedono strategia per il rischio di terze parti ICT, registri, due diligence, clausole contrattuali, diritto di audit, assistenza sugli incidenti, protezione dei dati, pianificazione dell’uscita e riesame del rischio di concentrazione.
NIST CSF 2.0 fornisce un linguaggio di governance e rischio tramite GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND e RECOVER. COBIT 2019 aggiunge obiettivi di governance, pratiche di gestione, titolarità, metriche, assurance e capacità dei processi.
| Evidenza PIMS | Valore per GDPR | Valore per NIS2 e DORA | Valore per NIST e COBIT 2019 | Controllo ISO/IEC 27002:2022 correlato da Zenith Controls |
|---|---|---|---|---|
| Inventario dei trattamenti REG02 | Dimostra visibilità su attività, ruolo, finalità, base giuridica e conservazione | Supporta la comprensione di asset, servizi e dipendenze | Supporta contesto organizzativo, input di rischio e tracciabilità della governance | 5.2 e 5.34 |
| Screening del rischio privacy REG04 | Supporta privacy by design, decisioni DPIA e misure di sicurezza | Supporta le aspettative di gestione del rischio ed efficacia dei controlli | Supporta categorizzazione del rischio, prioritizzazione e pianificazione del miglioramento | 5.34 |
| Registro dei responsabili e sub-responsabili REG08 | Supporta governance dei responsabili, clausole contrattuali, diritto di audit, cancellazione e obblighi di assistenza | Supporta rischio della catena di fornitura, rischio di terze parti ICT, riesame del rischio di concentrazione e pianificazione dell’uscita | Supporta gestione del rischio dei fornitori e assurance della governance | 5.20 e 5.21 |
| Indice delle evidenze REG12 | Dimostra controllo delle informazioni documentate e preparazione agli audit | Supporta supervisione, assurance e controllo della direzione | Supporta tracciabilità delle evidenze e monitoraggio dei controlli | 5.2 |
| Registrazioni di incidenti e violazioni | Supporta valutazione della violazione dei dati personali ed evidenze di notifica | Supporta i modelli di segnalazione degli incidenti NIS2 e DORA | Supporta rilevazione, risposta, ripristino e lezioni apprese | 5.34 e 5.20 |
Il vantaggio per la conformità è chiaro. Una singola catena controllata di evidenze PIMS può supportare GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0, COBIT 2019 e la due diligence dei clienti.
Come gli auditor testeranno il vostro PIMS
Un audit PIMS non è un semplice riesame documentale. È un esercizio di tracciabilità delle evidenze.
| Profilo dell’auditor | Probabile percorso di audit | Risposta forte delle evidenze PIMS |
|---|---|---|
| Auditor ISO/IEC 27001:2022 e ISO 27701:2025 | Ambito di applicazione, parti interessate, valutazione del rischio, SoA, controlli dell’Allegato A, audit interno, riesame della direzione | REG02 collegato al registro dei rischi, note SoA, indice delle evidenze REG12, rilievi di audit |
| Autorità GDPR o auditor privacy | Attività di trattamento, base giuridica, trasparenza, contratti con i responsabili del trattamento, gestione delle violazioni | REG02, Registro della base giuridica, informative privacy, REG08, registrazioni degli incidenti |
| Valutatore NIST CSF | Current and Target Profiles, governance, rischio, ruoli, rischio dei fornitori, risposta e ripristino | Profilo PIMS, piano di gap remediation, registro dei rischi, matrice dei ruoli, monitoraggio dei fornitori |
| Auditor COBIT 2019 | Obiettivi di governance, titolarità, capacità dei processi, metriche, assurance | Mandato di governance PIMS, KPI, reportistica alla direzione, registro degli audit |
| Auditor DORA o cliente finanziario | Rischio ICT, processo di gestione degli incidenti, registro delle terze parti, diritti contrattuali, strategia di uscita | REG08, registro dei fornitori ICT, playbook per gli incidenti, piani di uscita, evidenze di assurance |
| Valutatore NIS2 | Supervisione della direzione, misure di gestione del rischio, segnalazione degli incidenti, sicurezza della catena di fornitura | Approvazioni del consiglio di amministrazione, mappatura NIS2, controlli sui fornitori, flusso di notifica degli incidenti |
La P33 Audit and Compliance Monitoring Policy di Clarysec supporta il modello di audit:
L’organizzazione DEVE mantenere un Registro degli audit contenente:
L’equivalente SME, Audit and Compliance Monitoring Policy-sme, aggiunge un importante requisito di qualità delle evidenze:
I metadati (ad es. chi li ha raccolti, quando e da quale sistema) DEVONO essere documentati.
Questo requisito sui metadati è piccolo ma potente. Screenshot privi di fonte, data, raccoglitore e contesto del sistema sono evidenze deboli. Evidenze di audit controllate dimostrano autenticità, aggiornamento e tracciabilità.
Come si presenta una buona evidenza PIMS
Supponiamo che un auditor selezioni una singola attività: analisi dei ticket di assistenza clienti.
Una risposta debole è: “Abbiamo una privacy policy e il nostro DPA la copre”.
Una risposta PIMS solida è:
- REG02 identifica attività, sistemi, categorie di PII, interessati, finalità, classificazione del ruolo, conservazione, trasferimenti, controlli di sicurezza e proprietario.
- La classificazione del ruolo indica se l’organizzazione è titolare del trattamento, responsabile del trattamento o entrambi per specifiche parti del flusso di lavoro.
- Se è titolare del trattamento, la base giuridica è validata e registrata nel Registro della base giuridica.
- Se è responsabile del trattamento, l’istruzione del cliente e la clausola DPA sono collegate.
- REG04 mostra lo screening del rischio privacy prima del rilascio o di una modifica sostanziale.
- REG08 identifica la piattaforma di ticketing, il fornitore di riepilogo AI, i sub-responsabili, i controlli contrattuali, il diritto di audit, le assurance di sicurezza, le condizioni di cancellazione e l’assistenza sugli incidenti.
- Le evidenze di controllo degli accessi mostrano che l’accesso del personale di supporto è basato sui ruoli e riesaminato.
- Le evidenze di logging e monitoraggio mostrano che l’accesso ai ticket di assistenza è monitorato.
- Le evidenze di conservazione e cancellazione mostrano che i ticket sono cancellati o anonimizzati secondo il periodo di conservazione approvato.
- REG12 indicizza tutte le evidenze di supporto con proprietario e data di riesame.
- Il Registro degli audit mostra se l’attività è stata testata, quali rilievi sono stati sollevati e se le azioni correttive sono state chiuse.
È così che ISO 27701:2025 diventa operativa. Crea una catena ripetibile di responsabilizzazione.
Errori comuni nelle evidenze PIMS
Negli ambienti SaaS, fintech, servizi gestiti e tecnologia B2B, emergono ripetutamente le stesse lacune.
Primo, le organizzazioni mantengono un RoPA o un registro dei trattamenti, ma non classificano per attività i ruoli di titolare e responsabile del trattamento. Questo crea confusione su base giuridica, istruzioni documentate e obblighi dei sub-responsabili.
Secondo, la base giuridica viene registrata una volta e non viene rivalidata quando cambia la finalità. Il GDPR Article 6 richiede disciplina su finalità e base giuridica. Un trattamento ulteriore può richiedere una valutazione di compatibilità e misure di sicurezza.
Terzo, gli inventari dei fornitori elencano fornitori ma non mostrano i campi di controllo contrattuale. Un elenco di fornitori non equivale alla governance dei responsabili del trattamento.
Quarto, le decisioni DPIA sono informali. I team affermano “non è ad alto rischio”, ma non possono mostrare criteri di screening, approvatore, data o evidenza.
Quinto, le evidenze di audit esistono ma non sono controllate. Gli screenshot non hanno metadati. Le policy sono aggiornate, ma i registri sono obsoleti. I contratti esistono, ma le rivalutazioni al rinnovo vengono mancate.
Sesto, i processi di gestione degli incidenti si concentrano sugli eventi di cibersicurezza ma non classificano chiaramente le violazioni dei dati personali. L’analisi delle violazioni dei dati personali GDPR, la segnalazione degli incidenti significativi NIS2 e la segnalazione degli incidenti ICT DORA devono essere coordinate, non duplicate.
Clarysec affronta questi errori trattando le evidenze PIMS come un sistema di gestione controllato, non come una corsa dell’ultimo minuto prima dell’audit.
Checklist di preparazione delle evidenze PIMS ISO 27701:2025
Utilizzate questa checklist per il prossimo riesame interno di preparazione.
- Definire l’ambito di applicazione del PIMS e le parti interessate, inclusi clienti, autorità di regolamentazione, interessati, fornitori, audit interno e direzione.
- Assegnare ruoli e responsabilità PIMS, inclusi Responsabile PIMS, Responsabile privacy, Proprietario del processo, Legale, Approvvigionamento, Sicurezza e Audit interno.
- Creare voci REG02 per ogni attività di trattamento di PII.
- Classificare il ruolo di titolare del trattamento, responsabile del trattamento, contitolare del trattamento o sub-responsabile per ciascuna attività.
- Validare la base giuridica per il trattamento come titolare prima dell’inizio del trattamento e prima di una modifica della finalità.
- Registrare le istruzioni documentate per le attività svolte come responsabile del trattamento.
- Attivare lo screening del rischio privacy REG04 prima di trattamenti nuovi o modificati in modo sostanziale.
- Completare una DPIA quando lo screening del rischio indica un rischio privacy elevato.
- Mantenere REG08 per responsabili del trattamento, sub-responsabili, fornitori ICT e fornitori rilevanti per la privacy.
- Verificare i campi contrattuali relativi a ambito, durata, finalità, categorie di PII, riservatezza, sicurezza, assistenza, diritto di audit, restituzione, cancellazione e cessazione.
- Mantenere REG12 come indice delle informazioni documentate del PIMS.
- Mappare le evidenze PIMS al trattamento del rischio ISO/IEC 27001:2022 e alle note SoA.
- Collegare gli obblighi GDPR, NIS2, DORA, NIST CSF 2.0 e COBIT 2019 ove pertinenti.
- Condurre audit interni annuali di conformità privacy e aggiornare il Registro degli audit.
- Riesaminare trimestralmente rilievi aperti, azioni correttive, decisioni di rischio e reportistica alla direzione.
La P17 Data Protection and Privacy Policy rafforza il ciclo di audit:
Un audit interno di conformità privacy DEVE essere condotto annualmente oppure in caso di modifiche organizzative o regolamentari rilevanti. L’ambito dell’audit DEVE includere:
Il messaggio è semplice. La conformità privacy si monitora, non si presume.
Costruire il modello di evidenze PIMS con Clarysec
ISO 27701:2025 genera il massimo valore quando è integrata con ISO/IEC 27001:2022 e progettata per produrre evidenze per impostazione predefinita. È così che la privacy diventa un modello operativo difendibile, non un progetto di certificazione.
Quando un cliente chiede assurance privacy, potete mostrare evidenze. Quando un’autorità di regolamentazione chiede perché avete trattato dati, potete mostrare ruolo, finalità, base giuridica, misure di sicurezza e approvazioni. Quando un auditor chiede come governate i sub-responsabili, potete mostrare REG08, controlli contrattuali, rivalutazioni e diritto di audit. Quando il consiglio di amministrazione chiede se il rischio privacy è sotto controllo, potete mostrare metriche, azioni aperte, risultati di audit e riesame della direzione.
Se il vostro PIMS è ancora ricco di policy ma povero di evidenze, iniziate dalla catena che seguiranno gli auditor:
inventario dei trattamenti REG02, screening del rischio privacy REG04, governance dei responsabili e sub-responsabili REG08, indice delle evidenze REG12, Registro della base giuridica, Registro degli audit e mappatura SoA.
Clarysec può aiutarvi a rendere operativa questa catena attraverso:
- Zenith Blueprint: An Auditor’s 30-Step Roadmap, in particolare Step 2 per i requisiti degli stakeholder, Step 13 per il trattamento del rischio e la tracciabilità SoA, e Step 23 per controlli privacy, fornitori e organizzativi.
- Zenith Controls: The Cross-Compliance Guide, utilizzando i controlli ISO/IEC 27002:2022 5.2, 5.20, 5.21 e 5.34 come ancoraggi pratici per la responsabilizzazione privacy.
- Il set di policy PIMS ISO 27701 di Clarysec, incluse Privacy Information Management System Policy, PII Processing Inventory and Lawful Basis Policy, Privacy Risk Assessment and DPIA Policy, Processor, Subprocessor and Third-Party Privacy Management Policy e PIMS Documented Information and Evidence Management Policy.
- Supporto enterprise e SME tramite P17 Data Protection and Privacy Policy, Data Protection and Privacy Policy-sme, Third-Party and Supplier Security Policy-sme, P33 Audit and Compliance Monitoring Policy e Audit and Compliance Monitoring Policy-sme.
La prossima azione è semplice: scegliete un’attività di trattamento di PII ad alto rischio e percorrete la catena delle evidenze da REG02 a REG12. Se la catena si interrompe, quello è il vostro primo progetto di miglioramento. Se regge, estendete il modello all’intero inventario dei trattamenti.
È così che ISO 27701:2025 diventa più di un certificato. Diventa prova della responsabilizzazione GDPR.
Ottieni la certificazione PECB ISO/IEC 27701 e avvia il tuo PIMS
- ✓ Materiale didattico ufficiale PECB e due tentativi d'esame
- ✓ Quota di certificazione e AMF del primo anno incluse, ove applicabile
- ✓ In autoapprendimento o dal vivo online · corso assegnato entro 1 giorno lavorativo
Frequently Asked Questions
L'autore
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
