Classificazione dei dati per ISO 27001, GDPR, NIS2 e DORA
Il momento dell’audit nel 2026: “Mostratemi le evidenze”
È febbraio 2026 e la riunione trimestrale del consiglio di amministrazione di una società fintech SaaS in rapida crescita non sta procedendo con la fluidità che il CISO si aspettava.
L’azienda ha recentemente ottenuto la certificazione ISO/IEC 27001:2022. Dispone di MFA, protezione degli endpoint, scansioni di vulnerabilità, riesami degli accessi, procedure di risposta agli incidenti e una relazione di preparazione a DORA ben rifinita. Poi il CEO pone la domanda che cambia il tono della riunione.
“Il nostro principale investitore chiede come possiamo dimostrare che i dati finanziari dei clienti siano protetti in modo coerente tra AWS, Azure, la nostra piattaforma SaaS di supporto e il data warehouse analitico. Se un auditor estrae un file dall’object storage e un altro da una cartella di collaborazione, come sappiamo che sono governati dalle stesse regole?”
Il CISO apre il registro degli asset. Elenca database, account cloud, applicazioni, piattaforme SaaS e posizioni di archiviazione. Ma il campo relativo alla classificazione è incompleto. Alcune cartelle sono denominate per reparto, non per sensibilità. Le esportazioni dei clienti si trovano accanto ai file di reportistica interna. Alcuni fogli di calcolo del supporto contengono identificativi dei clienti, riferimenti di pagamento e note sui casi, ma sono etichettati come “interni”. Le regole DLP esistono, ma si attivano solo su pattern evidenti. La politica cloud stabilisce che i dati personali dell’UE devono rimanere in regioni approvate, ma il team non può dimostrare che le regole di localizzazione siano guidate dai metadati di classificazione.
Poi il Responsabile Compliance aggiunge il punto regolatorio: “Questo soddisferà GDPR Article 32, NIS2 Article 21 e le evidenze del rischio ICT DORA?”
La risposta onesta è: non ancora.
Questo è il divario che molte organizzazioni affrontano nel 2026. Dispongono di controlli di sicurezza, ma non del livello di governance che indica a ogni controllo cosa proteggere, con quale intensità proteggerlo e come dimostrarlo. Quel livello di governance è la classificazione dei dati e l’etichettatura delle informazioni.
In termini ISO/IEC 27001:2022, classificazione ed etichettatura non sono pratiche cosmetiche di gestione documentale. Sono il ponte operativo tra valutazione del rischio, controllo degli accessi, cifratura, conservazione, DLP, localizzazione dei dati nel cloud, due diligence sui fornitori, monitoraggio e segnalazione degli incidenti. Nel modello di implementazione di Clarysec si collocano al centro della catena delle evidenze del SGSI: inventariare l’asset, assegnare un proprietario, classificarlo, etichettarlo, applicare regole di gestione, monitorare le eccezioni e mostrare agli auditor la tracciabilità.
Perché classificazione ed etichettatura sono ora controlli a livello di consiglio di amministrazione
Autorità di regolamentazione e clienti si aspettano sempre più che le organizzazioni dimostrino che le misure di sicurezza sono adeguate alla sensibilità dei dati, alla criticità del servizio e all’impatto aziendale di un eventuale malfunzionamento.
Il GDPR lo rende esplicito attraverso il principio di responsabilizzazione. Article 5 richiede che i dati personali siano trattati in modo lecito, corretto e trasparente, limitati a quanto necessario, conservati solo per il tempo necessario e protetti mediante misure tecniche e organizzative adeguate. Il titolare del trattamento deve inoltre essere in grado di dimostrare la conformità. GDPR Article 32 diventa quindi difficile da comprovare senza sapere quali sistemi trattano dati personali, quali dati sono ad alto rischio o appartengono a categorie particolari, dove sono archiviati e quali misure di sicurezza si applicano.
NIS2 alza l’asticella della governance. Article 20 richiede agli organi di gestione dei soggetti essenziali e importanti di approvare le misure di gestione dei rischi di cibersicurezza, vigilare sulla loro attuazione e ricevere formazione. Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate, tra cui analisi dei rischi, politiche di sicurezza, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, sicurezza nelle attività di acquisizione e sviluppo, valutazione dell’efficacia, igiene cibernetica, formazione, crittografia, sicurezza delle risorse umane, controllo degli accessi e gestione degli asset. La classificazione non è un requisito separato da spuntare in quell’elenco. È il sistema decisionale che rende proporzionate tali misure.
DORA applica la stessa logica alle entità finanziarie e agli ecosistemi fintech. Dal 17 gennaio 2025, DORA richiede un quadro di gestione del rischio ICT documentato, la responsabilità dell’organo di gestione, politiche per riservatezza, integrità, disponibilità e autenticità, classificazione degli incidenti, test di resilienza e gestione del rischio ICT di terze parti. Per le entità finanziarie soggette a DORA, DORA può operare come atto giuridico dell’Unione settoriale in luogo degli obblighi NIS2 sovrapposti in materia di gestione del rischio e segnalazione, ma l’aspettativa sulle evidenze resta la stessa: dimostrare come informazioni e asset ICT critici siano identificati, protetti, testati, monitorati e governati.
ISO/IEC 27001:2022 è particolarmente adatta come sistema operativo per queste evidenze. Le clausole da 4.1 a 4.4 richiedono all’organizzazione di comprendere questioni interne ed esterne, requisiti delle parti interessate, obblighi normativi e contrattuali e interfacce con altre organizzazioni. Le clausole da 6.1.1 a 6.1.3 richiedono valutazione del rischio, trattamento del rischio, selezione dei controlli, una Dichiarazione di Applicabilità ed evidenze conservate. ISO/IEC 27001:2022
Se GDPR, NIS2 e DORA chiedono: “Perché avete applicato queste misure?”, ISO/IEC 27001:2022 aiuta a rispondere: “Perché questi asset, tipi di dati, rischi, obblighi e decisioni di trattamento ci hanno condotto qui.”
La classificazione è la decisione di rischio. L’etichettatura è il segnale operativo.
Clarysec separa classificazione ed etichettatura perché gli auditor lo fanno.
La classificazione è l’atto di decidere sensibilità, valore e criticità delle informazioni. L’etichettatura è l’atto di rendere tale decisione visibile, persistente e applicabile nelle attività quotidiane.
La Politica di classificazione ed etichettatura dei dati - PMI di Clarysec dichiara chiaramente la finalità:
Questa politica definisce come tutte le informazioni gestite dall’organizzazione devono essere classificate ed etichettate per garantire che riservatezza, integrità e disponibilità siano mantenute lungo tutto il ciclo di vita.
La stessa Politica di classificazione ed etichettatura dei dati - PMI richiede alle organizzazioni di:
Richiedere che ogni asset di dati sia classificato in base alla sua sensibilità ed etichettato di conseguenza, per guidarne la corretta gestione, archiviazione e accesso.
Per gli ambienti enterprise, la P13 Politica di classificazione ed etichettatura dei dati di Clarysec definisce il modello minimo di classificazione:
L’organizzazione deve mantenere uno schema di classificazione standardizzato con livelli chiaramente definiti. Come minimo, devono essere utilizzati i seguenti livelli di classificazione: 5.1.1 Pubblico: informazioni destinate alla pubblicazione aperta e alla distribuzione senza restrizioni 5.1.2 Interno: informazioni aziendali non pubbliche non destinate alla divulgazione esterna 5.1.3 Confidenziale: dati aziendali, contrattuali o dei clienti sensibili che richiedono un rigoroso controllo degli accessi 5.1.4 Riservato (o altamente confidenziale): informazioni critiche o regolamentate la cui divulgazione non autorizzata potrebbe causare danni significativi o responsabilità legale
Questa distinzione è importante. Una classificazione “Confidenziale” può richiedere cifratura, accesso basato sui ruoli e misure contrattuali di protezione. Una classificazione “Riservato” può attivare MFA, approvazione del CISO per la condivisione esterna, registrazione rafforzata, una governance della conservazione più rigorosa, segregazione ed escalation prioritaria degli incidenti.
La politica enterprise è esplicita sull’etichettatura operativa:
Tutti i patrimoni informativi devono essere etichettati in modo che l’etichetta sia: 6.2.1.1 Persistente: non facilmente rimossa o sovrascritta 6.2.1.2 Visibile: chiara per gli utenti al momento dell’utilizzo 6.2.1.3 Leggibile automaticamente: ove possibile, deve essere supportata l’etichettatura basata su metadati
Le etichette leggibili automaticamente sono il punto in cui il programma evolve dalla sensibilizzazione all’applicazione. Se le etichette sono basate su metadati, piattaforme cloud, sistemi DLP, gateway e-mail, strumenti di identità, regole SIEM, piattaforme CASB e motori di conservazione possono agire su di esse. Se le etichette sono soltanto un piè di pagina in un documento, possono aiutare gli utenti, ma non possono applicare in modo affidabile le regole su larga scala.
Dove si colloca la classificazione nella roadmap Clarysec
La Zenith Blueprint: roadmap in 30 passaggi per auditor di Clarysec colloca la classificazione nelle fasi iniziali del ciclo di vita della gestione del rischio, non dopo l’implementazione della tecnologia. Nella fase di Gestione del rischio, passaggio 9, “Identificazione di asset, minacce e vulnerabilità”, la roadmap indirizza i team a inventariare i patrimoni informativi e registrare proprietario, posizione e classificazione.
Questo evita un errore comune: avere un inventario cloud ma non un inventario delle informazioni. Un database, un tenant SaaS o un data warehouse è un asset tecnologico. Le registrazioni dei clienti, i fascicoli dei dipendenti, i log di pagamento, i set di dati per l’addestramento dei modelli, le trascrizioni del supporto e le evidenze degli incidenti contenuti al loro interno sono patrimoni informativi. La classificazione opera a questo livello informativo.
La guida Zenith Blueprint sul controllo ISO/IEC 27002:2022 5.12, Classificazione delle informazioni, spiega il principio:
Ogni controllo di sicurezza delle informazioni mai scritto, che si tratti di restrizione degli accessi, cifratura, backup, monitoraggio o smaltimento, presuppone una cosa: che l’organizzazione sappia che cosa sta proteggendo. Il controllo 5.12 richiede che le informazioni siano classificate in base a valore, sensibilità e criticità, costituendo la base per tutte le decisioni successive all’interno del SGSI.
Per il controllo ISO/IEC 27002:2022 5.13, Etichettatura delle informazioni, la stessa roadmap trasforma la classificazione in comportamento quotidiano:
L’etichettatura è il modo in cui si converte una politica astratta in realtà operativa. È il momento in cui un utente, vedendo un documento, un’e-mail, un campo di database o un report stampato, può comprendere a colpo d’occhio: che cosa sono queste informazioni, quanto sono sensibili e come devono essere trattate.
Il collegamento finale della roadmap compare nel passaggio 13, “Pianificazione del trattamento del rischio e Dichiarazione di Applicabilità”. La Zenith Blueprint descrive la SoA come il ponte tra rischi, trattamenti e controlli. È qui che la classificazione diventa tracciabilità ai fini di audit. Uno scenario di rischio come “divulgazione non autorizzata di dati finanziari dei clienti da archiviazione cloud condivisa” può essere mappato a classificazione, etichettatura, controllo degli accessi, cifratura, registrazione, DLP, uso del cloud, requisiti dei fornitori e risposta agli incidenti.
Le relazioni tra controlli che gli auditor si aspettano di vedere
Nella Zenith Controls: guida alla conformità trasversale di Clarysec, il controllo ISO/IEC 27002:2022 5.12, Classificazione delle informazioni, è mappato come controllo preventivo a supporto di riservatezza, integrità e disponibilità. È associato al concetto di cibersicurezza Identify, alla capacità operativa Information Protection e ai domini di sicurezza Protection and Defense.
Per il controllo ISO/IEC 27002:2022 5.13, Etichettatura delle informazioni, Zenith Controls mappa il controllo come preventivo, focalizzato su Protect, con le stesse proprietà di sicurezza delle informazioni e la stessa capacità operativa Information Protection.
L’intuizione critica è che classificazione ed etichettatura non sono isolate. Rendono difendibili i controlli circostanti.
| Area di controllo ISO/IEC 27002:2022 | Perché dipende dalla classificazione o dall’etichettatura | Evidenze che un auditor può richiedere |
|---|---|---|
| 5.9 Inventario delle informazioni e degli altri asset associati | I metadati di classificazione dovrebbero essere un campo essenziale nell’inventario degli asset | Registro degli asset con proprietario, posizione, stato del ciclo di vita e classificazione |
| 5.12 Classificazione delle informazioni | Definisce sensibilità, valore e criticità | Schema di classificazione approvato, criteri, esempi e registrazioni dei riesami |
| 5.13 Etichettatura delle informazioni | Rende la classificazione visibile e applicabile | Configurazione delle etichette, esempi di file etichettati, etichette e-mail, tag SaaS e guida per gli utenti |
| 5.14 Trasferimento delle informazioni | Determina se siano richieste condivisione esterna, cifratura o approvazione | Regole di trasferimento per classificazione, canali approvati e registrazioni delle eccezioni |
| 5.15 Controllo degli accessi | Le autorizzazioni di accesso dovrebbero seguire i confini della classificazione | Matrice dei ruoli, riesami degli accessi, regole di accesso privilegiato e cronologia delle approvazioni |
| 5.25 Valutazione e decisione sugli eventi di sicurezza delle informazioni | La gravità dell’incidente dipende in parte dalla sensibilità dei dati interessati | Criteri di triage degli incidenti basati su classificazione e criticità del servizio |
| 5.34 Privacy e protezione dei dati personali identificabili | Le categorie di dati personali richiedono una gestione specifica per la privacy | Registro PII, mappatura della base giuridica, regole di conservazione e controlli sui responsabili del trattamento |
| 8.15 Registrazione | L’accesso ai dati Riservati richiede una tracciabilità più forte | Log di accesso ai dati, impostazioni di conservazione dei log ed evidenze di riesame |
| 8.16 Attività di monitoraggio | La priorità del monitoraggio cambia quando vengono trattati dati Riservati | Casi d’uso SIEM, soglie di allerta e registrazioni di escalation |
Zenith Controls mappa il controllo 5.12 a GDPR Article 32 e Recital 83, NIS2 Article 21(2)(a) e 21(2)(f), ISO/IEC 27701 Annex B, NIST SP 800-53 MP-3 e PM-11, FIPS 199 e NIST SP 800-60, e COBIT 2019 DSS06.06 e APO13.01. Mappa il controllo 5.13 a GDPR Article 32, NIS2 Article 21(2)(a) e 21(2)(f), DORA Article 9(1) e 9(2), NIST SP 800-53 MP-3 e COBIT 2019 DSS06.06.
Ciò significa che un unico set di evidenze può rispondere a più quesiti di assurance.
| Driver di conformità | Contributo di classificazione ed etichettatura | Prova pratica |
|---|---|---|
| GDPR Article 32 | Mostra quali dati personali richiedono misure di sicurezza per riservatezza, integrità, disponibilità e resilienza | Classificazione PII, regole di cifratura, restrizioni di accesso, mappatura della conservazione e criteri di triage delle violazioni |
| NIS2 Article 21 | Supporta analisi dei rischi, politiche di sicurezza, valutazione dell’efficacia, controllo degli accessi, gestione degli asset e misure proporzionate | Politica approvata dalla direzione, inventario degli asset, formazione, metriche di riesame e regole di gestione testate |
| Gestione del rischio ICT DORA | Supporta identificazione e protezione di informazioni e asset ICT, classificazione degli incidenti e rischio ICT di terze parti | Registro degli asset ICT, criticità dei dati, requisiti contrattuali dei fornitori, ambito dei test e criteri di gravità degli incidenti |
| NIST CSF 2.0 | Supporta gli esiti GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND e RECOVER | Current Profile e Target Profile con lacune di classificazione e azioni di rimedio prioritarie |
| COBIT 2019 | Supporta la governance e i controlli di processo per sicurezza, gestione dei dati e funzionamento dei controlli | Obiettivi di controllo, titolarità del processo, test di assurance e gestione delle eccezioni |
Il registro degli asset è il punto in cui la classificazione diventa evidenza
Molti programmi di classificazione falliscono perché lo schema di classificazione esiste solo in una politica. L’approccio Clarysec parte dall’inventario degli asset.
La P12 Politica di gestione degli asset di Clarysec richiede che l’inventario degli asset includa il livello di classificazione come campo minimo:
L’inventario degli asset deve contenere, come minimo: 5.3.1 ID dell’asset, categoria e tipo 5.3.2 Numero di serie o tag univoco (per i beni fisici) 5.3.3 Versione software o chiave di licenza (per gli asset software) 5.3.4 Proprietario dell’asset 5.3.5 Livello di classificazione (Pubblico, Interno, Confidenziale, Riservato) 5.3.6 Posizione (fisica, virtuale, cloud) 5.3.7 Stato del ciclo di vita (attivo, in manutenzione, dismesso)
Questo si allinea direttamente alla pianificazione del rischio ISO/IEC 27001:2022. Se non è possibile identificare patrimonio informativo, proprietario, posizione e classificazione, non è possibile valutare in modo coerente probabilità, impatto, priorità di trattamento o rischio residuo. Inoltre, non è possibile decidere con sufficiente certezza se un rapporto con un fornitore, un servizio cloud o un’integrazione SaaS incida su informazioni regolamentate.
Per il GDPR, ciò supporta la responsabilizzazione. Le registrazioni delle attività di trattamento dell’Article 30 e le misure di sicurezza dell’Article 32 diventano più credibili quando il registro degli asset identifica dove i dati personali sono trattati e come sono protetti. Per DORA, lo stesso registro supporta asset ICT e criticità dei servizi, ambito dei test di resilienza e analisi delle dipendenze da terze parti. Per NIS2, supporta analisi dei rischi, controllo degli accessi e gestione degli asset.
| Campo | Esempio di voce |
|---|---|
| Nome dell’asset | Database di fatturazione clienti |
| Proprietario dell’asset | Responsabile Platform Engineering |
| Processo aziendale | Fatturazione degli abbonamenti ed emissione delle fatture |
| Posizione | Regione cloud UE, servizio di database gestito |
| Classificazione | Riservato |
| Categorie di dati | Identificativi dei clienti, dati di contatto per la fatturazione, riferimenti delle transazioni |
| Rilevanza GDPR | Dati personali, contesti di titolare e responsabile del trattamento |
| Criticità | Supporta le operazioni di ricavo e il servizio clienti |
| Controlli chiave | MFA, cifratura dei dati a riposo, cifratura dei dati in transito, approvazione dell’accesso privilegiato, registrazione di audit, test dei backup |
| Dipendenza dal fornitore | Fornitore del database cloud, responsabile dei pagamenti |
| Frequenza di riesame | Riesame trimestrale degli accessi, riesame annuale della classificazione, riesame in caso di modifica del sistema |
Questo tipo di registrazione cambia il tono di un audit. Invece di dire “riteniamo che i dati sensibili siano protetti”, l’organizzazione può mostrare cosa sono i dati, chi ne è responsabile, perché sono Riservati, quali controlli si applicano e quando tali controlli sono stati riesaminati l’ultima volta.
Le etichette devono guidare le regole di gestione cloud e SaaS
La maggior parte dei dati sensibili oggi transita attraverso piattaforme cloud, applicazioni SaaS, pipeline analitiche e strumenti di collaborazione. Una politica che dice agli utenti di “gestire con attenzione i dati confidenziali” non è sufficiente.
La P27 Politica di utilizzo del cloud di Clarysec collega l’uso del cloud direttamente alla classificazione e alla localizzazione dei dati:
Classificazione e localizzazione dei dati 6.6.1 Nessun dato può essere spostato su una piattaforma cloud senza classificazione in conformità alla Politica di classificazione ed etichettatura dei dati (P13). 6.6.2 I requisiti di localizzazione dei dati devono essere applicati contrattualmente (ad es. archiviazione solo nell’UE per dati regolamentati dal GDPR). 6.6.3 I trasferimenti transfrontalieri di dati devono essere conformi al GDPR Chapter V e, ove applicabile, a DORA Article 28.
Questo è rilevante perché il rischio cloud spesso entra attraverso la comodità. Un team esporta un set di dati verso un nuovo strumento di analisi. Le vendite sincronizzano liste clienti con una piattaforma di automazione. Uno sviluppatore copia dati di produzione in un ambiente di test. Senza classificazione ed etichettatura, queste azioni potrebbero non attivare un riesame legale, un’approvazione di sicurezza o controlli sui fornitori.
La Politica di classificazione ed etichettatura dei dati - PMI offre alle organizzazioni più piccole un modello semplice di applicazione:
Le cartelle condivise o le unità cloud devono utilizzare nomi di cartella o tag per indicare la classificazione (ad es. “/Clients_Confidential”).
Per ambienti maturi, i nomi delle cartelle dovrebbero essere integrati da etichette leggibili automaticamente, politiche di accesso condizionale, blocchi della condivisione esterna, cifratura, etichette di conservazione, regole DLP e registrazione. L’obiettivo non è semplicemente etichettare le informazioni. L’obiettivo è rendere l’etichetta azionabile.
Un’etichetta “Riservato” potrebbe attivare blocchi della condivisione esterna, cifratura dei dati a riposo e in transito, MFA, restrizioni al download su dispositivi non gestiti, conservazione dei registri di audit, allerte SIEM, regole di conservazione, limiti di localizzazione dei fornitori ed escalation della gravità degli incidenti.
La P13 Politica di classificazione ed etichettatura dei dati definisce la baseline:
Tutte le attività di gestione, trasmissione, accesso, archiviazione e smaltimento delle informazioni devono essere allineate al relativo livello di classificazione. Come minimo: 6.3.1.1 Pubblico: può essere divulgato liberamente; non richiede gestione speciale 6.3.1.2 Interno: condiviso all’interno dell’organizzazione; archiviato in sistemi interni sicuri 6.3.1.3 Confidenziale: 6.3.1.3.1 Accesso limitato al solo personale autorizzato 6.3.1.3.2 Deve essere cifrato in transito e a riposo 6.3.1.3.3 Può essere condiviso esternamente solo nell’ambito di un NDA o di misure contrattuali di protezione equivalenti 6.3.1.4 Riservato: 6.3.1.4.1 Si applicano i requisiti di sicurezza più elevati 6.3.1.4.2 Sono richiesti controlli degli accessi forti, autenticazione a più fattori (MFA) e registrazione di audit 6.3.1.4.3 Segregazione fisica e logica ove praticabile 6.3.1.4.4 La condivisione esterna è vietata senza approvazione del CISO
Ogni etichetta ha un comportamento. Ogni comportamento ha un controllo. Ogni controllo ha evidenze.
Un esempio pratico di applicazione
Si consideri un analista fintech che crea Q3_2026_Customer_Churn_Analysis.xlsx. Il foglio di calcolo include ID cliente, volumi di transazioni e scoring predittivo del churn.
L’analista lo classifica come Confidenziale perché contiene dati dei clienti e analisi strategiche. Utilizzando lo strumento aziendale di protezione delle informazioni, applica l’etichetta Confidenziale. Poiché l’etichetta è persistente, visibile e leggibile automaticamente, i controlli si attivano automaticamente.
Il file è cifrato a riposo sul dispositivo e nell’archiviazione cloud. Un’intestazione visibile lo contrassegna come Confidenziale. Quando l’analista tenta di sincronizzarlo su un’unità cloud personale, una regola DLP blocca l’azione e registra il tentativo. Quando l’analista tenta di inviarlo via e-mail a un dominio esterno non partner, il gateway e-mail mette il messaggio in quarantena e allerta le operazioni di sicurezza. Se il file viene successivamente riclassificato come Riservato perché contiene dati regolamentati relativi a transazioni finanziarie, la condivisione esterna viene disabilitata salvo approvazione dell’eccezione da parte del CISO o del titolare dei dati.
Questa è la prova che il CEO cercava. È tracciabile, automatizzata e collegata a una politica approvata dal consiglio di amministrazione. È inoltre allineata alla P27 Politica di utilizzo del cloud, perché nessuno spostamento verso il cloud è consentito senza classificazione e i trasferimenti transfrontalieri devono rispettare GDPR Chapter V e, ove applicabile, DORA Article 28.
Costruire una matrice classificazione-controllo in una settimana
Un programma completo richiede tempo, ma uno sprint mirato può creare la struttura portante delle evidenze prima di un audit, di un riesame da parte di un cliente o di una valutazione regolatoria.
Giorno 1: confermare lo schema di classificazione
Partire da quattro livelli: Pubblico, Interno, Confidenziale e Riservato. Utilizzare la P13 Politica di classificazione ed etichettatura dei dati come baseline. Definire i criteri utilizzando impatto aziendale, impatto legale, sensibilità contrattuale, rischio sui dati personali, criticità del servizio e danno finanziario.
| Classificazione | Esempi tipici | Logica di rischio |
|---|---|---|
| Pubblico | Contenuti marketing approvati, comunicati stampa, annunci di lavoro | Destinato alla distribuzione senza restrizioni |
| Interno | Procedure interne, note di progetto, comunicazioni interne | Informazioni aziendali non pubbliche |
| Confidenziale | Contratti con i clienti, fascicoli HR, report finanziari non pubblici | Dati aziendali, contrattuali o dei clienti sensibili |
| Riservato | Categorie particolari di dati personali, dati di pagamento, segreti di autenticazione, database clienti di produzione | Informazioni critiche o regolamentate con impatto legale o aziendale significativo |
Giorno 2: selezionare dieci patrimoni informativi critici
Utilizzare il passaggio 9 di Zenith Blueprint. Includere un database clienti, un sistema di ticketing del supporto, una piattaforma HR, un provider di identità, un’esportazione pagamenti, un data warehouse, un bucket di object storage, una cartella di reportistica per il consiglio di amministrazione, un repository di codice sorgente e un repository delle evidenze degli incidenti. Registrare proprietario, posizione, classificazione e rilevanza GDPR.
Giorno 3: mappare le regole di gestione
Definire i requisiti di gestione per accesso, archiviazione, trasferimento, monitoraggio e smaltimento.
| Classificazione | Accesso | Archiviazione | Trasferimento | Monitoraggio | Smaltimento |
|---|---|---|---|---|---|
| Pubblico | Ruoli di pubblicazione aperta o approvata | Canali pubblici approvati | Nessuna restrizione speciale dopo l’approvazione | Monitoraggio di base dell’integrità | Cancellazione standard |
| Interno | Dipendenti e contraenti approvati | Sistemi gestiti | Canali interni | Log di accesso standard | Piano di conservazione standard |
| Confidenziale | Accesso secondo il principio del need-to-know | Repository sicuri approvati | Cifratura e NDA o misure contrattuali di protezione | Riesame degli accessi e allerte DLP | Cancellazione sicura |
| Riservato | Principio del privilegio minimo con MFA e approvazione del proprietario | Sistemi segregati o con configurazione sicura | Condivisione esterna vietata salvo approvazione | Registrazione di audit rafforzata e allerte SIEM | Distruzione sicura verificata |
Giorno 4: configurare un percorso di applicazione tecnica
Scegliere una piattaforma, ad esempio un repository documentale cloud, un sistema e-mail o un servizio di object storage. Implementare etichette visibili e leggibili automaticamente. Configurare una regola per i dati Confidenziali e una per i dati Riservati. Ad esempio, richiedere la cifratura per le e-mail esterne Confidenziali e bloccare la condivisione esterna dei file Riservati.
Giorno 5: aggiornare il Registro dei rischi e la SoA
Utilizzare il passaggio 13 di Zenith Blueprint. Aggiungere i controlli di classificazione ed etichettatura alla Dichiarazione di Applicabilità. Collegarli a rischi quali divulgazione non autorizzata, errata configurazione cloud, esposizione eccessiva verso fornitori, mancato rispetto della conservazione dei dati e sotto-segnalazione degli incidenti.
Giorno 6: testare il controllo
Creare un file di test etichettato Riservato. Tentare di condividerlo esternamente da un dispositivo non gestito. Confermare se lo strumento blocca, avvisa, registra o attiva un’escalation. Acquisire screenshot, voci di log ed evidenze nel ticket. Se il controllo fallisce, registrare l’eccezione e il piano di rimedio.
Giorno 7: formare gli utenti di prima linea
La formazione deve essere specifica per ruolo. Gli sviluppatori devono sapere quando i dati di produzione non possono essere utilizzati negli ambienti di test. Le Risorse Umane devono comprendere perché i fascicoli dei dipendenti sono Confidenziali o Riservati. Le vendite devono sapere perché le esportazioni dei clienti non possono essere caricate in strumenti SaaS non approvati. I dirigenti devono comprendere perché board pack, file di acquisizione e dati degli investitori richiedono una gestione più rigorosa.
Questo sprint non completa l’intero programma, ma crea la struttura portante delle evidenze: politica, inventario, etichette, regole di gestione, applicazione tecnica, tracciabilità del rischio e formazione.
Come gli auditor testeranno classificazione ed etichettatura
Gli auditor raramente testano la classificazione in modo isolato. Seguono i dati.
Un auditor ISO/IEC 27001:2022 collegherà la classificazione al campo di applicazione del SGSI, ai requisiti delle parti interessate, agli obblighi legali e contrattuali, alla valutazione del rischio e alla Dichiarazione di Applicabilità. Si aspetterà evidenze per i controlli ISO/IEC 27002:2022 5.9, 5.12, 5.13, 5.14, 5.15, 5.34 e per i controlli tecnici pertinenti. Le evidenze tipiche includono politiche approvate, registrazioni dell’inventario degli asset, voci del Registro dei rischi, campioni etichettati, regole di gestione, riesami degli accessi, risultanze dell’audit interno e azioni correttive.
Un revisore GDPR si concentrerà sui dati personali. Chiederà se i dati personali siano identificati, se le categorie particolari di dati siano distinte, se le regole di conservazione siano allineate alla finalità e se le misure di sicurezza dell’Article 32 siano adeguate. La classificazione aiuta a distinguere le normali informazioni aziendali dai dati personali, dai dati personali sensibili, dai dati riservati dei clienti e dalle registrazioni regolamentate. L’etichettatura aiuta i team operativi a evitare divulgazioni accidentali, conservazione eccessiva e trasferimenti non autorizzati.
Un valutatore NIST CSF 2.0 probabilmente inquadrerà la classificazione in GOVERN, IDENTIFY e PROTECT. Potrebbe chiedere se i Current Profile e Target Profile definiscano la discovery dei dati sensibili, se l’applicazione delle etichette funzioni su sistemi SaaS e cloud, se i fornitori gestiscano i dati secondo la classificazione e se le priorità di monitoraggio si adeguino in base alla sensibilità.
Un auditor COBIT 2019 o di impostazione ISACA porrà l’accento su obiettivi di governance, titolarità del processo, disegno dei controlli ed efficacia operativa. Zenith Controls mappa il controllo di inventario 5.9 a COBIT 2019 BAI09.01, BAI09.02 e DSS05.04, e richiama ISACA ITAF 2204 e 2301. Per la classificazione, Zenith Controls mappa il controllo 5.12 a COBIT 2019 DSS06.06 e APO13.01, mentre l’etichettatura è mappata a DSS06.06. L’auditor chiederà chi è titolare del processo, come sono approvate le eccezioni, se le prestazioni sono monitorate e se la direzione riceve reportistica.
Un revisore focalizzato su DORA chiederà quali patrimoni informativi supportano funzioni critiche o importanti, quali dati sono Riservati, quali fornitori terzi ICT archiviano o trasmettono tali dati, se i contratti definiscono posizioni e misure di sicurezza, se i test sono circoscritti ai dati critici e se gli incidenti sono classificati anche in base alla perdita di dati rispetto a disponibilità, autenticità, integrità e riservatezza.
Se le risposte provengono da un unico modello di evidenze basato sulla classificazione per asset e fornitori, gli audit diventano più rapidi, più coerenti e più difendibili.
Schemi di errore comuni
I fallimenti della classificazione si verificano di solito perché le organizzazioni trattano le etichette come strumenti di sensibilizzazione invece che come segnali di controllo.
Primo, classificano i documenti ma non database, API, log, backup, esportazioni o registrazioni SaaS. Dati sensibili in un log di debug possono essere dannosi quanto dati sensibili in un foglio di calcolo.
Secondo, etichettano le informazioni ma non collegano le etichette al controllo degli accessi. Un’etichetta Riservato con accesso aperto dimostra che l’organizzazione conosceva la sensibilità e non ha applicato la regola di gestione.
Terzo, le migrazioni cloud avvengono prima della classificazione. I team spostano dati in nuovi strumenti SaaS senza confermare localizzazione, termini del fornitore, accesso dei sub-responsabili, requisiti di trasferimento transfrontaliero o diritti di cancellazione. La P27 Politica di utilizzo del cloud affronta direttamente questo punto vietando lo spostamento verso piattaforme cloud senza classificazione.
Quarto, i piani di risposta agli incidenti ignorano la classificazione. Se i criteri di gravità non includono la sensibilità dei dati, i team di gestione degli incidenti perdono tempo a scoprire cosa è stato interessato durante la crisi. Analisi delle violazioni GDPR, gestione degli incidenti NIS2 e classificazione degli incidenti DORA traggono tutti beneficio da un contesto dati immediato.
Quinto, la SoA non spiega perché i controlli di classificazione ed etichettatura siano applicabili. L’organizzazione può avere implementato le etichette, ma la SoA non le collega a GDPR Article 32, NIS2 Article 21, rischio ICT DORA, contratti con i clienti o scenari di rischio specifici.
Reportistica alla direzione: rendere visibile la classificazione
NIS2 e DORA rendono la cibersicurezza una questione di responsabilità della direzione. ISO/IEC 27001:2022 richiede inoltre impegno della leadership, allineamento delle politiche, risorse, ruoli e reportistica sulle prestazioni. Le metriche di classificazione dovrebbero quindi arrivare al Riesame della direzione.
Metriche utili includono:
- Percentuale di patrimoni informativi critici con proprietari assegnati.
- Percentuale di asset con classificazione approvata.
- Numero di asset Riservati senza registrazione rafforzata.
- Numero di repository Confidenziali o Riservati con condivisione esterna abilitata.
- Percentuale di fornitori che trattano dati Confidenziali o Riservati con clausole contrattuali aggiornate.
- Numero di eccezioni di classificazione e azioni di rimedio scadute.
- Incidenti DLP per etichetta.
- Completamento dei riesami degli accessi per asset Riservati.
- Posizioni di archiviazione cloud per dati regolamentati dal GDPR.
- Esercitazioni di risposta agli incidenti che hanno utilizzato criteri di gravità basati sulla classificazione.
Queste metriche supportano il Riesame della direzione ISO/IEC 27001:2022, la supervisione della direzione NIS2, la reportistica di governance DORA e l’assurance verso i clienti. Rendono inoltre la classificazione comprensibile ai dirigenti. La leadership può agire più rapidamente quando vede che più repository Riservati non dispongono di ripristino testato o che fornitori critici trattano dati dei clienti senza archiviazione UE confermata.
Dalla politica alla prova
Il modello di implementazione Clarysec è guidato dalle evidenze:
- Definire lo schema di classificazione nella P13 Politica di classificazione ed etichettatura dei dati o partire dalla Politica di classificazione ed etichettatura dei dati - PMI.
- Aggiungere la classificazione all’inventario degli asset utilizzando la P12 Politica di gestione degli asset.
- Applicare restrizioni cloud e requisiti di localizzazione attraverso la P27 Politica di utilizzo del cloud.
- Utilizzare il passaggio 9 di Zenith Blueprint per identificare patrimoni informativi, proprietari, posizioni e sensibilità.
- Utilizzare il passaggio 13 di Zenith Blueprint per mappare i rischi ai controlli nella SoA.
- Utilizzare il passaggio 22 di Zenith Blueprint per applicare i controlli ISO/IEC 27002:2022 5.12 e 5.13 nelle operazioni quotidiane.
- Utilizzare Zenith Controls per mappare le stesse evidenze a GDPR, NIS2, DORA, NIST CSF, COBIT 2019 e standard di supporto.
- Testare l’applicazione delle etichette, le restrizioni di accesso, la registrazione, la DLP e il triage degli incidenti.
- Comunicare alla direzione le prestazioni della classificazione.
- Riesaminare la classificazione dopo modifiche rilevanti a sistemi, processi, fornitori o requisiti normativi.
Questo funziona perché la classificazione diventa il linguaggio comune tra valore aziendale, obbligo legale, controllo tecnico ed evidenza di audit.
Se la vostra organizzazione si sta preparando alla certificazione ISO/IEC 27001:2022, ad assurance GDPR, alla preparazione NIS2, alla due diligence cliente DORA o a un audit di conformità combinato, iniziate con una domanda:
Potete mostrare, per ogni patrimonio informativo critico, che cosa sia, chi ne sia responsabile, dove si trovi, come sia classificato, come sia etichettato, chi possa accedervi, come sia protetto, per quanto tempo sia conservato, quale fornitore lo tocchi e cosa accada se viene esposto?
Se la risposta è non ancora, Clarysec può aiutarvi a costruire la catena delle evidenze in modo rapido e difendibile.
Utilizzate la Politica di classificazione ed etichettatura dei dati - PMI, la P13 Politica di classificazione ed etichettatura dei dati, la P12 Politica di gestione degli asset, la P27 Politica di utilizzo del cloud, la Zenith Blueprint: roadmap in 30 passaggi per auditor e la Zenith Controls: guida alla conformità trasversale per trasformare la classificazione da politica statica a livello operativo di controllo per GDPR Article 32, gestione del rischio cyber NIS2 ed evidenze del rischio ICT DORA.
Il momento migliore per classificare i dati era prima che arrivasse la richiesta di audit. Il secondo momento migliore è prima della prossima migrazione cloud, dell’onboarding dei fornitori, del questionario cliente o dell’incidente.
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
