Playbook GDPR delle 72 ore per le violazioni dei dati personali per CISO
Sono le 2:13 di martedì quando scatta l’allerta.
Maria, CISO di una piattaforma FinTech SaaS in forte crescita, viene svegliata da un’escalation del SOC: query anomale al database provengono da un account sviluppatore. L’account ha acceduto a tabelle contenenti nomi dei clienti, e-mail, cronologie delle transazioni e numeri di identificazione nazionale. In pochi minuti, il team conferma che le credenziali dello sviluppatore sono state sottratte tramite un attacco di phishing. La finestra di esposizione non è chiara. L’intento dell’attaccante è sconosciuto. Il perimetro dell’impatto è ancora in fase di quantificazione.
Il termine decorre da questo momento.
Per il GDPR, Maria potrebbe avere 72 ore per notificare l’autorità di controllo se l’incidente può comportare un rischio per le persone fisiche. Per NIS2, se la società è un soggetto essenziale o importante e l’incidente è significativo, possono essere richiesti un preallarme entro 24 ore e una notifica formale entro 72 ore. Per DORA, possono rilevare anche gli obblighi di segnalazione degli incidenti ICT del settore finanziario e di resilienza operativa. Clienti, assicuratori, consulenti legali, dirigenti e auditor vorranno tutti risposte.
È il momento in cui un piano generico di risposta agli incidenti spesso fallisce. Un runbook malware può spiegare come isolare gli host. Una procedura SOC può spiegare come conservare i log. Ma un processo ISO/IEC 27701:2025 per la gestione delle violazioni dei dati personali deve rispondere, sotto pressione, a domande più difficili:
- I dati personali sono stati esposti, alterati, persi, distrutti o consultati senza autorizzazione?
- L’organizzazione agisce come titolare del trattamento, responsabile del trattamento, contitolare del trattamento o sub-responsabile?
- Quando si è verificata la presa di conoscenza e quali evidenze lo dimostrano?
- È richiesta una notifica regolamentare ai sensi del GDPR Article 33?
- Gli interessati sono esposti a un rischio elevato ai sensi del GDPR Article 34?
- Se l’organizzazione agisce come responsabile del trattamento, entro quanto tempo deve informare il titolare del trattamento?
- Quali evidenze dimostreranno la decisione sei mesi dopo, durante un audit?
La differenza tra caos e controllo non dipende dal numero di strumenti di sicurezza presenti nello stack. Dipende dal fatto che l’organizzazione abbia costruito un Sistema di gestione delle informazioni sulla privacy, o PIMS, disciplinato, che colleghi risposta agli incidenti, governance della privacy, gestione delle evidenze, escalation verso i fornitori e segnalazione regolamentare in un unico ciclo di vita difendibile.
La gestione delle violazioni inizia prima che qualcuno dica “violazione”
Il primo errore operativo consiste nel presumere che la gestione delle violazioni dei dati personali inizi solo dopo la conferma legale di una violazione dei dati personali. In realtà, il processo inizia quando una persona, un sistema, un fornitore o un cliente rileva qualcosa che potrebbe coinvolgere dati personali.
Il Zenith Blueprint: An Auditor’s 30-Step Roadmap di Clarysec Zenith Blueprint colloca questo innesco umano nella fase Controls in Action, Step 16: People Controls II. La guida afferma:
“Un sistema efficace di risposta agli incidenti non inizia dagli strumenti, ma dalle persone. Control 6.8 sottolinea l’importanza di garantire che ogni dipendente, contraente o stakeholder sappia come riconoscere e segnalare un potenziale incidente di sicurezza e si senta sicuro e autorizzato a farlo.”
Questo è rilevante perché molti incidenti privacy non vengono rilevati inizialmente da un SIEM. Possono iniziare con un addetto al supporto che vede l’allegato di un altro cliente, un dipendente dell’area paghe che nota un foglio di calcolo inviato al destinatario errato, un cliente che segnala la fattura di un altro utente o un fornitore che comunica lo smarrimento di un laptop.
La Politica di protezione dei dati e privacy per PMI Politica di protezione dei dati e privacy per PMI, sezione Applicazione e conformità, clausola 8.3.1, trasforma questo principio in un obbligo immediato:
“Tutte le violazioni dei dati personali o gli incidenti sospetti devono essere segnalati immediatamente al Coordinatore privacy”
Per i programmi enterprise, la Politica di protezione dei dati e privacy Politica di protezione dei dati e privacy, sezione Applicazione e conformità, clausola 8.3.2, assegna la responsabilità di guida:
“Il Responsabile della protezione dei dati (DPO) deve guidare il contenimento, l’analisi e l’escalation della violazione in conformità a ISO/IEC 27035 e GDPR Articles 33 e 34.”
Questo è il passaggio da “l’IT sta verificando” a “il ciclo di vita PIMS della violazione è stato attivato”.
Il primo punto di pressione: evento, incidente di sicurezza, incidente privacy o violazione dei dati personali
Alle 2:13, il team di Maria ha un’allerta. Non ha ancora una violazione confermata soggetta a notifica. La prima decisione critica è la classificazione.
Il Zenith Blueprint, fase Controls in Action, Step 23: Organizational controls, spiega il controllo ISO/IEC 27002:2022 5.25, Assessment and decision on information security events:
“Non ogni anomalia è un disastro. Non ogni allerta indica una compromissione. Nel mondo reale, i team di sicurezza e le unità di business sono sommersi dal rumore: tentativi di accesso, anomalie nei log, violazioni minori delle politiche, attività di shadow IT. La vera sfida non è solo rilevare, ma distinguere ciò che è innocuo da ciò che è dannoso e sapere cosa richiede escalation.”
Il ciclo di vita di una violazione privacy deve rendere questa distinzione ripetibile. Non deve dipendere da chi è reperibile, da quale legale partecipa per primo o dal livello di confidenza del CISO di fronte all’incertezza.
Un modello pratico di classificazione Clarysec distingue quattro fasi:
| Fase di classificazione | Domanda | Responsabile tipico | Evidenze richieste |
|---|---|---|---|
| Evento | È accaduto qualcosa di insolito? | Helpdesk, SOC, titolare dell’attività | Ticket, segnalazione, allerta, e-mail, estratto dei log |
| Incidente di sicurezza | L’evento ha minacciato o compromesso la sicurezza delle informazioni? | Coordinatore della risposta agli incidenti | Ticket di incidente, note di triage, sistemi interessati |
| Incidente privacy | L’evento potrebbe coinvolgere dati personali o obblighi privacy? | Responsabile privacy o DPO | Categorie di dati personali, interessati, ruolo nel trattamento |
| Violazione dei dati personali confermata o sospetta | I dati personali sono stati esposti, persi, alterati, distrutti o consultati illecitamente o accidentalmente? | DPO, Responsabile privacy, funzione legale, titolare dell’attività | Valutazione del rischio, decisione di notifica, registro delle evidenze |
Il termine “sospetta” è essenziale. Clarysec non raccomanda di attendere la certezza assoluta prima di aprire il flusso di gestione della violazione privacy. Il registro delle violazioni deve essere aperto quando una violazione dei dati personali è ragionevolmente sospettata e poi aggiornato man mano che i fatti si consolidano.
La Politica di gestione degli incidenti e delle violazioni dei dati personali Politica di gestione degli incidenti e delle violazioni dei dati personali, sezione Classificazione e valutazione della violazione, clausola 4.2.3, richiede ai titolari del trattamento di documentare la decisione prima di qualsiasi azione esterna:
“[Titolare del trattamento] Il Responsabile della protezione dei dati / Consulente privacy DEVE valutare il rischio per gli interessati coinvolti per ogni violazione dei dati personali confermata o ragionevolmente sospettata e registrare in REG10 la raccomandazione sulla notifica, la motivazione del rischio e il parere prima che venga assunta la decisione di notifica esterna.”
Quella clausola è il nucleo operativo di una risposta alle violazioni GDPR idonea all’audit: valutare il rischio, registrare la motivazione, acquisire il parere, decidere e conservare le evidenze in REG10.
Il termine di 72 ore è un problema di evidenze, non un promemoria di calendario
Molti team trattano il requisito GDPR di notifica entro 72 ore come una scadenza in un piano di progetto. In un incidente reale, la parte difficile è dimostrare quando si è verificata la presa di conoscenza, cosa era noto in quel momento, con quale rapidità l’organizzazione ha agito e perché la decisione di notifica era ragionevole.
La Politica di risposta agli incidenti per PMI Politica di risposta agli incidenti per PMI, sezione Finalità, clausola 1.2, definisce l’obiettivo:
“Questa politica consente all’organizzazione di minimizzare i danni, proteggere i dati dei clienti e rispettare gli obblighi normativi, incluso il requisito GDPR di notifica delle violazioni dei dati personali entro 72 ore.”
La Politica di protezione dei dati e privacy per PMI, sezione Applicazione e conformità, clausola 8.3.3, stabilisce:
“Ove richiesto, la notifica alle autorità e agli interessati deve avvenire entro 72 ore”
Per i programmi enterprise, la Politica di protezione dei dati e privacy, sezione Applicazione e conformità, clausola 8.3.3, stabilisce:
“Le violazioni che soddisfano la soglia legale di notifica devono essere segnalate alle autorità di controllo entro 72 ore.”
Il punto non è notificare ogni anomalia. Il punto è assumere una decisione difendibile con sufficiente rapidità affinché, se richiesta, la notifica avvenga nei termini. Un PIMS maturo utilizza quindi scadenze interne più brevi delle scadenze legali esterne.
| Tempo dalla presa di conoscenza | Azione PIMS | Evidenze da acquisire in REG10 |
|---|---|---|
| Da 0 a 4 ore | Aprire la registrazione dell’incidente relativo ai dati personali, assegnare il responsabile, preservare le evidenze iniziali, identificare il ruolo nel trattamento | Segnalazione in ingresso, momento della presa di conoscenza, ruoli assegnati, sistemi e dati inizialmente coinvolti |
| Da 4 a 12 ore | Contenere l’esposizione, identificare le categorie di dati personali, determinare gli obblighi del titolare del trattamento o del responsabile del trattamento | Azioni di contenimento, tipologie di dati interessate, valutazione del ruolo, dipendenze da fornitori o clienti |
| Da 12 a 24 ore | Eseguire una valutazione preliminare del rischio e decidere se la notifica all’autorità di controllo è probabile | Motivazione del rischio, impatto probabile, incertezza, parere del DPO, contributo legale |
| Da 24 a 48 ore | Preparare la notifica o la motivazione della mancata notifica, coordinare le comunicazioni a clienti o titolari del trattamento | Bozza della notifica, registro decisionale, approvazioni, notifiche ai clienti, riferimenti alle evidenze |
| Da 48 a 72 ore | Inviare la notifica richiesta, documentare la motivazione del ritardo se necessario, preparare la comunicazione agli interessati se il rischio è elevato | Evidenza dell’invio, riferimento dell’autorità di controllo, decisione finale, piano di comunicazione |
| Dopo 72 ore | Proseguire l’indagine, aggiornare l’autorità di controllo se necessario, informare gli interessati ove richiesto, completare le lezioni apprese | Report di follow-up, azioni correttive, approvazione della chiusura, backlog di miglioramento |
La Politica di gestione degli incidenti e delle violazioni dei dati personali, sezione Notifica e comunicazioni, clausola 4.4.1, rende esplicito il requisito di documentazione:
“[Titolare del trattamento] Il Responsabile privacy / Responsabile PIMS DEVE predisporre una decisione documentata sulla notifica regolamentare per ogni violazione dei dati personali confermata, senza ingiustificato ritardo ed entro una scadenza interna che supporti le tempistiche di notifica esterna applicabili, e DEVE conservare in REG10 la notifica, la motivazione della mancata notifica o la motivazione del ritardo.”
Un’autorità di controllo può contestare una decisione. Un auditor può verificare se il processo è stato seguito. Ma se l’organizzazione può dimostrare evidenze tempestive, criteri strutturati, parere del DPO e motivazione documentata, si trova in una posizione molto più solida rispetto a un team che afferma: “Ne abbiamo discusso in call”.
Titolari e responsabili del trattamento richiedono percorsi di gestione della violazione diversi
Le moderne società SaaS operano spesso in più di un ruolo privacy. La piattaforma FinTech di Maria può essere titolare del trattamento per i propri abbonati diretti e responsabile del trattamento per i clienti enterprise. In un altro scenario, un portale di supporto B2B può essere responsabile del trattamento per gli allegati dei ticket dei clienti, ma titolare del trattamento per i propri metadati interni di supporto.
Questa distinzione modifica il percorso di notifica.
| Obbligo | Ruolo di titolare del trattamento dei dati personali | Ruolo di responsabile del trattamento dei dati personali |
|---|---|---|
| Obbligo primario | Verso l’autorità di controllo e gli interessati quando le soglie sono soddisfatte | Verso il titolare del trattamento o il cliente interessato |
| Destinatario della notifica | Autorità di controllo competente e, in caso di rischio elevato, interessati coinvolti | Cliente o titolare del trattamento indicato nel contratto |
| Presupposto per la notifica | Rischio per i diritti e le libertà delle persone fisiche | Presa di conoscenza di una violazione che riguarda dati personali del cliente |
| Tempistica | Senza ingiustificato ritardo e, ove possibile, entro 72 ore dalla presa di conoscenza | Senza ingiustificato ritardo ed entro i termini contrattuali, spesso 24 o 48 ore |
| Valutazione del rischio | Deve valutare il rischio per le persone fisiche e decidere in merito alla notifica ai sensi degli Article 33 e 34 | Fornisce i fatti affinché il titolare del trattamento possa valutare il rischio |
Per i responsabili del trattamento, la Politica di gestione degli incidenti e delle violazioni dei dati personali, sezione Notifica e comunicazioni, clausola 4.4.4, stabilisce:
“[Responsabile del trattamento] Il Responsabile privacy / Responsabile PIMS DEVE notificare il titolare del trattamento o il cliente interessato senza ingiustificato ritardo ed entro qualsiasi termine contrattuale applicabile dopo essere venuto a conoscenza di una violazione dei dati personali che interessa dati personali del cliente, e DEVE registrare le notifiche iniziali e di follow-up in REG08 e REG10.”
Un responsabile del trattamento non deve attendere di completare l’analisi del rischio GDPR del titolare. Deve informare il titolare del trattamento con i fatti disponibili e fornire aggiornamenti mentre l’indagine prosegue. Il titolare del trattamento decide poi sulla notifica all’autorità di controllo e sulla comunicazione agli interessati per il proprio trattamento.
Per gli impatti ad alto rischio sulle persone fisiche, il titolare deve valutare anche la comunicazione diretta. La Politica di gestione degli incidenti e delle violazioni dei dati personali, clausola 4.4.3, stabilisce:
“[Titolare del trattamento] Il Responsabile privacy / Responsabile PIMS DEVE coordinare la comunicazione agli interessati coinvolti quando la valutazione della violazione identifica un rischio elevato o un presupposto equivalente di comunicazione, e DEVE registrare in REG10 il contenuto della comunicazione, i destinatari, la tempistica, il metodo di invio e le evidenze di approvazione.”
La Politica di protezione dei dati e privacy enterprise, sezione Applicazione e conformità, clausola 8.3.4, rafforza il principio:
“Se viene identificato un rischio elevato per le persone fisiche, gli interessati coinvolti devono essere informati senza ingiustificato ritardo, salvo che si applichi un’eccezione (ad es. presenza di cifratura forte).”
Quell’eccezione deve essere basata su evidenze. Dire “i dati erano cifrati” non è sufficiente. L’organizzazione deve dimostrare che i dati esposti erano illeggibili per soggetti non autorizzati e che le chiavi pertinenti non sono state compromesse.
I fornitori possono determinare il successo o il fallimento delle prime 24 ore
Le terze parti spesso detengono i fatti necessari per la classificazione e la notifica. Un fornitore di servizi cloud può detenere log degli accessi. Un responsabile paghe può sapere quali dipendenti sono stati interessati. Un fornitore di servizi gestiti può aver eseguito la modifica di configurazione. Un sub-responsabile può detenere telemetria forense.
Le clausole sui termini di notifica delle violazioni da parte dei fornitori devono quindi essere progettate prima dell’incidente.
La Politica di sicurezza delle terze parti e dei fornitori Politica di sicurezza delle terze parti e dei fornitori, sezione Requisiti di governance, clausola 5.3.3, include la governance contrattuale su:
“Tempistiche di notifica delle violazioni (ad es. entro 24 o 72 ore, a seconda della criticità e dei requisiti normativi)”
Per le organizzazioni più piccole, la Politica di sicurezza delle terze parti e dei fornitori per PMI Politica di sicurezza delle terze parti e dei fornitori per PMI supporta analogamente le tempistiche di notifica delle violazioni nella governance dei fornitori.
Clarysec raccomanda che i contratti con i fornitori e gli accordi sul trattamento dei dati definiscano:
- Che cosa costituisce una violazione dei dati personali sospetta
- Chi deve essere informato e attraverso quale canale
- Il termine per la notifica iniziale, spesso più breve della scadenza regolamentare del titolare del trattamento
- I fatti minimi richiesti nella prima comunicazione
- La frequenza degli aggiornamenti durante l’indagine
- Gli obblighi di conservazione delle evidenze
- Il flusso degli obblighi di notifica verso i sub-responsabili
- Il supporto per le comunicazioni all’autorità di controllo e agli interessati
- Gli obblighi di azione correttiva post-incidente
Se gli accordi con i fornitori utilizzano formule vaghe come “non appena ragionevolmente possibile”, il termine GDPR del titolare del trattamento può dipendere dal dibattito interno di un’altra organizzazione. Non è un modello operativo difendibile.
Le evidenze trasformano la risposta in conformità difendibile
Durante l’incidente di Maria, il team ha bisogno di log di autenticazione, registrazioni delle query al database, evidenze di phishing, modifiche al controllo degli accessi, elenchi dei clienti interessati, azioni di contenimento, parere del DPO e bozze di comunicazione. Nello scenario del portale SaaS B2B, il team potrebbe avere bisogno di screenshot, autorizzazioni dello storage a oggetti, ID dei ticket di supporto, modifiche IAM e log degli accessi cross-tenant.
Le evidenze devono essere preservate correttamente. Screenshot isolati, esportazioni di chat e cartelle personali non sono sufficienti.
Il Zenith Blueprint, fase Controls in Action, Step 23, tratta il controllo ISO/IEC 27002:2022 5.28, Collection of evidence:
“Quando si verifica un incidente di sicurezza delle informazioni, uno degli elementi più critici, e spesso trascurati, della risposta è costituito dalle evidenze. Non log, non screenshot, non narrazioni sparse, ma evidenze correttamente preservate, rispettose della catena di custodia e resistenti alla manomissione.”
La Politica per la raccolta delle evidenze e l’analisi forense Politica per la raccolta delle evidenze e l’analisi forense, sezione Requisiti di governance, clausola 5.5, stabilisce:
“Tutte le evidenze raccolte devono essere identificate univocamente, etichettate e archiviate in un repository sicuro con:”
La Politica di gestione degli incidenti e delle violazioni dei dati personali, sezione Evidenze, tenuta delle registrazioni e riservatezza, clausola 4.5.1, collega tali evidenze alla registrazione PIMS:
“[Entrambi] Il Coordinatore della risposta agli incidenti DEVE mantenere una registrazione REG10 completa per ogni incidente relativo ai dati personali sospetto o confermato, dall’acquisizione iniziale alla chiusura, includendo fatti, tempistiche, classificazione, valutazione, azioni, decisioni, notifiche, riferimenti alle evidenze e stato di chiusura.”
REG10 diventa la fonte unica di verità per l’incidente. REG08 acquisisce le notifiche ai clienti o ai titolari del trattamento, ove applicabile. Insieme, consentono ai team di sicurezza, privacy, legale e audit di lavorare su un unico asse delle evidenze.
| Campo REG10 | Esempio di voce |
|---|---|
| ID incidente | PII-2026-034 |
| Momento della presa di conoscenza | 2026-06-23 02:13 UTC, allerta SOC confermata |
| Ruolo nel trattamento | Titolare del trattamento per abbonati diretti, responsabile del trattamento per set di dati dei clienti enterprise |
| Dati personali coinvolti | Nomi, e-mail aziendali, cronologie delle transazioni, numeri di identificazione nazionale |
| Classificazione iniziale | Incidente di sicurezza confermato con sospetta violazione dei dati personali |
| Contenimento | Credenziali dello sviluppatore revocate, sessioni terminate, accesso al database interessato limitato |
| Valutazione del rischio | Accesso a identificativi non pubblici; il rischio di frode d’identità non può essere escluso |
| Decisione di notifica | Notifica all’autorità di controllo approvata per i dati trattati come titolare; clienti enterprise notificati in qualità di titolari del trattamento |
| Riferimenti alle evidenze | Log di autenticazione E-034-01, esportazione query E-034-02, artifact di phishing E-034-03 |
| Chiusura | Causa radice corretta, controlli MFA rafforzati, formazione sul phishing aggiornata, follow-up con i clienti completato |
Lo scopo non è creare burocrazia. È evitare che l’organizzazione debba ricostruire i ricordi da messaggi Slack dispersi dopo la chiamata dell’autorità di controllo.
Mappare la risposta PIMS ISO 27701 su ISO 27001 e ISO 27002
Un processo maturo di gestione delle violazioni dei dati personali si colloca all’intersezione tra governance della privacy e gestione della sicurezza delle informazioni.
Le clausole da 4.1 a 4.4 di ISO/IEC 27001:2022 richiedono alle organizzazioni di comprendere il contesto, le parti interessate, il campo di applicazione del SGSI e i processi del sistema di gestione. Per la gestione delle violazioni dei dati personali, ciò significa che il processo deve riflettere obblighi normativi, contratti con i clienti, ruoli nel trattamento, dipendenze dai fornitori e obblighi settoriali prima che si verifichi un incidente.
Il Zenith Controls: The Cross-Compliance Guide Zenith Controls aiuta a mappare i controlli sugli incidenti in un modello di assurance più ampio. I controlli ISO/IEC 27002:2022 più rilevanti sono:
| Controllo ISO/IEC 27002:2022 | Trattamento in Zenith Controls | Perché è rilevante per la gestione delle violazioni dei dati personali |
|---|---|---|
| 5.24 Pianificazione e preparazione della gestione degli incidenti di sicurezza delle informazioni | Controllo correttivo, Respond and Recover, governance e gestione degli eventi di sicurezza delle informazioni | Definisce piani, ruoli, percorsi di escalation, modelli di comunicazione e preparazione alle violazioni privacy |
| 5.25 Valutazione e decisione sugli eventi di sicurezza delle informazioni | Controllo di rilevamento, Detect and Respond, gestione degli eventi di sicurezza delle informazioni | Crea il punto decisionale strutturato per classificare incidenti privacy e violazioni dei dati personali sospette |
| 5.26 Risposta agli incidenti di sicurezza delle informazioni | Controllo correttivo, Respond and Recover, gestione degli eventi di sicurezza delle informazioni | Attiva contenimento, coordinamento, supporto alla notifica, ripristino e comunicazione agli stakeholder |
| 5.28 Raccolta delle evidenze | Preservazione delle evidenze e affidabilità investigativa lungo il ciclo di vita dell’incidente | Supporta accountability GDPR, qualità forense, risposte alle autorità di controllo e difendibilità in audit |
| 6.8 Segnalazione degli eventi di sicurezza delle informazioni | Canale di segnalazione guidato dalle persone e formazione di sensibilizzazione | Garantisce che incidenti sospetti relativi ai dati personali siano segnalati rapidamente da dipendenti, contraenti e stakeholder |
ISO/IEC 27035 supporta una gestione strutturata degli incidenti. ISO/IEC 27037 supporta la gestione delle evidenze digitali. ISO/IEC 29134 può supportare la logica di valutazione d’impatto sulla privacy quando la remediation della violazione evidenzia la necessità di un riesame DPIA più approfondito. ISO/IEC 27701:2025 porta quindi nel sistema di gestione il contesto del ruolo privacy, l’impatto sugli interessati, gli obblighi del titolare e del responsabile del trattamento e i requisiti PIMS sulle evidenze.
Un incidente, molte prospettive regolamentari
L’incidente di Maria non è solo una questione GDPR. Poiché la società fornisce servizi cloud a clienti del settore finanziario, possono applicarsi anche NIS2 e DORA. I contratti con i clienti possono imporre una notifica entro 24 ore. L’assicurazione cyber può richiedere una comunicazione rapida. La governance interna può richiedere informativa al consiglio di amministrazione.
Creare narrazioni separate per ogni quadro di riferimento genera rischio di contraddizione. Il metodo Clarysec consiste nel mantenere un unico asse delle evidenze e produrre da esso output specifici per ciascun quadro di riferimento.
| Quadro di riferimento o normativa | Prospettiva sull’incidente | Output dell’asse delle evidenze Clarysec |
|---|---|---|
| GDPR | Violazione dei dati personali, rischio per le persone fisiche, notifica all’autorità di controllo, comunicazione agli interessati | Registrazione decisionale REG10, parere del DPO, motivazione relativa agli Article 33 e 34, evidenze di comunicazione |
| ISO/IEC 27701:2025 | Governance PIMS, obblighi del titolare e del responsabile del trattamento, rischio per l’interessato, evidenze privacy | Classificazione dell’incidente relativo ai dati personali, valutazione del ruolo, REG08 e REG10, azioni correttive |
| ISO/IEC 27001:2022 | Contesto SGSI, parti interessate, processo di risposta agli incidenti, miglioramento continuo | Registrazione dell’incidente, aggiornamenti al trattamento del rischio, input per il riesame della direzione, evidenze di efficacia dei controlli |
| NIS2 | Gestione degli incidenti significativi, segnalazione per fasi, misure di sicurezza baseline multirischio | Evidenze del preallarme entro 24 ore, pacchetto di notifica dell’incidente entro 72 ore, supporto al rapporto finale entro un mese |
| DORA | Gestione degli incidenti connessi alle ICT per le entità finanziarie e resilienza operativa digitale | Fatti sull’impatto ICT, dipendenze da terze parti, feedback dei test di resilienza, supporto alla segnalazione degli incidenti |
| NIST CSF 2.0 | Current Profile e Target Profile, piano d’azione prioritizzato, comunicazione del rischio | Aggiornamenti delle lacune, miglioramenti target, narrazione del rischio per il consiglio di amministrazione |
| COBIT 2019 | Governance, obiettivi di gestione, accountability, prestazione del controllo | RACI, registri decisionali, metriche di processo, tracciamento delle azioni correttive |
NIS2 Article 21 stabilisce misure di gestione dei rischi di cibersicurezza, incluse gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, valutazione dell’efficacia, igiene cyber, crittografia, controllo degli accessi, gestione degli asset, MFA e comunicazioni sicure. NIS2 Article 23 introduce una segnalazione per fasi degli incidenti significativi, incluso il preallarme entro 24 ore, la notifica dell’incidente entro 72 ore, gli aggiornamenti su richiesta e un rapporto finale non oltre un mese dalla notifica dell’incidente.
DORA si applica dal 17 gennaio 2025 e stabilisce requisiti uniformi per la gestione del rischio ICT, la segnalazione degli incidenti connessi alle ICT, i test di resilienza operativa digitale, la condivisione delle informazioni e la gestione del rischio ICT di terze parti per le entità finanziarie. Per un fornitore FinTech, un singolo incidente può quindi essere una violazione GDPR, un incidente significativo NIS2, un evento ICT rilevante ai fini DORA per i clienti e un evento soggetto a notifica contrattuale.
Come gli auditor testeranno il ciclo di vita
Gli auditor raramente si fermano a “mostratemi la vostra politica di risposta agli incidenti”. Verificano se il ciclo di vita funziona sotto pressione probatoria.
Un auditor ISO/IEC 27701:2025 o ISO/IEC 27001:2022 chiederà come gli incidenti privacy entrano nel SGSI e nel PIMS, chi classifica gli eventi, come si differenziano gli obblighi del titolare e del responsabile del trattamento e in che modo gli incidenti generano azioni correttive.
Un auditor GDPR o un’autorità di controllo si concentrerà sul momento della presa di conoscenza, sul rischio per le persone fisiche, sul coinvolgimento del DPO, sulla motivazione della notifica, sulla comunicazione agli interessati e sull’accountability. Potrà campionare incidenti non notificati per verificare se la motivazione della mancata notifica è stata documentata.
Un riesame NIS2 o DORA esaminerà le soglie degli incidenti significativi, la segnalazione per fasi, l’impatto ICT, le dipendenze da terze parti, le implicazioni di resilienza e l’allineamento della segnalazione ai requisiti dell’autorità competente o dei clienti.
Un valutatore NIST CSF 2.0 chiederà se l’incidente ha modificato il Current Profile e il Target Profile dell’organizzazione. Un reviewer COBIT 2019 si concentrerà su governance, accountability, titolarità del processo, metriche e tracciamento delle azioni correttive.
Un solido pacchetto di evidenze di audit deve includere:
| Elemento di evidenza | Perché gli auditor lo richiedono |
|---|---|
| Registrazione dell’incidente REG10 | Dimostra acquisizione iniziale, tempistica, classificazione, valutazione, decisioni, notifiche e chiusura |
| Registrazione REG08 di notifica al cliente o al titolare del trattamento | Dimostra le comunicazioni del responsabile del trattamento e la cronologia degli aggiornamenti al cliente |
| Segnalazione o allerta originale | Stabilisce come l’incidente è stato rilevato e quando è iniziata la presa di conoscenza |
| Cronologia delle azioni chiave | Mostra contenimento, valutazione, approvazioni e decisioni di notifica |
| Valutazione del ruolo nel trattamento | Dimostra la separazione degli obblighi di titolare e responsabile del trattamento |
| Categorie di dati personali e interessati coinvolti | Supporta la valutazione del rischio e il perimetro della notifica |
| Raccomandazione del DPO o del Consulente privacy | Dimostra il parere privacy responsabile prima della decisione esterna |
| Motivazione della notifica o della mancata notifica | Supporta l’accountability relativa al GDPR Article 33 e 34 |
| Indice del repository delle evidenze | Dimostra integrità delle evidenze e disciplina della catena di custodia |
| Causa radice e piano di azioni correttive | Mostra miglioramento continuo e riesame dell’efficacia dei controlli |
È qui che Zenith Controls ha valore commerciale e operativo. Aiuta a mappare le stesse evidenze sui controlli ISO/IEC 27002:2022 relativi agli incidenti, sull’accountability GDPR, sulla gestione degli incidenti NIS2, sulle aspettative di resilienza DORA, sulla comunicazione NIST CSF e sulla governance COBIT, senza ricostruire ogni volta la narrativa di audit.
Un ritmo operativo per le prime 24 ore
Un playbook realistico per le violazioni dei dati personali deve risultare pratico, non teorico. Si consideri un’esposizione cross-tenant SaaS segnalata da un cliente alle 08:12.
Alle 08:12, il team customer success riceve la segnalazione e segue il comportamento di segnalazione previsto dal Zenith Blueprint Step 16. Il ticket viene etichettato come incidente sospetto relativo ai dati personali.
Alle 08:25, il Coordinatore della risposta agli incidenti apre REG10. La registrazione include il momento della presa di conoscenza, il segnalante, il sistema, le tipologie di dati sospette e il responsabile.
Alle 09:02, il team engineering annulla la modifica delle autorizzazioni. I log vengono esportati prima della rotazione. Il responsabile delle evidenze etichetta la segnalazione del cliente, la modifica IAM, l’esportazione dei log degli accessi e la conferma del contenimento nel repository sicuro.
Alle 10:30, il Responsabile privacy determina che l’organizzazione agisce come responsabile del trattamento per gli allegati del supporto clienti. Ai sensi della Politica di gestione degli incidenti e delle violazioni dei dati personali, clausola 4.4.4, i clienti titolari del trattamento interessati devono essere informati senza ingiustificato ritardo ed entro i termini contrattuali. REG08 viene aperto.
Alle 12:00, il DPO valuta il rischio per gli interessati. I dati sembrano limitati, ma alcuni allegati possono includere nomi di dipendenti e ID interni. Il DPO registra in REG10 la motivazione del rischio e la raccomandazione.
Alle 15:00, i clienti titolari del trattamento interessati ricevono la comunicazione iniziale: che cosa è accaduto, quando è stato rilevato, che cosa è stato contenuto, quali dati personali possono essere coinvolti, che cosa è ancora in analisi e quando arriverà il prossimo aggiornamento.
Alle 18:00, la direzione riceve un breve briefing: notifiche ai clienti inviate, decisioni sulla notifica all’autorità di controllo di competenza dei titolari per i dati personali dei clienti, trattamento interno come titolare ancora in valutazione, evidenze preservate e analisi della causa radice in corso.
Questo ritmo evita i fallimenti più comuni nella gestione delle violazioni: scadenze mancate, ruoli confusi, pareri non documentati e comunicazioni non controllate.
Schemi di errore comuni da eliminare prima della prossima allerta
I fallimenti più dannosi nella gestione delle violazioni privacy raramente dipendono da un singolo documento mancante. Derivano da disallineamenti tra sicurezza, privacy, funzione legale, fornitori e titolari dell’attività.
Clarysec osserva frequentemente questi schemi:
- Esistono piani di risposta agli incidenti, ma manca la classificazione delle violazioni dei dati personali.
- La notifica GDPR entro 72 ore è menzionata, ma le scadenze interne non sono più brevi della scadenza legale.
- L’escalation del responsabile del trattamento è ritardata perché i team attendono l’analisi completa della causa radice.
- I contratti con i fornitori non richiedono una notifica rapida delle violazioni né supporto alle evidenze.
- Il parere del DPO è verbale e non viene mai inserito nel registro delle violazioni.
- La comunicazione agli interessati in caso di rischio elevato viene presa in considerazione troppo tardi.
- Le evidenze sono archiviate in cartelle personali, thread di chat o commenti nei ticket.
- Le decisioni di mancata notifica non sono documentate.
- Le lezioni apprese non aggiornano controlli, formazione, clausole dei fornitori o piani di trattamento del rischio.
Il Zenith Blueprint, Step 23, sintetizza perché la struttura è necessaria:
“Una risposta agli incidenti senza struttura diventa una corsa disordinata. Le e-mail si moltiplicano, vengono convocate riunioni e le decisioni sono prese in modo emotivo o incoerente. Ma un SGSI maturo trasforma la risposta in disciplina.”
Questa disciplina è lo scopo della gestione delle violazioni dei dati personali secondo ISO/IEC 27701:2025.
Costruire il ciclo di vita Clarysec per le violazioni dei dati personali
L’approccio Clarysec combina tre livelli.
Primo, Zenith Blueprint fornisce la roadmap di attuazione. Lo Step 16 assicura che le persone riconoscano e segnalino gli incidenti sospetti. Lo Step 23 rende operativi valutazione, decisione, risposta e raccolta delle evidenze attraverso i controlli ISO/IEC 27002:2022 5.25, 5.26 e 5.28.
Secondo, l’insieme delle politiche definisce autorità e obblighi. Le politiche per PMI rendono pratici, per le organizzazioni più piccole, la segnalazione, la presa di conoscenza entro il termine di 72 ore e i registri degli incidenti. Le politiche enterprise assegnano la guida al DPO, le soglie di violazione, la comunicazione agli interessati, i termini di notifica dei fornitori, la gestione delle evidenze e la governance forense. La Politica di gestione degli incidenti e delle violazioni dei dati personali specifica per il PIMS aggiunge obblighi del titolare e del responsabile del trattamento basati sui ruoli, REG08, REG10, motivazione della notifica ed evidenze di chiusura.
Terzo, Zenith Controls agisce come bussola di mappatura trasversale della conformità. Mappa pianificazione degli incidenti, valutazione, risposta ed evidenze in una vista integrata tra ISO/IEC 27002:2022, GDPR, NIS2, DORA, NIST CSF 2.0 e aspettative di assurance in stile COBIT.
Per i CISO, questo riduce la confusione operativa. Per i DPO, crea una traccia decisionale privacy difendibile. Per i responsabili della conformità, collega una singola registrazione di incidente a molteplici output regolamentari. Per gli auditor, crea evidenze tracciabili. Per i dirigenti, riduce la probabilità che un incidente privacy gestibile diventi una crisi regolamentare e reputazionale.
Il prossimo passo
Non attendere l’allerta delle 2:00 per scoprire se il tuo processo di gestione delle violazioni dei dati personali funziona.
Inizia questa settimana con tre azioni:
- Verifica se l’acquisizione iniziale degli incidenti registra esplicitamente gli incidenti sospetti relativi ai dati personali.
- Conferma che gli obblighi del titolare e del responsabile del trattamento in caso di violazione siano separati in politiche, contratti e registri delle evidenze.
- Esegui un’esercitazione tabletop con uno scenario realistico, come credenziali compromesse, esposizione cross-tenant, file paghe inviato al destinatario errato, laptop cifrato smarrito o compromissione di un fornitore.
Clarysec può aiutarti a rendere operativo questo approccio attraverso Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Zenith Controls: The Cross-Compliance Guide Zenith Controls e il set di politiche PIMS ISO/IEC 27701:2025, inclusa la Politica di gestione degli incidenti e delle violazioni dei dati personali Politica di gestione degli incidenti e delle violazioni dei dati personali, la Politica di protezione dei dati e privacy Politica di protezione dei dati e privacy, la Politica di risposta agli incidenti per PMI Politica di risposta agli incidenti per PMI, la Politica di sicurezza delle terze parti e dei fornitori Politica di sicurezza delle terze parti e dei fornitori e la Politica per la raccolta delle evidenze e l’analisi forense Politica per la raccolta delle evidenze e l’analisi forense.
Scarica il toolkit PIMS di Clarysec, prenota una valutazione della preparazione alla gestione delle violazioni o pianifica una demo per trasformare la tua risposta GDPR entro 72 ore da una corsa disordinata a un processo disciplinato e idoneo all’audit.
Ottieni la certificazione PECB ISO/IEC 27701 e avvia il tuo PIMS
- ✓ Materiale didattico ufficiale PECB e due tentativi d'esame
- ✓ Quota di certificazione e AMF del primo anno incluse, ove applicabile
- ✓ In autoapprendimento o dal vivo online · corso assegnato entro 1 giorno lavorativo
Frequently Asked Questions
L'autore
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
