DLP nel 2026: ISO 27001 per GDPR, NIS2 e DORA

Tutto inizia con un foglio di calcolo.

Alle 08:17 di un lunedì, un responsabile customer success esporta 14.000 contatti aziendali dal CRM per preparare una campagna di rinnovo. Alle 08:24, il foglio di calcolo viene allegato a un’e-mail. Alle 08:26, l’e-mail viene inviata a un account Gmail personale perché il dipendente vuole lavorare durante un viaggio in treno. Alle 08:31, lo stesso file viene caricato su un servizio di note basato su IA non approvato per “ripulire i duplicati”.

Nulla sembra ancora una violazione. Non c’è una nota di ransomware, nessun beacon malware, nessun account amministrativo compromesso e nessuna fuga pubblica di informazioni. Ma per il CISO, il Compliance Manager e il DPO, la domanda reale è già emersa: l’organizzazione può dimostrare che questo spostamento era autorizzato, classificato, registrato, cifrato, giustificato e reversibile?

Lo stesso scenario si ripete ogni settimana nei servizi finanziari. Uno sviluppatore prova a caricare Q1_Investor_Projections_DRAFT.xlsx su uno spazio cloud personale perché la VPN è lenta. Un responsabile commerciale esporta un elenco clienti in un’applicazione di collaborazione consumer. Un analista del supporto incolla registrazioni dei clienti in uno strumento IA non approvato. In tutti i casi, l’intento può essere la praticità anziché la malizia, ma il rischio è lo stesso. Dati sensibili hanno attraversato, o stanno per attraversare, un confine che l’organizzazione non controlla.

Questo è il problema moderno della prevenzione della perdita di dati. La DLP non è più solo una regola del gateway e-mail o un agente endpoint. Nel 2026, una prevenzione della perdita di dati efficace è un sistema di controllo governato e supportato da evidenze, che opera su SaaS, archiviazione cloud, endpoint, dispositivi mobili, fornitori, API, ambienti di sviluppo, esportazioni di backup, strumenti di collaborazione e scorciatoie adottate dagli utenti.

GDPR Article 32 richiede misure tecniche e organizzative adeguate per la sicurezza del trattamento. NIS2 Article 21 richiede misure di cibersicurezza basate sul rischio, tra cui igiene informatica, controllo degli accessi, gestione degli asset, sicurezza della catena di fornitura, gestione degli incidenti, cifratura e test di efficacia. DORA richiede agli enti finanziari di gestire il rischio ICT attraverso governance, rilevazione, risposta, ripristino, test, vigilanza sulle terze parti e verificabilità. ISO/IEC 27001:2022 fornisce l’ossatura del sistema di gestione per rendere questi obblighi operativi, misurabili e verificabili in audit.

L’errore di molte organizzazioni è acquistare uno strumento DLP prima di definire cosa significhi “perdita”. L’approccio di Clarysec parte prima: classificare i dati, definire i trasferimenti consentiti, applicare la policy, monitorare le eccezioni, predisporre le evidenze di risposta e collegare tutto al SGSI.

Come afferma Zenith Blueprint: An Auditor’s 30-Step Roadmap nella fase Controls in Action, Step 19, Technological Controls I:

La prevenzione della perdita di dati riguarda l’arresto della divulgazione non autorizzata o accidentale di informazioni sensibili, che avvenga tramite e-mail, caricamenti cloud, supporti portatili o persino una stampa dimenticata. Il controllo 8.12 affronta la necessità di monitorare, limitare e rispondere a qualsiasi dato che esca dai confini di fiducia dell’organizzazione, indipendentemente dal fatto che sia digitale, fisico o determinato dal comportamento umano. Zenith Blueprint

Questa frase è il cuore della DLP nel 2026: monitorare, limitare e rispondere.

Perché la DLP è ora un tema di conformità a livello di organo di amministrazione

L’organo di amministrazione di solito non chiede se una regex DLP rilevi i numeri di identificazione nazionale. Chiede se l’organizzazione sia in grado di proteggere la fiducia dei clienti, continuare a operare, evitare esposizioni regolatorie e dimostrare una sicurezza ragionevole quando qualcosa va storto.

È qui che GDPR, NIS2 e DORA convergono.

GDPR si applica in modo ampio al trattamento automatizzato dei dati personali, inclusi titolari e responsabili del trattamento stabiliti nell’UE e organizzazioni extra UE che offrono beni o servizi a persone nell’UE o ne monitorano il comportamento. Definisce i dati personali in modo ampio e copre operazioni quali raccolta, archiviazione, utilizzo, divulgazione, cancellazione e distruzione. La divulgazione non autorizzata di dati personali, o l’accesso non autorizzato agli stessi, può costituire una violazione dei dati personali. GDPR Article 5 rende inoltre esplicita la responsabilizzazione: le organizzazioni non devono solo rispettare principi quali minimizzazione dei dati, limitazione della conservazione, integrità e riservatezza, ma devono anche essere in grado di dimostrare la conformità.

NIS2 estende la pressione oltre la privacy. Si applica a molte entità essenziali e importanti, compresi settori quali banche, infrastrutture dei mercati finanziari, fornitori di servizi di cloud computing, fornitori di data center, prestatori di servizi gestiti, servizi di sicurezza gestiti, marketplace online, motori di ricerca e piattaforme di social networking. Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate, comprese analisi dei rischi, policy di sicurezza dei sistemi informativi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, sviluppo sicuro, test di efficacia, igiene informatica, formazione, crittografia, controllo degli accessi, gestione degli asset e autenticazione.

DORA si applica dal 17 gennaio 2025 e funge da regolamento dedicato alla resilienza ICT del settore finanziario. Per gli enti finanziari rientranti nell’ambito di applicazione, è trattato come atto giuridico dell’Unione specifico di settore ai fini delle sovrapposizioni con NIS2. DORA porta la DLP nella gestione del rischio ICT, nella classificazione degli incidenti, nella perdita di dati che incide su disponibilità, autenticità, integrità o riservatezza, nei test di resilienza operativa digitale, nella gestione delle terze parti ICT e nei controlli contrattuali.

La domanda sulla DLP nel 2026 non è “Possediamo uno strumento?”. È:

1. Sappiamo quali informazioni sono sensibili?
2. Sappiamo dove sono archiviate, trattate e trasferite?
3. I percorsi di trasferimento consentiti e vietati sono definiti?
4. Gli utenti sono formati e vincolati tecnicamente?
5. I percorsi cloud e SaaS sono governati?
6. I log sono sufficienti per l’indagine?
7. Gli alert sono sottoposti a triage e gli incidenti classificati rapidamente?
8. I fornitori e i servizi ICT esternalizzati sono vincolati contrattualmente?
9. Possiamo dimostrare che i controlli sono operativi?

ISO/IEC 27001:2022 è particolarmente adatta a rispondere a queste domande perché richiede contesto, requisiti delle parti interessate, valutazione del rischio, trattamento del rischio, obiettivi misurabili, controllo operativo, informazioni documentate, controllo dei fornitori, audit interno, riesame della direzione e miglioramento continuo. Non è uno standard DLP, ma trasforma la DLP da configurazione tecnologica isolata in un processo controllato del sistema di gestione.

La catena di controlli ISO 27001 alla base di una DLP efficace

Un programma DLP credibile non si costruisce su un singolo controllo. Si costruisce su una catena.

Zenith Controls: The Cross-Compliance Guide di Clarysec mappa il controllo ISO/IEC 27002:2022 8.12, prevenzione della perdita di dati, come controllo preventivo e di rilevamento focalizzato sulla riservatezza, allineato ai concetti di cibersicurezza Protect e Detect, con la protezione delle informazioni come capacità operativa e la protezione/difesa come dominio di sicurezza. Zenith Controls

Questo è importante perché gli auditor si aspettano sia blocco sia visibilità. Una regola DLP preventiva senza riesame degli alert è incompleta. Anche un approccio basato solo sulla registrazione degli eventi, senza applicazione per i trasferimenti ad alto rischio, è debole.

La stessa guida mappa il controllo ISO/IEC 27002:2022 5.12, Classificazione delle informazioni, come preventivo, a supporto di riservatezza, integrità e disponibilità, e allineato a Identify. Mappa il controllo 5.14, Trasferimento delle informazioni, come preventivo, a supporto di riservatezza, integrità e disponibilità, e allineato a Protect, Asset Management e Information Protection.

In termini pratici, la catena dei controlli DLP si presenta così:

Lo Zenith Blueprint, Step 22, spiega la dipendenza tra inventario degli asset, classificazione e DLP:

Riesaminare l’inventario degli asset corrente (5.9) per assicurare che includa asset fisici e logici, proprietari e classificazioni. Collegare questo inventario allo schema di classificazione (5.12), assicurando che gli asset sensibili siano etichettati e protetti in modo appropriato. Ove necessario, definire conservazione, backup o isolamento in base alla classificazione.

Per questo Clarysec raramente avvia un incarico DLP dalla messa a punto delle regole. Iniziamo riconciliando asset, proprietari, tipi di dati, etichette di classificazione, percorsi di trasferimento e registrazioni delle evidenze. Se l’organizzazione non sa dire quali set di dati siano riservati, regolamentati, di proprietà del cliente, relativi ai pagamenti o critici per l’operatività, uno strumento DLP può solo fare supposizioni.

I tre pilastri di un programma DLP moderno

Un programma DLP moderno poggia su tre pilastri che si rafforzano a vicenda: conoscere i dati, governare il flusso e difendere il perimetro. Questi pilastri rendono ISO/IEC 27001:2022 praticabile per la conformità a GDPR, NIS2 e DORA.

Pilastro 1: conoscere i dati con classificazione ed etichettatura

Non puoi proteggere ciò che non comprendi. I controlli ISO/IEC 27002:2022 5.12 e 5.13 richiedono alle organizzazioni di classificare le informazioni ed etichettarle in base alla sensibilità e alle esigenze di gestione. Non è un esercizio documentale. È il fondamento dell’applicazione automatizzata.

Per le piccole e medie imprese, la Politica di classificazione ed etichettatura dei dati stabilisce:

Riservato: richiede cifratura in transito e a riposo, accesso ristretto, approvazione esplicita per la condivisione e distruzione sicura allo smaltimento. Politica di classificazione ed etichettatura dei dati - PMI

Questa citazione, tratta dalla sezione “Requisiti di applicazione della policy”, clausola 6.3.3, fornisce al programma DLP quattro condizioni applicabili: cifratura, accesso ristretto, approvazione della condivisione e smaltimento sicuro.

Negli ambienti enterprise, la Politica di classificazione ed etichettatura dei dati è ancora più diretta. Dalla sezione “Requisiti di applicazione della policy”, clausola 6.2.6.2:

Blocco della trasmissione (ad es. e-mail esterna) per dati sensibili etichettati in modo improprio Politica di classificazione ed etichettatura dei dati

E dalla sezione “Applicazione e conformità”, clausola 8.3.2:

Validazione automatizzata della classificazione tramite prevenzione della perdita di dati (DLP) e strumenti di discovery

Queste clausole trasformano la classificazione in un controllo. Un file contrassegnato come Riservato può attivare la cifratura, bloccare la trasmissione esterna, richiedere un’approvazione o generare un alert di sicurezza. La DLP diventa quindi il livello di applicazione di una policy comprensibile a utenti, sistemi e auditor.

Pilastro 2: governare il flusso con il trasferimento sicuro delle informazioni

Una volta classificati i dati, l’organizzazione deve governarne lo spostamento. Il controllo ISO/IEC 27002:2022 5.14, Trasferimento delle informazioni, è spesso trascurato, ma è il punto in cui iniziano molti fallimenti della DLP.

Lo Zenith Blueprint inquadra il controllo 5.14 come la necessità di governare il flusso delle informazioni affinché il trasferimento sia sicuro, intenzionale e coerente con classificazione e finalità aziendale. Ciò si applica a e-mail, condivisione sicura dei file, API, integrazioni SaaS, supporti rimovibili, report stampati e portali dei fornitori.

Il lavoro da remoto rende questo aspetto particolarmente importante. La Politica di lavoro da remoto, sezione “Requisiti di applicazione della policy”, clausola 6.3.1.3, richiede ai dipendenti di:

Utilizzare solo soluzioni di condivisione file approvate (ad es. M365, Google Workspace con controlli di prevenzione della perdita di dati (DLP)) Politica di lavoro da remoto

Per mobile e BYOD, la Politica sui dispositivi mobili e sul Bring Your Own Device (BYOD), sezione “Requisiti di applicazione della policy”, clausola 6.6.4, prevede un’applicazione concreta sugli endpoint:

Le policy di prevenzione della perdita di dati (DLP) devono bloccare caricamenti non autorizzati, acquisizione di schermate, accesso agli appunti o condivisione di dati dalle app gestite verso aree personali. Politica sui dispositivi mobili e sul Bring Your Own Device (BYOD)

Questo è rilevante perché i dati non escono solo tramite e-mail. Escono tramite screenshot, sincronizzazione degli appunti, profili browser non gestiti, spazi personali, funzioni di condivisione mobile, plugin di collaborazione e strumenti IA.

La governance del cloud è altrettanto importante. Nella Politica di utilizzo del cloud per PMI, sezione “Requisiti di governance”, clausola 5.5:

Lo shadow IT, definito come l’uso di strumenti cloud non approvati, deve essere trattato come una violazione della policy e riesaminato dal direttore generale e dal fornitore IT per determinare il rischio e le azioni correttive richieste. Politica di utilizzo del cloud per PMI

Per le organizzazioni enterprise, la Politica di utilizzo del cloud, sezione “Requisiti di governance”, clausola 5.5, innalza il livello di monitoraggio:

Il team di sicurezza delle informazioni deve valutare regolarmente il traffico di rete, l’attività DNS e i log per rilevare l’uso non autorizzato del cloud (shadow IT). Le violazioni rilevate devono essere indagate tempestivamente. Politica di utilizzo del cloud

Lo shadow IT non è solo un fastidio IT. Ai sensi del GDPR può diventare una divulgazione illecita o un trattamento non controllato. Ai sensi di NIS2 è una debolezza di igiene informatica e di sicurezza della catena di fornitura. Ai sensi di DORA può diventare un rischio di terze parti ICT e un problema di classificazione degli incidenti.

Pilastro 3: difendere il perimetro con tecnologia DLP, policy e consapevolezza

Il controllo ISO/IEC 27002:2022 8.12, prevenzione della perdita di dati, è il controllo che la maggior parte delle persone associa alla DLP. Ma in un programma maturo è l’ultima linea di difesa, non la prima.

Lo Zenith Blueprint spiega che la DLP richiede un approccio a tre livelli: tecnologia, policy e sensibilizzazione. La tecnologia include DLP endpoint, sicurezza della posta elettronica, ispezione dei contenuti, sicurezza dell’accesso al cloud, controlli SaaS, controlli browser, filtraggio del traffico in uscita dalla rete e instradamento degli alert. La policy definisce ciò che gli strumenti applicano. La sensibilizzazione assicura che i dipendenti comprendano perché e-mail personali, servizi cloud personali di archiviazione e strumenti IA non approvati non siano modalità accettabili per gestire informazioni regolamentate o riservate.

La componente di risposta è importante quanto la prevenzione. Lo Zenith Blueprint, Step 19, afferma:

Ma la DLP non è solo prevenzione: è anche risposta. Se viene rilevata una potenziale perdita:

✓ Gli alert devono essere sottoposti rapidamente a triage, ✓ La registrazione degli eventi deve supportare l’analisi forense, ✓ Il Piano di risposta agli incidenti deve essere attivato senza ritardo.

Un programma DLP che blocca gli eventi ma non li sottopone a triage, non li indaga e non apprende da essi non è pronto per gli audit. È solo parzialmente implementato.

Dalla perdita del foglio di calcolo a una risposta pronta per l’audit

Torniamo al foglio di calcolo del lunedì mattina.

In un programma debole, l’organizzazione scopre il caricamento tre settimane dopo, durante un riesame privacy. Nessuno sa chi abbia approvato l’esportazione, se i dati fossero dati personali, se fossero coinvolti dati appartenenti a categorie particolari, se lo strumento IA abbia conservato il file o se sia necessario notificare i clienti.

In un programma progettato da Clarysec, la sequenza è diversa.

Primo, l’esportazione dal CRM viene etichettata come Riservato perché contiene dati personali e informazioni commerciali dei clienti. Secondo, l’evento di esportazione viene registrato nei log. Terzo, il gateway e-mail rileva un allegato riservato indirizzato a un dominio e-mail personale e lo blocca, salvo esistenza di un’eccezione approvata. Quarto, il tentativo di caricamento su un servizio cloud non approvato genera un alert di utilizzo del cloud. Quinto, l’alert viene sottoposto a triage rispetto alla procedura di risposta agli incidenti. Sesto, il team di sicurezza determina se vi sia stata una divulgazione effettiva, se i dati fossero cifrati, se il provider li abbia trattati o conservati, se siano soddisfatti i criteri di violazione GDPR e se si applichino le soglie di incidente NIS2 o DORA.

La Politica di registrazione e monitoraggio per PMI, sezione “Requisiti di governance”, clausola 5.4.3, indica al team esattamente cosa dovrebbe essere visibile:

Log degli accessi: accesso ai file (in particolare per dati sensibili o personali), modifiche alle autorizzazioni, utilizzo di risorse condivise Politica di registrazione e monitoraggio - PMI

Questa clausola è breve, ma decisiva. Se l’accesso ai file, le modifiche alle autorizzazioni e l’utilizzo di risorse condivise non sono registrati nei log, l’indagine DLP diventa congetturale.

Ai sensi di NIS2 Article 23, gli incidenti significativi richiedono una segnalazione per fasi: un preallarme entro 24 ore dal momento in cui se ne viene a conoscenza, una notifica dell’incidente entro 72 ore e un rapporto finale non oltre un mese dalla notifica dell’incidente. Ai sensi di DORA, gli Articles 17 to 19 richiedono agli enti finanziari di rilevare, gestire, classificare, registrare, segnalare internamente e notificare gli incidenti gravi connessi alle ICT. La classificazione include la perdita di dati che incide su disponibilità, autenticità, integrità o riservatezza, insieme a clienti interessati, durata, diffusione geografica, criticità e impatto economico. Ai sensi del GDPR, una divulgazione non autorizzata di dati personali può richiedere una valutazione della violazione e, ove siano soddisfatte le soglie, una notifica.

Un alert DLP non è quindi semplicemente un evento di sicurezza. Può diventare una valutazione di violazione privacy, un flusso di gestione degli incidenti NIS2, una classificazione di incidente ICT DORA, un trigger di notifica ai clienti e un pacchetto di evidenze per l’audit.

Controlli DLP per GDPR Article 32

GDPR Article 32 è spesso tradotto in un elenco di misure: cifratura, riservatezza, integrità, disponibilità, resilienza, test e ripristino. Per la DLP, il punto chiave è la protezione lungo il ciclo di vita.

I dati personali si muovono attraverso raccolta, archiviazione, uso, trasferimento, divulgazione, conservazione e cancellazione. GDPR Article 5 richiede minimizzazione dei dati, limitazione della finalità, limitazione della conservazione, integrità, riservatezza e responsabilizzazione. GDPR Article 6 richiede base giuridica e compatibilità della finalità. GDPR Article 9 richiede misure più rigorose per categorie particolari di dati personali.

La DLP supporta questi obblighi quando è collegata alla classificazione dei dati, alle registrazioni del trattamento lecito e ai percorsi di trasferimento approvati.

La Data Masking and Pseudonymization Policy-sme di Clarysec, sezione “Finalità”, clausola 1.2, supporta questo approccio di ciclo di vita:

Queste tecniche sono obbligatorie quando non sono richiesti dati dei sistemi in esercizio, anche in scenari di sviluppo, analisi e servizi di terze parti, al fine di ridurre il rischio di esposizione, uso improprio o violazione. Data Masking and Pseudonymization Policy-sme - PMI

Questo è un controllo pratico per GDPR Article 32. Se sviluppatori, analisti o fornitori non hanno bisogno di dati personali dei sistemi in esercizio, la DLP non dovrebbe essere l’unica barriera. Mascheramento e pseudonimizzazione riducono il raggio d’impatto prima ancora che i dati si muovano.

Una matrice DLP solida e allineata alla privacy dovrebbe mappare i tipi di dati personali su etichette di classificazione, base giuridica, sistemi approvati, metodi di esportazione approvati, requisiti di cifratura, regole DLP, regole di conservazione e trigger di incidente. Questa matrice diventa il ponte tra governance privacy e operatività di sicurezza.

Igiene informatica NIS2 e DLP oltre il team privacy

NIS2 cambia la conversazione sulla DLP perché inquadra la perdita come parte dell’igiene informatica e della resilienza, non solo della privacy.

Article 20 richiede agli organi di gestione delle entità essenziali e importanti di approvare le misure di gestione del rischio di cibersicurezza, supervisionarne l’attuazione e ricevere formazione sulla cibersicurezza. Article 21 richiede misure adeguate e proporzionate in materia di policy, gestione degli incidenti, continuità, catena di fornitura, sviluppo sicuro, test di efficacia, igiene informatica, formazione, crittografia, sicurezza HR, controllo degli accessi e gestione degli asset. Article 25 incoraggia l’uso di norme e specifiche tecniche europee e internazionali pertinenti.

La DLP contribuisce direttamente a queste aree:

La Politica di sicurezza della rete per PMI, sezione “Obiettivi”, clausola 3.4, rende esplicito l’obiettivo relativo all’esfiltrazione:

Prevenire la propagazione del malware e l’esfiltrazione di dati attraverso i canali di rete Politica di sicurezza della rete per PMI

Per NIS2, questo tipo di obiettivo offre agli auditor un percorso di test diretto: mostrare filtraggio del traffico in uscita, monitoraggio DNS, log dei proxy, alert endpoint, tentativi di caricamento bloccati e ticket di indagine.

Lo Zenith Blueprint, Step 23, aggiunge un’azione specifica per il cloud oggi essenziale per i fornitori digitali e ICT coperti da NIS2:

Elencare tutti i servizi cloud attualmente in uso (5.23), incluso lo shadow IT ove noto. Identificare chi li ha approvati e se sia stata eseguita la due diligence. Sviluppare una checklist di valutazione leggera che copra localizzazione dei dati, modello di accesso, logging e cifratura. Per i servizi futuri, assicurare che la checklist sia integrata nel processo di approvvigionamento o di onboarding IT.

Molte organizzazioni falliscono qui. Hanno un ambito del SGSI e un registro dei fornitori, ma non un elenco reale degli strumenti SaaS in cui i dipendenti spostano dati regolamentati o dei clienti. La DLP senza discovery del cloud è cieca.

Rischio ICT DORA: DLP per enti finanziari e fornitori

Per gli enti finanziari, la DLP deve inserirsi nel quadro di riferimento per la gestione del rischio ICT di DORA.

DORA Article 5 richiede un quadro interno di governance e controllo per la gestione del rischio ICT. L’organo di gestione resta responsabile del rischio ICT, delle policy che preservano disponibilità, autenticità, integrità e riservatezza dei dati, della chiarezza dei ruoli ICT, della strategia di resilienza operativa digitale, della tolleranza al rischio ICT, dei piani di continuità e risposta/ripristino, dei piani di audit, delle risorse, della policy per le terze parti e dei canali di segnalazione.

Article 6 richiede un quadro documentato di gestione del rischio ICT che copra strategie, policy, procedure, protocolli ICT e strumenti per proteggere informazioni e asset ICT. Article 9 riguarda protezione e prevenzione. Gli Articles 11 to 14 aggiungono continuità, risposta, ripristino, backup, restoration, controlli di integrità dei dati, lezioni apprese, formazione di sensibilizzazione e comunicazioni di crisi.

La DLP si inserisce in questo quadro come capacità di protezione, rilevazione, risposta e test.

DORA rende inoltre inevitabile il rischio di terze parti. Gli Articles 28 to 30 richiedono gestione del rischio di terze parti ICT, registri dei contratti di servizi ICT, due diligence precontrattuale, requisiti contrattuali, diritti di audit e ispezione, diritti di risoluzione, strategie di uscita, descrizioni dei servizi, sedi di trattamento e archiviazione dei dati, accesso ai dati, ripristino e restituzione, assistenza sugli incidenti, cooperazione con le autorità, misure di sicurezza e condizioni di subappalto.

Per una fintech o una banca, la DLP non può fermarsi al confine di Microsoft 365 o Google Workspace. Deve coprire processori di pagamento, provider di verifica dell’identità, piattaforme CRM, data warehouse, infrastruttura cloud, service desk in outsourcing, fornitori di servizi gestiti e integrazioni SaaS critiche.

Questo è particolarmente importante quando DORA opera come atto giuridico dell’Unione specifico di settore per obblighi NIS2 sovrapposti. I controlli devono comunque esistere. Il percorso di segnalazione e supervisione può essere diverso.

Uno sprint di 90 minuti per una regola DLP

Clarysec utilizza uno sprint pratico con i clienti che devono fare progressi rapidi senza fingere che un intero programma DLP possa essere costruito in una sola riunione. L’obiettivo è implementare un controllo DLP ad alto valore, dalla policy all’evidenza.

Step 1: scegliere un tipo di dati e un percorso di trasferimento

Scegliere “dati personali dei clienti esportati dal CRM e inviati esternamente via e-mail”. Non partire da ogni repository, paese e tipo di dato.

Step 2: confermare classificazione ed etichetta

Usare la policy di classificazione per confermare che questa esportazione è Riservato. In una PMI, la clausola 6.3.3 richiede cifratura, accesso ristretto, approvazione esplicita per la condivisione e distruzione sicura. In un’organizzazione enterprise, la Politica di classificazione ed etichettatura dei dati supporta il blocco della trasmissione di dati sensibili etichettati in modo improprio e la validazione automatizzata tramite DLP e strumenti di discovery.

Step 3: definire il modello di trasferimento consentito

Consentito: esportazione dal CRM inviata a un dominio cliente approvato tramite e-mail cifrata o piattaforma di condivisione sicura dei file approvata, con giustificazione aziendale.

Non consentito: e-mail personale, link pubblici di condivisione file, strumenti IA non approvati e spazi cloud non gestiti.

Questo è allineato allo Zenith Blueprint, Step 22, che afferma:

Se le informazioni “Riservato” non possono lasciare l’azienda senza cifratura, i sistemi e-mail devono applicare policy di cifratura o bloccare la trasmissione esterna.

Step 4: configurare la regola DLP minima

Configurare la piattaforma e-mail o di collaborazione per rilevare l’etichetta riservata, il pattern di dati personali o la convenzione di denominazione del file esportato. Iniziare con il monitoraggio se sono attesi falsi positivi, poi passare al blocco per domini personali e destinatari non approvati.

Step 5: abilitare registrazione degli eventi e instradamento degli alert

Assicurare che i log acquisiscano accesso ai file, modifiche alle autorizzazioni e utilizzo di risorse condivise, come richiesto dalla Politica di registrazione e monitoraggio - PMI. Instradare gli alert alla coda del sistema di ticketing con gravità, tipo di dati, mittente, destinatario, nome file, azione eseguita e revisore.

Step 6: testare tre scenari

Testare un trasferimento cifrato approvato verso un cliente, un trasferimento bloccato verso e-mail personale e un tentativo di caricamento solo in alert verso un dominio cloud non approvato.

Step 7: conservare le evidenze

Salvare il riferimento alla clausola della policy, lo screenshot della regola DLP, i risultati dei test, il ticket di alert, la decisione del revisore e l’approvazione della direzione. Aggiungere il controllo al piano di trattamento del rischio e alla Dichiarazione di Applicabilità.

In termini ISO/IEC 27001:2022, questo esercizio collega la clausola 6.1.2 valutazione del rischio, la clausola 6.1.3 trattamento del rischio, la clausola 8 pianificazione operativa e controllo, l’Allegato A trasferimento delle informazioni, prevenzione della perdita di dati, registrazione degli eventi, monitoraggio, controlli su fornitori e cloud, e la clausola 9 valutazione delle prestazioni.

Mappatura cross-compliance: un programma DLP, più obblighi

Il punto di forza dell’approccio Clarysec è che evita di costruire stack di controllo separati per GDPR, NIS2, DORA, NIST e COBIT. Un programma DLP ben progettato può soddisfare più aspettative se le evidenze sono strutturate correttamente.

NIST CSF 2.0 è utile come livello di comunicazione. La sua funzione GOVERN supporta il tracciamento dei requisiti legali, normativi e contrattuali, la propensione al rischio, l’applicazione della policy, i ruoli e la supervisione. Il metodo dei Profili aiuta le organizzazioni a delimitare la postura attuale e target, documentare le lacune e implementare un piano d’azione. Le funzioni RESPOND e RECOVER supportano il contenimento degli incidenti DLP, l’analisi della causa radice, la conservazione delle evidenze e il ripristino.

COBIT 2019 aggiunge una lente di governance. Un auditor orientato a COBIT chiederà se gli obiettivi DLP siano allineati agli obiettivi aziendali, se la titolarità sia chiara, se esistano indicatori di prestazione, se la propensione al rischio sia definita e se la direzione riceva report significativi.

Come gli auditor testeranno il tuo programma DLP

Gli audit DLP raramente riguardano un singolo screenshot. Background di audit diversi producono aspettative di evidenza diverse.

Un pacchetto di audit DLP solido include dichiarazione di ambito e rischio, schema di classificazione, metodi di trasferimento approvati, regole DLP, approvazioni delle eccezioni, architettura di registrazione degli eventi, procedura di triage degli alert, albero decisionale per la segnalazione degli incidenti, inventario di fornitori e cloud, risultati dei test e registrazioni delle azioni correttive.

Fallimenti DLP comuni nel 2026

I fallimenti DLP più comuni sono operativi, non esotici.

Primo, la classificazione è opzionale o incoerente. Le etichette esistono nella policy, ma gli utenti non le applicano, i sistemi non le fanno rispettare e i repository contengono anni di file sensibili non etichettati.

Secondo, la DLP resta per sempre in modalità solo alert. La modalità solo alert è utile durante la messa a punto, ma un trasferimento ad alto rischio di dati cliente riservati verso e-mail personale dovrebbe alla fine essere bloccato, salvo esistenza di un’eccezione approvata.

Terzo, lo shadow IT è trattato come un fastidio IT invece che come un rischio di protezione dei dati. La Politica di utilizzo del cloud e la Politica di utilizzo del cloud per PMI sono progettate per rendere gli strumenti cloud non approvati visibili, riesaminabili e correggibili.

Quarto, i log non sono sufficienti per l’indagine. Se il team di sicurezza non può ricostruire chi ha avuto accesso, condiviso, scaricato, caricato o modificato autorizzazioni, l’organizzazione non può valutare con sicurezza gli obblighi di segnalazione GDPR, NIS2 o DORA.

Quinto, i fornitori sono fuori dal modello DLP. Gli Articles 28 to 30 di DORA rendono questo aspetto particolarmente pericoloso per gli enti finanziari, ma il problema riguarda ogni settore. I contratti dovrebbero definire localizzazione dei dati, accesso, ripristino, restituzione, assistenza sugli incidenti, misure di sicurezza, subappalto e diritto di audit.

Sesto, la risposta agli incidenti non include scenari DLP. Un’e-mail inviata al destinatario sbagliato, un caricamento SaaS non autorizzato o un’esportazione massiva dal CRM dovrebbero avere un playbook, criteri di gravità e un percorso decisionale di notifica.

Infine, le organizzazioni dimenticano i canali fisici e umani. Lo Zenith Blueprint ricorda che la DLP include comportamento da scrivania pulita, triturazione sicura, code di stampa bloccate, log di audit delle stampanti e sensibilizzazione dei dipendenti. Un programma DLP che ignora carta, screenshot e conversazioni è incompleto.

Costruire un programma DLP di cui gli auditor possano fidarsi

Se il tuo programma DLP è oggi una configurazione di strumenti, il 2026 è l’anno per trasformarlo in un sistema di controllo governato e supportato da evidenze.

Inizia con tre azioni pratiche:

1. Seleziona i tuoi tre principali tipi di dati sensibili, ad esempio dati personali dei clienti, dati delle carte di pagamento e codice sorgente.
2. Mappa dove si muovono, includendo e-mail, SaaS, archiviazione cloud, endpoint, API, fornitori e ambienti di sviluppo.
3. Costruisci una regola DLP applicabile per ciascun tipo di dato, collegata a policy, registrazione degli eventi, risposta agli incidenti e conservazione delle evidenze.

Clarysec può aiutarti ad accelerare questo percorso con Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Zenith Controls: The Cross-Compliance Guide Zenith Controls e policy pronte da adattare come la Politica di classificazione ed etichettatura dei dati Politica di classificazione ed etichettatura dei dati, la Politica di lavoro da remoto Politica di lavoro da remoto, la Politica di utilizzo del cloud Politica di utilizzo del cloud, la Politica di registrazione e monitoraggio per PMI Politica di registrazione e monitoraggio - PMI e la Politica sui dispositivi mobili e sul Bring Your Own Device (BYOD) Politica sui dispositivi mobili e sul Bring Your Own Device (BYOD).

L’obiettivo non è impedire a ogni file di muoversi. L’obiettivo è rendere lo spostamento sicuro l’impostazione predefinita, lo spostamento rischioso visibile, lo spostamento vietato bloccato e ogni eccezione attribuibile.

Scarica i toolkit Clarysec, riesamina il tuo pacchetto di evidenze DLP e prenota una valutazione di preparazione per verificare se i controlli attuali possono reggere l’esame di GDPR Article 32, le aspettative di igiene informatica NIS2 e il riesame del rischio ICT DORA.