Evidenze sulle TOM dell’Articolo 32 GDPR con ISO, NIS2 e DORA
L’e-mail arriva nella casella di posta del CISO con il peso familiare di un’opportunità commerciale che potrebbe cambiare il trimestre dell’azienda.
Un importante potenziale cliente enterprise chiede evidenze delle “misure tecniche e organizzative dell’Articolo 32 GDPR, mappate a ISO 27001:2022, NIS2 e DORA ove applicabile”. Allo stesso tempo, la funzione legale ha aggiornato il consiglio di amministrazione sulla responsabilità degli organi di gestione prevista da NIS2 e sulle aspettative di resilienza operativa di DORA. L’indicazione del consiglio sembra semplice: dimostrare la conformità, evitare duplicazioni e non trasformare il lavoro in tre progetti separati.
L’azienda dispone di controlli. L’MFA è abilitata. I backup vengono eseguiti. Gli sviluppatori riesaminano il codice. Il team privacy mantiene il registro delle attività di trattamento. Il team infrastruttura esegue scansioni delle vulnerabilità. I fornitori sono riesaminati durante il processo di approvvigionamento. Ma quando il potenziale cliente chiede evidenze, la risposta si frammenta.
Il report del provider di identità si trova in un punto. I log dei backup in un altro. Il Registro dei rischi non è stato aggiornato dall’ultimo rilascio del prodotto. Le evidenze di sicurezza dei fornitori sono disperse nelle e-mail dell’ufficio acquisti. Le note delle esercitazioni tabletop di risposta agli incidenti esistono, ma nessuno può dimostrare che le lezioni apprese siano state reinserite nel trattamento del rischio. Il consiglio di amministrazione ha approvato la spesa per la sicurezza, ma l’approvazione non è collegata a un rischio ICT o a una decisione documentata sui controlli.
Questo è il vero problema delle misure tecniche e organizzative dell’Articolo 32 GDPR, comunemente chiamate TOM. La maggior parte delle organizzazioni non fallisce perché non ha controlli. Fallisce perché non riesce a dimostrare che i controlli sono basati sul rischio, approvati, implementati, monitorati e migliorati.
Il principio di accountability del GDPR rende esplicita questa aspettativa. L’Articolo 5 GDPR richiede che i dati personali siano protetti mediante misure di sicurezza adeguate contro trattamenti non autorizzati o illeciti e contro perdita, distruzione o danno accidentali. L’Articolo 5(2) rende il titolare del trattamento responsabile di dimostrare la conformità. Anche le definizioni del GDPR sono rilevanti. Il concetto di dati personali è ampio, il trattamento copre quasi ogni operazione sui dati, la pseudonimizzazione è una misura di sicurezza riconosciuta e una violazione dei dati personali comprende distruzione, perdita, modifica, divulgazione non autorizzata o accesso accidentali o illeciti.
Un file di evidenze per l’Articolo 32 non può quindi essere una cartella di screenshot casuali. Deve essere un sistema di controllo vivo.
L’approccio di Clarysec consiste nel trasformare le TOM dell’Articolo 32 GDPR in un motore di evidenze tracciabile costruito su ISO/IEC 27001:2022 ISO/IEC 27001:2022, rafforzato dalla gestione del rischio ISO/IEC 27005:2022 e collegato agli obblighi NIS2 e DORA quando applicabili. L’obiettivo non è produrre documentazione fine a sé stessa. L’obiettivo è rendere l’organizzazione pronta per l’audit prima che un cliente, un auditor, un’autorità di regolamentazione o un membro del consiglio ponga la domanda difficile.
Perché le TOM dell’Articolo 32 GDPR falliscono nella pratica
L’Articolo 32 è spesso frainteso come un elenco di strumenti di sicurezza: cifratura, backup, registrazione degli eventi, controllo degli accessi e risposta agli incidenti. Queste misure sono importanti, ma sono difendibili solo quando sono adeguate al rischio e collegate al ciclo di vita dei dati personali.
Per una società SaaS che tratta dati dei dipendenti dei clienti, “usiamo la cifratura” non è sufficiente. Un auditor può chiedere quali dati sono protetti dalla cifratura, dove la cifratura è richiesta, come sono gestite le chiavi, se i backup sono cifrati, se i dati di produzione sono mascherati nei test, chi può aggirare i controlli e come vengono approvate le eccezioni.
La Politica di protezione dei dati e privacy enterprise di Clarysec esprime il principio operativo:
“Implementare misure tecniche e organizzative (TOM) che proteggano la riservatezza, l’integrità e la disponibilità delle informazioni personali identificabili (PII) lungo tutto il loro ciclo di vita.”
Fonte: Politica di protezione dei dati e privacy, Obiettivi, clausola di policy 3.3. Politica di protezione dei dati e privacy
L’espressione “lungo tutto il loro ciclo di vita” è il punto in cui molti programmi TOM si indeboliscono. I dati personali possono essere protetti in produzione, ma copiati in sistemi di analisi, log, esportazioni di supporto, ambienti di test, backup, piattaforme dei fornitori e dispositivi dei dipendenti. Ogni ubicazione crea rischi per la sicurezza e la privacy.
L’Articolo 6 GDPR richiede una base giuridica per il trattamento, inclusi consenso, contratto, obbligo legale, interessi vitali, compito di interesse pubblico o legittimi interessi. Quando i dati sono riutilizzati per una finalità ulteriore, devono essere considerate compatibilità e misure di sicurezza quali cifratura o pseudonimizzazione. Per i dati a rischio più elevato, l’onere probatorio aumenta. L’Articolo 9 GDPR pone limiti rigorosi alle categorie particolari di dati personali, come dati sanitari, dati biometrici utilizzati per l’identificazione e altre informazioni sensibili. L’Articolo 10 limita il trattamento dei dati relativi a condanne penali e reati.
Per le PMI, Clarysec esprime il trattamento del rischio in termini pratici:
“Devono essere implementati controlli per ridurre i rischi identificati, inclusi cifratura, anonimizzazione, smaltimento sicuro e restrizioni di accesso.”
Fonte: Politica di protezione dei dati e privacy - PMI, Trattamento del rischio ed eccezioni, clausola di policy 7.2.1. Politica di protezione dei dati e privacy - PMI
Questa è una solida baseline per le TOM. Per diventare pronta per l’audit, ogni controllo deve inoltre essere collegato a un rischio, a un proprietario, a un requisito di policy, a un elemento di evidenza e a una cadenza di riesame.
ISO 27001:2022 è la spina dorsale delle evidenze per l’Articolo 32
ISO 27001:2022 funziona bene per l’Articolo 32 GDPR perché tratta la sicurezza come un sistema di gestione, non come una checklist di controlli scollegati. Richiede un Sistema di gestione della sicurezza delle informazioni, o SGSI, progettato per preservare riservatezza, integrità e disponibilità attraverso la gestione del rischio.
Il primo passaggio critico è il campo di applicazione. Le clausole 4.1-4.4 di ISO 27001:2022 richiedono all’organizzazione di comprendere i fattori interni ed esterni, identificare le parti interessate e i requisiti, determinare quali requisiti saranno affrontati dal SGSI e definire il campo di applicazione del SGSI, incluse interfacce e dipendenze con organizzazioni esterne. Per le TOM dell’Articolo 32, il campo di applicazione del SGSI dovrebbe riflettere il trattamento dei dati personali, gli obblighi verso i clienti, responsabili del trattamento, sub-responsabili, piattaforme cloud, lavoro da remoto, funzioni di supporto e ambienti di prodotto.
Il secondo passaggio è la leadership. Le clausole 5.1-5.3 richiedono l’impegno dell’alta direzione, una Politica per la sicurezza delle informazioni, risorse, ruoli e responsabilità, e reportistica sulle prestazioni. Questo è rilevante perché GDPR Articolo 32, NIS2 e DORA si basano tutti sulla governance. Un controllo privo di titolarità, finanziamento o riesame costituisce un’evidenza debole.
La Politica per la sicurezza delle informazioni enterprise di Clarysec lo rende esplicito:
“Il SGSI deve includere confini del campo di applicazione definiti, una metodologia di valutazione del rischio, obiettivi misurabili e controlli documentati giustificati nella Dichiarazione di Applicabilità (SoA).”
Fonte: Politica per la sicurezza delle informazioni, Requisiti di applicazione della policy, clausola di policy 6.1.2. Politica per la sicurezza delle informazioni
La stessa policy stabilisce l’aspettativa in materia di evidenze:
“Tutti i controlli implementati devono essere verificabili, supportati da procedure documentate e da evidenze conservate del loro funzionamento.”
Fonte: Politica per la sicurezza delle informazioni, Requisiti di applicazione della policy, clausola di policy 6.6.1.
Le clausole 6.1.1-6.1.3 di ISO 27001:2022 richiedono quindi valutazione del rischio, trattamento del rischio, Dichiarazione di Applicabilità, approvazione del rischio residuo e accountability del Proprietario del rischio. La clausola 6.2 richiede obiettivi misurabili. Le clausole 7.5, 9.1, 9.2, 9.3 e 10.2 richiedono informazioni documentate, monitoraggio, audit interno, riesame della direzione e azione correttiva.
Per l’Articolo 32 GDPR, questo crea una struttura difendibile.
| Domanda sulle evidenze dell’Articolo 32 GDPR | Risposta basata sulle evidenze ISO 27001:2022 |
|---|---|
| Come avete deciso quali TOM sono adeguate? | Criteri di valutazione del rischio, Registro dei rischi, punteggio di probabilità e impatto, Piano di trattamento del rischio |
| Quali controlli si applicano e perché? | Dichiarazione di Applicabilità con giustificazioni di inclusione ed esclusione |
| Chi ha approvato il rischio residuo? | Approvazione del Proprietario del rischio e approvazione formale della direzione |
| I controlli sono operativi? | Log, ticket, registrazioni dei riesami, risultati dei test, report di monitoraggio |
| I controlli sono riesaminati? | Report di audit interno, verbali del riesame della direzione, registro delle azioni correttive |
| I rischi relativi ai dati personali sono considerati? | Voci di rischio sulla protezione dei dati, requisiti privacy nel campo di applicazione, DPIA o valutazione equivalente ove applicabile |
ISO/IEC 27005:2022 rafforza questa struttura. Raccomanda alle organizzazioni di identificare i requisiti derivanti dall’Allegato A di ISO 27001:2022, da regolamenti, contratti, standard di settore, regole interne e controlli esistenti, per poi inserirli nella valutazione e nel trattamento del rischio. Richiede inoltre criteri di rischio e criteri di accettazione che considerino fattori legali, normativi, operativi, relativi ai fornitori, tecnologici e umani, inclusa la privacy.
La Politica di gestione del rischio di Clarysec è direttamente allineata:
“Deve essere mantenuto un processo formale di gestione del rischio in conformità a ISO/IEC 27005 e ISO 31000, che copra identificazione, analisi, valutazione, trattamento, monitoraggio e comunicazione del rischio.”
Fonte: Politica di gestione del rischio, Requisiti di governance, clausola di policy 5.1. Politica di gestione del rischio
Per le PMI, lo stesso requisito diventa semplice e azionabile:
“Ogni voce di rischio deve includere: descrizione, probabilità, impatto, punteggio, proprietario e piano di trattamento.”
Fonte: Politica di gestione del rischio - PMI, Requisiti di governance, clausola di policy 5.1.2. Politica di gestione del rischio - PMI
Questa frase è un rapido test di preparazione agli audit. Se un rischio non ha proprietario o piano di trattamento, non è ancora pronto come evidenza.
Il ponte Clarysec: rischio, SoA, controlli e normative
Zenith Blueprint: An Auditor’s 30-Step Roadmap di Clarysec Zenith Blueprint tratta la conformità come un lavoro di tracciabilità. Nella fase di gestione del rischio, il Passaggio 13 si concentra sulla pianificazione del trattamento del rischio e sulla Dichiarazione di Applicabilità. Spiega che le organizzazioni dovrebbero mappare i controlli ai rischi, aggiungere riferimenti ai controlli dell’Allegato A nelle voci di trattamento del rischio, creare riferimenti incrociati alle normative esterne e ottenere l’approvazione della direzione.
Il Zenith Blueprint è diretto sul ruolo della SoA:
“La SoA è di fatto un documento ponte: collega la valutazione/il trattamento del rischio ai controlli effettivamente presenti. Completandola, si verifica anche se sono stati omessi controlli.”
Fonte: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fase di gestione del rischio, Passaggio 13: Pianificazione del trattamento del rischio e Dichiarazione di Applicabilità (SoA). Zenith Blueprint
Il Passaggio 14 del Zenith Blueprint aggiunge il livello dei riferimenti incrociati normativi. Raccomanda alle organizzazioni di documentare come i requisiti GDPR, NIS2 e DORA siano coperti da policy e controlli. Per il GDPR, enfatizza la protezione dei dati personali nelle valutazioni e nei trattamenti del rischio, inclusa la cifratura come misura tecnica e la risposta alle violazioni come parte dell’ambiente di controllo. Per NIS2, evidenzia valutazione del rischio, sicurezza della rete, controllo degli accessi, gestione degli incidenti e continuità operativa. Per DORA, richiama gestione del rischio ICT, risposta agli incidenti, segnalazione e vigilanza sulle terze parti ICT.
Questo è il nucleo del metodo Clarysec: un solo SGSI, un solo Registro dei rischi, una sola SoA, una sola libreria di evidenze, più esiti di conformità.
Zenith Controls: The Cross-Compliance Guide Zenith Controls supporta questo approccio aiutando le organizzazioni a utilizzare i temi di controllo ISO/IEC 27002:2022 ISO/IEC 27002:2022 come ancoraggi di conformità trasversale. Per l’Articolo 32 GDPR, gli ancoraggi più importanti includono spesso Privacy and Protection of PII, controllo 5.34; Independent Review of Information Security, controllo 5.35; e Use of Cryptography, controllo 8.24.
| Ancoraggio di controllo ISO/IEC 27002:2022 in Zenith Controls | Perché è rilevante per le TOM dell’Articolo 32 | Esempi di evidenze |
|---|---|---|
| 5.34 Privacy and Protection of PII | Collega i controlli di sicurezza delle informazioni alla gestione dei dati personali e agli obblighi privacy | Inventario dei dati, valutazione del rischio privacy, piano di conservazione, registrazioni DPA, riesami degli accessi |
| 5.35 Independent Review of Information Security | Dimostra assurance oggettiva, verificabilità e miglioramento | Report di audit interno, valutazione esterna, registro delle azioni correttive, riesame della direzione |
| 8.24 Use of Cryptography | Protegge riservatezza e integrità dei dati in transito, a riposo e nei backup | Standard di cifratura, registrazioni di gestione delle chiavi, evidenze di cifratura del disco, configurazione TLS, cifratura dei backup |
NIS2 trasforma le TOM in un tema di cibersicurezza a livello di consiglio di amministrazione
Molte organizzazioni trattano le TOM GDPR come responsabilità del team privacy. NIS2 cambia la conversazione.
NIS2 si applica a molte entità medie e grandi nei settori elencati e, in alcuni casi, indipendentemente dalle dimensioni. I settori digitali e tecnologici coperti includono fornitori di servizi di cloud computing, fornitori di data center, reti di distribuzione dei contenuti, prestatori di servizi DNS, registri dei nomi di dominio di primo livello, prestatori di servizi fiduciari, fornitori di reti pubbliche di comunicazione elettronica, fornitori di servizi gestiti, fornitori di servizi di sicurezza gestiti, mercati online, motori di ricerca e piattaforme di social networking. L’applicabilità a SaaS e PMI tecnologiche dipende da settore, dimensione, designazione dello Stato membro e impatto sistemico o transfrontaliero.
L’Articolo 20 NIS2 attribuisce la responsabilità della cibersicurezza agli organi di gestione. Essi devono approvare le misure di gestione dei rischi di cibersicurezza, sorvegliarne l’attuazione e seguire una formazione. Le entità essenziali possono essere soggette a sanzioni amministrative pecuniarie pari ad almeno EUR 10 milioni o almeno al 2 percento del fatturato annuo mondiale. Le entità importanti possono essere soggette a sanzioni pari ad almeno EUR 7 milioni o almeno all’1,4 percento.
L’Articolo 21 NIS2 è direttamente pertinente alle TOM dell’Articolo 32 perché richiede misure tecniche, operative e organizzative adeguate e proporzionate. Tali misure devono considerare stato dell’arte, norme europee e internazionali, costi, esposizione, dimensioni, probabilità, gravità e impatto sociale o economico. Le aree richieste includono analisi dei rischi, policy di sicurezza, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, acquisizione e sviluppo sicuri, gestione delle vulnerabilità, valutazione dell’efficacia, igiene informatica, formazione, crittografia, sicurezza delle risorse umane, controllo degli accessi, gestione degli asset, MFA o autenticazione continua e comunicazioni sicure ove opportuno.
L’Articolo 23 NIS2 aggiunge la segnalazione degli incidenti per fasi: preallarme entro 24 ore, notifica dell’incidente entro 72 ore, aggiornamenti intermedi ove richiesti e rapporto finale non oltre un mese dalla notifica delle 72 ore. Se una violazione dei dati personali si qualifica anche come incidente significativo ai sensi di NIS2, il file di evidenze deve supportare sia le decisioni di segnalazione privacy sia quelle di cibersicurezza.
DORA alza l’asticella per la resilienza finanziaria e i fornitori ICT
DORA si applica dal 17 gennaio 2025 e introduce un corpus di regole per il settore finanziario sulla resilienza operativa digitale. Copre gestione del rischio ICT, segnalazione di incidenti rilevanti connessi all’ICT, test di resilienza operativa, condivisione di informazioni su minacce e vulnerabilità informatiche, rischio ICT di terze parti, requisiti contrattuali per fornitori ICT, vigilanza sui prestatori terzi critici di servizi ICT e supervisione.
Per le entità finanziarie identificate anche ai sensi delle norme nazionali NIS2, DORA opera come atto giuridico settoriale dell’Unione per gli obblighi sovrapposti di gestione dei rischi di cibersicurezza e segnalazione degli incidenti. In pratica, le entità finanziarie coperte dovrebbero dare priorità a DORA per tali aree sovrapposte, mantenendo il coordinamento con le autorità competenti NIS2 e i CSIRT ove pertinente.
Per le evidenze relative all’Articolo 32 GDPR, DORA rileva in due modi. Primo, le imprese fintech possono rientrare direttamente nell’ambito come entità finanziarie, incluse banche, istituti di pagamento, prestatori di servizi di informazione sui conti, istituti di moneta elettronica, imprese di investimento, prestatori di servizi per le cripto-attività, sedi di negoziazione e fornitori di servizi di crowdfunding. Secondo, fornitori SaaS, cloud, dati, software e servizi gestiti possono essere trattati dai clienti finanziari come prestatori terzi di servizi ICT perché DORA definisce i servizi ICT in modo ampio.
L’Articolo 5 DORA richiede governance e controlli interni per la gestione del rischio ICT, con l’organo di gestione che definisce, approva, vigila e resta responsabile degli assetti di rischio ICT. L’Articolo 6 richiede un quadro documentato di gestione del rischio ICT, incluse strategie, policy, procedure, protocolli ICT e strumenti per proteggere informazioni e asset ICT. L’Articolo 17 richiede un processo di gestione degli incidenti connessi all’ICT che copra rilevazione, gestione, notifica, registrazione, causa radice, indicatori di preallarme, classificazione, ruoli, comunicazioni, escalation e risposta. L’Articolo 19 richiede che gli incidenti rilevanti connessi all’ICT siano segnalati alle autorità competenti.
Gli Articoli 28 e 30 di DORA trasformano il rischio ICT di terze parti in un dominio di controllo regolamentato. Le entità finanziarie restano responsabili della conformità quando utilizzano servizi ICT. Devono disporre di una strategia per il rischio di terze parti, registri contrattuali, valutazioni di criticità, due diligence, riesame del rischio di concentrazione, diritti di audit e ispezione, trigger di risoluzione, strategie di uscita e disposizioni contrattuali relative a ubicazione dei dati, disponibilità, autenticità, integrità, riservatezza, assistenza sugli incidenti, ripristino, livelli di servizio e cooperazione con le autorità.
Per l’Articolo 32, ciò significa che i fornitori fanno parte del file TOM. Non è possibile dimostrare la sicurezza del trattamento se responsabili del trattamento critici, piattaforme cloud, provider di analytics, strumenti di supporto e fornitori ICT non sono controllati.
Costruire in una settimana evidenze pratiche per l’Articolo 32
Un file di evidenze solido parte da uno scenario di rischio chiaro.
Usare questo esempio: “Accesso non autorizzato ai dati personali dei clienti nell’applicazione di produzione.”
Creare o aggiornare la voce di rischio. Includere descrizione, probabilità, impatto, punteggio, proprietario e piano di trattamento. Assegnare il proprietario al Responsabile dell’ingegneria, al Responsabile della sicurezza o a un ruolo responsabile equivalente. Valutare la probabilità in base al modello di accesso, alla superficie di attacco esposta, alle vulnerabilità note e agli incidenti precedenti. Valutare l’impatto in base a volume dei dati personali, sensibilità, contratti con i clienti, conseguenze GDPR e possibile impatto sul servizio NIS2 o DORA.
Selezionare trattamenti quali MFA per l’accesso privilegiato, controllo degli accessi basato sui ruoli, riesami trimestrali degli accessi, cifratura a riposo, TLS, scansioni di vulnerabilità, registrazione degli eventi, alerting, backup sicuro, procedure di risposta agli incidenti e mascheramento dei dati negli ambienti non di produzione.
Mappare quindi il rischio alla SoA. Aggiungere riferimenti ISO/IEC 27002:2022 quali 5.34 Privacy and Protection of PII, 8.24 Use of Cryptography, 5.15 Access Control, 5.18 Access Rights, 8.13 Information Backup, 8.15 Logging, 8.16 Monitoring Activities, 8.8 Management of Technical Vulnerabilities, 8.25 Secure Development Life Cycle e 8.10 Information Deletion, ove applicabile. Aggiungere note che mostrino come questi controlli supportano l’Articolo 32 GDPR, l’Articolo 21 NIS2 e la gestione del rischio ICT DORA ove pertinente.
Per la mappatura normativa, mantenere accurati i nomi dei controlli ed evitare di forzare false equivalenze.
| Controllo ISO/IEC 27002:2022 | Nome del controllo | Perché incluso | Mappatura normativa |
|---|---|---|---|
| 8.24 | Use of Cryptography | Protegge riservatezza e integrità dei dati personali in transito, a riposo e nei backup | GDPR Art. 32; NIS2 Art. 21(2)(h) |
| 5.20 | Addressing information security within supplier agreements | Assicura che gli obblighi di sicurezza dei fornitori siano definiti contrattualmente e applicabili | Controlli sui responsabili del trattamento GDPR; NIS2 Art. 21(2)(d); DORA Art. 28 e Art. 30 |
| 5.24 | Information security incident management planning and preparation | Stabilisce la preparazione per rilevazione, escalation, valutazione e segnalazione | Accountability delle violazioni GDPR; NIS2 Art. 23; DORA Art. 17 e Art. 19 |
| 8.13 | Information Backup | Supporta disponibilità, ripristino e resilienza dopo interruzioni o perdita di dati | GDPR Art. 32; NIS2 Art. 21(2)(c); aspettative DORA di continuità ICT |
| 8.10 | Information Deletion | Supporta smaltimento sicuro, applicazione della conservazione e minimizzazione dei dati | Limitazione della conservazione GDPR e Art. 32; requisiti contrattuali dei clienti |
Costruire ora la cartella delle evidenze. La Politica di audit e monitoraggio della conformità - PMI di Clarysec fornisce una regola semplice:
“Tutte le evidenze devono essere conservate in una cartella di audit centralizzata.”
Fonte: Politica di audit e monitoraggio della conformità - PMI, Requisiti di applicazione della policy, clausola di policy 6.2.1. Politica di audit e monitoraggio della conformità - PMI
Per questo singolo scenario di rischio, la cartella dovrebbe contenere:
| Elemento di evidenza | Che cosa conservare | Perché è rilevante |
|---|---|---|
| Voce di rischio | Descrizione del rischio, proprietario, punteggio, piano di trattamento e decisione sul rischio residuo | Dimostra la selezione delle TOM basata sul rischio |
| Estratto SoA | Controlli applicabili e note GDPR, NIS2, DORA | Mostra la tracciabilità dal rischio al controllo |
| Riesame degli accessi | Utenti riesaminati, decisioni, rimozioni ed eccezioni | Dimostra il funzionamento del controllo degli accessi |
| Report MFA | Esportazione che mostra l’applicazione dell’MFA agli accessi privilegiati | Supporta le evidenze di autenticazione |
| Evidenze di cifratura | Registrazione di configurazione, nota architetturale o registrazione di gestione delle chiavi | Supporta riservatezza e integrità |
| Registrazione delle vulnerabilità | Ultima scansione, ticket di remediation ed eccezioni accettate | Supporta la riduzione del rischio tecnico |
| Prova di registrazione degli eventi | Esempio di evento SIEM, regola di alerting e impostazione di conservazione | Supporta rilevazione e indagine |
| Test di backup | Risultato del test di ripristino e registrazione della copertura del backup | Supporta disponibilità e resilienza |
| Esercitazione sugli incidenti | Note tabletop, log di incidente di test o registrazione delle lezioni apprese | Supporta la preparazione alla risposta |
| Approvazione della direzione | Verbali di riunione, approvazione formale o registrazione di accettazione del rischio | Supporta accountability e proporzionalità |
Le evidenze sugli accessi non dovrebbero fermarsi agli screenshot. La Politica di controllo degli accessi - PMI aggiunge un utile requisito operativo:
“Il responsabile IT deve documentare i risultati del riesame e le azioni correttive.”
Fonte: Politica di controllo degli accessi - PMI, Requisiti di governance, clausola di policy 5.5.3. Politica di controllo degli accessi - PMI
Le evidenze sui backup devono dimostrare la recuperabilità, non solo l’esecuzione corretta dei job. La Politica di backup e ripristino - PMI afferma:
“I test di ripristino sono eseguiti almeno trimestralmente e i risultati sono documentati per verificare la recuperabilità.”
Fonte: Politica di backup e ripristino - PMI, Requisiti di governance, clausola di policy 5.3.3. Politica di backup e ripristino - PMI
Questo fornisce un ciclo completo delle evidenze: la normativa crea il requisito, il rischio spiega perché è rilevante, la SoA seleziona il controllo, la policy ne definisce il funzionamento e le evidenze conservate dimostrano che il controllo opera.
Controlli in azione: trasformare la policy in prova operativa
La fase Controls in Action del Zenith Blueprint, Passaggio 19, si concentra sulla verifica tecnica. Raccomanda il riesame della conformità della sicurezza degli endpoint, della gestione delle identità e degli accessi, delle configurazioni di autenticazione, della sicurezza del controllo del codice sorgente, di capacità e disponibilità, della gestione delle vulnerabilità e delle patch, delle baseline sicure, della protezione malware, della cancellazione e minimizzazione dei dati, del mascheramento e dei dati di test, del DLP, di backup e ripristino, della ridondanza, della registrazione degli eventi e del monitoraggio e della sincronizzazione temporale.
Per le TOM dell’Articolo 32 GDPR, il Passaggio 19 è il punto in cui il linguaggio astratto dei controlli diventa prova. Un file di evidenze solido dovrebbe mostrare che:
- La cifratura degli endpoint è abilitata e monitorata.
- Gli utenti privilegiati hanno l’MFA.
- I processi di inserimento, trasferimento e cessazione sono riconciliati con le registrazioni HR.
- Gli account di servizio sono documentati e limitati.
- I repository di codice sono sottoposti a controllo degli accessi ed è eseguita la scansione dei segreti.
- Le scansioni di vulnerabilità sono eseguite e tracciate fino alla remediation.
- I dati di produzione non sono copiati con leggerezza negli ambienti di test.
- Le policy di cancellazione sicura e conservazione sono applicate.
- Gli alert DLP sono riesaminati.
- I test di ripristino dei backup dimostrano la recuperabilità.
- I log sono centralizzati, conservati e riesaminabili.
- La sincronizzazione temporale supporta indagini affidabili sugli incidenti.
La chiave è il collegamento. Un report sulle patch senza riferimento a rischio, policy e SoA è un artefatto IT. Un report sulle patch collegato all’Articolo 32 GDPR, all’Articolo 21 NIS2, alla gestione del rischio ICT DORA e a un Piano di trattamento del rischio ISO 27001:2022 è un’evidenza pronta per l’audit.
Un solo file di evidenze, più prospettive di audit
Le stesse evidenze TOM saranno lette in modo diverso dai diversi stakeholder. Un reviewer privacy può concentrarsi su dati personali, necessità, proporzionalità e accountability. Un auditor ISO 27001 può concentrarsi su campo di applicazione, trattamento del rischio, SoA ed evidenze di funzionamento. Un’autorità NIS2 può concentrarsi sulla supervisione della direzione, sulle misure dell’Articolo 21 e sulla preparazione alla segnalazione dell’Articolo 23. Un supervisore DORA o un cliente finanziario può concentrarsi sulla governance del rischio ICT, sui test di resilienza e sulle dipendenze da terze parti.
Clarysec utilizza Zenith Controls come guida di conformità trasversale per questa traduzione.
| Destinatario | Che cosa chiederà | Come dovrebbero rispondere le evidenze |
|---|---|---|
| Reviewer privacy GDPR | Le TOM sono adeguate al rischio per i dati personali e l’accountability può essere dimostrata? | Registro dei rischi, inventario dei dati, controlli privacy, registrazioni di conservazione, restrizioni di accesso, evidenze di cifratura e registrazioni di valutazione delle violazioni |
| Auditor ISO 27001:2022 | Il SGSI è definito nel campo di applicazione, basato sul rischio, implementato, monitorato e migliorato? | Campo di applicazione, metodologia del rischio, SoA, audit interno, riesame della direzione e azioni correttive |
| Reviewer NIS2 | Le misure di cibersicurezza sono approvate, proporzionate e coprono le aree dell’Articolo 21? | Approvazione del consiglio, policy di sicurezza, gestione degli incidenti, continuità, rischio dei fornitori, formazione, MFA e gestione delle vulnerabilità |
| Supervisore DORA o cliente finanziario | Il rischio ICT è governato, testato e resiliente, incluso il rischio ICT di terze parti? | Quadro di riferimento del rischio ICT, strategia di resilienza, processo incidenti, evidenze di test, Registro dei fornitori e piani di uscita |
| Valutatore orientato a NIST | L’organizzazione può identificare, proteggere, rilevare, rispondere e ripristinare usando evidenze ripetibili? | Inventario degli asset e dei dati, controlli di protezione, registrazioni di monitoraggio, log di risposta e test di ripristino |
| Auditor COBIT 2019 o ISACA | La governance è responsabile, misurata e allineata agli obiettivi aziendali? | Ruoli, reportistica della direzione, propensione al rischio, metriche di prestazione, risultati di assurance e azioni di miglioramento |
Questo evita lavoro di conformità duplicato. Invece di costruire pacchetti di evidenze separati per GDPR, NIS2 e DORA, costruire un unico file di evidenze dei controlli e taggare ogni elemento per gli obblighi che supporta.
Lacune comuni nei programmi TOM dell’Articolo 32
La lacuna più comune è l’orfanizzazione dei controlli. Un’azienda dispone di un controllo, come la cifratura, ma non sa spiegare quale rischio tratta, quale policy lo richiede, chi ne è proprietario o come viene riesaminato.
La seconda lacuna riguarda evidenze deboli sui fornitori. Ai sensi del GDPR, responsabili del trattamento e sub-responsabili sono rilevanti. Ai sensi di NIS2, la sicurezza della catena di fornitura fa parte della gestione dei rischi di cibersicurezza. Ai sensi di DORA, il rischio ICT di terze parti è un dominio regolamentato con registri, due diligence, misure di sicurezza contrattuali, diritti di audit e pianificazione dell’uscita. Un foglio di calcolo dei vendor non è sufficiente se le dipendenze critiche non sono sottoposte a valutazione del rischio e controllate.
La terza lacuna riguarda le evidenze sugli incidenti. Le organizzazioni spesso dispongono di un Piano di risposta agli incidenti ma non hanno prove che classificazione, escalation, segnalazione alle autorità e comunicazione ai clienti siano state testate. NIS2 e DORA aumentano qui le aspettative, e la valutazione della violazione dei dati personali ai sensi del GDPR deve essere integrata nello stesso workflow.
La quarta lacuna riguarda la prova dei backup. Un job di backup completato con successo non dimostra la recuperabilità. Un test di ripristino documentato sì.
La quinta lacuna riguarda il riesame della direzione. Le TOM dell’Articolo 32 devono essere proporzionate al rischio. Se la direzione non riesamina mai rischi, incidenti, problemi dei fornitori, budget, risultanze dell’audit e rischio residuo, la proporzionalità diventa difficile da dimostrare.
Il toolkit finale pronto per l’audit
La fase Audit, Review and Improvement del Zenith Blueprint, Passaggio 30, fornisce la checklist finale di preparazione. Include campo di applicazione e contesto del SGSI, Politica per la sicurezza delle informazioni firmata, documenti di valutazione e trattamento del rischio, SoA, policy e procedure dell’Allegato A, registrazioni della formazione, registrazioni operative, report di audit interno, registro delle azioni correttive, verbali del riesame della direzione, evidenze di miglioramento continuo e registrazioni degli obblighi di conformità.
La Politica di audit e monitoraggio della conformità enterprise di Clarysec definisce lo scopo di questa disciplina:
“Generare evidenze difendibili e una traccia di audit a supporto di richieste delle autorità di regolamentazione, procedimenti legali o richieste di assurance dei clienti.”
Fonte: Politica di audit e monitoraggio della conformità, Obiettivi, clausola di policy 3.4. Politica di audit e monitoraggio della conformità
Un file di evidenze TOM dell’Articolo 32 maturo dovrebbe includere:
| Categoria di evidenze | Contenuto minimo pronto per l’audit |
|---|---|
| Governance | Campo di applicazione del SGSI, approvazione della policy, ruoli, obiettivi, verbali del riesame della direzione |
| Rischio | Metodologia del rischio, Registro dei rischi, piano di trattamento, approvazioni del rischio residuo |
| SoA | Controlli applicabili, esclusioni, giustificazioni e mappatura normativa |
| Privacy | Inventario dei dati, controlli PII, evidenze di conservazione, DPIA o valutazione del rischio privacy ove applicabile |
| Controlli tecnici | MFA, riesami degli accessi, cifratura, gestione delle vulnerabilità, registrazione degli eventi, monitoraggio ed evidenze di sviluppo sicuro |
| Resilienza | Copertura dei backup, test di ripristino, Piani di continuità operativa, esercitazioni sugli incidenti e metriche di ripristino |
| Assurance dei fornitori | Registro dei fornitori, due diligence, clausole contrattuali, monitoraggio, diritto di audit e pianificazione dell’uscita |
| Miglioramento | Audit interni, azioni correttive, lezioni apprese e riesami dell’efficacia dei controlli |
Prossimi passi: costruire evidenze TOM dell’Articolo 32 con Clarysec
Se devi dimostrare le misure tecniche e organizzative dell’Articolo 32 GDPR, non iniziare raccogliendo screenshot casuali. Inizia dalla tracciabilità.
- Definire il campo di applicazione del SGSI e i confini del trattamento dei dati personali.
- Identificare requisiti GDPR, NIS2, DORA, contrattuali e dei clienti.
- Costruire i criteri di rischio utilizzando ISO/IEC 27005:2022 e la propensione al rischio approvata dalla direzione.
- Creare o aggiornare il Registro dei rischi.
- Mappare ogni trattamento ai controlli ISO 27001:2022 e alla SoA.
- Usare Zenith Controls per creare riferimenti incrociati tra controlli privacy, crittografici, sui fornitori, sugli incidenti e di riesame indipendente rispetto alle aspettative di conformità.
- Seguire Zenith Blueprint Passaggio 13 e Passaggio 14 per collegare rischi, controlli e obblighi normativi.
- Usare Zenith Blueprint Passaggio 19 per verificare i controlli tecnici in esercizio.
- Usare Zenith Blueprint Passaggio 30 per assemblare il file finale di evidenze pronto per l’audit.
- Conservare tutte le evidenze centralmente, etichettarle per rischio e tema di controllo e mantenere visibili le azioni correttive.
Clarysec può aiutarti a convertire l’Articolo 32 GDPR da un obbligo di conformità vago in un sistema di evidenze difendibile e basato sul rischio, allineato a ISO 27001:2022, NIS2 e DORA.
Inizia con il Zenith Blueprint, rafforzalo con le policy Clarysec e usa Zenith Controls per rendere ogni TOM tracciabile, testabile e pronta per l’audit.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
