Un data breach non è soltanto una violazione tecnica. È il momento in cui il dato perde il controllo del titolare e diventa materia prima del cybercrime. Può accadere attraverso un’intrusione, una credenziale rubata, una vulnerabilità non corretta, un ransomware, un account cloud compromesso, un bucket esposto, un repository lasciato pubblico o una configurazione errata. Il risultato operativo resta lo stesso: informazioni che dovevano restare protette diventano accessibili, copiabili, vendibili, ricattabili o riutilizzabili. La distinzione tra data breach e data leak è utile sul piano tecnico, ma non deve ingannare. Il breach richiama l’idea di una violazione attiva: qualcuno entra, supera un controllo, sottrae dati o ottiene accesso non autorizzato. Il leak richiama invece una fuoriuscita, spesso legata a errore, esposizione involontaria, configurazione cloud sbagliata, repository pubblico, link condiviso male o permessi IAM troppo ampi. Tuttavia, dal punto di vista dell’impatto, la gravità non dipende dalla forma della fuoriuscita, ma dal valore dei dati esposti. Il GDPR definisce la violazione dei dati personali come una violazione di sicurezza che comporta accidentalmente o illecitamente distruzione, perdita, modifica, divulgazione non autorizzata o accesso ai dati personali trasmessi, conservati o trattati. Questa definizione è ampia proprio perché include sia eventi dolosi sia eventi accidentali: ciò che conta è la perdita di controllo sul dato personale.
Nel 2026 il problema è più profondo perché i dati non restano fermi. Una volta esfiltrati o esposti, entrano in una filiera secondaria: vengono catalogati, rivenduti, accorpati, arricchiti, usati per phishing, SIM swapping, furto d’identità, credential stuffing, frodi finanziarie, estorsione, accesso iniziale e campagne ransomware. Il dato rubato non si consuma con il primo abuso. Può essere monetizzato più volte, contro la stessa vittima o contro soggetti collegati. Matrice Digitale ha seguito questa trasformazione in casi che mostrano la varietà del fenomeno: dai milioni di dati coinvolti nei breach Medtronic, ADT e Itron alla compromissione di repository e piattaforme come Trellix, Vercel e Instructure, passando per le violazioni che colpiscono Trellix e Zara tra codice sorgente e dati clienti e per gli incidenti in cui Vercel, Rituals e Seiko mostrano la fragilità di account, loyalty program e piattaforme e-commerce. Il data breach è quindi un evento tecnico, giuridico, reputazionale ed economico nello stesso momento. Non riguarda solo la sicurezza del sistema violato, ma la sicurezza futura delle persone i cui dati sono stati esposti. Una password rubata può diventare accesso. Un numero di telefono può diventare SIM swap. Un documento d’identità può diventare frode. Una cartella sanitaria può diventare estorsione. Un elenco clienti può diventare phishing mirato. Un codice sorgente può diventare vulnerabilità futura.
Cosa leggere
Data breach e data leak: due strade diverse verso lo stesso rischio
Il data breach nasce di solito da una compromissione. Un attaccante viola un sistema, ottiene credenziali, sfrutta una vulnerabilità, aggira controlli, entra in un database, copia file o intercetta informazioni. Il breach è quindi associato a una azione ostile, anche se può includere anche accessi accidentali non autorizzati. In un breach, l’organizzazione deve capire come l’attaccante è entrato, quali dati ha visto, cosa ha copiato, quanto tempo è rimasto nell’ambiente e se può ancora accedere. Il data leak, invece, può nascere anche senza un attaccante iniziale. Un bucket cloud pubblico, un file Excel caricato su un server indicizzabile, un repository GitHub con chiavi API, un database Elasticsearch esposto, una cartella condivisa senza autenticazione o un link pubblico non protetto possono rendere disponibili dati sensibili senza che qualcuno abbia “sfondato” il perimetro. Tuttavia, appena quei dati vengono trovati, copiati o indicizzati, il leak diventa potenzialmente indistinguibile da un breach nei suoi effetti. Questa distinzione è importante per la difesa. Contro il breach servono controlli attivi: vulnerability management, MFA, EDR, logging, rilevazione anomalie, hardening, segmentazione e risposta agli incidenti. Contro il leak servono governance, configurazione corretta, CSPM, DLP, secret management, controllo dei permessi, scanning continuo, code review e revisione degli ambienti cloud. Il primo scenario è spesso attacco. Il secondo è spesso esposizione. Ma entrambi possono produrre lo stesso danno. Il caso dei documenti italiani pubblicati online e analizzato da Matrice Digitale in Anonymous Algeria e documenti italiani su Telegram mostra la parte più concreta del problema: una volta che scansioni, fotografie e documenti personali circolano in canali pubblici o semi-pubblici, la discussione non riguarda più solo la causa della fuoriuscita. Riguarda il rischio successivo per le persone coinvolte. Nel cloud, questa distinzione diventa ancora più sottile. Un token rubato può generare breach. Un bucket pubblico può generare leak. Una API con permessi eccessivi può produrre entrambe le cose. Un’integrazione SaaS lasciata attiva dopo la fine di un contratto può diventare accesso non autorizzato. La guida Matrice Digitale sulla Cloud Security ha chiarito una dinamica ormai evidente: l’identità e la configurazione sono il nuovo perimetro del dato.
Il valore del record underground: perché un dato rubato non vale mai zero
Nel mercato underground, il dato viene valutato in base a freschezza, completezza, sensibilità, rarità e possibilità di riutilizzo. Un indirizzo email isolato ha valore basso. Un indirizzo email associato a password, numero di telefono, ruolo aziendale, documento, codice fiscale, indirizzo fisico, IBAN, cronologia acquisti o dato sanitario vale molto di più. Il valore cresce quando il record permette azione criminale successiva. Un database clienti può alimentare phishing mirato. Un dump di credenziali può alimentare credential stuffing. Un set di documenti può alimentare furto d’identità. Un elenco di dipendenti può alimentare vishing e business email compromise. Un archivio sanitario può alimentare ricatti e frodi assicurative. Un repository di codice può svelare chiavi, endpoint, logica applicativa e vulnerabilità. Un dataset cloud può contenere token, API key e segreti operativi. Questa monetizzazione produce un mercato stratificato. I Data Broker criminali acquistano e rivendono pacchetti di informazioni. Gli Initial Access Broker usano credenziali, token e sessioni per entrare nelle reti aziendali e vendere l’accesso a gruppi ransomware o affiliati. I gruppi di data extortion minacciano la pubblicazione dei dati se la vittima non paga. Gli operatori di phishing usano i record per costruire messaggi credibili. I truffatori finanziari cercano dati bancari e documenti. Gli attori più sofisticati incrociano fonti diverse per costruire profili ad alto valore. Europol descrive il commercio illecito dei dati come un ciclo in cui i criminali rubano, vendono e riutilizzano informazioni personali e aziendali, trasformando i dataset sottratti in strumenti per ulteriori frodi, intrusioni e campagne di social engineering. Matrice Digitale ha osservato questa economia nei casi su ShinyHunters e furti dati massivi in ambienti cloud e SaaS, sulle violazioni che coinvolgono Medtronic, ADT e Itron e sulle campagne in cui Trellix e Zara diventano bersagli tra codice sorgente e dati clienti. Il punto comune è che il dato non viene rubato solo per essere pubblicato: viene rubato per essere riutilizzato come infrastruttura criminale.
Dark web, Telegram e leak site: dove finisce il dato violato
Dopo un breach o un leak, i dati possono prendere strade diverse. Possono finire su forum underground, marketplace dark web, canali Telegram, leak site ransomware, gruppi privati, archivi condivisi, paste site o piattaforme di rivendita. La scelta del canale dipende dal tipo di dato, dal modello criminale e dalla strategia di monetizzazione. Il dark web resta centrale per i mercati più strutturati, dove reputazione, escrow, storico delle vendite e specializzazione contano. I leak site dei gruppi ransomware servono invece a generare pressione pubblica: la vittima viene esposta, il countdown viene mostrato, i campioni vengono pubblicati e l’intero processo diventa spettacolo dell’estorsione. Telegram ha un ruolo diverso: velocità, facilità di creazione dei canali e distribuzione rapida lo rendono utile per vendite veloci, propaganda criminale, leak frammentari o diffusione di materiali. Questa pluralità rende difficile la bonifica. Chiudere un canale non cancella i dati. Bloccare un dominio non elimina le copie. Sequestrare un leak site non garantisce che un affiliato non abbia già rivenduto il pacchetto. Una volta che il dato è stato copiato, la vittima non può più applicare un vero “restore” della riservatezza. Può solo ridurre il danno, notificare, avvisare gli interessati, ruotare credenziali, monitorare abusi e rafforzare i controlli. Il caso Vercel, Rituals e Seiko mostra quanto sia ampio il valore dei dati commerciali, dagli account compromessi ai programmi loyalty. Il caso ITA Airways, Garante e breach Volare ricorda invece che dati apparentemente meno “esplosivi” di una carta di credito possono comunque alimentare phishing, profilazione e truffe mirate. Nel ransomware, questa dinamica è ancora più brutale. La pubblicazione sul leak site serve a dimostrare che il gruppo possiede davvero i dati e a spingere la vittima verso la negoziazione. La guida Matrice Digitale su i signori del ransomware spiega perché la cifratura sia ormai solo una parte dell’estorsione: il dato pubblicabile vale quanto, e spesso più, della chiave di decriptazione.
Criptovalute e riciclaggio: il pagamento del dato rubato
Il pagamento dei dati rubati, degli accessi iniziali e dei riscatti avviene spesso tramite criptovalute. Bitcoin resta una valuta storica del cybercrime, ma non garantisce anonimato assoluto: offre pseudonimato e tracciabilità pubblica della blockchain, che può essere analizzata dalle autorità. Monero e altre soluzioni orientate alla privacy offrono livelli più elevati di opacità, mentre mixer, bridge, stablecoin, exchange offshore e servizi OTC complicano ulteriormente il tracciamento. Il punto non è che la criptovaluta sia criminale in sé. Il punto è che l’ecosistema dei virtual asset può essere abusato per trasferire valore rapidamente, oltre confine e fuori dai circuiti bancari tradizionali. I proventi di un data breach possono essere incassati come pagamento diretto per il database, come riscatto per evitare pubblicazione, come acquisto di accesso iniziale o come compenso per servizi criminali accessori. Il FATF considera i virtual asset e i VASP un ambito rilevante per gli obblighi antiriciclaggio e contrasto al finanziamento illecito, proprio perché i trasferimenti digitali possono essere usati per muovere proventi criminali se non adeguatamente presidiati. La relazione con i data breach è diretta. Un Data Broker vende pacchetti di record. Un Initial Access Broker vende accessi ottenuti dai dati. Un affiliato ransomware usa quei dati per aumentare la pressione. Un riciclatore muove i proventi. Ogni passaggio può essere pagato in crypto. È una catena in cui il valore del record underground si trasforma in liquidità criminale. Matrice Digitale ha collegato questa economia al pillar su cybercrime, ransomware, dark web e criptovalute e alla guida su DORA, rischio ICT e supply chain finanziaria, dove la resilienza operativa non può essere separata dalla gestione del rischio di terze parti e dagli incidenti digitali. Nel settore finanziario, un data breach può diventare anche problema di frode, riciclaggio, compliance e continuità.
GDPR, NIS2 e DORA: quando la violazione diventa responsabilità
Dal punto di vista regolatorio, la distinzione tra breach doloso e leak accidentale conta meno dell’impatto. Se dati personali, servizi essenziali o funzioni finanziarie vengono compromessi, l’organizzazione deve dimostrare di aver adottato misure adeguate, di aver rilevato l’incidente, di aver valutato il rischio, di aver notificato quando necessario e di aver contenuto il danno. Il GDPR impone al titolare del trattamento di notificare la violazione dei dati personali all’autorità di controllo senza ingiustificato ritardo e, quando possibile, entro 72 ore da quando ne è venuto a conoscenza, salvo che la violazione sia improbabile che presenti un rischio per i diritti e le libertà delle persone fisiche. Il Garante Privacy ricorda inoltre che le notifiche oltre le 72 ore devono essere accompagnate dai motivi del ritardo. La NIS2, recepita in Italia nel quadro ACN, sposta il tema dagli interessati ai servizi essenziali e importanti. Per i soggetti rientranti nel perimetro, gli incidenti significativi devono essere gestiti con procedure di notifica verso CSIRT Italia e con una governance documentata. ACN indica che la nuova normativa NIS è in vigore dal 16 ottobre 2024 e individua l’Agenzia come autorità competente NIS e punto di contatto unico nazionale. Il DORA aggiunge un livello specifico per il settore finanziario. Dal 17 gennaio 2025, le entità finanziarie rientranti nel perimetro devono segnalare gli incidenti ICT rilevanti secondo il quadro della resilienza operativa digitale. Banca d’Italia indica che le entità finanziarie di cui all’articolo 2 del DORA sono tenute a segnalare tutti gli incidenti ICT gravi e, su base volontaria, le minacce informatiche significative.
Questi tre livelli non si escludono. Un’unica violazione può generare obblighi GDPR se coinvolge dati personali, obblighi NIS2 se colpisce un soggetto essenziale o importante, obblighi DORA se riguarda una entità finanziaria o un servizio ICT critico per il settore. La stessa fuoriuscita di dati può quindi diventare contemporaneamente evento privacy, incidente cyber, rischio operativo, problema di terze parti e crisi reputazionale.
Matrice Digitale ha già costruito i collegamenti utili per questa lettura integrata nella guida al GDPR dentro il quadro dei dati personali e della compliance, nell’approfondimento su NIS online e piattaforma ACN, nella guida definitiva al DORA e nel caso su Garante Privacy e delega per le violazioni dati. La compliance non è più un adempimento separato dalla threat intelligence: è il modo in cui l’organizzazione dimostra di aver capito il rischio.
Come si misura la gravità di una violazione dati
La gravità di un data breach o di un data leak non si misura soltanto con il numero dei record. Il volume conta, ma non basta. Mille cartelle cliniche possono essere più gravi di un milione di email generiche. Un singolo file contenente chiavi API può essere più pericoloso di un grande archivio di dati pubblici. Un database con documenti, numeri telefonici e indirizzi può generare più rischio di un elenco anonimo. La valutazione deve incrociare almeno quattro fattori: volume, sensibilità, facilità di abuso ed esposizione pubblica. Il volume indica quante persone, account, record o documenti sono coinvolti. La sensibilità indica se i dati riguardano salute, finanza, identità, minori, credenziali, segreti industriali o informazioni strategiche. La facilità di abuso indica se quei dati possono essere usati subito per frodi, phishing, accesso o estorsione. L’esposizione pubblica indica quanto tempo i dati sono rimasti accessibili e quanto si sono diffusi.
Una formula concettuale può aiutare a leggere il rischio:
Gravità = volume dei record × sensibilità del dato × facilità di abuso ÷ tempo di rilevamento e contenimento
Non è una formula normativa, ma descrive bene la logica operativa. Più il dato è sensibile, più è numeroso, più è facile da usare e più a lungo resta esposto, maggiore è il danno. Al contrario, rilevamento rapido, contenimento efficace, cifratura robusta, token revocati, password resettate e comunicazione tempestiva possono ridurre l’impatto.
Il caso Medtronic, ADT e Itron mostra il punto con chiarezza: dati sanitari, clienti, dipendenti e infrastrutture energetiche hanno pesi diversi ma convergono sullo stesso problema. Non conta solo “quanto” è stato esposto. Conta che cosa può fare un attaccante con ciò che è stato esposto. Questa valutazione è essenziale anche per decidere la notifica. Un’organizzazione deve capire se la violazione comporta rischio o rischio elevato per le persone, se coinvolge servizi essenziali, se impatta continuità, se richiede comunicazione agli interessati, se va segnalata a CSIRT Italia o ad autorità settoriali, e se coinvolge fornitori o clienti. La gestione del breach è quindi un processo di analisi, non una comunicazione automatica.
Difesa attiva contro il data breach
La difesa contro il data breach parte dall’ipotesi che l’attaccante tenti di entrare. Il primo livello è Zero Trust Architecture: nessun utente, dispositivo, workload o sessione deve essere considerato sicuro per il solo fatto di trovarsi dentro la rete. L’accesso deve essere continuo, contestuale, verificato e limitato. Questo approccio riduce il rischio che una credenziale rubata diventi accesso illimitato a database, file server e ambienti cloud. Il secondo livello è identity security. MFA resistente al phishing, conditional access, rotazione dei token, controllo delle sessioni, protezione degli account privilegiati e monitoraggio dei login anomali sono essenziali perché molti breach moderni non iniziano da un exploit, ma da una identità compromessa. Una password rubata, un cookie sottratto o un token OAuth abusato possono valere più di una vulnerabilità zero-day. Il terzo livello è Endpoint Detection and Response. Un EDR non deve limitarsi a rilevare malware, ma deve osservare comportamenti: compressione anomala di archivi, accesso massivo a file, esecuzione di strumenti di esfiltrazione, uso sospetto di PowerShell, creazione di processi inconsueti, connessioni verso server esterni, download di database e movimenti laterali. Il data breach spesso produce segnali prima dell’esfiltrazione completa. Il quarto livello è vulnerability management. Le vulnerabilità sfruttate su VPN, firewall, applicazioni web, CMS, sistemi di collaborazione, repository e appliance perimetrali restano tra le cause principali di accesso iniziale. La guida Matrice Digitale su CISA e catalogo KEV spiega perché una vulnerabilità osservata in attacchi reali non può restare in fondo alla coda di patching. Il quinto livello è segmentazione dei dati. Non tutti gli utenti devono vedere tutti i database. Non tutte le applicazioni devono accedere a tutti i record. Non tutti gli account di servizio devono esportare dati. La segmentazione non riguarda solo la rete: riguarda tabelle, bucket, cartelle, API, log, backup e ambienti di sviluppo. Un breach diventa catastrofico quando un singolo accesso apre l’intero patrimonio informativo.
Hardening e governance contro il data leak
La difesa contro il data leak richiede una logica diversa. Qui il nemico non è sempre un attaccante esterno. Può essere un errore di configurazione, un permesso eccessivo, un link condiviso, un repository pubblico, un backup lasciato online, un ambiente di test popolato con dati reali o una chiave API caricata per sbaglio nel codice sorgente. Il primo controllo è il Cloud Security Posture Management. Gli strumenti CSPM scansionano ambienti cloud alla ricerca di bucket pubblici, regole IAM eccessive, database esposti, security group permissivi, chiavi non ruotate, log disattivati e configurazioni non conformi. Nel cloud, la velocità di creazione delle risorse è un vantaggio operativo ma anche un rischio: un singolo bucket pubblico può esporre milioni di record. Il secondo controllo è il Data Loss Prevention. I sistemi DLP identificano dati sensibili, ne monitorano il movimento e possono bloccare trasferimenti non autorizzati verso email personali, storage esterni, endpoint non gestiti, canali web o repository pubblici. Un DLP efficace non deve essere solo strumento repressivo, ma parte di una mappa più ampia: sapere dove si trovano i dati, chi li usa e perché. Il terzo controllo è il secret management. Chiavi API, token, password, certificati e credenziali non devono vivere nel codice sorgente, nei file di configurazione, nei ticket, nei log o nei repository. Devono essere gestiti tramite vault, rotazione, accessi temporanei, logging e policy di scadenza. Una chiave pubblicata per errore può trasformare un leak in breach nel giro di pochi minuti. Il quarto controllo è la data minimization. Molte aziende conservano troppi dati, troppo a lungo, in troppi luoghi. Ogni copia aumenta la superficie di esposizione. Ridurre i dati non necessari, pseudonimizzare, anonimizzare quando possibile, separare ambienti di test e produzione, eliminare backup obsoleti e limitare export massivi riduce la gravità di eventuali fuoriuscite. Il quinto controllo è la governance dei fornitori. Molti leak nascono da terze parti, integrazioni SaaS, partner regionali, piattaforme di analytics o ambienti gestiti esternamente. Il caso Vercel, Rituals e Seiko e le violazioni trattate nella guida sul ransomware e cloud-crime mostrano che il dato può uscire anche da un perimetro indiretto. La supply chain non è un dettaglio contrattuale: è una estensione reale del rischio.
Perché il backup non risolve la violazione della riservatezza
Il backup protegge la disponibilità, non la riservatezza. Questa distinzione è fondamentale. Se un ransomware cifra i sistemi, un backup offline, immutabile e testato può permettere di ripristinare. Ma se prima della cifratura l’attaccante ha copiato i dati, il backup non può recuperarli dalla rete criminale. Può ridurre il downtime, ma non cancellare l’esfiltrazione. È per questo che il ransomware moderno punta alla doppia estorsione. Il backup riduce il potere della cifratura, quindi gli attaccanti spostano la pressione sui dati rubati. Se la vittima non paga per la chiave, viene minacciata con pubblicazione, vendita o contatto diretto di clienti e partner. Il valore dell’attacco si sposta dalla disponibilità alla reputazione. La guida Matrice Digitale su i signori del ransomware mostra questo passaggio: LockBit, BlackCat, Scattered Spider, ShinyHunters e altri cluster non cercano solo di bloccare sistemi, ma di costruire leva su dati, identità, supply chain e cloud. Il backup resta indispensabile, ma non è una risposta completa. La protezione della riservatezza richiede cifratura robusta, controlli di accesso, logging delle letture massive, DLP, segmentazione, mascheramento, tokenizzazione, monitoraggio delle esportazioni, gestione dei privilegi e analisi dei comportamenti. Se un utente può scaricare tutto, se un account di servizio può leggere tutto, se un bucket contiene tutto e se i log non mostrano nulla, il breach è solo questione di tempo.
Incident response: le prime ore dopo la scoperta
Quando emerge un data breach o un data leak, le prime ore sono decisive. L’organizzazione deve evitare due errori opposti: minimizzare senza prove o comunicare senza sapere. Serve invece una procedura già preparata, con ruoli chiari, raccolta evidenze, contenimento tecnico, valutazione legale, comunicazione interna e decisione sulla notifica. La prima attività è preservare le evidenze. Log, snapshot, accessi, query, export, configurazioni, regole IAM, token, chiavi, ticket, email e alert devono essere conservati. Se l’organizzazione cancella o sovrascrive log, perde la possibilità di capire cosa è accaduto. La seconda attività è contenere: revocare token, bloccare accessi, chiudere bucket, disabilitare integrazioni, ruotare credenziali, isolare sistemi, fermare export e limitare la propagazione. La terza attività è qualificare i dati coinvolti. Non basta dire “abbiamo avuto un breach”. Bisogna capire quali categorie di dati sono state esposte, quanti soggetti sono coinvolti, se i dati erano cifrati, se includono credenziali, se riguardano minori, salute, finanza, documenti, dipendenti, clienti o fornitori. Questa valutazione guida notifica, comunicazione e mitigazione. La quarta attività è decidere gli obblighi. GDPR, NIS2, DORA, contratti con clienti, assicurazione cyber e norme settoriali possono imporre comunicazioni diverse. La guida Matrice Digitale su law enforcement e cybercrime ricorda inoltre che, nei casi di reato informatico, la collaborazione con le autorità può diventare parte della risposta, non un passaggio accessorio. La quinta attività è proteggere le persone coinvolte. Se sono esposte password, vanno resettate. Se sono esposti documenti, bisogna avvisare sui rischi di furto d’identità. Se sono esposti dati sanitari o finanziari, servono misure aggiuntive. Se il breach coinvolge clienti o dipendenti, la comunicazione deve essere chiara, tempestiva e utile. Nascondere il problema peggiora quasi sempre l’impatto.
FAQ su data breach e data leak
Un data leak è meno grave di un data breach?
No, un data leak non è automaticamente meno grave di un data breach. La gravità dipende da volume, sensibilità, esposizione e possibilità di abuso dei dati. Un bucket pubblico con dati sanitari può essere più grave di un’intrusione limitata su una macchina isolata.
Qual è la differenza tra data breach e data leak?
Il data breach indica una violazione di sicurezza che porta ad accesso, divulgazione o sottrazione non autorizzata di dati. Il data leak indica una fuoriuscita o esposizione, spesso accidentale o legata a configurazioni errate. Sul piano dell’impatto, entrambi possono produrre lo stesso danno.
Come si calcola la gravità di una violazione dati?
La gravità si valuta incrociando volume dei record, sensibilità delle informazioni, facilità di abuso, durata dell’esposizione e capacità di contenimento. Dati sanitari, finanziari, documenti, credenziali e token hanno peso maggiore perché possono generare frodi, estorsione e furto d’identità.
Il backup protegge da un data breach?
No, il backup protegge la disponibilità dei dati, non la riservatezza. Permette di ripristinare sistemi cifrati o cancellati, ma non può recuperare dati già copiati da un attaccante. Per proteggere la riservatezza servono access control, DLP, cifratura, logging e segmentazione.
Quando va notificato un data breach al Garante Privacy?
Un data breach va notificato al Garante quando presenta un rischio per i diritti e le libertà delle persone fisiche. La notifica deve avvenire senza ingiustificato ritardo e, ove possibile, entro 72 ore dalla conoscenza della violazione, salvo casi improbabili di rischio.
Che ruolo ha la NIS2 nelle violazioni dati?
La NIS2 riguarda gli incidenti che impattano soggetti essenziali e importanti, servizi critici e sicurezza delle reti. Un breach può generare obblighi NIS2 se incide su continuità, sicurezza o servizi regolati. In Italia, il riferimento operativo è ACN con CSIRT Italia.
Che ruolo ha il DORA nei data breach?
Il DORA riguarda il settore finanziario e impone gestione del rischio ICT, segnalazione degli incidenti gravi, resilienza operativa, test e controllo dei fornitori ICT. Un data breach nel settore finanziario può diventare incidente ICT rilevante se impatta servizi, dati, continuità o terze parti critiche.
Perché i dati rubati finiscono nel dark web?
I dati rubati finiscono nel dark web o in canali underground perché possono essere venduti, accorpati e riutilizzati per phishing, SIM swapping, credential stuffing, frodi, furto d’identità e ransomware. Il dato violato diventa una merce, non solo una prova dell’attacco.
Quali controlli riducono il rischio di data leak?
I controlli principali sono CSPM, DLP, secret management, revisione IAM, cifratura, data minimization, controllo dei repository, scansione dei bucket, logging degli accessi e governance dei fornitori. Il data leak si previene soprattutto riducendo esposizioni accidentali e permessi eccessivi.
Cosa fare nelle prime ore dopo una violazione dati?
Bisogna preservare le evidenze, contenere l’esposizione, revocare token, ruotare credenziali, qualificare i dati coinvolti, valutare obblighi di notifica, coinvolgere legale e sicurezza, informare le autorità quando necessario e preparare comunicazioni chiare per interessati, clienti o partner.
Iscriviti alla Newsletter
Non perdere le analisi settimanali: Entra nella Matrice Digitale.
Matrice Digitale partecipa al Programma Affiliazione Amazon EU. In qualità di Affiliato Amazon, ricevo un guadagno dagli acquisti idonei. Questo non influenza i prezzi per te.
