Protezione dei dati personali identificabili pronta per l’audit per GDPR, NIS2 e DORA
L’allerta arrivò nella casella di posta di Sarah alle 22:00 di un martedì.
Come responsabile della sicurezza delle informazioni di una società FinTech SaaS in crescita, Sarah era abituata agli avvisi notturni. Questo, però, era diverso. Uno sviluppatore junior aveva esposto un database dell’ambiente di staging su un endpoint pubblico durante il test di una nuova funzionalità di analytics. Il database avrebbe dovuto contenere dati di test, ma una recente sincronizzazione dalla produzione allo staging lo aveva popolato con PII reali dei clienti.
L’incidente fu contenuto rapidamente. Poi arrivò la seconda scoperta. Un foglio di calcolo di migrazione denominato customer_users_final_v7.xlsx era stato copiato dallo stesso set di dati. Conteneva nomi, e-mail, autorizzazioni basate sui ruoli, log di utilizzo, campi relativi al Paese, note di supporto e commenti a testo libero che non avrebbero mai dovuto entrare in un flusso di lavoro di test. Era stato copiato su un’unità condivisa, scaricato da uno sviluppatore, allegato a un ticket e dimenticato.
A mezzanotte Sarah non stava più gestendo una semplice errata configurazione tecnica. Stava gestendo un problema di audit.
L’azienda era già certificata ISO/IEC 27001:2022. Il consiglio di amministrazione chiedeva assurance GDPR prima del lancio sul mercato UE. I clienti dei servizi finanziari inviavano questionari di due diligence DORA. Le relazioni cloud e con i fornitori di servizi gestiti sollevavano domande NIS2 sulla catena di fornitura. Il team legale poteva spiegare gli obblighi. L’ingegneria poteva indicare la cifratura. Il prodotto aveva obiettivi di privacy by design. La Dichiarazione di Applicabilità citava la privacy e la protezione delle PII.
Ma nessuno era in grado di mostrare, in un’unica catena tracciabile, quali PII esistessero, perché fossero trattate, chi potesse accedervi, dove fossero mascherate, quali fornitori le trattassero, per quanto tempo fossero conservate e come un incidente sarebbe stato classificato ai sensi di GDPR, NIS2 o DORA.
Questo divario spiega esattamente perché ISO/IEC 27701:2025 e ISO/IEC 29151:2022 sono importanti. Non sono semplici etichette privacy. Aiutano le organizzazioni a trasformare le promesse sulla privacy in controlli di protezione delle PII pronti per l’audit. ISO/IEC 27701:2025 estende un sistema di gestione della sicurezza delle informazioni ISO/IEC 27001:2022 alla gestione delle informazioni sulla privacy. ISO/IEC 29151:2022 aggiunge indicazioni pratiche per proteggere le informazioni personali identificabili lungo l’intero ciclo di vita.
L’approccio di Clarysec consiste nel costruire un unico modello operativo di privacy e sicurezza basato sulle evidenze, non silos di conformità separati. Questo modello combina Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Zenith Controls: The Cross-Compliance Guide Zenith Controls e le politiche Clarysec in un unico sistema tracciabile per GDPR, ISO/IEC 27001:2022, ISO/IEC 27701:2025, ISO/IEC 29151:2022, NIS2, DORA, assurance secondo l’approccio NIST e aspettative di governance COBIT 2019.
Perché la protezione delle PII è ormai un tema di audit a livello di consiglio di amministrazione
La protezione delle PII veniva tradizionalmente trattata come responsabilità del team privacy. Oggi è un tema di fiducia, resilienza e conformità normativa a livello di consiglio di amministrazione.
Il GDPR resta il riferimento di base per la protezione dei dati personali in Europa e oltre. Definisce dati personali, trattamento, titolare del trattamento, responsabile del trattamento, destinatario, terza parte, consenso e violazione dei dati personali in modi che incidono sui contratti SaaS, sulle attività di supporto, sull’analytics, sulla telemetria di prodotto, sulla gestione dei fornitori e sulla risposta agli incidenti. I suoi principi richiedono liceità, correttezza, trasparenza, limitazione delle finalità, minimizzazione dei dati, esattezza, limitazione della conservazione, integrità, riservatezza e accountability. In termini di audit, il GDPR non chiede soltanto se i dati siano cifrati. Chiede se l’organizzazione sia in grado di dimostrare perché i dati esistono e come viene conseguita la conformità.
NIS2 innalza il livello della governance della cibersicurezza per i soggetti essenziali e importanti. Article 21 richiede misure di gestione dei rischi di cibersicurezza, incluse analisi dei rischi, politiche di sicurezza dei sistemi informativi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, sviluppo sicuro, gestione delle vulnerabilità, valutazione dell’efficacia dei controlli, igiene informatica, crittografia, sicurezza delle risorse umane, controllo degli accessi, gestione degli asset, autenticazione e comunicazioni sicure. Article 23 aggiunge una segnalazione degli incidenti per fasi, inclusa un’allerta precoce entro 24 ore, una notifica entro 72 ore e una relazione finale entro un mese dalla notifica.
DORA cambia la prospettiva per le entità finanziarie e i loro fornitori ICT. Si applica dal 17 gennaio 2025 e istituisce un regime armonizzato di resilienza operativa digitale che copre gestione del rischio ICT, segnalazione degli incidenti rilevanti connessi all’ICT, test di resilienza, rischio ICT di terze parti, requisiti contrattuali e supervisione dei fornitori terzi critici di servizi ICT. Per molte entità finanziarie, DORA opera come atto giuridico dell’Unione specifico di settore quando si sovrappongono obblighi equivalenti a NIS2. Per i fornitori SaaS e ICT che servono istituzioni finanziarie, la pressione DORA arriva spesso attraverso clausole contrattuali, audit dei clienti, requisiti di pianificazione dell’uscita, obblighi di supporto agli incidenti e test di resilienza.
ISO/IEC 27001:2022 fornisce la struttura portante del sistema di gestione. Richiede contesto, parti interessate, ambito di applicazione, responsabilità della leadership, politiche, ruoli, valutazione del rischio, trattamento del rischio, Dichiarazione di Applicabilità, audit interno, riesame della direzione e miglioramento continuo. L’Annex A include controlli direttamente rilevanti per la protezione delle PII, tra cui 5.34 Privacy e protezione delle PII, 5.18 Diritti di accesso, 8.11 Mascheramento dei dati, 5.23 Sicurezza delle informazioni per l’uso dei servizi cloud, 8.15 Registrazione, 8.33 Informazioni di test, 8.24 Uso della crittografia e 8.10 Cancellazione delle informazioni.
Il problema non è che le organizzazioni non abbiano controlli. Il problema è che i controlli sono frammentati. Le registrazioni privacy sono presso il legale. I riesami degli accessi sono presso l’IT. Gli script di mascheramento sono presso l’ingegneria. I contratti con i fornitori sono presso gli acquisti. Le evidenze sono distribuite tra ticket, screenshot, fogli di calcolo ed e-mail.
ISO/IEC 27701:2025 e ISO/IEC 29151:2022 aiutano a unificare queste evidenze intorno alla gestione delle informazioni sulla privacy e alle pratiche di protezione delle PII. Clarysec trasforma questa struttura in un modello operativo.
Da SGSI a PIMS: la catena integrata dei controlli privacy
Un SGSI ISO/IEC 27001:2022 risponde a una domanda centrale: la sicurezza delle informazioni è governata, basata sul rischio, attuata, monitorata e migliorata?
Un sistema di gestione delle informazioni sulla privacy, o PIMS, estende questa domanda ai dati personali: responsabilità privacy, attività di trattamento delle PII, rischi privacy, obblighi di titolare e responsabile del trattamento, diritti degli interessati ed evidenze dei controlli privacy sono gestiti all’interno dello stesso sistema?
ISO/IEC 27701:2025 estende il SGSI alla governance privacy. ISO/IEC 29151:2022 lo integra con indicazioni pratiche per la protezione delle PII, incluse limitazione della raccolta, gestione della divulgazione, applicazione del mascheramento o della pseudonimizzazione, protezione dei trasferimenti, restrizione degli accessi e allineamento dei controlli al rischio privacy.
| Livello | Domanda principale | Evidenze di audit tipiche |
|---|---|---|
| ISO/IEC 27001:2022 | Esiste un SGSI governato, basato sul rischio, con controlli selezionati e operativi? | Ambito di applicazione, parti interessate, valutazione del rischio, piano di trattamento, SoA, politiche, audit interno, riesame della direzione |
| ISO/IEC 27701:2025 | Le responsabilità privacy, i rischi privacy e le attività di trattamento delle PII sono governati nel sistema di gestione? | Ruoli privacy, registro dei trattamenti, procedure del titolare e del responsabile del trattamento, valutazioni dei rischi privacy, DPIA, processo per le richieste degli interessati |
| ISO/IEC 29151:2022 | Sono applicate misure pratiche di protezione delle PII lungo il ciclo di vita dei dati? | Classificazione delle PII, restrizioni di accesso, mascheramento, pseudonimizzazione, controlli di conservazione, misure di protezione dei trasferimenti, evidenze sugli incidenti |
| GDPR | L’organizzazione può dimostrare un trattamento lecito, corretto, trasparente, minimizzato, sicuro e responsabile? | Registrazioni della base giuridica, informative privacy, DPIA, processo di gestione delle violazioni, accordi con i responsabili del trattamento, gestione dei diritti |
| NIS2 e DORA | L’organizzazione può governare i rischi di cibersicurezza e resilienza, inclusi incidenti e fornitori? | Supervisione della direzione, quadro di riferimento per il rischio ICT, classificazione degli incidenti, playbook di segnalazione, registri dei fornitori, diritto di audit, test di continuità |
Questo modello a livelli evita l’errore più comune nella conformità privacy: trattare le PII come un qualsiasi altro tipo di dati sensibili. Le PII comportano obblighi legali, etici, operativi, contrattuali e reputazionali. Richiedono una catena di controlli che inizi dalla consapevolezza e termini con le evidenze.
Parti dalla consapevolezza sui dati, non dai diagrammi di cifratura
Il fallimento privacy più frequente osservato da Clarysec è la mancanza di contesto. Un’azienda non può proteggere le PII se non sa quali PII possiede, dove risiedono, quale finalità servono, per quanto tempo sono conservate o chi può raggiungerle.
Il Zenith Blueprint avvia questo lavoro nelle prime fasi della gestione del rischio. Nello Step 9, Identifying Assets, Threats, and Vulnerabilities, indica alle organizzazioni di inventariare gli asset informativi e contrassegnare esplicitamente i dati personali:
“Per ciascun asset, registrare i dettagli chiave: nome/descrizione, proprietario, ubicazione e classificazione (sensibilità). Ad esempio, un asset potrebbe essere ‘Database clienti – di proprietà del Dipartimento IT – ospitato su AWS – contiene dati personali e finanziari (alta sensibilità)’.”
Aggiunge inoltre: “Assicurarsi che gli asset contenenti dati personali siano contrassegnati (per rilevanza GDPR) e che gli asset dei servizi critici siano indicati (per una potenziale applicabilità NIS2 se si opera in un settore regolamentato).”
Questa è la base per l’adozione di ISO/IEC 27701:2025 e ISO/IEC 29151:2022. La sequenza pratica è semplice:
- Identificare sistemi, set di dati, repository, log, report, backup, strumenti di supporto, ambienti di sviluppo e test e fornitori che trattano PII.
- Assegnare un proprietario a ciascun asset PII.
- Classificare le PII per sensibilità, finalità aziendale, base giuridica, ruolo nel trattamento e requisito di conservazione.
- Collegare ogni asset PII a minacce, vulnerabilità, scenari di rischio e obblighi normativi.
- Selezionare i controlli, assegnare le evidenze e monitorarne l’operatività nel tempo.
Le politiche Clarysec rendono tutto questo eseguibile. La Politica di protezione dei dati e privacy per PMI Politica di protezione dei dati e privacy - PMI stabilisce:
“Il coordinatore privacy deve mantenere un registro di tutte le attività di trattamento dei dati personali, incluse categorie di dati, finalità, base giuridica e periodi di conservazione”
Dalla sezione “Requisiti di governance”, clausola della politica 5.2.1.
Per le organizzazioni enterprise, la Politica di protezione dei dati e privacy Politica di protezione dei dati e privacy stabilisce una regola rigorosa di minimizzazione:
“Possono essere raccolti e trattati solo i dati necessari per una finalità aziendale specifica e legittima.”
Dalla sezione “Requisiti di applicazione della politica”, clausola della politica 6.2.1.
Queste clausole trasformano l’accountability GDPR in attività operative quotidiane. Supportano anche la gestione delle informazioni sulla privacy e la protezione delle PII perché impongono all’organizzazione di definire quali dati esistono, perché esistono e se sono necessari.
I tre controlli che rendono concreta la protezione delle PII
Tre controlli dell’Annex A di ISO/IEC 27001:2022 determinano spesso se la protezione delle PII sia difendibile in sede di audit: 5.34 Privacy e protezione delle PII, 8.11 Mascheramento dei dati e 5.18 Diritti di accesso.
5.34 Privacy e protezione delle PII
Il controllo 5.34 è il fulcro della governance. In Zenith Controls, 5.34 è trattato come controllo preventivo a supporto di riservatezza, integrità e disponibilità, con concetti di cibersicurezza Identify e Protect e capacità operative nella protezione delle informazioni e nella conformità legale.
Zenith Controls rende chiara la dipendenza:
“Un inventario degli asset informativi (5.9) dovrebbe includere i patrimoni di dati PII (database clienti, fascicoli HR). Questo sostiene 5.34 assicurando che l’organizzazione sappia quali PII possiede e dove si trovano, che è il primo passo per proteggerle.”
Il controllo 5.34 dipende da 5.9 Inventario delle informazioni e degli altri asset associati perché le PII non possono essere protette se non possono essere individuate. Si collega inoltre a 5.23 Sicurezza delle informazioni per l’uso dei servizi cloud, perché oggi la maggior parte delle PII risiede in piattaforme cloud, strumenti SaaS, ambienti di analytics e servizi gestiti.
Per i trattamenti ad alto rischio, la Politica di protezione dei dati e privacy enterprise richiede:
“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 politica”, clausola della politica 6.3.4.
Questa clausola è essenziale. Trasforma la privacy in un’attività di progettazione e gestione del rischio, non in un riesame legale dell’ultimo minuto.
8.11 Mascheramento dei dati
Il controllo 8.11 è la risposta diretta all’esposizione del database di staging di Sarah. Zenith Controls descrive 8.11 come un controllo preventivo di riservatezza nell’ambito della protezione delle informazioni. Collega 8.11 a 5.12 Classificazione delle informazioni perché le decisioni di mascheramento dipendono dalla sensibilità, a 5.34 perché il mascheramento supporta la protezione della privacy e a 8.33 Informazioni di test perché gli ambienti di test non dovrebbero esporre PII reali.
La Politica sul Mascheramento dei dati e sulla Pseudonimizzazione Politica sul Mascheramento dei dati e sulla Pseudonimizzazione rende esplicita la regola:
“I dati personali reali non devono essere utilizzati in ambienti di sviluppo, test o staging. Devono invece essere utilizzati dati mascherati o pseudonimizzati, generati da modelli di trasformazione pre-approvati.”
Dalla sezione “Requisiti di applicazione della politica”, clausola della politica 6.3.
Per le PMI, la Politica sul Mascheramento dei dati e sulla Pseudonimizzazione per PMI Politica sul Mascheramento dei dati e sulla Pseudonimizzazione - PMI aggiunge un requisito chiave di sicurezza ed evidenza:
“L’accesso alle chiavi deve essere cifrato, controllato mediante accessi autorizzati e registrato nei log.”
Dalla sezione “Requisiti di applicazione della politica”, clausola della politica 6.2.1.3.
Questo è rilevante perché la pseudonimizzazione riduce il rischio solo quando la logica di trasformazione, le chiavi e i percorsi di reidentificazione sono controllati.
5.18 Diritti di accesso
Il controllo 5.18 è il cuore operativo del principio del privilegio minimo. Zenith Controls lo tratta come preventivo, collegato a riservatezza, integrità e disponibilità, e collocato nell’ambito della gestione delle identità e degli accessi. Collega 5.18 a 5.15 Controllo degli accessi, 5.16 Gestione delle identità e 8.2 Diritti di accesso privilegiato.
La Politica di classificazione ed etichettatura dei dati per PMI Politica di classificazione ed etichettatura dei dati - PMI stabilisce:
“L’accesso deve essere limitato a utenti specificamente autorizzati secondo il principio del need-to-know.”
Dalla sezione “Requisiti di governance”, clausola della politica 5.2.1.
La Politica di classificazione ed etichettatura dei dati enterprise Politica di classificazione ed etichettatura dei dati aggiunge la baseline di classificazione:
“Tutti gli asset informativi devono avere una classificazione chiaramente assegnata al momento della creazione o dell’onboarding. In assenza di una classificazione esplicita, gli asset devono essere classificati per impostazione predefinita come ‘Riservato’ fino al riesame formale.”
Dalla sezione “Requisiti di governance”, clausola della politica 5.4.
Insieme, questi controlli formano la catena pratica di protezione delle PII: conoscere le PII, classificarle, limitare l’accesso, mascherarle quando l’identità completa non è necessaria, proteggere le chiavi, registrare gli accessi e conservare le evidenze.
Costruire la tracciabilità attraverso la Dichiarazione di Applicabilità
Un sistema di gestione della privacy diventa pronto per l’audit quando può dimostrare la tracciabilità. Il Zenith Blueprint, fase di gestione del rischio, Step 13, Risk Treatment Planning and Statement of Applicability, descrive la Dichiarazione di Applicabilità come un documento ponte:
“La SoA è di fatto un documento ponte: collega la valutazione/trattamento del rischio ai controlli effettivamente presenti. Completandola, si verifica anche se siano stati omessi controlli.”
Questo concetto è centrale per la preparazione a ISO/IEC 27701:2025, ISO/IEC 29151:2022, GDPR, NIS2 e DORA. Ogni controllo PII dovrebbe essere tracciabile dal requisito al rischio, dal rischio al controllo, dal controllo al proprietario, dal proprietario all’evidenza e dall’evidenza al riesame.
| Elemento di tracciabilità | Esempio per PII nel supporto clienti | Evidenza attesa |
|---|---|---|
| Asset PII | Piattaforma di ticketing di supporto con nomi dei clienti, e-mail, log e allegati | Voce del registro degli asset, proprietario, ubicazione cloud, classificazione |
| Finalità del trattamento | Supporto clienti e diagnostica del servizio | Registro dei trattamenti, base giuridica, periodo di conservazione |
| Scenario di rischio | Un operatore di supporto o uno sviluppatore accede a un volume eccessivo di dati cliente | Voce del registro dei rischi, probabilità, impatto, proprietario |
| Selezione dei controlli | 5.34 Protezione delle PII, 5.18 Diritti di accesso, 8.11 Mascheramento, 8.15 Registrazione, 5.23 Governance cloud | SoA, politica di accesso, standard di mascheramento, configurazione della registrazione |
| Evidenze operative | Accesso basato sui ruoli, esportazioni mascherate, riesame trimestrale degli accessi, allerte sui download massivi | Registrazioni del riesame degli accessi, allerte DLP, log, evidenze del ticket |
| Mappatura normativa | Accountability e sicurezza GDPR, gestione del rischio NIS2, rischio ICT DORA e requisiti dei fornitori | Matrice di conformità, playbook degli incidenti, registro dei contratti con i fornitori |
| Evidenze di riesame | Risultanza dell’audit interno chiusa, azione di riesame della direzione accettata | Rapporto di audit, azione correttiva, verbali del riesame della direzione |
ISO/IEC 27005:2022 supporta questo approccio basato sul rischio ponendo enfasi su requisiti delle parti interessate, criteri di rischio comuni, titolari del rischio responsabili, valutazione del rischio ripetibile, trattamento del rischio, selezione dei controlli, allineamento alla Dichiarazione di Applicabilità, approvazione del rischio residuo, monitoraggio e miglioramento continuo. La protezione delle PII deve essere un ciclo di rischio vivo, non un esercizio documentale GDPR una tantum.
Correggere il foglio di calcolo rischioso e il database di staging
L’incidente di Sarah può essere trasformato in un pacchetto di controlli ripetibile se la bonifica viene gestita in modo sistematico.
| Passaggio | Azione | Esito delle evidenze Clarysec |
|---|---|---|
| 1 | Registrare il database di staging e il foglio di calcolo come asset PII | Voci dell’inventario degli asset con proprietario, ubicazione, classificazione, categorie PII, finalità e conservazione |
| 2 | Aggiornare l’attività di trattamento | Voce del registro che mostra categorie di dati, base giuridica, finalità e periodo di conservazione |
| 3 | Classificare file e set di dati | Classificazione Riservato o superiore applicata per impostazione predefinita fino al riesame formale |
| 4 | Rimuovere i PII reali dall’ambiente non di produzione | Set di dati mascherato o pseudonimizzato generato da modelli di trasformazione approvati |
| 5 | Limitare e riesaminare gli accessi | Autorizzazioni secondo il principio del need-to-know, revoca degli accessi eccessivi, registrazione del riesame degli accessi |
| 6 | Proteggere logica di trasformazione e chiavi | Accesso alle chiavi cifrato, controllato e registrato nei log |
| 7 | Acquisire le evidenze centralmente | Registrazione dell’asset, voce di rischio, riesame degli accessi, prova di cancellazione, approvazione del mascheramento e chiusura del ticket |
| 8 | Aggiornare la SoA e il piano di trattamento del rischio | Scenario di rischio collegato a 5.34, 5.18, 8.11, 8.15, 8.10, 5.23 e ai controlli sui fornitori |
| 9 | Decidere se è richiesta una DPIA | DPIA o motivazione documentata per le decisioni relative ai trattamenti ad alto rischio |
| 10 | Registrare le lezioni apprese | Formazione aggiornata, regole di sviluppo sicuro, controlli sulle esportazioni, monitoraggio DLP e indicazioni sui dati di test |
La Politica di audit e monitoraggio della conformità per PMI Politica di audit e monitoraggio della conformità - PMI stabilisce:
“Tutte le evidenze devono essere archiviate in una cartella di audit centralizzata.”
Dalla sezione “Requisiti di applicazione della politica”, clausola della politica 6.2.1.
La Politica per la sicurezza delle informazioni Politica per la sicurezza delle informazioni rende esplicita l’aspettativa di audit più ampia:
“Tutti i controlli implementati devono essere verificabili in sede di audit, supportati da procedure documentate e da evidenze conservate della loro operatività.”
Dalla sezione “Requisiti di applicazione della politica”, clausola della politica 6.6.1.
Queste due clausole segnano la differenza tra avere un controllo e poterlo dimostrare.
Mappatura di conformità integrata per un unico set di controlli PII
La protezione delle PII è più facile da difendere quando viene mappata tra i diversi quadri di riferimento prima che l’auditor lo chieda.
| Tema di protezione delle PII | Rilevanza GDPR | Rilevanza ISO/IEC 27001:2022, ISO/IEC 27701:2025 e ISO/IEC 29151:2022 | Rilevanza NIS2 | Rilevanza DORA | Lente di audit NIST e COBIT 2019 |
|---|---|---|---|---|---|
| Inventario PII e registro dei trattamenti | Accountability, base giuridica, limitazione delle finalità, limitazione della conservazione | Contesto SGSI, 5.9 inventario degli asset, gestione delle informazioni sulla privacy, protezione delle PII | Gestione degli asset e analisi dei rischi | Consapevolezza delle dipendenze tra asset ICT e servizi | Evidenze della funzione Identify e governance sugli asset informativi |
| Diritti di accesso e privilegio minimo | Integrità e riservatezza, accesso limitato per ruolo | 5.15 controllo degli accessi, 5.16 Gestione delle identità, 5.18 Diritti di accesso, 8.2 diritti di accesso privilegiato | Controllo degli accessi, sicurezza delle risorse umane, autenticazione | Controlli del rischio ICT e supervisione degli accessi privilegiati | Applicazione degli accessi, titolarità, responsabilità e monitoraggio |
| Mascheramento e pseudonimizzazione | Minimizzazione dei dati, protezione dei dati fin dalla progettazione, sicurezza del trattamento | 5.12 classificazione, 5.34 protezione delle PII, 8.11 Mascheramento dei dati, 8.33 informazioni di test | Igiene informatica e sviluppo sicuro | Test sicuri, riduzione della perdita di dati, resilienza operativa | Test delle misure tecniche di sicurezza e operatività affidabile dei controlli |
| Classificazione e segnalazione degli incidenti | Valutazione e notifica della violazione dei dati personali | Pianificazione degli incidenti, valutazione degli eventi, risposta, raccolta delle evidenze | Allerta precoce entro 24 ore, notifica entro 72 ore, relazione finale | Classificazione e segnalazione degli incidenti rilevanti connessi all’ICT | Criteri di escalation, log decisionali, causa radice, bonifica |
| Trattamento da parte di fornitori e cloud | Obblighi del responsabile del trattamento, trasferimenti, contratti | 5.21 catena di fornitura ICT, 5.23 servizi cloud, 5.31 requisiti legali e contrattuali | Sicurezza della catena di fornitura | Rischio ICT di terze parti, diritto di audit, uscita e transizione | Governance di terze parti, assurance e responsabilità della direzione |
È qui che Zenith Controls risulta particolarmente utile. Per 5.34, mappa la protezione delle PII all’inventario degli asset, al Mascheramento dei dati e alla governance cloud. Per 8.11, mappa il mascheramento alla classificazione, alla protezione della privacy e alle informazioni di test. Per 5.18, mappa i Diritti di accesso al controllo degli accessi, alla Gestione delle identità e agli accessi privilegiati. Queste relazioni consentono a un team di spiegare non solo che un controllo esiste, ma perché esiste e quali controlli adiacenti devono operare insieme ad esso.
Come auditor diversi testano lo stesso controllo PII
Un singolo controllo, come 8.11 Mascheramento dei dati, sarà esaminato in modo diverso a seconda della lente di audit.
| Tipo di auditor | Focus principale | Evidenze attese |
|---|---|---|
| Auditor ISO/IEC 27001:2022 e ISO/IEC 27701:2025 | Integrazione SGSI e PIMS, trattamento del rischio, accuratezza della SoA | Valutazione del rischio, voce SoA, politica di mascheramento, registrazioni delle modifiche, risultati dell’audit interno |
| Revisore GDPR o autorità di controllo per la protezione dei dati | Protezione dei dati fin dalla progettazione, minimizzazione, accountability | Registro dei trattamenti, base giuridica, DPIA, evidenze di pseudonimizzazione, logica di conservazione |
| Valutatore NIS2 | Sviluppo sicuro, prevenzione degli incidenti, governance | Procedura di sviluppo sicuro, formazione degli sviluppatori, evidenze di bonifica degli incidenti, riesame dell’efficacia dei controlli |
| Cliente o auditor DORA | Resilienza operativa digitale e rischio di terze parti | Evidenze dei test sulle applicazioni critiche, clausole contrattuali con i fornitori, obblighi di supporto agli incidenti, pianificazione del ripristino e dell’uscita |
| Revisore secondo l’approccio NIST o COBIT 2019 | Progettazione, operatività, titolarità e monitoraggio dei controlli | Proprietario del controllo, metriche, repository delle evidenze, reportistica alla direzione, azioni correttive |
Un auditor ISO/IEC 27001:2022 parte dalla logica del sistema di gestione. Le PII rientrano nell’ambito di applicazione? I requisiti delle parti interessate sono identificati? I rischi privacy sono valutati usando criteri definiti? I controlli sono selezionati tramite trattamento del rischio? La SoA è accurata? Gli audit interni e i riesami della direzione coprono i controlli correlati alle PII?
Un revisore privacy parte dall’accountability. Quali dati personali sono trattati? Qual è la base giuridica? Gli interessati sono informati? Il trattamento è limitato a una finalità specifica? Le attività ad alto rischio sono valutate? I responsabili del trattamento sono governati?
Un valutatore focalizzato su NIS2 parte dalla governance e dalla gestione dei rischi di cibersicurezza. La direzione approva e supervisiona le misure? Gestione degli incidenti, continuità, sicurezza dei fornitori, controllo degli accessi, gestione degli asset, sviluppo sicuro e valutazione dell’efficacia dei controlli sono integrati?
Un cliente o auditor DORA chiede se la gestione del rischio ICT sia documentata, governata dal consiglio di amministrazione, proporzionata e supportata da contratti. Se le PII sono trattate in servizi a supporto di entità finanziarie, ci si devono attendere domande su assistenza agli incidenti, localizzazione dei trattamenti, ripristino, diritto di audit, livelli di servizio, cessazione e uscita.
Un revisore COBIT 2019 o secondo l’approccio ISACA verifica l’allineamento della governance. Chi possiede il rischio PII? Quale organo di governance riceve la reportistica? Le responsabilità sono assegnate? I fornitori sono monitorati? Le deviazioni sono tracciate? Le metriche sono usate per il processo decisionale? Il rischio residuo è formalmente accettato?
Un unico modello di evidenze può soddisfare tutte queste prospettive, ma solo se il sistema dei controlli è progettato per la tracciabilità fin dall’inizio.
Risultanze di audit comuni nei programmi di protezione delle PII
Le organizzazioni che affrontano la preparazione a ISO/IEC 27701:2025 o ISO/IEC 29151:2022 senza un kit di strumenti integrato riscontrano spesso le stesse risultanze.
| Risultanza | Perché è importante | Azione correttiva Clarysec |
|---|---|---|
| L’inventario PII esclude log, backup, esportazioni di analytics o allegati di supporto | Le PII nascoste non possono essere protette o cancellate in modo affidabile | Estendere l’inventario degli asset e il registro dei trattamenti dello Step 9 a tutte le ubicazioni delle PII |
| Gli ambienti di test usano dati di produzione | Le PII reali sono esposte dove non sono necessarie | Applicare la politica di mascheramento e i modelli di trasformazione approvati |
| I riesami degli accessi sono generici e non si concentrano sui repository PII | Gli accessi eccessivi restano non rilevati | Mappare 5.18 Diritti di accesso ai proprietari degli asset PII e alle evidenze di riesame periodico |
| La base giuridica è documentata ma non collegata ai sistemi o alla conservazione | L’accountability GDPR non può essere dimostrata | Aggiungere campi per base giuridica e conservazione al registro dei trattamenti e all’inventario degli asset |
| I contratti con i fornitori non includono localizzazione dei dati, assistenza agli incidenti, diritto di audit o disposizioni di uscita | Permangono lacune di assurance sui fornitori rispetto a DORA, NIS2 e GDPR | Allineare la due diligence sui fornitori e i contratti alla governance ICT di terze parti e cloud |
| I playbook degli incidenti non distinguono gli incidenti di sicurezza dalle violazioni dei dati personali | Le scadenze di segnalazione possono essere mancate | Costruire alberi di classificazione per i trigger di segnalazione GDPR, NIS2 e DORA |
| Le evidenze sono disperse tra ticket, unità, screenshot ed e-mail | La preparazione agli audit fallisce anche quando i controlli operano | Utilizzare cartelle di audit centralizzate e standard di denominazione delle evidenze |
Queste risultanze non sono problemi documentali. Sono problemi di modello operativo. ISO/IEC 27701:2025 e ISO/IEC 29151:2022 non li risolveranno se governance privacy, controlli di sicurezza e gestione delle evidenze non sono incorporati nei flussi di lavoro ordinari.
Cosa dovrebbe chiedere la direzione prima del prossimo audit
Prima di perseguire la preparazione a ISO/IEC 27701:2025, l’applicazione di ISO/IEC 29151:2022 o una valutazione cliente GDPR, NIS2 o DORA, la direzione dovrebbe porre dieci domande dirette:
- Disponiamo di un registro completo delle attività di trattamento delle PII, incluse categorie di dati, finalità, base giuridica e conservazione?
- Gli asset PII sono contrassegnati nell’inventario degli asset, inclusi log, backup, esportazioni, strumenti di analytics e allegati di supporto?
- Le classificazioni dei dati sono assegnate al momento della creazione o dell’onboarding, con gli asset non riesaminati classificati per impostazione predefinita come Riservato?
- Possiamo dimostrare che l’accesso alle PII è limitato agli utenti autorizzati secondo il principio del need-to-know?
- Gli ambienti di sviluppo, test e staging utilizzano dati mascherati o pseudonimizzati invece di dati personali reali?
- I modelli di mascheramento sono approvati, le chiavi sono protette, l’accesso è controllato e registrato nei log?
- La SoA collega i rischi PII ai controlli e agli obblighi normativi?
- I contratti cloud e con i fornitori sono riesaminati per localizzazione dei dati, sicurezza, supporto agli incidenti, diritto di audit, ripristino e uscita?
- Il nostro processo di gestione degli incidenti può classificare violazioni dei dati personali ai sensi del GDPR, incidenti significativi NIS2 e incidenti rilevanti connessi all’ICT DORA?
- Le evidenze sono archiviate centralmente e conservate in modo che un auditor possa seguirne il percorso?
Se la risposta a una qualsiasi di queste domande non è chiara, l’organizzazione non è ancora pronta per l’audit.
Rendere dimostrabile la protezione delle PII
L’incidente notturno di Sarah avrebbe potuto trasformarsi in una corsa frammentata alla conformità. Può invece diventare il punto di partenza per un modello operativo più solido: un SGSI ISO/IEC 27001:2022 esteso alla privacy tramite ISO/IEC 27701:2025, rafforzato dalle pratiche ISO/IEC 29151:2022 e mappato a GDPR, NIS2, DORA, assurance secondo l’approccio NIST e aspettative di governance COBIT 2019.
Questo è il vero valore della protezione delle PII pronta per l’audit. Non dipende dal trovare il foglio di calcolo giusto prima dell’arrivo dell’auditor. Dipende da un sistema che sa già dove sono le PII, perché esistono, come sono protette, chi ne risponde, quali fornitori sono coinvolti e dove risiedono le evidenze.
Inizia con Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint per strutturare la tua attuazione. Usa Zenith Controls: The Cross-Compliance Guide Zenith Controls per mappare la protezione delle PII attraverso ISO/IEC 27001:2022, GDPR, NIS2, DORA, assurance secondo l’approccio NIST e aspettative di governance COBIT 2019. Operazionalizza il lavoro con le politiche Clarysec, incluse la Politica di protezione dei dati e privacy Politica di protezione dei dati e privacy, la Politica sul Mascheramento dei dati e sulla Pseudonimizzazione Politica sul Mascheramento dei dati e sulla Pseudonimizzazione, la Politica di classificazione ed etichettatura dei dati Politica di classificazione ed etichettatura dei dati, la Politica di audit e monitoraggio della conformità per PMI Politica di audit e monitoraggio della conformità - PMI e la Politica per la sicurezza delle informazioni Politica per la sicurezza delle informazioni.
Se il tuo prossimo audit cliente, riesame GDPR, progetto di preparazione NIS2 o valutazione DORA dei fornitori si avvicina, non aspettare che una violazione riveli le lacune. Scarica i kit di strumenti Clarysec, richiedi una demo o pianifica una valutazione della protezione delle PII e costruisci un programma privacy non solo conforme, ma difendibile.
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
