Playbook GDPR, NIS2 e DORA per i dati personali nei log di sicurezza

Un analista di sicurezza apre il SIEM alle 02:17. L’allerta sembra inizialmente ordinaria: più accessi non riusciti, una sessione riuscita da un indirizzo IP insolito, poi una sequenza improvvisa di chiamate API verso un endpoint di esportazione dei dati dei clienti. Nel giro di pochi minuti, il canale dell’incidente si riempie. Il Responsabile della sicurezza delle informazioni vuole sapere se si tratta di una compromissione dell’account. La funzione legale chiede se i log contengono dati personali. Il Responsabile della protezione dei dati (DPO) chiede se l’ID utente, l’indirizzo IP, l’identificativo del dispositivo e gli URL delle richieste nel SIEM sono coperti dall’informativa privacy e dal registro delle attività di trattamento. Il Responsabile della conformità chiede se i log debbano essere preservati ai fini delle segnalazioni regolamentari. L’assistenza clienti chiede se domani un cliente potrebbe richiedere la cancellazione delle stesse voci di log.

È in momenti come questo che molte organizzazioni scoprono che la registrazione degli eventi di sicurezza e la governance privacy sono state progettate come mondi separati.

I team di sicurezza vogliono log dettagliati, conservazione prolungata, archiviazione immutabile e accesso rapido. I team privacy vogliono minimizzazione, limitazione della finalità, accesso basato sui ruoli, disciplina nella conservazione e cancellazione quando i dati non sono più necessari. I team di risposta agli incidenti vogliono che le evidenze siano preservate esattamente com’erano. La responsabilizzazione prevista dal GDPR richiede all’organizzazione di spiegare perché i dati personali sono presenti, chi vi ha avuto accesso e per quanto tempo sono conservati. NIS2 e DORA aggiungono urgenza, perché soggetti essenziali, soggetti importanti e organizzazioni finanziarie hanno bisogno di evidenze sufficienti per classificare gli incidenti, segnalarli nei tempi previsti e dimostrare una gestione efficace del rischio ICT.

La realtà scomoda è semplice: i log di sicurezza sono spesso repository di dati personali. I log di autenticazione possono contenere nomi utente, indirizzi e-mail, indirizzi IP, impronte dei dispositivi e dati di geolocalizzazione. I log applicativi possono esporre URL, stringhe di ricerca, frammenti di payload, numeri di pratica e contenuti dei messaggi. I log EDR e cloud possono includere hostname collegati ai dipendenti, percorsi di file con nomi, identificativi di sessione e azioni degli amministratori. I log IAM possono rivelare modifiche dei privilegi, appartenenza a gruppi e tentativi di accesso non riusciti a sistemi sensibili.

Se i log contengono dati personali, non sono più soltanto un tema di registrazione degli eventi ai fini ISO 27001. Diventano un tema di privacy, conservazione, evidenze, segnalazione degli incidenti e governance dei fornitori. Clarysec tratta la governance dei dati personali nei log di sicurezza come un problema di conformità trasversale, non come un semplice problema di configurazione dello strumento.

Il vero dilemma del CISO: evidenze di rilevamento contro minimizzazione privacy

Il CISO nello scenario delle 02:17 affronta un conflitto operativo reale. Se i log sono troppo scarni, il SOC non può rilevare la compromissione, ricostruire le cronologie o supportare le segnalazioni NIS2 e DORA. Se i log sono troppo ricchi, l’organizzazione può raccogliere più dati personali del necessario, conservarli troppo a lungo, esporli a troppi amministratori o non riuscire a supportare i diritti GDPR e gli obblighi di trasparenza.

Il GDPR definisce in modo ampio i dati personali come informazioni relative a una persona identificata o identificabile. Il trattamento include raccolta, archiviazione, uso, comunicazione, cancellazione e distruzione. In pratica, i log contenenti indirizzi IP, ID utente, identificativi dei dispositivi o registrazioni delle attività possono costituire dati personali a seconda del contesto. I principi del GDPR richiedono un trattamento lecito, corretto e trasparente, la limitazione della finalità, la minimizzazione dei dati, la limitazione della conservazione, l’integrità e riservatezza, oltre alla responsabilizzazione.

La domanda di governance non è: “Possiamo mai registrare dati personali?” La domanda corretta è: “Quali dati personali dobbiamo registrare per sicurezza, risposta agli incidenti e conformità, quale base giuridica li sostiene, quali misure di protezione si applicano e quando devono essere cancellati, anonimizzati o posti sotto sospensione approvata?”

La libreria di politiche privacy enterprise di Clarysec affronta direttamente questa tensione. La Politica di protezione dei dati e privacy, Requisiti di applicazione della politica, clausola 6.2.1, stabilisce:

Possono essere raccolti e trattati solo i dati necessari per una finalità aziendale specifica e legittima.

Per le PMI, lo stesso principio è indicato nella Politica di protezione dei dati e privacy per PMI, Requisiti di applicazione della politica, clausola 6.2.1:

Devono essere raccolti e conservati solo i dati personali minimi necessari.

Questa frase deve guidare ogni decisione di progettazione della registrazione degli eventi. Ogni campo di ciascuna fonte di log è necessario per una finalità di sicurezza, operativa, legale o contrattuale definita?

Perché ISO 27701 cambia la discussione sui log

ISO/IEC 27001:2022 fornisce il sistema di gestione: ambito di applicazione, parti interessate, valutazione del rischio, trattamento del rischio, controllo operativo, monitoraggio, audit interno e miglioramento continuo. ISO/IEC 27002:2022 fornisce indicazioni pratiche sui controlli per registrazione degli eventi, monitoraggio, protezione della privacy dei dati personali, raccolta delle evidenze, protezione delle registrazioni, cancellazione, controllo degli accessi e gestione dei fornitori. ISO 27701 estende il modello di governance alla gestione delle informazioni sulla privacy, concentrandosi su titolari del trattamento e responsabili del trattamento dei dati personali, ruoli privacy, registri dei trattamenti di dati personali, privacy by design, gestione dei diritti e obblighi dei responsabili del trattamento.

Per i log di sicurezza, ISO 27701 è rilevante perché impone domande specifiche sulla privacy che i team di sicurezza talvolta saltano:

• La fonte di log tratta dati personali in qualità di titolare del trattamento, responsabile del trattamento, contitolare del trattamento o sub-responsabile?
• I dati di log sono inclusi nell’inventario delle attività di trattamento?
• L’organizzazione sa quali campi dei log contengono dati personali?
• I dati personali nei log sono collegati a regole di conservazione e cancellazione?
• I clienti del responsabile del trattamento sono informati sulla registrazione degli accessi ai dati personali quando contrattualmente richiesto?
• I log sono considerati nelle risposte alle richieste di accesso, cancellazione o limitazione?
• Gli incidenti relativi ai dati personali sono valutati rispetto ai presupposti di segnalazione privacy, cybersecurity e del settore finanziario?

La Politica di sicurezza e controllo degli accessi ai dati personali di Clarysec traduce questo approccio in requisiti operativi. Da Registrazione e monitoraggio, clausola 4.6.1:

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

La clausola 4.6.2 chiude quindi il ciclo tra registrazione, controllo degli accessi e conservazione:

[Entrambi] Il Responsabile della sicurezza delle informazioni DEVE garantire che i log contenenti dati personali siano soggetti a restrizioni di accesso e collegati a una regola approvata di conservazione o cancellazione in REG02 o REG12 prima dell’avvio del monitoraggio dei log.

Questo rende concreta la governance del PIMS. REG12 definisce quale registrazione dei dati personali è consentita e richiesta. REG02 identifica dove esistono dati personali, inclusi i log. Le regole di conservazione e cancellazione non sono documentazione aggiunta in seguito. Diventano prerequisiti per la registrazione in produzione.

I log di sicurezza sono registrazioni, evidenze e attività di trattamento dei dati personali

Un’organizzazione matura non dovrebbe trattare i log come scarti tecnici eliminabili. I log sono registrazioni. Durante un incidente possono diventare evidenze legali. Quando contengono dati personali, sono anche dati di trattamento soggetti alla governance privacy.

La Politica di registrazione e monitoraggio di Clarysec definisce le aspettative di normalizzazione dei log. Dai Requisiti di governance, clausola 5.1.4:

Requisiti di formato e normalizzazione dei log (ad es. marcatura temporale, ID utente, tipo di evento, IP sorgente)

Sono esattamente questi i campi che rendono i log utili per la risposta agli incidenti. Sono anche i campi che spesso rendono i log dati personali. La stessa politica enterprise segnala ciò che non deve mai accadere, dai Requisiti di governance, clausola 5.3.3:

Archiviazione di dati sensibili in chiaro (ad es. password, segreti crittografici)

Il punto non è che i log debbano evitare tutti gli identificativi. Il punto è che gli identificativi devono essere intenzionali, protetti e giustificati. Password, segreti, token completi e payload non necessari non devono essere registrati. ID utente, indirizzi IP e metadati degli eventi possono essere necessari, ma richiedono controlli.

Per le PMI, la Politica di registrazione e monitoraggio per PMI di Clarysec inserisce il riesame privacy nella struttura dei ruoli. Da Ruoli e responsabilità, clausola 4.3.1, richiede all’organizzazione di:

Verificare che i dati di log relativi a informazioni personali o sensibili siano gestiti in conformità al GDPR e alle altre leggi sulla protezione dei dati.

La versione per PMI stabilisce anche un requisito baseline chiaro per la conservazione. Dai Requisiti di governance, clausola 5.2.1:

I log devono essere conservati per almeno 12 mesi, salvo che un periodo di conservazione più lungo sia richiesto dalla legge o da un contratto, oppure sia giustificato nell’ambito di un incidente attivo o di una controversia legale.

E stabilisce l’aspettativa di protezione, dai Requisiti di governance, clausola 5.3.1:

I log devono essere archiviati in posizioni protette da scrittura e l’accesso deve essere limitato esclusivamente al personale autorizzato.

Per la risposta agli incidenti enterprise, la Politica per la raccolta delle evidenze e l’analisi forense, Requisiti di applicazione della politica, clausola 6.3.1, richiede:

I log provenienti da firewall, SIEM, agenti endpoint, piattaforme di Gestione delle identità e degli accessi (IAM) e piattaforme cloud devono essere esportati e archiviati in formati immutabili.

La versione per PMI aggiunge un criterio di proporzionalità. La Politica per la raccolta delle evidenze e l’analisi forense per PMI, Trattamento del rischio ed eccezioni, clausola 7.2.1, stabilisce:

Minimizzare l’ambito della raccolta; raccogliere solo ciò che è necessario.

Questo è il nucleo della registrazione consapevole della privacy: preservare ciò che è necessario, dimostrare perché è necessario, limitare chi può vederlo e cancellarlo quando la finalità approvata scade.

Il modello di controllo Clarysec per evidenze sicure sotto il profilo privacy

In Zenith Blueprint: roadmap in 30 passi per auditor, Clarysec colloca la registrazione nella fase Controlli in azione, Passo 19: Controlli tecnologici I. La guida spiega l’aspettativa di controllo ISO/IEC 27002:2022:

A.8.15 – Registrazione: “I log che registrano attività, eccezioni, guasti e altri eventi rilevanti devono essere prodotti, archiviati, protetti e analizzati.”

Lo stesso passo indica alle organizzazioni di generare log per eventi chiave, archiviarli in modo sicuro affinché non possano essere alterati, conservarli per un periodo definito e analizzarli tramite un SIEM o un processo di riesame. Collega inoltre la registrazione alla notifica delle violazioni prevista dal GDPR, alle registrazioni degli incidenti DORA, alla gestione del rischio NIS2 e all’analisi dei log di sicurezza COBIT.

Ma la registrazione da sola non basta. Nella stessa fase Controlli in azione, Passo 19, Zenith Blueprint tratta la cancellazione. Avverte che i dati conservati oltre il valore operativo aumentano l’esposizione e il rischio regolamentare, e richiama esplicitamente backup, snapshot e archivi. Questo è importante perché una regola di conservazione del SIEM è priva di valore se archivi di log replicati o bucket di archiviazione cloud conservano gli stessi dati personali a tempo indeterminato.

Nel Passo 23: Controlli organizzativi, Zenith Blueprint tratta la raccolta delle evidenze. Stabilisce che le evidenze dell’incidente devono essere identificate, raccolte e preservate in modo giuridicamente ammissibile, affidabile e allineato alle esigenze investigative. Evidenzia inoltre una realtà operativa: spesso le evidenze vengono perse nei primi minuti della risposta, quando i log vengono sovrascritti, i sistemi vengono riavviati o gli amministratori modificano account compromessi prima che siano acquisiti gli snapshot.

Il Passo 23 tratta anche privacy e protezione dei dati personali. La guida inquadra i dati personali come un tema di ciclo di vita che richiede consapevolezza dei dati, classificazione, controllo degli accessi, mascheramento, cancellazione, cifratura e obblighi dei fornitori. Per i log, ciò significa che SIEM, EDR, piattaforma di registrazione cloud e sistema di ticketing devono far parte dell’inventario dei dati personali.

Mappatura trasversale della conformità per i dati personali nei log

Zenith Controls: guida alla conformità trasversale mappa il controllo ISO/IEC 27002:2022 8.15, Registrazione, ai controlli correlati essenziali per la governance dei dati personali. Queste relazioni mostrano perché la registrazione non è solo una responsabilità del SOC.

Zenith Controls mappa inoltre la Registrazione alla clausola ISO/IEC 27002:2022 8.15, a ISO/IEC 27035-1 e ISO/IEC 27035-2 per la gestione degli incidenti, a ISO 27701 per il registro delle attività di trattamento dei dati personali, a ISO/IEC 27017 per i log di audit cloud, a ISO/IEC 27018 per la registrazione degli accessi ai dati personali nel cloud, a ISO/IEC 27005 per i rischi derivanti da registrazione insufficiente, a ISO/IEC 27033 per la registrazione delle attività di rete e a ISO/IEC 15408-2 per le funzionalità di audit nei prodotti valutati.

Per la privacy in particolare, Zenith Controls mappa il controllo ISO/IEC 27002:2022 5.34, Privacy e protezione dei dati personali, a inventario degli asset, mascheramento dei dati, servizi cloud, classificazione, trasferimento delle informazioni, controllo degli accessi, gestione delle identità e riesame di sicurezza di progetti e modifiche. Per un programma di governance dei log, questi collegamenti diventano requisiti pratici di progettazione:

• Inventariare gli archivi dei log come posizioni contenenti dati personali.
• Mascherare o tokenizzare i dati personali quando non sono necessari identificativi completi.
• Riesaminare i servizi di registrazione cloud e i fornitori SIEM nell’ambito dei controlli cloud e dei fornitori.
• Classificare i log contenenti dati personali come registrazioni sensibili.
• Governare esportazioni e trasferimenti di log come trasferimenti di dati personali.
• Limitare l’accesso ai log tramite controlli di identità e accessi privilegiati.
• Riesaminare le modifiche alla registrazione applicativa prima del rilascio in produzione.

GDPR, NIS2 e DORA: un log, tre prospettive regolamentari

La stessa voce di log può essere valutata in modo diverso ai sensi di GDPR, NIS2 e DORA.

Ai sensi del GDPR, l’organizzazione chiede se la voce di log contiene dati personali, quale base giuridica sostiene il trattamento, se i dati sono necessari, per quanto tempo sono conservati, chi può accedervi, se sono comunicati a responsabili del trattamento o clienti e se devono essere considerati in una richiesta di esercizio dei diritti o in una valutazione della violazione.

Ai sensi di NIS2, l’organizzazione chiede se i log supportano la gestione del rischio di cibersicurezza, il trattamento degli incidenti, la continuità operativa, il controllo degli accessi, la sicurezza della catena di fornitura e la valutazione dell’efficacia dei controlli. NIS2 Article 20 rende gli organi di gestione responsabili dell’approvazione e della supervisione delle misure di gestione dei rischi di cibersicurezza. Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate, inclusi trattamento degli incidenti, continuità operativa, sicurezza della catena di fornitura, sviluppo sicuro, gestione delle vulnerabilità, valutazione dell’efficacia, igiene informatica, controllo degli accessi e gestione degli asset. Article 23 prevede una segnalazione per fasi degli incidenti significativi, inclusi preallarme entro 24 ore, notifica entro 72 ore e relazione finale entro un mese.

Ai sensi di DORA, le entità finanziarie devono gestire un quadro documentato per la gestione del rischio ICT. DORA Article 5 assegna la responsabilità all’organo di gestione. Article 10 riguarda il rilevamento. Article 17 richiede un processo di gestione degli incidenti connessi alle TIC. Article 18 riguarda la classificazione degli incidenti connessi alle TIC e delle minacce informatiche. Article 19 riguarda la segnalazione degli incidenti gravi connessi alle TIC. I log supportano rilevamento, classificazione, analisi della causa radice, valutazione dell’impatto, risposta, ripristino ed evidenza delle azioni di rimedio.

Una mappatura di controllo più dettagliata aiuta il CISO a giustificare la registrazione senza affidarsi ad affermazioni vaghe come “ci serve per la sicurezza”.

Costruire un ambito di registrazione dei dati personali in REG12

Un cliente Clarysec gestirebbe l’incidente SIEM delle 02:17 prima ancora che si verifichi. L’organizzazione parte da un’applicazione rivolta ai clienti che tratta dati degli account. Prima della produzione, il Responsabile dell’applicazione utilizza REG12 per definire l’ambito della registrazione dei dati personali. L’obiettivo è acquisire eventi sufficienti per sicurezza ed evidenze regolamentari senza registrare dati personali o contenuti del payload non necessari.

Successivamente, il responsabile privacy conferma se l’organizzazione agisce come titolare del trattamento, responsabile del trattamento o entrambi per ciascuna fonte di log. Se l’organizzazione è responsabile del trattamento, le istruzioni contrattuali del cliente e le comunicazioni relative ai sub-responsabili possono limitare accesso e condivisione dei log. Se è titolare del trattamento, devono essere gestite informative privacy, base giuridica e gestione dei diritti.

Il Responsabile delle informazioni aggiorna quindi REG02 per includere archivi di log in esercizio, indici SIEM, archivi, backup ed esportazioni forensi temporanee. Questo è allineato alla Politica di conservazione, cancellazione e smaltimento dei dati personali, Backup, archivi, repliche, log e file temporanei, clausola 4.4.1:

[Entrambi] Il Responsabile del sistema / Responsabile dell’applicazione DEVE identificare archivi attivi, archivi, copie di backup, repliche, log, aree di staging e file temporanei contenenti dati personali in REG02 prima della messa in esercizio in produzione e durante ogni riesame annuale della conservazione.

La Politica di conservazione e smaltimento dei dati deve quindi allineare le regole di conservazione aziendale con i requisiti legali, contrattuali e di preservazione delle evidenze.

Infine, il team di sicurezza configura il SIEM affinché password, segreti e corpi dei payload siano scartati o oscurati prima dell’ingestione. Ai log contenenti dati personali vengono assegnati indici ad accesso ristretto. La conservazione è applicata automaticamente salvo approvazione di un incidente o di una conservazione legale. Le azioni di cancellazione sono registrate. Le esportazioni forensi richiedono approvazione e tracciamento della catena di custodia. Le dashboard mostrano identificativi pseudonimizzati quando l’identità completa non è necessaria. Il recupero dei log storici è testato durante gli audit interni.

Questa è la differenza tra dire “registriamo per sicurezza” e dimostrare “registriamo solo ciò che è necessario, lo proteggiamo, lo conserviamo secondo regole approvate e possiamo usarlo come evidenza senza violare gli obblighi privacy”.

DSAR, cancellazione e log: decidere prima che arrivi la richiesta

Una delle domande più difficili è se i log debbano essere ricercati, comunicati o cancellati in risposta a richieste di accesso dell’interessato o di cancellazione. La risposta dipende da ruolo, finalità, base giuridica, fattibilità, esenzioni e obblighi di conservazione. Tuttavia, il processo di governance non può essere definito richiesta per richiesta.

La Politica di gestione dei diritti degli interessati, Verifica dell’identità, ambito di applicazione e valutazione, clausola 4.2.3, stabilisce:

[Titolare del trattamento] Il Responsabile del processo / Responsabile dell’attività DEVE identificare sistemi, registrazioni, finalità, categorie di dati personali, destinatari e vincoli di conservazione rilevanti da REG02 prima di valutare l’evasione della richiesta.

Questo significa che i log devono essere in REG02 con metadati chiari: quali categorie di dati personali contengono, quale finalità servono, quale vincolo di conservazione si applica e se una richiesta può essere evasa tramite comunicazione diretta, accesso in forma riepilogativa, limitazione, cancellazione alla scadenza o rifiuto basato su un fondamento giuridico documentato.

Clarysec raccomanda un approccio a tre livelli:

1. Log operativi a basso impatto privacy, come i log degli eventi di sistema che utilizzano ID utente pseudonimi, possono essere ricercabili e comunicabili ove appropriato.
2. Log di sicurezza con elevata sensibilità di sicurezza, come dati di correlazione SIEM o contesto di threat intelligence, possono richiedere filtraggio, comunicazione riepilogativa o limitazione per evitare di esporre logiche di rilevamento o dati di terze parti.
3. Evidenze forensi soggette a incidente attivo o conservazione legale non devono essere alterate con leggerezza. La cancellazione può essere differita o limitata quando giuridicamente giustificato, con decisione documentata dagli stakeholder privacy e legali.

Se DPO e SOC discutono ogni DSAR da zero, l’organizzazione sarà incoerente e lenta. Se REG02 e REG12 sono mantenuti, la gestione dei diritti diventa basata sulle evidenze.

Segnalazione di violazioni e incidenti: un evento, più decorrenze

L’allerta delle 02:17 può attivare più decorrenze. La valutazione della violazione dei dati personali ai sensi del GDPR può richiedere una notifica all’autorità di controllo quando le soglie di rischio sono soddisfatte. La segnalazione di un incidente significativo ai sensi di NIS2 può richiedere un preallarme entro 24 ore, una notifica entro 72 ore e una relazione finale. DORA può richiedere la segnalazione di un incidente grave connesso alle TIC attraverso fasi iniziali, intermedie e finali. I contratti con i clienti possono prevedere finestre di notifica ancora più brevi.

La Politica di gestione degli incidenti e delle violazioni dei dati personali di Clarysec affronta direttamente questo problema di presupposti multipli. Da Classificazione e valutazione della violazione, clausola 4.2.6:

[Condizionale] Il Responsabile privacy / Responsabile del PIMS DEVE valutare i presupposti di segnalazione applicabili di natura legale, settoriale, del settore finanziario, di cibersicurezza, contrattuale, verso il cliente e verso il destinatario del servizio per ciascun incidente relativo ai dati personali ad alto impatto e registrare l’esito di applicabilità in REG01, REG08 e REG10.

Durante il triage, l’organizzazione deve chiedersi:

• L’attaccante ha avuto accesso a dati personali o solo a metadati?
• I log hanno esposto ulteriori dati personali a utenti non autorizzati?
• I log sono necessari per determinare persone interessate, sistemi e periodo temporale?
• I log sono archiviati in modo immutabile e soggetti a restrizioni di accesso?
• Una sospensione per incidente ha bloccato la cancellazione dei log rilevanti?
• Sono interessati clienti del responsabile del trattamento, clienti del settore finanziario o destinatari del servizio?
• Quali decorrenze di segnalazione si applicano e chi è responsabile di ciascuna notifica?

Log ben governati accelerano la segnalazione perché forniscono ai decisori fatti affidabili. Una registrazione carente causa ritardi. Una registrazione eccessiva crea rischio privacy. La risposta corretta è una registrazione mirata, protetta e mappata.

Registrazione presso fornitori e cloud: il problema del responsabile del trattamento nascosto nel SIEM

La maggior parte delle organizzazioni non archivia tutti i log su infrastrutture pienamente controllate. I log confluiscono in piattaforme SIEM, portali EDR, servizi di registrazione cloud-native, strumenti di osservabilità, sistemi di ticketing e fornitori di servizi gestiti di rilevamento e risposta. Ai sensi del GDPR, questi fornitori possono essere responsabili del trattamento o sub-responsabili. Ai sensi di NIS2 e DORA, possono anche essere fornitori diretti, fornitori terzi di servizi ICT, fornitori di servizi gestiti o fornitori di servizi di sicurezza gestiti.

NIS2 Article 21 include esplicitamente sicurezza della catena di fornitura, vulnerabilità dei fornitori e pratiche complessive di cibersicurezza dei fornitori. DORA aggiunge requisiti dettagliati di rischio ICT di terze parti per le entità finanziarie, inclusi due diligence precontrattuale, registri delle informazioni, diritti di audit e accesso, assistenza negli incidenti, localizzazione dei dati, clausole di protezione dei dati, strategie di uscita e disposizioni contrattuali per funzioni essenziali o importanti.

Per i dati personali nei log di sicurezza, i riesami dei fornitori devono includere queste domande:

Un contratto SIEM non è solo una sottoscrizione software. È una dipendenza per il trattamento dei dati personali e per le evidenze degli incidenti.

Prospettiva di audit: come i valutatori testano i dati personali nei log di sicurezza

Un buon auditor non accetterà l’affermazione “i log sono protetti”. Testerà la catena dalla politica alla configurazione, dalle evidenze al riesame.

Un test di audit pratico è semplice ma rivelatore: chiedere al SOC di recuperare una voce di log di dieci mesi prima che mostri una modifica di accesso privilegiato in una piattaforma cloud, dimostrare chi ha avuto accesso a quel log, dimostrare che non è stato alterato, mostrare la regola di conservazione che ne ha consentito l’esistenza, mostrare i campi di dati personali che contiene e mostrare come sarebbe gestito in una DSAR o in un rapporto di incidente. Se il team non riesce a rispondere trasversalmente su sicurezza, privacy e conformità, la governance è incompleta.

Risultanze comuni negli audit sui dati personali nei log

Clarysec osserva spesso gli stessi schemi:

• I team applicativi registrano payload completi delle richieste per il debug, inclusi nomi, e-mail, numeri di account o contenuto dei messaggi.
• Gli indici SIEM sono aperti a gruppi ampi di amministratori IT invece che a ruoli SOC ristretti.
• La conservazione dei log è impostata globalmente senza considerare sensibilità dei dati personali, contratti con i clienti o regole di sospensione per incidente.
• I log del fornitore cloud sono abilitati, ma l’accesso degli amministratori del fornitore ai dati di log del cliente non è riesaminato.
• Le procedure DSAR non menzionano log, casi SIEM o esportazioni forensi.
• I playbook di risposta agli incidenti preservano le evidenze, ma i team privacy non sono coinvolti nella classificazione.
• Backup e archivi conservano dati personali nei log più a lungo del SIEM.
• Gli sviluppatori possono modificare i livelli di registrazione in produzione senza riesame privacy o sicurezza.
• Gli ambienti di test ricevono log di produzione con dati personali.
• L’organizzazione ha obblighi di segnalazione NIS2 o DORA ma non può recuperare rapidamente evidenze affidabili.

Queste risultanze raramente derivano da cattive intenzioni. Derivano da titolarità frammentata. I log di sicurezza si collocano tra SOC, ingegneria delle piattaforme, privacy, legale, conformità, audit e fornitori. Se nessuno governa l’intero ciclo di vita, compaiono lacune.

Una checklist Clarysec per una governance dei log idonea all’audit

Usa questa checklist come punto di partenza operativo per il prossimo riesame della governance:

1. Definire quali fonti di log possono contenere dati personali: IAM, applicazione, gateway API, SIEM, EDR, cloud, database, rete, accesso fisico e ticketing.
2. Registrare ciascun archivio di log in REG02, inclusi archivi attivi, archivi, backup, repliche ed esportazioni forensi temporanee.
3. Definire l’ambito della registrazione dei dati personali in REG12 prima dell’uso in produzione o di modifiche sostanziali.
4. Identificare finalità e base giuridica del trattamento dei log di sicurezza.
5. Vietare password, segreti, token completi e payload non necessari nei log.
6. Usare mascheramento, hashing o pseudonimizzazione quando non sono richiesti identificativi completi.
7. Limitare per ruolo l’accesso ai log contenenti dati personali, con riesame degli accessi privilegiati.
8. Archiviare i log ad alto valore in formati immutabili o protetti da scrittura.
9. Definire la conservazione per tipo di log, obbligo legale, contratto, necessità di incidente e rischio privacy.
10. Applicare sospensioni per incidente con approvazione, ambito e scadenza.
11. Includere i log nella logica di valutazione delle DSAR e della cancellazione.
12. Riesaminare fornitori SIEM, EDR, cloud e MDR come responsabili del trattamento o terze parti ICT.
13. Testare recupero storico e integrità delle evidenze.
14. Mappare la registrazione rispetto alle esigenze di segnalazione GDPR, ISO 27701, NIS2, DORA, NIST CSF e COBIT.
15. Formare SOC, privacy e team applicativi su ciò che può e non può essere registrato.

Questa checklist trasforma la registrazione consapevole della privacy in un processo di controllo ripetibile.

Dal dilemma alla fiducia a livello di consiglio di amministrazione

NIS2 rende la cibersicurezza una responsabilità della direzione. DORA rende l’organo di gestione responsabile della gestione del rischio ICT, della strategia di resilienza operativa digitale, della riservatezza dei dati, della comunicazione degli incidenti e delle politiche sui servizi ICT di terze parti. ISO/IEC 27001:2022 richiede all’alta direzione di allineare il SGSI agli obiettivi aziendali, assegnare responsabilità, fornire risorse e guidare il miglioramento continuo.

I dati personali nei log di sicurezza non sono quindi un dettaglio tecnico circoscritto. Sono un tema di fiducia a livello di consiglio di amministrazione. La capacità dell’organizzazione di rilevare incidenti, proteggere dati personali, preservare evidenze, rispondere ai clienti, soddisfare le autorità di regolamentazione e ripristinare le operazioni dipende da decisioni di registrazione prese molto prima dell’incidente.

I migliori programmi di governance non scelgono tra privacy e sicurezza. Definiscono la registrazione minima necessaria per una sicurezza robusta, proteggono tale registrazione come dati personali sensibili quando richiesto e la collegano a conservazione, evidenze, gestione dei diritti e obblighi dei fornitori.

Prossimi passi con Clarysec

Se i log SIEM, IAM, EDR o cloud contengono dati personali, questo è il momento di governarli in modo deliberato.

Clarysec può aiutarti a:

• Costruire un ambito di registrazione dei dati personali usando REG12 e allinearlo alla Politica di sicurezza e controllo degli accessi ai dati personali.
• Inventariare archivi di log, archivi, backup ed esportazioni forensi usando REG02 e la Politica di conservazione, cancellazione e smaltimento dei dati personali.
• Allineare controlli di registrazione, monitoraggio, evidenze e privacy con Zenith Blueprint.
• Mappare i controlli tra GDPR, ISO 27701, NIS2, DORA, NIST CSF e COBIT usando Zenith Controls.
• Preparare evidenze idonee all’audit per riesami di assurance ISO, privacy, NIST, COBIT, NIS2 e DORA.

Inizia da un sistema ad alto rischio: la piattaforma IAM, il SIEM o un’applicazione rivolta ai clienti. Identifica quali dati personali entrano nei log, perché sono necessari, chi può accedervi, per quanto tempo sono conservati e come sarebbero utilizzati durante un incidente o una richiesta di esercizio dei diritti. Questo singolo esercizio rivelerà se l’attuale programma di registrazione è soltanto operativo o realmente idoneo all’audit.