Scadenze di notifica

Da quando il soggetto viene a conoscenza dell'incidente significativo, non da quando l'incidente è iniziato. L'articolo 23, paragrafo 4, conta da quel momento sia il preallarme (24 ore) sia la notifica dell'incidente (72 ore).

Ai sensi dell'articolo 23, paragrafo 4, lettera a), il preallarme indica, se del caso, se si sospetta che l'incidente significativo sia causato da atti illegittimi o malevoli e se potrebbe avere un impatto transfrontaliero. I dettagli seguono nella notifica a 72 ore.

No: un mese dopo l'invio della notifica dell'incidente. Se l'incidente è ancora in corso in quel momento, si presenta invece una relazione sui progressi, e la relazione finale entro un mese dalla gestione dell'incidente.

Sì. Un prestatore di servizi fiduciari notifica gli incidenti significativi che incidono sulla fornitura dei suoi servizi fiduciari entro 24 ore da quando ne è venuto a conoscenza, invece che entro 72 ore.

Secondo l'articolo 33 del GDPR, il titolare notifica la violazione dei dati personali all'autorità di controllo senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui ne è venuto a conoscenza, a meno che sia improbabile che presenti un rischio per le persone. Secondo l'articolo 34, se è probabile che presenti un rischio elevato, va comunicata senza ingiustificato ritardo agli interessati. NetSenX prepara per il Suo DPO una notifica ai sensi dell'articolo 33; la decisione e l'invio restano a Lei.

L'articolo 14 del regolamento sulla ciberresilienza obbliga i fabbricanti di prodotti con elementi digitali a notificare, in più fasi, le vulnerabilità attivamente sfruttate nei loro prodotti e gli incidenti gravi che incidono sulla sicurezza di tali prodotti. Per le fasi, i relativi termini e i destinatari delle notifiche si veda il regolamento (UE) 2024/2847, articolo 14. Questi obblighi di notifica si applicano dall'11 settembre 2026. Riguardano i fabbricanti, non le aziende che si limitano a usare i prodotti, anche se l'incidente proprio di un utente può dover essere notificato ai sensi della NIS2 o del GDPR.

Il DORA, il regolamento sulla resilienza operativa digitale (regolamento (UE) 2022/2554), si applica dal 17 gennaio 2025 alle entità finanziarie come banche, assicurazioni, imprese di investimento e istituti di pagamento, e ai fornitori terzi critici di servizi TIC designati in base a esso. L'articolo 19 impone alle entità finanziarie di segnalare all'autorità competente gli incidenti gravi connessi alle TIC, con una notifica iniziale, una relazione intermedia e una relazione finale; i termini sono fissati da norme tecniche adottate ai sensi dell'articolo 20. Per un'entità finanziaria le regole del DORA sugli incidenti TIC prevalgono su quelle generali della NIS2. Se fornisce servizi TIC a un'entità finanziaria, il DORA La raggiunge tramite il contratto: l'articolo 30 elenca le clausole che tali contratti devono contenere, tra cui assistenza in caso di incidente, diritti di audit e piani di uscita. Si aspetti domande dettagliate e clausole dai clienti finanziari.

Un incidente che ha causato o può causare una grave perturbazione operativa dei servizi o perdite finanziarie per l'azienda, oppure che ha colpito o può colpire altre persone o organizzazioni causando perdite materiali o immateriali considerevoli. È il criterio dell'articolo 23, paragrafo 3, e solo gli incidenti significativi vanno notificati. «Può causare» significa che non si aspetta che il danno si verifichi. Per alcuni fornitori digitali, come quelli di cloud, DNS e servizi gestiti, il regolamento di esecuzione (UE) 2024/2690 fissa soglie più precise; per gli altri possono pubblicare indicazioni le leggi e le autorità nazionali. Stabilisca in anticipo, nella procedura di gestione degli incidenti, quali criteri userà, per esempio servizi fermi oltre un certo tempo, dati dei clienti coinvolti o un attore criminale, e chi decide. NetSenX monitora le scadenze una volta presa la decisione; la decisione spetta a Lei.

Di solito non come incidente significativo, ma può esserlo, e si può sempre notificare volontariamente. L'obbligo dell'articolo 23 riguarda gli incidenti significativi: quelli che hanno causato, o avrebbero potuto causare, gravi perturbazioni, perdite finanziarie o danni considerevoli ad altri. Un attacco fermato prima di produrre effetti di norma non soddisfa il criterio, ma uno andato molto vicino, per esempio un ransomware individuato quando aveva già raggiunto il server di backup, può soddisfarlo. La NIS2 distingue anche i quasi incidenti e le minacce informatiche significative, e l'articolo 30 consente di notificarli volontariamente, il che aiuta il CSIRT ad avvisare altri. Registri ogni evento di questo tipo nel registro degli incidenti con il Suo ragionamento, per poter spiegare poi perché ha notificato o no. NetSenX conserva gli avvisi dietro ogni decisione.

Preparando in anticipo tutto ciò che non dipende dall'incidente. Il preallarme dell'articolo 23, paragrafo 4, lettera a), è breve: dice che si è verificato un incidente significativo e, se del caso, se si sospetta che sia dovuto ad atti illegittimi o malevoli e se potrebbe avere un impatto transfrontaliero. I dettagli arrivano nella notifica entro 72 ore. Prepari quindi un modello di una pagina, il canale di notifica e l'accesso al CSIRT o all'autorità nazionale, una persona designata e un sostituto autorizzati a inviarlo, e una regola interna su chi decide che un incidente è significativo. Faccia una prova all'anno. I piccoli team perdono la maggior parte del tempo a capire che cosa è successo, quindi si assicuri che gli avvisi raggiungano qualcuno di notte e nei fine settimana. NetSenX avvia il conto alla rovescia per incidente e tiene in un unico posto gli avvisi con orario, dispositivi e destinazioni.

Un breve elenco di fatti, un canale pronto e una persona autorizzata a inviarlo. Per il preallarme in sé servono: l'ora in cui si è venuti a conoscenza dell'incidente; una descrizione semplice di ciò che è colpito finora; se si sospetta un atto malevolo o illecito; e se altri Paesi potrebbero essere coinvolti. Per la notifica entro 72 ore che segue, inizi subito a raccogliere: gravità e impatto, sistemi e servizi colpiti, indicatori di compromissione come indirizzi malevoli o hash di file, e misure adottate. Tenga dal primo minuto una cronologia di chi ha fatto che cosa. Verifichi se sono coinvolti dati personali, perché può correre in parallelo una notifica GDPR. NetSenX fornisce la parte di rete di questa cronologia: la prima connessione insolita, i dispositivi coinvolti, destinazioni e volumi, e le scadenze dell'articolo 23 calcolate dal momento di conoscenza che Lei registra.

A volte. Secondo l'articolo 23, paragrafo 1, se del caso, i soggetti interessati notificano senza indebito ritardo ai destinatari dei loro servizi gli incidenti significativi che possono ripercuotersi negativamente sulla fornitura di tali servizi. Secondo l'articolo 23, paragrafo 2, ove applicabile, i soggetti comunicano anche ai destinatari potenzialmente interessati da una minaccia informatica significativa le misure che possono adottare e, se del caso, la minaccia stessa. Anche le autorità possono ordinare queste comunicazioni. La legge nazionale stabilisce i dettagli: in Germania il BSI può ordinare di informare i destinatari (articolo 35, comma 1, della BSIG), e i soggetti di settori come finanza, infrastrutture digitali e gestione dei servizi TIC devono informarli delle minacce informatiche significative (articolo 35, comma 2). Contratti e GDPR possono aggiungere obblighi propri. Prepari un modello di messaggio ai clienti nel piano di risposta.

Spesso sì, se sono coinvolti dati personali, anche quando nulla è stato rubato. Il GDPR definisce all'articolo 4, punto 12, la violazione dei dati personali come la violazione di sicurezza che comporta accidentalmente o in modo illecito la distruzione, la perdita, la modifica, la divulgazione non autorizzata o l'accesso ai dati personali. La cifratura da ransomware rende i dati indisponibili, una violazione della disponibilità, e gli attaccanti spesso copiano i dati prima di cifrarli. Secondo l'articolo 33 il titolare notifica la violazione all'autorità di controllo senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui ne è venuto a conoscenza, a meno che sia improbabile che presenti un rischio per le persone, per esempio perché un backup recente ha ripristinato tutto in fretta e nulla è uscito dalla rete. Documenti il ragionamento in entrambi i casi. NetSenX può mostrare se prima della cifratura sono partiti caricamenti insoliti da dispositivi monitorati, il che conta per questa valutazione.

Forse all'autorità, ma spesso non agli interessati. L'articolo 34, paragrafo 3, lettera a), del GDPR esclude la comunicazione agli interessati se il titolare aveva applicato misure, come la cifratura, che rendono i dati incomprensibili a chiunque non sia autorizzato. La notifica all'autorità di controllo dell'articolo 33 è una questione separata: è necessaria salvo che sia improbabile che la violazione presenti un rischio per le persone, e questo dipende dalla robustezza della cifratura, dal fatto che anche la chiave sia stata esposta e dalla disponibilità dei dati per Lei. Se la chiave era sullo stesso portatile rubato, o la cifratura era debole, i dati vanno trattati come esposti. Annoti quali dati erano cifrati, come e dove si trovavano le chiavi. Le prove di rete su che cosa è uscito, e quando, aiutano il DPO a decidere.

Sì per fasi, e in ritardo solo con le motivazioni. L'articolo 33, paragrafo 4, del GDPR consente di fornire le informazioni in fasi successive, senza ulteriore ingiustificato ritardo, quando non è possibile fornirle tutte insieme, e l'articolo 33, paragrafo 1, richiede che una notifica fatta oltre le 72 ore sia corredata dei motivi del ritardo. Non aspetti dunque il quadro completo: invii entro il termine una notifica iniziale con ciò che sa, la natura della violazione, le conseguenze probabili, le misure adottate e i recapiti del DPO, poi la integri man mano che emergono i fatti. Registri quando ne è venuto a conoscenza e perché una parte è arrivata dopo. Le autorità di controllo offrono di solito moduli online che permettono integrazioni, come il Garante in Italia. NetSenX prepara per il Suo DPO una notifica ai sensi dell'articolo 33 a partire dai dati dell'incidente; l'invio spetta a Lei.

Quando il titolare viene a conoscenza della violazione dei dati personali, non quando la violazione è iniziata. L'articolo 33, paragrafo 1, conta le 72 ore dal momento in cui il titolare ne è venuto a conoscenza. Le linee guida del Comitato europeo per la protezione dei dati ritengono che il titolare ne sia a conoscenza quando ha un ragionevole grado di certezza che si è verificato un incidente di sicurezza che ha compromesso dati personali. È ammessa una breve indagine iniziale per stabilirlo, ma deve essere rapida; non si può ritardare la conoscenza evitando di guardare. Un responsabile del trattamento che scopre una violazione deve informare il titolare senza ingiustificato ritardo (articolo 33, paragrafo 2), e il termine del titolare decorre di solito da quando lo viene a sapere. Registri quindi nel registro degli incidenti l'ora esatta in cui qualcuno ha concluso che erano coinvolti dati personali. NetSenX permette di registrare questo momento per incidente e conserva gli avvisi che mostrano quando è iniziata l'attività.

Ogni norma ha la propria notifica, il proprio destinatario e il proprio termine, e un incidente può attivarne più d'una. Un incidente significativo presso un soggetto interessato va al CSIRT o all'autorità competente ai sensi dell'articolo 23 della NIS2; se riguarda dati personali, il titolare lo notifica anche all'autorità di protezione dei dati ai sensi dell'articolo 33 del GDPR; un'entità finanziaria segnala gli incidenti gravi connessi alle TIC ai sensi dell'articolo 19 del DORA anziché della NIS2; e un fabbricante di prodotti può avere obblighi in base al regolamento sulla ciberresilienza, si veda il regolamento (UE) 2024/2847, articolo 14. Alcuni sistemi nazionali offrono un portale unico, ma non dia per scontato che una notifica copra tutto. Tenga un unico fascicolo dell'incidente e generi ogni notifica da lì, così che i fatti coincidano. L'articolo 35 della NIS2 chiede inoltre alle autorità NIS2 di informare le autorità di protezione dei dati delle violazioni di cui vengono a conoscenza. NetSenX monitora le scadenze NIS2 e prepara una bozza di notifica GDPR articolo 33 dagli stessi dati.

Un incidente che un'entità finanziaria classifica come grave secondo i criteri dell'articolo 18 del DORA e le norme tecniche adottate in base a esso. L'articolo 18 elenca criteri come il numero e la rilevanza dei clienti o delle controparti finanziarie colpiti, l'importo o il numero delle operazioni interessate, l'impatto reputazionale, la durata e l'indisponibilità del servizio, la diffusione geografica, le perdite di dati che incidono su disponibilità, autenticità, integrità o riservatezza, la criticità dei servizi colpiti e l'impatto economico. Le norme li traducono in soglie. Vanno segnalati ai sensi dell'articolo 19 solo gli incidenti gravi; le minacce informatiche significative si possono segnalare volontariamente. Inserisca la classificazione nella procedura di gestione degli incidenti, così che la decisione sia rapida, ripetibile e documentata, e concordi con i fornitori TIC come Le forniranno i fatti necessari. I clienti finanziari si aspetteranno lo stesso dai loro fornitori.

Sono fissati dalle norme tecniche adottate ai sensi dell'articolo 20 del DORA, non dal testo del regolamento, quindi per ore e giorni esatti consulti quelle norme e le indicazioni della Sua autorità competente. L'articolo 19, paragrafo 4, fissa la sequenza: una notifica iniziale, una relazione intermedia non appena lo stato dell'incidente originario è cambiato in modo significativo o la sua gestione è cambiata alla luce di nuove informazioni, seguita da notifiche aggiornate secondo necessità, e una relazione finale una volta completata l'analisi delle cause profonde. Le norme stabiliscono anche contenuti e modelli. Poiché i termini sono legati al rilevamento dell'incidente e alla sua classificazione come grave, la rapidità della classificazione conta quanto quella della scrittura. Se è fornitore TIC di un'entità finanziaria, si aspetti che il contratto Le chieda di avvisare il cliente abbastanza presto da permettergli di rispettare questi termini.

Tramite la piattaforma unica di segnalazione che l'ENISA gestisce per il regolamento sulla ciberresilienza. Secondo l'articolo 14 del regolamento (UE) 2024/2847, i fabbricanti di prodotti con elementi digitali notificano tramite questa piattaforma le vulnerabilità attivamente sfruttate dei loro prodotti e gli incidenti gravi che incidono sulla loro sicurezza; la notifica va al CSIRT designato come coordinatore nello Stato membro dello stabilimento principale del fabbricante e all'ENISA. Per fasi, termini e contenuti si veda il regolamento (UE) 2024/2847, articolo 14. Questi obblighi riguardano i fabbricanti, comprese le aziende di software che immettono prodotti sul mercato UE, non le imprese che si limitano a usarli. Gli utilizzatori possono avere proprie notifiche NIS2 o GDPR dopo lo stesso evento. Se sviluppa software, predisponga un processo di gestione delle vulnerabilità e stabilisca chi accede alla piattaforma prima che serva.

Spesso sì, ma è una decisione separata dalle notifiche regolamentari. Un attacco ransomware, un furto di dati, una frode o un'estorsione sono di solito reati, e una denuncia può aiutare nella pratica assicurativa, con la banca che tenta di richiamare un bonifico fraudolento e nelle indagini che collegano il Suo caso ad altri; alcuni assicuratori chiedono gli estremi della denuncia. La denuncia non sostituisce le notifiche al CSIRT, all'autorità competente o al Garante, e queste non sostituiscono la denuncia. Molti Paesi hanno unità specializzate o moduli online; in Italia c'è la Polizia Postale e delle Comunicazioni. Prima di denunciare, concordi con avvocati e società di incident response quali prove consegnare e come conservarle, per non distruggere ciò che serve agli investigatori. Il preallarme NIS2 chiede già se si sospetta un atto illecito o malevolo; la Sua risposta e la denuncia devono essere coerenti.

Le basi sono ovunque le stesse: che cosa è successo, quando, che cosa è stato colpito, quanto è grave, che cosa avete fatto e chi contattare. Secondo l'articolo 23, paragrafo 4, della NIS2, il preallarme indica se si sospetta un atto malevolo o illecito e se l'incidente potrebbe avere un impatto transfrontaliero; la notifica entro 72 ore aggiunge una valutazione iniziale di gravità e impatto e, se disponibili, indicatori di compromissione; la relazione finale aggiunge una descrizione dettagliata, il tipo di minaccia o la causa di fondo, le misure di attenuazione e l'impatto transfrontaliero. Secondo l'articolo 33, paragrafo 3, del GDPR, la notifica descrive la natura della violazione, le categorie e il numero approssimativo di interessati e di registrazioni, le conseguenze probabili, le misure adottate e i recapiti del DPO. Tenga nettamente separati fatti e ipotesi. NetSenX fornisce dalla rete orari, dispositivi, destinazioni e volumi.

Sì, se era significativo o comportava una violazione dei dati personali da notificare; averlo risolto non elimina l'obbligo. L'articolo 23 della NIS2 lega l'obbligo di notifica all'incidente significativo, che sia ancora in corso o no, e i termini decorrono da quando se ne è venuti a conoscenza. Se scopre solo ora che il guasto del mese scorso era un attacco, il termine parte da questa scoperta, e deve notificare tempestivamente spiegando la cronologia. Secondo il GDPR, una violazione che può presentare un rischio per le persone va notificata anche se è stata contenuta; il contenimento può ridurre il rischio e influire sul contenuto. Un incidente risolto si può di solito notificare direttamente con i fatti già noti, ma segua il formato della Sua autorità. Registri separatamente le date di accadimento, di conoscenza e di risoluzione.

Soprattutto ciò che è stato fatto prima e dopo: notifica tempestiva, vera attenuazione e collaborazione. L'articolo 83, paragrafo 2, del GDPR elenca i fattori che le autorità considerano, tra cui natura, gravità e durata della violazione, carattere doloso o colposo, misure adottate per attenuare il danno subito dagli interessati, misure tecniche e organizzative già in atto, violazioni precedenti, grado di cooperazione con l'autorità, categorie di dati interessate e modo in cui l'autorità ha preso conoscenza della violazione, in particolare se è stata notificata. Per le violazioni più gravi le sanzioni possono arrivare a 20 milioni di euro o al 4% del fatturato mondiale annuo secondo l'articolo 83, paragrafo 5. In pratica: notificare in tempo con i fatti, mostrare le misure di sicurezza esistenti, contenere rapidamente la violazione, informare gli interessati quando richiesto e documentare ogni passo. NetSenX aiuta con la cronologia e con una bozza di notifica articolo 33 per il Suo DPO.

Sì, come bozza per il Suo DPO; decidere e inviare restano compiti Suoi. Dai dati dell'incidente NetSenX prepara una bozza con ciò che mostra la rete: quando è stato rilevato il problema e quali dispositivi e destinazioni erano coinvolti. L'articolo 33, paragrafo 3, chiede anche informazioni che ha solo Lei, come le categorie e il numero approssimativo di interessati e registrazioni, le conseguenze probabili, le misure adottate e i recapiti del DPO. Le prove di rete hanno limiti: NetSenX vede connessioni, volumi e destinazioni, non quali file o record siano usciti, quindi il DPO deve completare il contenuto da altre fonti. La bozza fa risparmiare tempo il venerdì sera, quando corre il termine di 72 ore, e mantiene i fatti coerenti con le notifiche NIS2. La verifichi, la completi e la presenti Lei stesso all'autorità di controllo.

Sì, per la parte dei controlli che riguarda lo strumento stesso. I revisori del bilancio e gli auditor ISO o SOC 2 verificano i controlli generali IT: chi ha accesso ai sistemi, come vengono approvate e registrate le modifiche e come vengono monitorati operatività e incidenti. Il registro di audit di uno strumento di sicurezza fornisce prove per la sua parte: chi ha account, chi ha modificato le impostazioni di rilevamento o le regole di notifica, chi ha chiuso o deciso ogni avviso, e quando. In tutti i piani NetSenX tiene un registro di audit di questo tipo, con una conservazione che cresce con il piano. Non registra le modifiche nell'ERP, nei file server o in altri sistemi, che hanno bisogno dei propri log. Esporti l'estratto del periodo di revisione e lo affianchi alle revisioni degli accessi e ai ticket di modifica, così che il revisore veda un quadro coerente.

Con un registro di audit che annoti ogni modifica, chi l'ha fatta e quando, conservato dove non si possa modificarlo di nascosto. Per i Suoi sistemi significa attivare la registrazione delle modifiche su firewall, servizi di directory, console cloud e strumenti di sicurezza, inviare i log a un punto centrale ad accesso limitato e collegare le modifiche a ticket approvati. Gli account amministrativi condivisi rendono impossibile la prova, quindi dia a ogni persona un proprio account nominativo con autenticazione a più fattori. Esamini i log alla ricerca di modifiche inattese, soprattutto fuori orario. Per NetSenX stesso, il registro di audit di tutti i piani annota chi ha modificato impostazioni di rilevamento, regole di notifica o membri del team e chi ha deciso sugli avvisi, con data e ora; può esportarne l'estratto per un revisore. Copre le modifiche fatte in NetSenX, non le impostazioni degli altri sistemi.

Con una semplice dichiarazione di copertura supportata da prove, lacune comprese. Elenchi ogni sede e segmento di rete, se è osservato da un sensore o da un agente, da quando e che cosa copre; poi indichi ciò che non è osservato, come il Wi-Fi ospiti, una filiale o un ambiente cloud, e come lo gestite in altro modo. Alleghi prove: l'elenco dei sensori, un avviso recente da ogni segmento monitorato e la mappa di rete. I revisori si fidano più di una dichiarazione onesta con lacune note che di una pretesa di copertura totale che crolla alla prima domanda. In NetSenX un agente sulla porta mirror di uno switch (SPAN) o su un TAP di rete osserva un intero segmento, e la dashboard mostra quali agenti girano dove; il traffico di un segmento non replicato resta fuori vista, e NetSenX non finge il contrario.

Tutto ciò che accade solo all'interno di quel segmento. Un sensore vede il traffico che riceve; se una porta dello switch non viene replicata verso di esso e sugli host non gira un agente, le connessioni tra dispositivi di quel segmento, come un attaccante che passa da un PC al file server accanto, restano invisibili. Potrebbe ancora vedere il traffico che lascia il segmento attraverso un punto monitorato, verso internet o un'altra sede, ma i passi interni di un'intrusione sono spesso proprio ciò che serve vedere. Decida in base al rischio: replichi prima i segmenti con server, amministrazione, finanza, HR e produzione, poi il resto. Dove la replica non è pratica, faccia girare l'agente sugli host importanti stessi. NetSenX mostra quali segmenti osservano i suoi sensori e agenti, così le lacune sono visibili.

Abbastanza per ricostruire ogni incidente e ogni decisione senza affidarsi alla memoria di qualcuno. Per ogni voce: un riferimento univoco; quando l'incidente è iniziato, quando e con che cosa è stato rilevato, e quando è stato valutato significativo o no; una breve descrizione e i sistemi, servizi e dati colpiti; la valutazione della gravità e chi l'ha fatta; se è stato notificato, a chi e a che ora, con copia delle notifiche; i passi di contenimento, eradicazione e ripristino con orari e responsabili; la causa di fondo; e le lezioni e i cambiamenti seguiti. Registri anche i quasi incidenti, con il motivo della mancata notifica. Tenga il registro protetto da manomissioni e ad accesso controllato. NetSenX alimenta automaticamente la parte di rete: avvisi con orario, dispositivi e destinazioni, scadenze NIS2 per incidente e il registro di audit su chi ha deciso che cosa.

Con una registrazione che colleghi ogni avviso a una decisione, una persona, un orario e una motivazione. I revisori vogliono vedere che gli avvisi non spariscono: ognuno è stato esaminato, classificato come innocuo, in analisi o incidente, e chiuso con una spiegazione. Un foglio di calcolo basta per pochi avvisi, ma non regge con volumi crescenti ed è facile da compilare a posteriori. Usi, dove possibile, il flusso dello strumento stesso, scriva motivazioni brevi invece di stati di una parola e riveda ogni trimestre un campione di avvisi chiusi per verificare la qualità delle decisioni. In NetSenX le decisioni degli analisti sugli avvisi sono registrate nel registro di audit in tutti i piani, con chi ha deciso e quando; dal piano Starter può esportare report PDF per il revisore.

La NIS2 non fissa un periodo unico, quindi lo decida Lei e scriva il perché. Diverse regole vanno nella stessa direzione. Il GDPR impone di documentare ogni violazione dei dati personali (articolo 33, paragrafo 5) per consentire all'autorità di verificare il rispetto delle norme, il che implica conservare la documentazione finché una verifica del genere può ragionevolmente arrivare. Le autorità NIS2 possono chiedere prove di incidenti e notifiche passati, gli assicuratori possono esaminare un sinistro molto dopo l'evento e i termini di prescrizione delle azioni contrattuali e di responsabilità durano anni in molti Paesi. Norme di settore e nazionali possono fissare periodi propri. Un approccio comune è conservare per alcuni anni il registro degli incidenti e le notifiche, e per meno tempo i log grezzi, cancellando i dati personali non più necessari. La conservazione dello storico degli avvisi e del registro di audit di NetSenX dipende dal piano; esporti ciò che deve conservare più a lungo.

Sì, per i segmenti monitorati, ed è spesso più accurata di uno schema disegnato. Una mappa costruita dal traffico osservato mostra quali dispositivi esistono, i nomi che annunciano e chi parla con chi, comprese connessioni che nessuno ha documentato, come una postazione che raggiunge un server che non dovrebbe o la sessione remota di un fornitore. Non mostra ciò che non invia mai traffico, i segmenti senza sensore né l'architettura prevista, quindi conservi lo schema di architettura e lo verifichi con la mappa osservata. In tutti i piani NetSenX costruisce una mappa di questo tipo dal traffico monitorato, con la prima e l'ultima volta in cui è stato visto ogni dispositivo. Prima di mostrarla a un revisore esterno, consideri che cosa rivela: i nomi dei dispositivi possono contenere nomi di dipendenti e la mappa descrive la struttura interna, quindi la mostri a schermo o con un accordo di riservatezza.

Sì. L'articolo 33, paragrafo 5, del GDPR impone al titolare di documentare qualsiasi violazione dei dati personali, comprese le circostanze, le conseguenze e i provvedimenti adottati per porvi rimedio, sia che sia stata notificata all'autorità di controllo sia che no. Lo scopo è consentire all'autorità di verificare in seguito il rispetto delle norme, compresa la Sua decisione che una violazione non presentasse probabilmente un rischio per le persone. Per ogni violazione annoti quindi che cosa è successo, quali dati e persone sono stati coinvolti, perché ha concluso che la notifica era necessaria o no, chi ha deciso e quando, e che cosa ha cambiato. Tenga un registro delle violazioni separato dal registro degli incidenti di sicurezza ma collegato a esso. Le autorità possono chiederlo durante un'ispezione o dopo un reclamo, e la mancata registrazione di una violazione non notificata fa peggiore impressione della violazione stessa. NetSenX conserva le prove degli avvisi dietro ogni voce per il periodo previsto dal piano.

Quando la violazione è suscettibile di presentare un rischio elevato per i loro diritti e le loro libertà. L'articolo 34 del GDPR impone allora al titolare di comunicarla loro senza ingiustificato ritardo, con un linguaggio semplice e chiaro, descrivendo la natura della violazione, le conseguenze probabili, le misure adottate o proposte e i recapiti del DPO. Rischio elevato significa di solito dati che possono causare un danno reale, come documenti d'identità, dati bancari o sanitari, password o informazioni che permettono frodi. L'articolo 34, paragrafo 3, prevede eccezioni: i dati sono stati resi incomprensibili, per esempio con una cifratura robusta; misure successive rendono improbabile il rischio elevato; oppure comunicazioni individuali richiederebbero sforzi sproporzionati, nel qual caso si procede con una comunicazione pubblica. Anche l'autorità di controllo può imporre la comunicazione. Dica alle persone che cosa fare, come cambiare le password o diffidare del phishing.