Governance degli accessi ai dati personali identificabili (PII) per ISO 27701:2025 e GDPR

La domanda dell’auditor esterno rimase sospesa nell’aria, apparentemente semplice.

“Può mostrarmi il registro dei riesami degli accessi del team di supporto ai dati personali identificabili (PII) in produzione relativo all’ultimo trimestre?”

Per Anya, CISO di Medtelligence, fornitore SaaS di tecnologia sanitaria in rapida crescita, era il momento della verità. Medtelligence opera come responsabile del trattamento di dati personali per conto di ospedali e tratta dati sanitari sensibili dei pazienti in una piattaforma cloud. L’azienda disponeva di autenticazione forte, ruoli definiti e un team di ingegneria maturo. Ma l’auditor non stava chiedendo se esistesse una schermata di accesso. Chiedeva la prova che l’accesso ai dati personali fosse governato nel tempo.

Voleva vedere chi poteva accedere ai dati personali identificabili (PII) in produzione, perché disponeva di tale accesso, quando l’accesso era stato approvato, se fosse ancora necessario, se l’attività di supporto fosse registrata nei log e se le autorizzazioni non più necessarie fossero state rimosse.

Anya aprì la console IAM. C’erano ingegneri di supporto, amministratori di database, un account di servizio per le integrazioni, un fornitore di servizi gestiti, due ruoli break-glass di emergenza e un ex collaboratore ancora presente in un gruppo perché il ticket di offboarding era stato chiuso prima della rimozione dell’autorizzazione. Le Risorse Umane indicavano che la persona aveva lasciato l’azienda sei settimane prima. Il foglio di calcolo per il riesame degli accessi riportava “in sospeso”. Il SIEM aveva log, ma nessuno aveva mappato quali eventi dimostrassero l’accesso ai dati personali identificabili (PII).

È qui che la governance della privacy diventa concreta.

Ai sensi del GDPR, i dati personali devono essere trattati in modo da garantirne integrità e riservatezza, con protezione da trattamenti non autorizzati o illeciti e da perdita, distruzione o danno accidentali mediante misure tecniche e organizzative adeguate. Il GDPR rende inoltre esplicita la responsabilizzazione: il titolare del trattamento deve poter dimostrare la conformità. ISO/IEC 27701:2025 traduce tale responsabilizzazione in un Sistema di gestione delle informazioni sulla privacy, o PIMS, in cui l’accesso ai dati personali identificabili (PII) non è più un dettaglio tecnico successivo. Diventa un ciclo di vita governato che coinvolge ruoli, responsabili del trattamento, piattaforme cloud, dipendenti, amministratori privilegiati, log, riesami, contratti ed evidenze.

Per molte organizzazioni, la lacuna non consiste nell’assenza di controllo degli accessi. La lacuna consiste nell’incapacità di dimostrare in modo coerente la governance degli accessi ai dati personali identificabili (PII) rispetto a ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0 e COBIT 2019.

La governance degli accessi ai dati personali identificabili (PII) non è solo IAM

Un programma IAM tradizionale si chiede: “Gli utenti corretti possono accedere ai sistemi corretti?”

Un PIMS maturo secondo ISO/IEC 27701:2025 pone domande più rigorose:

• Quali sistemi trattano dati personali identificabili (PII)?
• Quali ruoli richiedono accesso a quali categorie di dati personali identificabili (PII)?
• L’organizzazione agisce come titolare del trattamento, responsabile del trattamento, contitolare del trattamento o sub-responsabile?
• L’accesso è limitato in base alla finalità, a un’esigenza aziendale documentata e al principio del privilegio minimo?
• Le azioni privilegiate sono registrate nei log e riesaminate?
• L’organizzazione può dimostrare che l’accesso di responsabili e sub-responsabili è disciplinato contrattualmente?
• I percorsi di supporto cloud, l’isolamento dei tenant, le esportazioni e le azioni amministrative sono inclusi nelle evidenze?
• Le decisioni di accesso sono riesaminate dopo onboarding, cambio di ruolo, incidente, offboarding e modifica sostanziale del sistema?

Per questo la sicurezza dei dati personali identificabili (PII) e la governance del controllo degli accessi costituiscono un collegamento naturale tra ISO/IEC 27701:2025 e GDPR. Il GDPR fornisce il quadro giuridico della responsabilizzazione. ISO/IEC 27701:2025 rende operativa la gestione della privacy per titolari e responsabili del trattamento. ISO/IEC 27001:2022 fornisce il motore di gestione del rischio del SGSI. ISO/IEC 27002:2022 fornisce l’architettura dei controlli, inclusi privacy e protezione dei dati personali identificabili (PII), controllo degli accessi, diritti di accesso, logging, servizi cloud, rapporti con i fornitori, classificazione, cancellazione, mascheramento e cifratura.

Zenith Blueprint: An Auditor’s 30-Step Roadmap di Clarysec colloca questo tema nella fase Controls in Action. Nello Step 23, che copre i controlli organizzativi da 5.19 a 5.37, descrive il controllo ISO/IEC 27002:2022 5.34, Privacy and Protection of PII, come una questione di fiducia, non semplicemente di dati:

le informazioni personali identificabili non sono semplicemente un altro tipo di dato, sono una rappresentazione profondamente sensibile della fiducia. Nomi, indirizzi, documenti identificativi, cartelle sanitarie, dati finanziari: questi dati raccontano una storia su persone reali.

Lo stesso passaggio fornisce il fondamento pratico: la protezione della privacy inizia dalla consapevolezza sui dati. Un’organizzazione deve sapere quali dati personali identificabili (PII) raccoglie, dove risiedono, perché sono trattati e chi può accedervi.

La pressione di conformità dietro il controllo degli accessi ai dati personali identificabili (PII)

La governance degli accessi ai dati personali identificabili (PII) non è più un tema confinato a un singolo framework. Organizzazioni come Medtelligence operano all’intersezione tra normativa privacy, legislazione sulla cybersicurezza, resilienza operativa, assurance verso i clienti e certificazioni di sicurezza.

Il GDPR Article 5 richiede che i dati personali siano trattati secondo liceità, correttezza, trasparenza, limitazione della finalità, minimizzazione dei dati, esattezza, limitazione della conservazione, integrità e riservatezza. Article 5(2) introduce la responsabilizzazione: il titolare del trattamento è responsabile della conformità e deve poterla dimostrare. Article 32 richiede poi misure tecniche e organizzative adeguate per la sicurezza del trattamento.

NIS2 Article 21 richiede ai soggetti essenziali e importanti di adottare misure tecniche, operative e organizzative adeguate e proporzionate per la gestione dei rischi di cybersicurezza. I domini minimi includono analisi dei rischi, politiche di sicurezza, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, acquisizione e sviluppo sicuri, valutazione dell’efficacia, igiene informatica e formazione, crittografia, sicurezza delle risorse umane, controllo degli accessi, gestione degli asset e, ove opportuno, autenticazione a più fattori o autenticazione continua e comunicazioni sicure. Article 20 attribuisce inoltre agli organi di gestione la responsabilità di approvare e supervisionare le misure di gestione dei rischi di cybersicurezza.

DORA si applica dal 17 gennaio 2025 a un’ampia gamma di entità finanziarie e istituisce un regime settoriale specifico di resilienza operativa. Copre gestione del rischio ICT, segnalazione degli incidenti gravi connessi all’ICT, test di resilienza operativa digitale, condivisione delle informazioni, rischio di terze parti ICT e accordi contrattuali con fornitori terzi di servizi ICT. Per le entità finanziarie e i fornitori di servizi ICT che le supportano, il controllo degli accessi non è solo un tema privacy. È parte della resilienza operativa.

ISO/IEC 27001:2022 collega questi obblighi a un sistema di gestione basato sul rischio. Le clausole 6.1.1, 6.1.2 e 6.1.3 richiedono alle organizzazioni di affrontare rischi e opportunità, definire un processo di valutazione dei rischi per la sicurezza delle informazioni, identificare i rischi per riservatezza, integrità e disponibilità, valutare i rischi, selezionare le opzioni di trattamento, determinare i controlli, confrontare i controlli selezionati con l’Annex A, documentare la Dichiarazione di Applicabilità, ottenere l’approvazione del proprietario del rischio e accettare i rischi residui. Le clausole 8.2 e 8.3 richiedono valutazioni del rischio a intervalli pianificati o dopo modifiche significative, nonché l’attuazione del piano di trattamento del rischio con risultati documentati.

Per la governance dei dati personali identificabili (PII), questo significa che il controllo degli accessi non è una configurazione IAM isolata. È una decisione di trattamento del rischio. Un ruolo che può esportare registrazioni payroll, dati dei pazienti, dati di pagamento, documenti di identità, dati di localizzazione o trascrizioni del supporto clienti deve essere giustificato nel registro dei rischi, riflesso nella Dichiarazione di Applicabilità, applicato in IAM, registrato nei log in produzione, riesaminato periodicamente e rimosso quando non è più necessario.

Il modello dei controlli Clarysec: dalla promessa privacy alle evidenze

Clarysec tratta la governance degli accessi ai dati personali identificabili (PII) come una catena di evidenze. La catena inizia con l’inventario dei dati e la definizione dei ruoli, prosegue con l’approvazione e l’applicazione degli accessi e si conclude con monitoraggio, riesame, revoca e registrazioni idonee all’audit.

In Zenith Controls: The Cross-Compliance Guide, il tema si concentra principalmente su tre controlli ISO/IEC 27002:2022:

Gli auditor raramente accettano “usiamo IAM” come evidenza. Si aspettano di vedere come le decisioni IAM si ricollegano a obblighi privacy, titolarità dei sistemi, classificazione dei dati, esigenza aziendale, trattamento del rischio, frequenza dei riesami degli accessi, ambito del logging e contratti con i fornitori.

La PII Security and Access Control Policy di Clarysec stabilisce la baseline in linguaggio PIMS:

[Both] Il Responsabile del sistema / Responsabile dell’applicazione DEVE limitare l’accesso ai dati personali identificabili (PII) ai ruoli approvati e agli utenti autorizzati registrati o tracciabili in REG02 o REG12 prima dell’abilitazione dell’accesso.

Dalla sezione “4.2 Access control baseline”, clausola di politica 4.2.1.

Il tag “[Both]” indica che il controllo si applica sia quando l’organizzazione agisce come titolare del trattamento di dati personali sia quando agisce come responsabile del trattamento. La distinzione è rilevante. I titolari spesso non riescono a definire regole di accesso basate sulla finalità. I responsabili spesso non riescono a dimostrare che l’accesso è limitato alle istruzioni del cliente, a percorsi di supporto approvati e a personale contrattualmente autorizzato.

La stessa politica innalza il livello atteso per i dati personali identificabili (PII) sensibili o ad alto impatto:

[Both] Il Responsabile del sistema / Responsabile dell’applicazione DEVE riesaminare almeno trimestralmente l’accesso degli utenti ai sistemi che trattano dati personali identificabili (PII) sensibili o ad alto impatto e registrare l’esito del riesame in REG12.

Dalla sezione “4.2 Access control baseline”, clausola di politica 4.2.3.

È qui che un PIMS diventa verificabile in audit. Il riesame degli accessi non è una semplice e-mail del responsabile. È una registrazione in REG12, collegata a sistema, categoria di dati, ruolo, titolare, esito del riesame e azione di rimedio.

Fondamento delle politiche: privilegio minimo, esigenza aziendale e diniego predefinito

Una governance efficace inizia da regole applicabili. Prima che Anya potesse mostrare all’auditor un registro dei riesami degli accessi, doveva dimostrare che il requisito dei riesami degli accessi era stato formalmente stabilito.

La Access Control Policy - SME di Clarysec per le PMI stabilisce il principio:

Questa politica applica il principio del privilegio minimo e richiede che l’accesso sia limitato al minimo necessario per svolgere le mansioni lavorative.

Dalla sezione “Purpose”, clausola di politica 1.3.

La Data Protection and Privacy Policy - SME per le PMI collega l’accesso all’esigenza aziendale:

L’accesso degli utenti ai dati personali deve essere limitato ai ruoli con un’esigenza aziendale documentata.

Dalla sezione “Governance Requirements”, clausola di politica 5.3.2.

Per le organizzazioni più grandi, la Data Protection and Privacy Policy enterprise esprime l’aspettativa di controllo come requisito di sistema:

Tutti i sistemi devono applicare per impostazione predefinita l’accesso secondo il principio del privilegio minimo.

Dalla sezione “Policy Implementation Requirements”, clausola di politica 6.3.1.

La distinzione è importante. Un’azienda più piccola può aver bisogno di una registrazione leggera ma esplicita dell’esigenza aziendale. Un’organizzazione enterprise necessita di applicazione a livello di sistema, riesame periodico, segregazione dei compiti, governance degli accessi privilegiati ed evidenze conservate per audit interno, assurance verso i clienti, richieste delle autorità di regolamentazione e indagini su violazioni.

Il ciclo di vita degli accessi ai dati personali identificabili (PII): approvazione, uso, riesame, revoca

Il problema più comune negli accessi ai dati personali identificabili (PII) non è l’approvazione iniziale. È la persistenza dell’accesso.

Lo Zenith Blueprint, nella fase Controls in Action, Step 22, spiega così il controllo ISO/IEC 27002:2022 5.18, Access Rights:

Il controllo 5.18 assicura che i diritti di accesso non siano solo concessi correttamente, ma anche riesaminati, adeguati e revocati in modo controllato e tracciabile.

Descrive poi scenari familiari: un nuovo assunto riceve accessi, cambia ruolo e conserva vecchie autorizzazioni; un ex amministratore lascia l’azienda ma un token rimane attivo; l’account di un collaboratore scade sulla carta ma non in IAM. Sono esattamente le debolezze che diventano incidenti di sicurezza rilevanti ai fini del GDPR quando sono coinvolti dati personali identificabili (PII).

La User Account and Privilege Management Policy - SME di Clarysec per le PMI stabilisce una cadenza di baseline:

Deve essere effettuato ogni sei mesi un riesame di tutti gli account utente e dei relativi privilegi.

Dalla sezione “Policy Implementation Requirements”, clausola di politica 6.4.1.

Per gli ambienti enterprise, la User Account and Privilege Management Policy rende più rigoroso il ritmo operativo:

La Sicurezza IT deve condurre riesami trimestrali di tutti gli account utente e dei privilegi associati in collaborazione con i responsabili di dipartimento.

Dalla sezione “Policy Implementation Requirements”, clausola di politica 6.5.1.

Un ciclo di vita pratico degli accessi ai dati personali identificabili (PII) dovrebbe includere:

1. Classificare il sistema e le categorie di dati personali identificabili (PII).
2. Definire ruoli approvati ed esigenza aziendale documentata.
3. Mappare i ruoli alle finalità del trattamento.
4. Approvare l’accesso prima dell’abilitazione.
5. Applicare il principio del privilegio minimo, la segregazione dei compiti e l’autenticazione forte.
6. Registrare nei log autenticazione, accesso, esportazione, configurazione e azioni privilegiate.
7. Riesaminare l’accesso secondo una cadenza basata sul rischio.
8. Rimuovere l’accesso in caso di cambio di ruolo, cessazione del rapporto, chiusura del progetto, scadenza del contratto o istruzione del cliente.
9. Conservare le evidenze nel registro PIMS e nella traccia di audit.

Non è burocrazia. È il modo in cui un’organizzazione dimostra che l’accesso ai dati personali identificabili (PII) è controllato fin dalla progettazione, per impostazione predefinita e mediante evidenze.

Un esempio pratico: il riesame trimestrale degli accessi ai dati personali identificabili (PII)

L’audit di Anya ebbe successo quando spostò la conversazione dalle dichiarazioni di politica alle evidenze.

Per prima cosa citò la PII Security and Access Control Policy, clausola 4.2.3, che richiedeva il riesame trimestrale dell’accesso ai dati personali identificabili (PII) sensibili o ad alto impatto e la registrazione dell’esito del riesame in REG12.

Poi accompagnò l’auditor attraverso il trimestre precedente:

• L’IT aveva generato un elenco di tutti gli utenti, gruppi, ruoli privilegiati, account di servizio, account dei fornitori, ruoli break-glass e autorizzazioni di supporto per il database di produzione contenente dati dei pazienti.
• L’elenco era stato inviato al Responsabile dell’applicazione, il responsabile del Customer Success, che era titolare dell’esigenza operativa del team di supporto.
• Il Responsabile dell’applicazione aveva riesaminato l’elenco riga per riga rispetto a ruolo attuale, responsabilità di supporto clienti e finalità del trattamento.
• Due operatori di supporto che avevano cambiato team erano stati contrassegnati per la revoca.
• Era stato creato un ticket nel sistema di gestione dei servizi IT, collegato al riesame degli accessi, assegnato a uno SLA e chiuso dopo la revoca.
• REG12 era stato aggiornato con la registrazione del riesame, l’approvatore, le eccezioni, il ticket di remediation, l’evidenza di chiusura e la data del riesame successivo.

Il risultato era una catena di evidenze a ciclo chiuso. Anya non si limitò a dire che Medtelligence usava il principio del privilegio minimo. Mostrò il requisito di politica, il proprietario responsabile, l’elenco degli accessi, la decisione di riesame, l’azione correttiva e la revoca completata.

Questa è la differenza tra controllo degli accessi e governance degli accessi.

Accesso dei fornitori e dei responsabili del trattamento: il punto cieco negli audit PIMS

Molti rischi di accesso non autorizzato entrano attraverso supporto, outsourcing, partner di integrazione, fornitori di servizi gestiti e sub-responsabili. Un responsabile del trattamento può avere accesso remoto ai dati di produzione dei clienti. Un fornitore cloud può mettere a disposizione percorsi di accesso per il supporto. Un sub-responsabile può gestire un indice di ricerca contenente identificativi dei clienti. Un fornitore di servizi di sicurezza gestiti può accedere a log contenenti dati personali.

Ai sensi del GDPR, i titolari del trattamento devono ricorrere a responsabili del trattamento che offrano garanzie sufficienti. Ai sensi di ISO/IEC 27701:2025, la governance dei responsabili e dei sub-responsabili deve essere resa operativa tramite istruzioni documentate, controlli contrattuali, assurance e monitoraggio. ISO/IEC 27002:2022 supporta questo approccio mediante i controlli sui rapporti con i fornitori, inclusi 5.19 Information security in supplier relationships, 5.20 Addressing information security within supplier agreements e 5.21 Managing information security in the ICT supply chain.

Lo Zenith Blueprint, nella fase Controls in Action, Step 23, riassume le aree di evidenza degli accordi con i fornitori includendo:

✓ Responsabilità di controllo degli accessi, ad esempio chi può accedere ai tuoi dati, come sono gestite le credenziali e quale monitoraggio è in essere;

Include inoltre obblighi di riservatezza, misure tecniche e organizzative, tempistiche di segnalazione degli incidenti, diritto di audit, controlli sui subappaltatori e disattivazione degli account a fine contratto.

La Processor, Subprocessor and Third-Party Privacy Management Policy di Clarysec converte questi aspetti in evidenze PIMS lato titolare:

[Controller] Il Responsabile privacy / Responsabile PIMS DEVE verificare, prima dell’approvazione, che i campi dei controlli contrattuali del responsabile del trattamento in REG08 coprano ambito del trattamento, durata, finalità, categorie di dati personali identificabili (PII), categorie di interessati, riservatezza, sicurezza, autorizzazione dei sub-responsabili, assistenza, audit o assurance, restituzione, cancellazione e cessazione.

Dalla sezione “4.3 Contract and documented instruction controls”, clausola di politica 4.3.2.

L’accesso dei fornitori è controllato direttamente anche nelle politiche Clarysec per PMI ed enterprise sui fornitori. La Third-Party and Supplier Security Policy - SME per le PMI afferma:

Ai fornitori deve essere concesso accesso solo ai sistemi e ai dati minimi necessari per svolgere la propria funzione.

Dalla sezione “Policy Implementation Requirements”, clausola di politica 6.2.1.

La Third party and supplier security policy enterprise aggiunge RBAC, riesame e privilegio minimo:

Il personale dei fornitori deve essere soggetto a controllo degli accessi basato sui ruoli (RBAC), riesami periodici degli accessi e applicazione del principio del privilegio minimo.

Dalla sezione “Policy Implementation Requirements”, clausola di politica 6.3.1.

Se l’accesso del fornitore può raggiungere dati personali identificabili (PII), rientra nel PIMS. Deve comparire nei controlli contrattuali, nelle approvazioni degli accessi, nei gruppi IAM, nell’ambito del logging, nelle registrazioni dei riesami, nelle registrazioni di offboarding, nei playbook di incidente e nelle evidenze di audit.

Accesso ai dati personali identificabili (PII) nel cloud: responsabilità condivisa non equivale a responsabilizzazione condivisa

La governance degli accessi ai dati personali identificabili (PII) nel cloud è l’ambito in cui le organizzazioni spesso sovrastimano il provider e sottovalutano le proprie responsabilità. Il fornitore cloud può mettere in sicurezza l’infrastruttura, ma il cliente governa comunque identità, ruoli, configurazione dei tenant, accesso per il supporto, log, impostazioni di cifratura, autorizzazioni di esportazione e preparazione alla risposta agli incidenti.

Lo Zenith Blueprint, nella fase Controls in Action, Step 23, lo afferma in modo esplicito nella guida sui servizi cloud:

I provider cloud mettono in sicurezza l’infrastruttura, ma tu resti responsabile dei tuoi dati, delle tue configurazioni, delle tue politiche di accesso e della tua preparazione alla risposta agli incidenti.

Avverte inoltre:

Nel cloud, la visibilità è parziale se non viene progettata intenzionalmente. Devi configurare il logging, applicare la cifratura, definire i ruoli di identità e monitorare l’attività tramite strumenti nativi o integrazioni di terze parti. Non è un’attività infrastrutturale: è un requisito del SGSI.

La Cloud Usage Policy di Clarysec trasforma questo principio in un requisito di accesso enterprise:

Tutti i servizi cloud devono applicare il controllo degli accessi basato sull’identità, allineato al principio del privilegio minimo.

Dalla sezione “Policy Implementation Requirements”, clausola di politica 6.2.1.

Per le organizzazioni che agiscono come responsabili del trattamento in ambienti cloud, la Cloud PII Processor Policy di Clarysec definisce un obbligo PIMS di riesame più specifico:

[Processor] Il Responsabile della sicurezza delle informazioni DEVE riesaminare almeno trimestralmente in REG12 l’accesso cloud privilegiato, l’accesso per il supporto, l’accesso ai dati personali identificabili (PII) dei clienti e la copertura dei log.

Dalla sezione “4.2 Cloud Configuration, Tenant Isolation, Access and Logging”, clausola di politica 4.2.4.

Questa clausola è particolarmente rilevante per aziende SaaS, piattaforme ospitate nel cloud, servizi gestiti sui dati e responsabili del trattamento B2B.

La governance degli accessi ai dati personali identificabili (PII) nel cloud non è completa se log cloud-native, politiche IAM, account di servizio, ruoli privilegiati, strumenti di supporto clienti, chiavi API e funzioni di esportazione dei dati non vengono riesaminati congiuntamente.

Logging e monitoraggio: la memoria della governance dei dati personali identificabili (PII)

Un programma PIMS di controllo degli accessi senza log è una promessa senza memoria.

La PII Security and Access Control Policy richiede la definizione dell’ambito del logging prima dell’uso in produzione o di una modifica sostanziale:

[Both] Il Responsabile del sistema / Responsabile dell’applicazione DEVE definire in REG12 l’ambito del logging dei dati personali identificabili (PII) per eventi di autenticazione, eventi di accesso, azioni privilegiate, attività di esportazione di dati personali identificabili (PII) e modifiche sostanziali della configurazione prima dell’uso in produzione o di una modifica sostanziale.

Dalla sezione “4.6 Logging and monitoring”, clausola di politica 4.6.1.

La Logging and Monitoring Policy - SME per le PMI rende esplicito il contenuto dei log di accesso:

Log di accesso: accesso ai file, in particolare per dati sensibili o personali, modifiche delle autorizzazioni, utilizzo di risorse condivise.

Dalla sezione “Governance Requirements”, clausola di politica 5.4.3.

La Logging and Monitoring Policy enterprise si concentra sull’utilizzabilità in sede di audit:

L’ISMS Audit Trail Register deve registrare la disponibilità dei dati di log per audit, indagini e riesami normativi.

Dalla sezione “Governance Requirements”, clausola di politica 5.4.

Questo è essenziale perché le evidenze privacy devono spesso rispondere a domande basate sugli eventi:

• Chi ha avuto accesso ai dati personali identificabili (PII)?
• L’accesso era autorizzato?
• L’accesso era collegato a un ticket di supporto, una richiesta legale, un’attività operativa o un’istruzione del cliente?
• I dati sono stati esportati, copiati, modificati o cancellati?
• È stato usato un accesso privilegiato?
• Le autorizzazioni sono state modificate prima o dopo l’accesso?
• L’attività indicava un incidente di sicurezza o una violazione dei dati personali?

I log non servono solo al SOC. Sono evidenze PIMS, evidenze di assurance verso i clienti, evidenze di assurance dei responsabili del trattamento ed evidenze per la risposta agli incidenti.

Mappatura trasversale della conformità: un solo modello di accesso, molte prospettive

Una debolezza nei riesami degli accessi ai dati personali identificabili (PII) non è mai una sola risultanza. Può diventare un problema di responsabilizzazione GDPR, una debolezza del PIMS ISO/IEC 27701:2025, una non conformità ISO/IEC 27001:2022, un fallimento di governance NIS2, un elemento critico per la resilienza DORA, una lacuna di governance NIST CSF 2.0 o un problema di maturità dei processi COBIT 2019.

Una mappatura più dettagliata dei controlli mostra come un singolo processo di governance degli accessi ai dati personali identificabili (PII) supporti più requisiti:

Il valore di Zenith Controls è che i team possono ricondurre queste prospettive alle stesse evidenze di controllo invece di mantenere silos di conformità separati.

Esegui uno sprint di 45 minuti sulle evidenze degli accessi ai dati personali identificabili (PII)

Un modo utile per verificare lo stato di preparazione consiste nello scegliere un sistema ad alto impatto, ad esempio una piattaforma di supporto clienti, un sistema HR, un portale pagamenti, un portale pazienti, un data lake o un database di produzione SaaS, ed eseguire uno sprint mirato sulle evidenze.

Step 1: definire il contesto del trattamento dei dati personali identificabili (PII)

Registrare in REG12:

• Nome e proprietario del sistema
• Categorie di dati personali identificabili (PII)
• Categorie di interessati
• Ruolo di titolare o responsabile del trattamento
• Finalità del trattamento
• Indicatore di dati personali identificabili (PII) sensibili o ad alto impatto
• Dipendenze da cloud, fornitori e sub-responsabili

Se il sistema coinvolge un responsabile del trattamento, verificare i campi di controllo contrattuale in REG08 usando la Processor, Subprocessor and Third-Party Privacy Management Policy. L’approvazione deve coprire ambito del trattamento, durata, finalità, categorie di dati personali identificabili (PII), categorie di interessati, riservatezza, sicurezza, autorizzazione dei sub-responsabili, assistenza, audit o assurance, restituzione, cancellazione e cessazione.

Step 2: estrarre l’elenco degli accessi

Esportare tutti gli utenti, gruppi, ruoli privilegiati, account di servizio, ruoli di supporto, account break-glass, chiavi API e account dei fornitori. Confrontare ogni autorizzazione con i ruoli approvati.

Step 3: confermare privilegio minimo e allineamento alla finalità

Usare la baseline della PII Security and Access Control Policy: l’accesso deve essere limitato a ruoli approvati e utenti autorizzati registrati o tracciabili in REG02 o REG12 prima dell’abilitazione. Se un utente non può essere ricondotto a ruolo, finalità e approvazione, la risultanza non è “documentazione mancante”. La risultanza è “accesso ai dati personali identificabili (PII) non dimostrabilmente autorizzato”.

Step 4: verificare l’ambito del logging

Confermare che i log acquisiscano autenticazione, eventi di accesso, azioni privilegiate, attività di esportazione di dati personali identificabili (PII) e modifiche sostanziali della configurazione. Confermare poi dove sono archiviati i log, per quanto tempo sono conservati, chi può accedervi e se sono registrati nell’ISMS Audit Trail Register per audit, indagini e riesami normativi.

Step 5: chiudere il ciclo

Per ogni eccezione, registrare il proprietario del rischio, l’azione immediata di contenimento, la remediation permanente, la data obiettivo, le evidenze richieste, la decisione sul rischio residuo e se sia necessaria una valutazione della violazione.

Questo singolo esercizio di solito rivela la reale maturità della governance degli accessi ai dati personali identificabili (PII). Le organizzazioni solide rispondono rapidamente. Le organizzazioni deboli scoprono che politica privacy, configurazione IAM, contratti con i responsabili del trattamento, logging cloud ed evidenze di audit sono scollegati.

Risultanze di audit comuni nella governance degli accessi ai dati personali identificabili (PII)

La maggior parte delle risultanze è prevedibile. Emergono quando privacy, sicurezza, legale, IT e fornitori controllano ciascuno una parte della storia, ma nessuno possiede l’intero ciclo di vita degli accessi ai dati personali identificabili (PII).

Le risultanze comuni includono:

• I sistemi che trattano dati personali identificabili (PII) non sono elencati integralmente nell’inventario PIMS.
• I ruoli di accesso sono definiti tecnicamente ma non mappati alle finalità del trattamento.
• I dati personali sensibili identificabili (PII) sono accessibili tramite gruppi operativi troppo ampi.
• I riesami trimestrali coprono i dipendenti ma non gli account di servizio, le chiavi API o gli utenti dei fornitori.
• L’accesso del supporto cloud è possibile ma non viene riesaminato come accesso ai dati personali identificabili (PII).
• I log esistono ma non dimostrano accesso ai dati personali identificabili (PII), esportazione o attività privilegiata.
• I contratti con i responsabili del trattamento includono clausole generiche di riservatezza ma non controlli specifici su controllo degli accessi, audit, sub-responsabili, restituzione, cancellazione o cessazione.
• Ex dipendenti o collaboratori mantengono accesso tramite gruppi condivisi o token non gestiti.
• L’accesso al data warehouse è più ampio dell’accesso all’applicazione sorgente.
• Esistono account break-glass senza riesame post-utilizzo.
• L’impersonificazione del supporto clienti non viene registrata con il contesto del ticket.
• La Dichiarazione di Applicabilità include controlli degli accessi, ma le evidenze non mostrano un’attuazione specifica per i dati personali identificabili (PII).

Ciascuna di queste risultanze può diventare, a seconda dell’ambito, un problema di responsabilizzazione GDPR, una criticità di assurance verso i clienti, una debolezza di governance NIS2 o DORA oppure una non conformità ISO/IEC 27001:2022.

Come appare un modello efficace

Un modello operativo maturo non dipende da interventi eroici di pulizia trimestrale. Integra la governance degli accessi ai dati personali identificabili (PII) nelle normali operazioni.

Primo, l’organizzazione dispone di consapevolezza sui dati. Sa dove esistono i dati personali identificabili (PII), perché sono trattati, quale ruolo PIMS si applica e quali sistemi, fornitori, servizi cloud, log, backup ed esportazioni rientrano nell’ambito.

Secondo, l’accesso è basato sui ruoli e allineato alle finalità. Le autorizzazioni sono definite in base a ruoli approvati, esigenza aziendale documentata, finalità del trattamento e principio del privilegio minimo.

Terzo, i controlli sono applicati tecnicamente. IAM, RBAC, gestione degli accessi privilegiati (PAM), MFA, accesso condizionale, controlli sui tenant, cifratura e segregazione degli ambienti applicano le aspettative delle politiche.

Quarto, il monitoraggio è intenzionale. L’organizzazione può ricostruire autenticazione, accesso, esportazione, azioni privilegiate, accesso per il supporto e modifiche di configurazione che incidono sui dati personali identificabili (PII).

Quinto, i riesami sono basati sul rischio e documentati. I dati personali identificabili (PII) ad alto impatto ricevono almeno un riesame trimestrale. L’accesso dei fornitori e del supporto cloud è incluso. Le eccezioni sono tracciate fino alla chiusura.

Sesto, le evidenze sono riutilizzabili. Le stesse registrazioni supportano la responsabilizzazione GDPR, l’operatività del PIMS ISO/IEC 27701:2025, il trattamento del rischio ISO/IEC 27001:2022, le misure di gestione dei rischi NIS2, la governance del rischio ICT DORA, gli esiti GOVERN di NIST CSF 2.0 e l’assurance di gestione COBIT 2019.

Questa è la differenza tra controllo degli accessi come impostazione e governance degli accessi come sistema.

Trasformare l’accesso ai dati personali identificabili (PII) in evidenze idonee all’audit

Se il prossimo audit, riesame da parte di un cliente o richiesta dell’autorità di regolamentazione iniziasse domani con “mostratemi chi può accedere ai dati personali identificabili (PII)”, il tuo team produrrebbe evidenze in pochi minuti oppure inizierebbe a riconciliare fogli di calcolo?

Clarysec può aiutarti a colmare questa lacuna.

Inizia dalla PII Security and Access Control Policy, allinea gli obblighi dei responsabili del trattamento e del cloud tramite la Processor, Subprocessor and Third-Party Privacy Management Policy e la Cloud PII Processor Policy, quindi usa Zenith Blueprint: An Auditor’s 30-Step Roadmap per implementare i controlli nella sequenza corretta. Infine, usa Zenith Controls: The Cross-Compliance Guide per mappare le evidenze sugli accessi ai dati personali identificabili (PII) tra ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0 e COBIT 2019.

Il passo pratico più rapido è semplice: seleziona un sistema PII ad alto impatto, popola REG12, esporta l’elenco degli accessi, verifica l’ambito del logging ed esegui un riesame in stile trimestrale. In una sola sessione saprai se la tua governance degli accessi ai dati personali identificabili (PII) è idonea all’audit o solo pronta sulla carta.