Garante & email: se 7 giorni vi sembran pochi

Non ce la posso farcela!

Ho appena finito di “elogiare” l’AGICOM per l’ennesima implementazione a mentula canis del “piracy shield de no artri”, che mi trovo a dover confrontarmi con la ennesima trovata italica, questa volta del GPDP.

Provvedimento del 21 dicembre 2023 – Documento di indirizzo “Programmi e servizi informatici di gestione della posta elettronica nel contesto lavorativo e trattamento dei metadati” [9978728]

Intendiamoci io capisco che occorra imporre delle limitazioni per legge sull’uso distorto e non autorizzato di dati, e che queste non necessariamente siano coerenti con gli sviluppi tecnologici, ma ogni tanto metterci un po di cervello non guasterebbe. Qui il riferimento più che al garante va ai DPO e responsabili aziendali che, per mettersi in una “posizione sicura” interpretano certi indirizzi in maniera rigida e decontestualizzata.

Allora vediamo di cosa si tratta questa volta:

A seguito di alcune sentenze, e alle considerazioni che già il garante aveva espresso in passato, il garante stesso si è posto il problema dei cosiddetti “metadati” della posta elettronica.

I metadati

I metadati sono, fondamentalmente, tutto quello che concerne la descrizione di un messaggio di posta elettronica, fatta eccezione dei contenuti. Vengono ricavati durante la transazione SMTP (il protocollo che serve al trasferimento dei messaggi della posta elettronica), le intestazioni tecniche del messaggio di posta elettronica stesso (fate riferimento ai miei Email files per capirne di più), e i log dei nodi attraverso cui passa il messaggio fino al raggiungimento (o meno) della casella di posta dell’utente.

Questi dati, se non gestiti correttamente ed usati in maniera non legale, possono dare adito a processi che violano la riservatezza di mittente e destinatario, e possono consentire un monitoraggio non legittimo, ad esempio, delle attività dei lavoratori ai sensi dello statuto dei lavoratori.

I metadati quindi possono e devono essere oggetto di attenta considerazione.

Ma

Ma, ettepareva, c'è un ma.

io me

I metadati sono anche fondamentali per il funzionamento delle soluzioni che gestiscono la posta, e tra queste esigenze vi è una roba che, sempre per esigenze anche delle normicciuole sulla protezione dei dati, si chiama sicurezza.

Esiste quindi un esigenza di capire quanti metadati vanno tenuti per preservare le esigenze di riservatezza verso quanti servano per il corretto funzionamento dei sistemi.

Il garante ci da una prima risposta: 7 giorni

il garante

Infatti, il Garante ha analizzato (in precedenti provvedimenti) quale fosse il tempo di conservazione dei metadati compatibile con l’attività di raccolta e conservazione degli stessi metadati necessari ad assicurare il funzionamento delle infrastrutture del sistema della posta elettronica e che rispettasse il principio di accountability e il comma 2 dell’art. 4 dello Statuto dei Lavoratori. La conclusione del Garante è stata – appunto –  in poche ore o ad alcuni giorni, in ogni caso non oltre sette giorni, estensibili, in presenza di comprovate e documentate esigenze che ne giustifichino il prolungamento, di ulteriori 48 ore.

Sarei curioso di capire quale sia la componente “tecnica” sottesa a tale valutazione. e metto le virgolette a ragion veduta.

Limitarsi a 7 giorni di metadati è, di per se, una stupidata galattica. Non me ne voglia il garante ed i suoi illuminati esperti, ma evidentemente non hanno mai avuto a che fare con la posta elettronica sia dal punto di vista gestionale che tecnico, e si vede.

Sono pronto a discutere della cosa con qualsiasi “esperto” che ritenga che i 7 giorni siano piu che sufficienti.

Vi sono ottime ragioni per considerare tale finestra temporale inadatta, facciamo qualche esempio:

• Cosa succede se occorre fare ricerca di un messaggio, si pensi ad esempio a problematiche legali in cui le email possano essere oggetto della contesa, risalente a problemi anteriori ai 7 (+2) giorni?
• Cosa succede se occorre fare troubleshooting di problematiche che si protraggono nel tempo e che richiedono, ad esempio, l’analisi di log di server e MTA?
• Cosa succede se occorrono informazioni per monitorare i livelli di sicurezza del sistema?
• Cosa succede se per motivi di sicurezza si cerca di capire quale sia la esposizione al rischio degli utenti in funzione delle metriche di attacco che avvengono sulla posta medesima?

Potrei continuare, ma sono sicuro che i più (voglio essere positivo) hanno capito la problematica.

Ma siccome sono duro di comprendonio mi chiedo:

Tali metadati hanno esigenze di vita diverse se si parla di un Mail Server o di un security gateway?  

Le due cose solo marginalmente coincidono (la condivisione, ad esempio, del protocollo SMTP e la modifica degli Header di posta)

Alcuni dei metadati citati sono, quantomeno, da meglio definire ad esempio:

Cosa si intende per mittente? il campo “from: ” nella intestazione tecnica o il campo “from: ” in quella visibile?

No signor tenente non coincidono.

e l’ip mittente si intende quello dell’ultimo HoP o quello indicato come iniziale?

E cosi il dominio di provenienza (HELO/EHLO) quale è?

Ovviamente se fossi un pessimo soggetto potrei ricordare che l’alterazione, o la costruzione malevola, di questi metadati è alla base di diversi attacchi perpetrati attraverso la posta elettronica, e siccome sono, fondamentalmente, un pessimo soggetto lo ricordo

I metadati della posta elettronica sono spesso modificati ed alterati da attori malevoli al fine di perpetrare attacchi attraverso tale canale di comunicazione

un cattivo soggetto

La conseguenza di questo piccolo punto è, quindi, che il monitoraggio di questi elementi è fondamentale per questioni di gestione della posta, troubleshooting di problematiche e analisi di sicurezza. Pensare che tali esigenze possano essere ricondotte a un 7+2 giorni significa non avere la benchè minima ne pallida idea della realtà tecnica e delle esigenze di sicurezza.

E quindi?

Li vedo i puristi della “privacy” già si ergono:

le questioni tecniche non devono prevalere sui legittimi diritti e protezione delle lavoratrici e dei lavoratori

i DPO duri e puri del GDPR e gli avvocati indefessi dello statuto dei lavoratori

In realtà il garante ha un problema: far si che i metadati siano usati in maniera legittima e consapevole da parte dei soggetti.

Il garante stesso da la soluzione al di la della delirante richiesta dei 7+2 giorni:

I datori di lavoro che per esigenze organizzative e produttive o di tutela del patrimonio anche informativo del titolare (in particolare, per la sicurezza dei sistemi) avessero necessità di trattare i metadati per un periodo di tempo più esteso (quindi tutti salvo rarissime eccezioni quali gli esperti del garante), dovranno espletare le procedure di garanzia previste dallo Statuto dei lavoratori (accordo sindacale o autorizzazione dell’ispettorato del lavoro).

L’estensione del periodo di conservazione oltre l’arco temporale fissato dal Garante può infatti comportare un indiretto controllo a distanza dell’attività del lavoratore ma non per il metadato in se, ma per l’uso illecito effettuato di dali dati.

Del resto se vogliamo estendere la vexata quaestio al piu generico mondo della posta elettronica, compreso, quindi, il messaggio intero, potremmo per estensione pensare di chiederci se è possibile tenere nella casella di posta dell’utente un messaggio per piu di 7+2 giorni.

Attenzione che in pancia a quel mail-server le informazioni sono, almeno negli assunti indicati dal garante per indicare il metadato, tutti presenti.

La eliminazione, quindi, dei metadati comporterebbe la necessaria eliminazione dei messaggi archiviati nel server nella casella dell’utente.

Certo possiamo fargli creare archivi locali, ma questa non è certo una soluzione che si accompagni alla sicurezza (e se volete ne possiamo parlare).

Spieghi il garante allora agli utenti il razionale di tale vincolo e limitazione 🙂

Insomma ad essere chiari le finalità primarie per tenere i metadati per oltre 7+2 giorni, ovviamente, restano troubleshooting di problemi e la sicurezza informatica e i necessari accertamenti da fare a seguito di data breach o comunque incidente sulla sicurezza informatica. Elementi più che validi per ritenere che le indicazioni date siano non sufficienti ne adatte al mantenimento e gestione dei sistemi di posta elettronica.

Ma, occorre dire, il garante stesso non indica un vincolo assoluto nei 7 giorni, ma richiede che retention più lunghe siano poste in essere con la garanzia del rispetto delle tutele previste dal GDPR e dallo statuto dei lavoratori.

Non provateci a dire che non ve lo avevo detto.

Etica e DPO, un difficile rapporto?

Caso non comune ma sto ampliando un mio precedente articolo che, nei fatti, costituisce il corpo centrale di questo post.

Stimolato dai feedback sul mio ultimo post sul DPO

e stimolato dalla lettura di un post ed i commenti sagaci di Andrea Monti mi sono rimesso a pensare a certi ruoi aziendali.

Prima di proseguire nella lettura però dovete leggervi di Andrea Monti:

La scomoda sedia del Data Protection Officer, e perché gli avvocati non possono occuparla

La chiusura finale in particolare è interessante dove Andrea nota:

“…o il DPO fa finta di non vedere (e diventa concorrente in un illecito. Formale, ma pur sempre illecito) oppure mette il veto sull’iniziativa e, se l’azienda prosegue, non ha troppe alternative rispetto a segnalare il fatto all’autorità di protezione.”

…

“Quindi il DPO, anche se non segnala in autonomia una violazione normativa, può essere ascoltato dall’autorità (non solo) di protezione dei dati su queste circostanze. E dunque diventare un potenziale teste a carico (dell’accusa, in altri termini).”

…

Andrea Monti

E qui si apre un interessante punto .. ed è una esperienza che ho vissuto come manager in una multinazionale.

image taken from http://elaine.ie/2016/05/27/state-should-pay-whistleblowers/

Ad un certo punto, in una certa azienda, mi è stato detto che certi dati del personale sarebbero stati trasferiti fuori europa semplicemente perchè si, in barba al GDPR, e che non si doveva dire.

La questione mi ha subito dato fastidio per un motivo personale, tra quei dipendenti c’ero anche io. Erano i miei diritti che erano lesi, anche se i dati sarebbero stati trattati in maniera sicura.

Il punto era che invece che provare a discorrere con le autorità europee o trovare delle vie di mezzo percorribili si era scelto di non rispettare alcuni termini del GDPR. sapendo benissimo di violare un regolamento EU e sapendo benissimo di capire di tale regolamento poco o nulla.

Ancora più fastidioso era l’essere messo in mezzo ad un dilemma etico ed economico.

Durante la riunione ho obiettato che:

1. mi si chiedeva esplicitamente di mentire alle mie persone e colleghi
2. mi si chiedeva di non rispettare le leggi del mio paese
3. mi si chiedeva di rendermi complice di un illecito.

Lo scopo era vedere se ci fossero state reazione da parte dei miei colleghi. Aimè solo 2 CSO nord europei mi diedero ragione.

Ovviamente le mie obiezioni furono derubricate a “quello rompe sempre le scatole” il che mi ha portato, assieme ad altre considerazioni (alcune strettamente personali) alla decisione di non rinnovare la collaborazione con quella azienda e contestualmente segnalare la cosa all’authority dopo la fuoriuscita.

Ora la questione è dove deve, eticamente, cadere la mia lealtà in questi casi? Verso la azienda o verso, in questo caso, le leggi del mio paese?

La cosa non è semplice, ne parlavo in un altro post quando osservavo che considero mascalzoni quei CEO/Board che per puro calcolo matematico preferiscono il rischio della sanzione che l’implementazione corretta del GDPR.

La mia obiezione risiede nel fatto che il GDPR è norma per proteggere le libertà di noi cittadini e residenti EU, non rispettarlo quindi implicitamente mette a rischio le mie libertà individuali.

Nel mio caso la mia lealtà va alla protezione dei miei concittadini e al rispetto della legge, anche se parliamo di un illecito amministrativo o formale la questione non è banale.

Un manager potrebbe allinearsi alla richiesta aziendale, potrebbe non allinearsi e prenderne le conseguenze (lo ho vissuto) o fare una via di mezzo, ad esempio denunciare il comportamento in via anonima alla autorità competente dopo aver, almeno, provato a obiettare sul comportamento.

Ancora più delicato, in questo caso, è il dipendente non manager, vaso di coccio.

L’istituto del whistleblowing potrebbe in qualche modo “proteggere” ma diciamocelo se si viene a sapere chi ha cantato…

Il problema etico rimane, in mancanza di obblighi formali a comunicare alla opportuna authority un eventuale illecito.

Il caso del DPO è anche più critico, visto che istituzionalmente ha obblighi chiari in merito al rispetto del GDPR che sono di indirizzo, formazione e controllo. Il punto è che in assenza di segnalazione alla autorità della non aderenza al regolamento il DPO non esercita la sua funzione di controllo.

Supponiamo per un momento che il DPO presenti le sue valutazioni di rischio su di un processo al board dando una valutazione che presenta un piccolo rischio residuale come accettabile, e che il board rifiuti le conclusioni definendo un rischio accettabile più alto. Ora posso comprendere che questo entri in un ambito di contrattazione tra le parti, se il rischio residuale è troppo alto il DPO deve comunicare con l’authority per la valutazione.

Ora il quanto alto sia è il punto dirimente, se il DPO considera il rischio accettato dal board troppo alto fa bene a comunicare al garante la cosa per un parere?

E se non lo fa e accade un incidente? E se non lo fa e viene una ispezione che giunge alle conclusioni del DPO e trova scritto nelle minute dei meeting del board quali erano le posizioni in merito?

Situazione scivolosa persino senza che vi sia un illecito formale come indicato nel post di andrea che vi invitavo a leggere inizialmente.

Analogo discorso potremmo farlo per il CISO che non ritenga adatti i meccanismi di protezione messi in atto dall’azienda ed in caso di breach incalzato dalle autorità esprima le sue perplessità (possibilmente scritte in qualche documento ufficiale).

Fa bene?

Fa male?

La questione delle responsabilità è quindi delicata, si prenda il caso INPS, dove alla fine tutto è finito a tarallucci e vino. Possibile che internamente nessuno ha sentito il bisogno di denunciare una situazione che ha portato al disastro? Non voglio credere che il livello di incompetenza sia tale per cui nessuno se ne potesse rendere conto.

Se è vero che vi sono vincoli di riservatezza, fino a dove questi si possono spingere?

Come Whistleblower o per ruolo la questione è non semplice, anche perchè vi sono altri termini da considerare tipo:

1. la necessità di uno stipendio
2. la possibilità di trovare lavoro

Pensate, ad esempio, un DPO che denuncia al garante una non conformità della propria azienda. Tra lui ed il CEO difficilmente sarà il CEO ad essere licenziato.

Ma se il DPO perde il lavoro a seguito della cosa (e i metodi ci sono per farlo) e la cosa si sa (questo è un mondo piccolo)…quante possibilità avrà di trovare una nuova collocazione?

Pensare ad una indipendenza che sia reale diventa estremamente difficile soprattutto in una situazione economica dove la ricollocazione non è ne facile ne garantita.

Meditiamo, Meditiamo

Etica e DPO, un difficile rapporto?

Caso non comune ma sto ampliando un mio precedente articolo che, nei fatti, costituisce il corpo centrale di questo post.

Stimolato dai feedback sul mio ultimo post sul DPO

e stimolato dalla lettura di un post ed i commenti sagaci di Andrea Monti mi sono rimesso a pensare a certi ruoi aziendali.

Prima di proseguire nella lettura però dovete leggervi di Andrea Monti:

La scomoda sedia del Data Protection Officer, e perché gli avvocati non possono occuparla

La chiusura finale in particolare è interessante dove Andrea nota:

“…o il DPO fa finta di non vedere (e diventa concorrente in un illecito. Formale, ma pur sempre illecito) oppure mette il veto sull’iniziativa e, se l’azienda prosegue, non ha troppe alternative rispetto a segnalare il fatto all’autorità di protezione.”

…

“Quindi il DPO, anche se non segnala in autonomia una violazione normativa, può essere ascoltato dall’autorità (non solo) di protezione dei dati su queste circostanze. E dunque diventare un potenziale teste a carico (dell’accusa, in altri termini).”

…

Andrea Monti

E qui si apre un interessante punto .. ed è una esperienza che ho vissuto come manager in una multinazionale.

image taken from http://elaine.ie/2016/05/27/state-should-pay-whistleblowers/

Ad un certo punto, in una certa azienda, mi è stato detto che certi dati del personale sarebbero stati trasferiti fuori europa semplicemente perchè si, in barba al GDPR, e che non si doveva dire.

La questione mi ha subito dato fastidio per un motivo personale, tra quei dipendenti c’ero anche io. Erano i miei diritti che erano lesi, anche se i dati sarebbero stati trattati in maniera sicura.

Il punto era che invece che provare a discorrere con le autorità europee o trovare delle vie di mezzo percorribili si era scelto di non rispettare alcuni termini del GDPR. sapendo benissimo di violare un regolamento EU e sapendo benissimo di capire di tale regolamento poco o nulla.

Ancora più fastidioso era l’essere messo in mezzo ad un dilemma etico ed economico.

Durante la riunione ho obiettato che:

1. mi si chiedeva esplicitamente di mentire alle mie persone e colleghi
2. mi si chiedeva di non rispettare le leggi del mio paese
3. mi si chiedeva di rendermi complice di un illecito.

Lo scopo era vedere se ci fossero state reazione da parte dei miei colleghi. Aimè solo 2 CSO nord europei mi diedero ragione.

Ovviamente le mie obiezioni furono derubricate a “quello rompe sempre le scatole” il che mi ha portato, assieme ad altre considerazioni (alcune strettamente personali) alla decisione di non rinnovare la collaborazione con quella azienda e contestualmente segnalare la cosa all’authority dopo la fuoriuscita.

Ora la questione è dove deve, eticamente, cadere la mia lealtà in questi casi? Verso la azienda o verso, in questo caso, le leggi del mio paese?

La cosa non è semplice, ne parlavo in un altro post quando osservavo che considero mascalzoni quei CEO/Board che per puro calcolo matematico preferiscono il rischio della sanzione che l’implementazione corretta del GDPR.

La mia obiezione risiede nel fatto che il GDPR è norma per proteggere le libertà di noi cittadini e residenti EU, non rispettarlo quindi implicitamente mette a rischio le mie libertà individuali.

Nel mio caso la mia lealtà va alla protezione dei miei concittadini e al rispetto della legge, anche se parliamo di un illecito amministrativo o formale la questione non è banale.

Un manager potrebbe allinearsi alla richiesta aziendale, potrebbe non allinearsi e prenderne le conseguenze (lo ho vissuto) o fare una via di mezzo, ad esempio denunciare il comportamento in via anonima alla autorità competente dopo aver, almeno, provato a obiettare sul comportamento.

Ancora più delicato, in questo caso, è il dipendente non manager, vaso di coccio.

L’istituto del whistleblowing potrebbe in qualche modo “proteggere” ma diciamocelo se si viene a sapere chi ha cantato…

Il problema etico rimane, in mancanza di obblighi formali a comunicare alla opportuna authority un eventuale illecito.

Il caso del DPO è anche più critico, visto che istituzionalmente ha obblighi chiari in merito al rispetto del GDPR che sono di indirizzo, formazione e controllo. Il punto è che in assenza di segnalazione alla autorità della non aderenza al regolamento il DPO non esercita la sua funzione di controllo.

Supponiamo per un momento che il DPO presenti le sue valutazioni di rischio su di un processo al board dando una valutazione che presenta un piccolo rischio residuale come accettabile, e che il board rifiuti le conclusioni definendo un rischio accettabile più alto. Ora posso comprendere che questo entri in un ambito di contrattazione tra le parti, se il rischio residuale è troppo alto il DPO deve comunicare con l’authority per la valutazione.

Ora il quanto alto sia è il punto dirimente, se il DPO considera il rischio accettato dal board troppo alto fa bene a comunicare al garante la cosa per un parere?

E se non lo fa e accade un incidente? E se non lo fa e viene una ispezione che giunge alle conclusioni del DPO e trova scritto nelle minute dei meeting del board quali erano le posizioni in merito?

Situazione scivolosa persino senza che vi sia un illecito formale come indicato nel post di andrea che vi invitavo a leggere inizialmente.

Analogo discorso potremmo farlo per il CISO che non ritenga adatti i meccanismi di protezione messi in atto dall’azienda ed in caso di breach incalzato dalle autorità esprima le sue perplessità (possibilmente scritte in qualche documento ufficiale).

Fa bene?

Fa male?

La questione delle responsabilità è quindi delicata, si prenda il caso INPS, dove alla fine tutto è finito a tarallucci e vino. Possibile che internamente nessuno ha sentito il bisogno di denunciare una situazione che ha portato al disastro? Non voglio credere che il livello di incompetenza sia tale per cui nessuno se ne potesse rendere conto.

Se è vero che vi sono vincoli di riservatezza, fino a dove questi si possono spingere?

Come Whistleblower o per ruolo la questione è non semplice, anche perchè vi sono altri termini da considerare tipo:

1. la necessità di uno stipendio
2. la possibilità di trovare lavoro

Pensate, ad esempio, un DPO che denuncia al garante una non conformità della propria azienda. Tra lui ed il CEO difficilmente sarà il CEO ad essere licenziato.

Ma se il DPO perde il lavoro a seguito della cosa (e i metodi ci sono per farlo) e la cosa si sa (questo è un mondo piccolo)…quante possibilità avrà di trovare una nuova collocazione?

Pensare ad una indipendenza che sia reale diventa estremamente difficile soprattutto in una situazione economica dove la ricollocazione non è ne facile ne garantita.

Meditiamo, Meditiamo

Chi va con lo zoppo impara a DPOare

Caso non comune ma sto ampliando un mio precedente articolo che, nei fatti, costituisce il corpo centrale di questo post.

Stimolato dai feedback sul mio ultimo post sul DPO

e stimolato dalla lettura di un post ed i commenti sagaci di Andrea Monti mi sono rimesso a pensare a certi ruoi aziendali.

Prima di proseguire nella lettura però dovete leggervi di Andrea Monti:

La scomoda sedia del Data Protection Officer, e perché gli avvocati non possono occuparla

La chiusura finale in particolare è interessante dove Andrea nota:

“…o il DPO fa finta di non vedere (e diventa concorrente in un illecito. Formale, ma pur sempre illecito) oppure mette il veto sull’iniziativa e, se l’azienda prosegue, non ha troppe alternative rispetto a segnalare il fatto all’autorità di protezione.”

…

“Quindi il DPO, anche se non segnala in autonomia una violazione normativa, può essere ascoltato dall’autorità (non solo) di protezione dei dati su queste circostanze. E dunque diventare un potenziale teste a carico (dell’accusa, in altri termini).”

…

Andrea Monti

E qui si apre un interessante punto .. ed è una esperienza che ho vissuto come manager in una multinazionale.

image taken from http://elaine.ie/2016/05/27/state-should-pay-whistleblowers/

Ad un certo punto, in una certa azienda, mi è stato detto che certi dati del personale sarebbero stati trasferiti fuori europa semplicemente perchè si, in barba al GDPR, e che non si doveva dire.

La questione mi ha subito dato fastidio per un motivo personale, tra quei dipendenti c’ero anche io. Erano i miei diritti che erano lesi, anche se i dati sarebbero stati trattati in maniera sicura.

Il punto era che invece che provare a discorrere con le autorità europee o trovare delle vie di mezzo percorribili si era scelto di non rispettare alcuni termini del GDPR. sapendo benissimo di violare un regolamento EU e sapendo benissimo di capire di tale regolamento poco o nulla.

Ancora più fastidioso era l’essere messo in mezzo ad un dilemma etico ed economico.

Durante la riunione ho obiettato che:

1. mi si chiedeva esplicitamente di mentire alle mie persone e colleghi
2. mi si chiedeva di non rispettare le leggi del mio paese
3. mi si chiedeva di rendermi complice di un illecito.

Lo scopo era vedere se ci fossero state reazione da parte dei miei colleghi. Aimè solo 2 CSO nord europei mi diedero ragione.

Ovviamente le mie obiezioni furono derubricate a “quello rompe sempre le scatole” il che mi ha portato, assieme ad altre considerazioni (alcune strettamente personali) alla decisione di non rinnovare la collaborazione con quella azienda e contestualmente segnalare la cosa all’authority dopo la fuoriuscita.

Ora la questione è dove deve, eticamente, cadere la mia lealtà in questi casi? Verso la azienda o verso, in questo caso, le leggi del mio paese?

La cosa non è semplice, ne parlavo in un altro post quando osservavo che considero mascalzoni quei CEO/Board che per puro calcolo matematico preferiscono il rischio della sanzione che l’implementazione corretta del GDPR.

La mia obiezione risiede nel fatto che il GDPR è norma per proteggere le libertà di noi cittadini e residenti EU, non rispettarlo quindi implicitamente mette a rischio le mie libertà individuali.

Nel mio caso la mia lealtà va alla protezione dei miei concittadini e al rispetto della legge, anche se parliamo di un illecito amministrativo o formale la questione non è banale.

Un manager potrebbe allinearsi alla richiesta aziendale, potrebbe non allinearsi e prenderne le conseguenze (lo ho vissuto) o fare una via di mezzo, ad esempio denunciare il comportamento in via anonima alla autorità competente dopo aver, almeno, provato a obiettare sul comportamento.

Ancora più delicato, in questo caso, è il dipendente non manager, vaso di coccio.

L’istituto del whistleblowing potrebbe in qualche modo “proteggere” ma diciamocelo se si viene a sapere chi ha cantato…

Il problema etico rimane, in mancanza di obblighi formali a comunicare alla opportuna authority un eventuale illecito.

Il caso del DPO è anche più critico, visto che istituzionalmente ha obblighi chiari in merito al rispetto del GDPR che sono di indirizzo, formazione e controllo. Il punto è che in assenza di segnalazione alla autorità della non aderenza al regolamento il DPO non esercita la sua funzione di controllo.

Supponiamo per un momento che il DPO presenti le sue valutazioni di rischio su di un processo al board dando una valutazione che presenta un piccolo rischio residuale come accettabile, e che il board rifiuti le conclusioni definendo un rischio accettabile più alto. Ora posso comprendere che questo entri in un ambito di contrattazione tra le parti, se il rischio residuale è troppo alto il DPO deve comunicare con l’authority per la valutazione.

Ora il quanto alto sia è il punto dirimente, se il DPO considera il rischio accettato dal board troppo alto fa bene a comunicare al garante la cosa per un parere?

E se non lo fa e accade un incidente? E se non lo fa e viene una ispezione che giunge alle conclusioni del DPO e trova scritto nelle minute dei meeting del board quali erano le posizioni in merito?

Situazione scivolosa persino senza che vi sia un illecito formale come indicato nel post di andrea che vi invitavo a leggere inizialmente.

Analogo discorso potremmo farlo per il CISO che non ritenga adatti i meccanismi di protezione messi in atto dall’azienda ed in caso di breach incalzato dalle autorità esprima le sue perplessità (possibilmente scritte in qualche documento ufficiale).

Fa bene?

Fa male?

La questione delle responsabilità è quindi delicata, si prenda il caso INPS, dove alla fine tutto è finito a tarallucci e vino. Possibile che internamente nessuno ha sentito il bisogno di denunciare una situazione che ha portato al disastro? Non voglio credere che il livello di incompetenza sia tale per cui nessuno se ne potesse rendere conto.

Se è vero che vi sono vincoli di riservatezza, fino a dove questi si possono spingere?

Come Whistleblower o per ruolo la questione è non semplice, anche perchè vi sono altri termini da considerare tipo:

1. la necessità di uno stipendio
2. la possibilità di trovare lavoro

Pensate, ad esempio, un DPO che denuncia al garante una non conformità della propria azienda. Tra lui ed il CEO difficilmente sarà il CEO ad essere licenziato.

Ma se il DPO perde il lavoro a seguito della cosa (e i metodi ci sono per farlo) e la cosa si sa (questo è un mondo piccolo)…quante possibilità avrà di trovare una nuova collocazione?

Pensare ad una indipendenza che sia reale diventa estremamente difficile soprattutto in una situazione economica dove la ricollocazione non è ne facile ne garantita.

Meditiamo, Meditiamo

Chi va con lo zoppo impara a DPOare

Caso non comune ma sto ampliando un mio precedente articolo che, nei fatti, costituisce il corpo centrale di questo post.

Stimolato dai feedback sul mio ultimo post sul DPO

e stimolato dalla lettura di un post ed i commenti sagaci di Andrea Monti mi sono rimesso a pensare a certi ruoi aziendali.

Prima di proseguire nella lettura però dovete leggervi di Andrea Monti:

La scomoda sedia del Data Protection Officer, e perché gli avvocati non possono occuparla

La chiusura finale in particolare è interessante dove Andrea nota:

“…o il DPO fa finta di non vedere (e diventa concorrente in un illecito. Formale, ma pur sempre illecito) oppure mette il veto sull’iniziativa e, se l’azienda prosegue, non ha troppe alternative rispetto a segnalare il fatto all’autorità di protezione.”

…

“Quindi il DPO, anche se non segnala in autonomia una violazione normativa, può essere ascoltato dall’autorità (non solo) di protezione dei dati su queste circostanze. E dunque diventare un potenziale teste a carico (dell’accusa, in altri termini).”

…

Andrea Monti

E qui si apre un interessante punto .. ed è una esperienza che ho vissuto come manager in una multinazionale.

image taken from http://elaine.ie/2016/05/27/state-should-pay-whistleblowers/

Ad un certo punto, in una certa azienda, mi è stato detto che certi dati del personale sarebbero stati trasferiti fuori europa semplicemente perchè si, in barba al GDPR, e che non si doveva dire.

La questione mi ha subito dato fastidio per un motivo personale, tra quei dipendenti c’ero anche io. Erano i miei diritti che erano lesi, anche se i dati sarebbero stati trattati in maniera sicura.

Il punto era che invece che provare a discorrere con le autorità europee o trovare delle vie di mezzo percorribili si era scelto di non rispettare alcuni termini del GDPR. sapendo benissimo di violare un regolamento EU e sapendo benissimo di capire di tale regolamento poco o nulla.

Ancora più fastidioso era l’essere messo in mezzo ad un dilemma etico ed economico.

Durante la riunione ho obiettato che:

1. mi si chiedeva esplicitamente di mentire alle mie persone e colleghi
2. mi si chiedeva di non rispettare le leggi del mio paese
3. mi si chiedeva di rendermi complice di un illecito.

Lo scopo era vedere se ci fossero state reazione da parte dei miei colleghi. Aimè solo 2 CSO nord europei mi diedero ragione.

Ovviamente le mie obiezioni furono derubricate a “quello rompe sempre le scatole” il che mi ha portato, assieme ad altre considerazioni (alcune strettamente personali) alla decisione di non rinnovare la collaborazione con quella azienda e contestualmente segnalare la cosa all’authority dopo la fuoriuscita.

Ora la questione è dove deve, eticamente, cadere la mia lealtà in questi casi? Verso la azienda o verso, in questo caso, le leggi del mio paese?

La cosa non è semplice, ne parlavo in un altro post quando osservavo che considero mascalzoni quei CEO/Board che per puro calcolo matematico preferiscono il rischio della sanzione che l’implementazione corretta del GDPR.

La mia obiezione risiede nel fatto che il GDPR è norma per proteggere le libertà di noi cittadini e residenti EU, non rispettarlo quindi implicitamente mette a rischio le mie libertà individuali.

Nel mio caso la mia lealtà va alla protezione dei miei concittadini e al rispetto della legge, anche se parliamo di un illecito amministrativo o formale la questione non è banale.

Un manager potrebbe allinearsi alla richiesta aziendale, potrebbe non allinearsi e prenderne le conseguenze (lo ho vissuto) o fare una via di mezzo, ad esempio denunciare il comportamento in via anonima alla autorità competente dopo aver, almeno, provato a obiettare sul comportamento.

Ancora più delicato, in questo caso, è il dipendente non manager, vaso di coccio.

L’istituto del whistleblowing potrebbe in qualche modo “proteggere” ma diciamocelo se si viene a sapere chi ha cantato…

Il problema etico rimane, in mancanza di obblighi formali a comunicare alla opportuna authority un eventuale illecito.

Il caso del DPO è anche più critico, visto che istituzionalmente ha obblighi chiari in merito al rispetto del GDPR che sono di indirizzo, formazione e controllo. Il punto è che in assenza di segnalazione alla autorità della non aderenza al regolamento il DPO non esercita la sua funzione di controllo.

Supponiamo per un momento che il DPO presenti le sue valutazioni di rischio su di un processo al board dando una valutazione che presenta un piccolo rischio residuale come accettabile, e che il board rifiuti le conclusioni definendo un rischio accettabile più alto. Ora posso comprendere che questo entri in un ambito di contrattazione tra le parti, se il rischio residuale è troppo alto il DPO deve comunicare con l’authority per la valutazione.

Ora il quanto alto sia è il punto dirimente, se il DPO considera il rischio accettato dal board troppo alto fa bene a comunicare al garante la cosa per un parere?

E se non lo fa e accade un incidente? E se non lo fa e viene una ispezione che giunge alle conclusioni del DPO e trova scritto nelle minute dei meeting del board quali erano le posizioni in merito?

Situazione scivolosa persino senza che vi sia un illecito formale come indicato nel post di andrea che vi invitavo a leggere inizialmente.

Analogo discorso potremmo farlo per il CISO che non ritenga adatti i meccanismi di protezione messi in atto dall’azienda ed in caso di breach incalzato dalle autorità esprima le sue perplessità (possibilmente scritte in qualche documento ufficiale).

Fa bene?

Fa male?

La questione delle responsabilità è quindi delicata, si prenda il caso INPS, dove alla fine tutto è finito a tarallucci e vino. Possibile che internamente nessuno ha sentito il bisogno di denunciare una situazione che ha portato al disastro? Non voglio credere che il livello di incompetenza sia tale per cui nessuno se ne potesse rendere conto.

Se è vero che vi sono vincoli di riservatezza, fino a dove questi si possono spingere?

Come Whistleblower o per ruolo la questione è non semplice, anche perchè vi sono altri termini da considerare tipo:

1. la necessità di uno stipendio
2. la possibilità di trovare lavoro

Pensate, ad esempio, un DPO che denuncia al garante una non conformità della propria azienda. Tra lui ed il CEO difficilmente sarà il CEO ad essere licenziato.

Ma se il DPO perde il lavoro a seguito della cosa (e i metodi ci sono per farlo) e la cosa si sa (questo è un mondo piccolo)…quante possibilità avrà di trovare una nuova collocazione?

Pensare ad una indipendenza che sia reale diventa estremamente difficile soprattutto in una situazione economica dove la ricollocazione non è ne facile ne garantita.

Meditiamo, Meditiamo

Shrems II, Data transfer, and the USA: wheels are rolling.

Probably everyone now has, at least, heard about the EJC sentence called Shrems III that basically rules out the possibility to use Privacy Shield infamous agreement to allow data transfer between EU and USA based on the fact that the USA does not provide enough guarantees EU data will be protected.

If you don’t know (but you should) here my previous article:

https://thepuchiherald.com/2020/07/17/ops-privacy-shield-bye-bye/

After the sentence one of the question was: what now?

Will a Grace period be offered to survive this? (lot of companies were transferring data using privacy shield to USA)

And most of all does SCC will be enough?

The answer my friend, is blowing in the wind...

er no actually there have been some FAQ form the EDPB that should call to action fel local authorities.

According to the new FAQs of the European Data Protection Board on #SchremsII decision, if you want to transfer personal data to the US under the SCCs or other means, you will have to notify the data protection supervisory authority. This approach will oblige companies to perform a massive amount of work since the notification will have to be definitely accompanied by an assessment as to the adequacy of the data transfer mechanism. Are companies and SA ready to handle this large amount of work?

https://edpb.europa.eu/news/news/2020/european-data-protection-board-publishes-faq-document-cjeu-judgment-c-31118-schrems_en

While some Authorities do have not yet reacted (and this is not a surprise for Italians, I am afraid) some others (wonder who) have made a statement that clarifies the doubts that can eventually rise up and not solved by the EDPB’s FAQ.

The Conference of German Supervisory Authorities (DSK) issued its statement yesterday about the consequences of the #Schrems II judgment that, as we can imagine, is completely aligned with the EDPB position. There are some points that are critical on the matter:

dskshremsDownload

Data transfers based on the Privacy Shield are no longer allowed and all companies must immediately suspend them

This is a critical point since I am quite sure there are companies that do not even know their data were delivered to the USA under Privacy Shield. I would like to remind you that if an audit from the authority knock at your door something like: “I don’t know”, “I don’t remember” will not save you. GDPR requires that you, company, prove you have done your duty in a concrete, effective way, so not paper compliance here allowed. Just to make life easier I would love to remind you also that this is not just the German way, and sooner or later the other authorities will align with such requirements.

Transfers based on the SCC require an assessment of the adequacy of the context and the supplier

And here we have the headache since it is not “optional” the assessment is mandatory. This comes as an obvious consequence to the fact in the EDPB FAQ it is written to be allowed SCC’s transfer should be communicated to the authority. Now this means, for some of you so naive that was thinking, I can send a mail to the authority telling, “hey chap I use SCC do not worry” does not work like this. For some reason they want you to prove you did your duty.

The use of SCC for the transfer of data to the United States, in the absence of additional guarantee measures, it is not sufficient to legitimize the activity

And of course, if you send your data to a country that does not guarantee the privacy of EU citizens and residents, well, your duty is kind of complex. And let be clear and brutally honest (while usually I am obscure but kind rotfl) this will require the active cooperation of the vendors that offer you services because you need solid proofs and not just paperBS.

There is no “grace period”

And this means you need to do this right fucking now.

And just for the sake of my Italian fellow countrymen, this means that even if our authority is under a sleeping spell and did not react yet, you have to act nevertheless because again an audit will knock and you will have show you’ve done the right thing. But the “garante” did not tell us nothing will not be an excuse to avoid non-compliance (with the relative consequences).

Time for DPO to start working and earn their money 😂🤣 (Is a joke I know many DPOs already do something)

Guida al GDPR per chi non ne vuol sapere: DPO il responsabile irresponsabile

Lo capisco, leggere il GDPR in inglese è una palla pazzesca…allora affidiamoci alla traduzione italiana …

la idea di tradurre in italiano un testo che deve diventare legge non sarebbe peregrina, ma siccome noi di solito traduciamo le cose con approssimazione assoluta ecco il capovalovoro italiano, DPO (Data Protection Officer) diventa Responsabile Protezione Dati… in barba al significato voluto da chi ha scrittoil GDPR non abbiamo potuto resistere alla ennesima dimostrazione di come con sottile abilità si possa creare confusione anche in ambiti chiarissimi.

Orbene la traduzione italica di DPO deriva da una consuetudine legata all’armonizzazione delle diciture presenti nelle varie leggti precedenti al GDPR con le nuove, la cosa non sarebbe grave se non fosse che il DPO NON è responsabile ne della protezione ne del trattamento dei dati. Secondo il GDPR la responsabilità cade interamente sul Data Controller e sul Data Processor, e al secondo in misura correlata a vincoli di gestione del dato indicati dal Data Controller.

Facciamo quindi uno sforzo di astrazione e esimiamoci dal significato delle parole in italiano.

l’ RPD è il DPO che per ruolo non è responsabilefdella protezione del dato

Lo so è imbarazzante dover negare il significato di un termine italiano (responsabile) ponendolo come termine distintivo di un ruolo che essenziamente non ha responsabilità in merito a quanto descritto dal rimanente acronimo.

Ci troviamo quindi nel curioso stato in cui secondo la legge italiana sulla privacy allineata al GDPR un responsabile della protezione dei dati non è responabile di tle protezione, e se non ci credete oltre me, il testo originale del GDPR fate un salto sul sito del garante http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/8036793 .

1. Chi è il responsabile della protezione dei dati personali (RPD) e quali sono i suoi compiti?

Il responsabile della protezione dei dati personali (anche conosciuto con la dizione in lingua inglese data protection officer – DPO) è una figura prevista dall’art. 37 del Regolamento (UE) 2016/679. Si tratta di un soggetto designato dal titolare o dal responsabile del trattamento per assolvere a funzioni di supporto e controllo, consultive, formative e informative relativamente all’applicazione del Regolamento medesimo. Coopera con l’Autorità (e proprio per questo, il suo nominativo va comunicato al Garante; v. faq 6) e costituisce il punto di contatto, anche rispetto agli interessati, per le questioni connesse al trattamento dei dati personali (artt. 38 e 39 del Regolamento).

Fantastico l’RDP viene designato dal responsabile da cui ne consegue che il responabile è altro dall’RDP. il sillogismo funziona.

altro discorso poi è a chi serve un DPO, ci sono casi in cui la assegnazione del RDPDPO è obbligatoria, ed altri in cui non lo è. ma considerando la complessità dell’ambito cui il DPORDP lavora sarebbe consigliabile averlo, il GDPR chiede che tale figura sia indipendente ma non che sia un dipendente, ne che sia dedicato solo ad un cliente. è quindi possibile utilizzare servizi di DPORDP esterni che eplichino le funzioni richieste come da indicazione del garante.

Va da se che una figura che deve poter offrire funzioni di supporto e controllo, consultive, formative e informative a questo livello non può essere un junior e quindi il mercato attuale con cifre attorno ai 30k annui identifica come, tanto per cambiare, il mercato italiano non abbia ancora capito cosa sia il GDPR, il DPORDP e non solo.

Una nota finale, visto che in questo giorni ho visto e sentito di tutto, dal fatto che si deve ottenere la “certificazione GDPR”, vi ricordo che al momento in italia non esiste una certificazione per il DPORDP ne esiste in assoluto una certificazione GDPR.

 

sempre dal sito del garante prendo

Sul tema della certificazione inoltre si richiama l’attenzione sul comunicato congiunto, pubblicato sul sito dell’Autorità il 18 luglio 2017 (doc. web n. 6621723), con il quale il Garante e ACCREDIA (l’Ente unico nazionale di accreditamento designato dal Governo italiano) hanno ritenuto necessario sottolineare – al fine di indirizzare correttamente le attività svolte dai soggetti a vario titolo interessati in questo ambito – che «al momento le certificazioni di persone, nonché quelle emesse in materia di privacy o data protection eventualmente rilasciate in Italia, sebbene possano costituire una garanzia e atto di diligenza verso le parti interessate dell’adozione volontaria di un sistema di analisi e controllo dei principi e delle norme di riferimento, a legislazione vigente non possono definirsi “conformi agli artt. 42 e 43 del regolamento 2016/679”, poiché devono ancora essere determinati i “requisiti aggiuntivi” ai fini dell’accreditamento degli organismi di certificazione e i criteri specifici di certificazione».

Si potrebbe obbiettare che sia tardi, ma sicccome siamo in ritardo su tutto siamo allineati alla timeline italiana.

 

ciao

Guida al GDPR per chi non ne vuol sapere: DPO il responsabile irresponsabile

Lo capisco, leggere il GDPR in inglese è una palla pazzesca…allora affidiamoci alla traduzione italiana …

la idea di tradurre in italiano un testo che deve diventare legge non sarebbe peregrina, ma siccome noi di solito traduciamo le cose con approssimazione assoluta ecco il capovalovoro italiano, DPO (Data Protection Officer) diventa Responsabile Protezione Dati… in barba al significato voluto da chi ha scrittoil GDPR non abbiamo potuto resistere alla ennesima dimostrazione di come con sottile abilità si possa creare confusione anche in ambiti chiarissimi.

Orbene la traduzione italica di DPO deriva da una consuetudine legata all’armonizzazione delle diciture presenti nelle varie leggti precedenti al GDPR con le nuove, la cosa non sarebbe grave se non fosse che il DPO NON è responsabile ne della protezione ne del trattamento dei dati. Secondo il GDPR la responsabilità cade interamente sul Data Controller e sul Data Processor, e al secondo in misura correlata a vincoli di gestione del dato indicati dal Data Controller.

Facciamo quindi uno sforzo di astrazione e esimiamoci dal significato delle parole in italiano.

l’ RPD è il DPO che per ruolo non è responsabilefdella protezione del dato

Lo so è imbarazzante dover negare il significato di un termine italiano (responsabile) ponendolo come termine distintivo di un ruolo che essenziamente non ha responsabilità in merito a quanto descritto dal rimanente acronimo.

Ci troviamo quindi nel curioso stato in cui secondo la legge italiana sulla privacy allineata al GDPR un responsabile della protezione dei dati non è responabile di tle protezione, e se non ci credete oltre me, il testo originale del GDPR fate un salto sul sito del garante http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/8036793 .

1. Chi è il responsabile della protezione dei dati personali (RPD) e quali sono i suoi compiti?

Il responsabile della protezione dei dati personali (anche conosciuto con la dizione in lingua inglese data protection officer – DPO) è una figura prevista dall’art. 37 del Regolamento (UE) 2016/679. Si tratta di un soggetto designato dal titolare o dal responsabile del trattamento per assolvere a funzioni di supporto e controllo, consultive, formative e informative relativamente all’applicazione del Regolamento medesimo. Coopera con l’Autorità (e proprio per questo, il suo nominativo va comunicato al Garante; v. faq 6) e costituisce il punto di contatto, anche rispetto agli interessati, per le questioni connesse al trattamento dei dati personali (artt. 38 e 39 del Regolamento).

Fantastico l’RDP viene designato dal responsabile da cui ne consegue che il responabile è altro dall’RDP. il sillogismo funziona.

altro discorso poi è a chi serve un DPO, ci sono casi in cui la assegnazione del RDPDPO è obbligatoria, ed altri in cui non lo è. ma considerando la complessità dell’ambito cui il DPORDP lavora sarebbe consigliabile averlo, il GDPR chiede che tale figura sia indipendente ma non che sia un dipendente, ne che sia dedicato solo ad un cliente. è quindi possibile utilizzare servizi di DPORDP esterni che eplichino le funzioni richieste come da indicazione del garante.

Va da se che una figura che deve poter offrire funzioni di supporto e controllo, consultive, formative e informative a questo livello non può essere un junior e quindi il mercato attuale con cifre attorno ai 30k annui identifica come, tanto per cambiare, il mercato italiano non abbia ancora capito cosa sia il GDPR, il DPORDP e non solo.

Una nota finale, visto che in questo giorni ho visto e sentito di tutto, dal fatto che si deve ottenere la “certificazione GDPR”, vi ricordo che al momento in italia non esiste una certificazione per il DPORDP ne esiste in assoluto una certificazione GDPR.

 

sempre dal sito del garante prendo

Sul tema della certificazione inoltre si richiama l’attenzione sul comunicato congiunto, pubblicato sul sito dell’Autorità il 18 luglio 2017 (doc. web n. 6621723), con il quale il Garante e ACCREDIA (l’Ente unico nazionale di accreditamento designato dal Governo italiano) hanno ritenuto necessario sottolineare – al fine di indirizzare correttamente le attività svolte dai soggetti a vario titolo interessati in questo ambito – che «al momento le certificazioni di persone, nonché quelle emesse in materia di privacy o data protection eventualmente rilasciate in Italia, sebbene possano costituire una garanzia e atto di diligenza verso le parti interessate dell’adozione volontaria di un sistema di analisi e controllo dei principi e delle norme di riferimento, a legislazione vigente non possono definirsi “conformi agli artt. 42 e 43 del regolamento 2016/679”, poiché devono ancora essere determinati i “requisiti aggiuntivi” ai fini dell’accreditamento degli organismi di certificazione e i criteri specifici di certificazione».

Si potrebbe obbiettare che sia tardi, ma sicccome siamo in ritardo su tutto siamo allineati alla timeline italiana.

 

ciao

Guida al GDPR per chi non ne vuol sapere: dice il controller "lei non sa chi sono io"

Manca un anno al GDPR Doom’s Day e ovviamente siamo ancora impreparati ad affrontare la cosa.

Non lo dico io, ovvio, ma lo dicono le statistiche. E se i nostri amici al di la delle alpi sono messi non benissimo leggendo queste statistiche, vi lascio immaginare come siamo messi noi.

Siccome è un po che mi occupo della faccenda devo dire che mi sembra evidente che la comprensione di cosa sia il GDPR latita tra i responsabili aziendali, e le idee su come implementarlo sono spesso poche ma ben confuse.

Ho parlato in articoli precedenti diffusamente sul GDPR in tono lieve e talvolta ironico, ci provo ancora, anche se confesso che incomincio a provare un vago senso di inquietudine quando parlo di questi argomenti.

iniziamo dai alcuni errori di comprensione comuni

Il Bestiario GDPR

• Il GDPR mi impedisce di collezionare i dati personali

lo ho sentito dire parecchie volte, ed ovviamente la risposta più corretta a questa osservazione è:

…ma la finiamo di dire pirlate?

Il GDPR è un regolamento che impone regole stringenti di gestione e processo dei dati personali, ma non ne impedisce ne la raccolta ne l’utilizzo. il punto è: sappiamo che ti servono, ma devi proteggere l’identità delle persone legate ai dati che hai raccolto.

• Il GDPR è una roba IT, non mi interessa

e si …

…ma le multe le paghi tu non l’IT

Ovviamente tutto quello che non ci piace diventa un problema IT, peccato che l’IT sia impattata dal GDPR in maniera strumentale. Mi spiego meglio, l’IT deve implementare quelle misure che qualcuno decide debbano essere implementate per garantire il rispetto della normativa, ma non è l’IT che decide cosa implementare.

• Il GDPR è una roba da avvocati, l’IT non centra

Ovviamente duale al precedente esiste la versione IT che si declina con un

ma a me cosa importa di sta roba?

peccato che una corretta implementazione dei dettami del GDPR imponga anche all’IT a ripensare i propri processi ed iniziare a gestire le cose in maniera adulta.

• Io Faccio HR non mi devo occupare di queste cose

Ora notoriamente la mia posizione nei confronti della moderna interpretazione delle funzioni HR è abbastanza “critica” (lo so è un eufemismo).

…Il GDPR fa riferimento ai dati personali, ma anche quelli dei dipendenti…mi spiace ma ci sei dentro fino al collo caro HR manager…

Purtroppo per gli amici HR il GDPR non fa distinzioni tra clienti, fornitori o dipendenti. il GDPR si occupa di preservare le libertà fondamentali dell’individuo, essere impiegato non ne inficia né gli obiettivi né gli obblighi. Si, le funzioni HR devono tenere conto del GDPR.

e via scemenzando ne ho sentite fin troppe, anche da sedicenti personaggi che si offrono come esperti. Ok Ok loro dicono lo stesso di me 🙂

GDPR e Processi

Il primo che dovrebbe preoccuparsi del GDPR non è altri che il Board della azienda. La corretta implementazione del GDPR richiede infatti la esplicita presa in carico della azienda della implementazione della conformità alla nuova legge.

Nel dettato del GDPR viene esplicitato diverse volte che spetta all Data Controller di fare le valutazioni inerenti a quale sia il rischio legato alla getione dei dati personali tenendo presente da un lato le esigenze del business dall’altro le libertà individuali da proteggere.

In altre parole il motore della analisi è il Business. e questo non è un dominio che attiene all’IT ma al board della azienda.

l’implementazione del GDPR richiede che si sia in grado di fare una valutazione di Business dell’impatto del processo di raccolta ed elaborazione di dati personali. è il business che determina anche come devono essere gestiti e protetti questi dati.

Il soggetto utilizzato nella nomenclatura GDPR per fare queste valutazioni è il Data Controller. Il responsabile ultimo del trattamento, il CEO della azienda.

in altre parole chiedere alle funzioni IT di gestire il GDPR è come chiedere ad un pilota di progettare una macchina.

Alla fine della fiera la corretta implementazione della normativa richiede la definizione di processi definiti tracciabili e sicuri che consentano di gestire tutta la vita del dato personale all’interno della azienda. questo comporta:

1. la definizione delle responsabilità all’interno della struttura (ruolo che spetta per definizione al management)
2. la definizione del livello di rischio accettabile in relazione all’attività aziendale ed alla natura dei dati raccolti (che secondo il GDR spetta al management aziendale)
3. la implementazione di misure correttive atte a minimizzare il rischio ANCHE dal punto di vista informatico, cosa che richiede l’intervento delle funzioni IT e di sicurezza

Data Controller e Data Processor

Non si può capire cosa sia il GDPR senza aver capito appieno chi è il Data controller, chi è il Data processor e come gira il fumo 🙂

Data Controller

chi cavolo è il data controller?

Il Data controller secondo il GDPR è il responsabile del trattamento dei dati, insomma quello che decide:

• che dati raccogliere
• per cosa utilizzarli
• valutare e gestire il rischio (attraverso lo strumento della DPIA)

In quanto responsabile, spetta al Data Controller (il CEO aziendale o chi per lui) definire quale sia il livello di rischio accettabile e quindi quali siano le misure di mitigazione corrette da mettere in piedi tenendo presente i vincoli dettati dal GDPR.

Questo non significa che altre funzioni aziendali non siano coinvolte nel processo di definizione; HR, MKTG, Sales ed IT sono componenti attive del processo. Ma alla fine la decisione spetta a chi ha la responsabilità, e questa ricade, secondo il GDPR, sul Data Controller in quanto è l’owner delle attività di business e quindi l’unico che possa valutare, come richiede GPR esposizione e rischio.

Data Processor

Ma allora chi o cosa cavolo è un data processor?

Il data Processor altri non è che chi materialmente si occupa delle attività di raccolta e processo dei dati. In quest’ottica, ad esempio, il data processor può essere sia l’operatore marketing che fa le interviste telefoniche e raccoglie i dati, che la struttura IT che gestisce la struttura informatiche che questi dati manipola e gestisce seguendo le istruzioni impartite dal Data Controller..

Mentre il Data controller è una funzione aziendale interna, il data processor può essere anche una entità esterna. è il caso di servizi offerti da terzi: dai cloud providers, alle agenzie di marketing la variabilità dei data processor dipende da come i dati ed il business è stato disegnato ed implementato.

Essendo il Data controller chi decide quale sia il livello di rischio accettabile e quindi le opportune misure di mitigazione il processo di implementazione del GDPR non può partire dai data processor che invece sono le funzioni “implementative”.

Per esemplificare al data controller spetta la definizione dei parametri di business e il livello di rischio accettabile. questo comporta assumersi la responsabilità di come i dati vengono raccolti, gestiti e protetti.

Al Data processor invece spetta l’implementazione operativa delle misure di sicurezza richieste dal Data controller e le operazioni generiche di gestione dei dati.

Insomma il GDPR non dice che devi usare encryption, ma dice che spetta al Data Controller decidere se questa sia una misura adatta a proteggere le libertà individuali associate an un non corretto uso dei dati raccolti in funzione degli imperativi di business.

ovviamente il Data Controller è libero di andare dalle funzioni IT per chiedere:

1. si può fare?
2. quanto costa?

ma non spetta all’IT decidere in seno alla implementazione o meno della misura.

Altri aspetti del GDPR richiedono attività che coinvolgono un corretto disegno della struttura manageriale e di reporting che sono di delicata implementazione vista la storica sclerosi delle strutture manageriali italiane storicamente avverse a qualsiasi cambiamento. ma questo è un punto su cui il GDOR non transige, pur non dando indicazioni specifiche richiede l’esplicita responsabilità aziendale nei confronti della implementazione del dettato di legge. alcuni vincoli tuttavia sono esplicitati in termini di legislazione locale anche in italia, ad esempio come si sta definendo la figura del DPO che, è chiaro dal dettato del GDPR, non ha responsabilità diretta sulla implementazione del GDPR che rimane in toto al data controller, e che deve avere il garantito livello di autonomia ed indipendenza dalle altre funzioni aziendali (il che taglia fuori, ad esempio, it managers, sales managers o ruoli simili).

L’inversione dell’onere della prova

Un aspetto probabilmente non ancora ben digerito della nuova normativa è il concetto sottointeso di inversione dell’onere della prova.

Spetta al Data controller dimostrare di essere compliant al GDPR in caso di controlli e o di incidenti.

in altre parole:

sei colpevole se non dimostri la tua innocenza

Questo significa che gli obblighi indicati dal GDPR non sono formali ma sostanziali, e la loro implementazione deve essere formalmente dimostrabile, altrimenti, indipendentemente che ci si sia comportati bene o meno, si è formalmente e sostanzialmente non conformi e quindi perseguibili a termini della normativa.

Insomma non possiamo “ciurlare nel manico” più di tanto, ma siamo obbligati a mettere in piedi processi dimostrabili in maniera chiara, attraverso documentazione, reporting, funzioni aziendali correttamente definite.

 

 

 

 

Guida al GDPR per chi non ne vuol sapere: dice il controller "lei non sa chi sono io"

Manca un anno al GDPR Doom’s Day e ovviamente siamo ancora impreparati ad affrontare la cosa.

Non lo dico io, ovvio, ma lo dicono le statistiche. E se i nostri amici al di la delle alpi sono messi non benissimo leggendo queste statistiche, vi lascio immaginare come siamo messi noi.

Siccome è un po che mi occupo della faccenda devo dire che mi sembra evidente che la comprensione di cosa sia il GDPR latita tra i responsabili aziendali, e le idee su come implementarlo sono spesso poche ma ben confuse.

Ho parlato in articoli precedenti diffusamente sul GDPR in tono lieve e talvolta ironico, ci provo ancora, anche se confesso che incomincio a provare un vago senso di inquietudine quando parlo di questi argomenti.

iniziamo dai alcuni errori di comprensione comuni

Il Bestiario GDPR

• Il GDPR mi impedisce di collezionare i dati personali

lo ho sentito dire parecchie volte, ed ovviamente la risposta più corretta a questa osservazione è:

…ma la finiamo di dire pirlate?

Il GDPR è un regolamento che impone regole stringenti di gestione e processo dei dati personali, ma non ne impedisce ne la raccolta ne l’utilizzo. il punto è: sappiamo che ti servono, ma devi proteggere l’identità delle persone legate ai dati che hai raccolto.

• Il GDPR è una roba IT, non mi interessa

e si …

…ma le multe le paghi tu non l’IT

Ovviamente tutto quello che non ci piace diventa un problema IT, peccato che l’IT sia impattata dal GDPR in maniera strumentale. Mi spiego meglio, l’IT deve implementare quelle misure che qualcuno decide debbano essere implementate per garantire il rispetto della normativa, ma non è l’IT che decide cosa implementare.

• Il GDPR è una roba da avvocati, l’IT non centra

Ovviamente duale al precedente esiste la versione IT che si declina con un

ma a me cosa importa di sta roba?

peccato che una corretta implementazione dei dettami del GDPR imponga anche all’IT a ripensare i propri processi ed iniziare a gestire le cose in maniera adulta.

• Io Faccio HR non mi devo occupare di queste cose

Ora notoriamente la mia posizione nei confronti della moderna interpretazione delle funzioni HR è abbastanza “critica” (lo so è un eufemismo).

…Il GDPR fa riferimento ai dati personali, ma anche quelli dei dipendenti…mi spiace ma ci sei dentro fino al collo caro HR manager…

Purtroppo per gli amici HR il GDPR non fa distinzioni tra clienti, fornitori o dipendenti. il GDPR si occupa di preservare le libertà fondamentali dell’individuo, essere impiegato non ne inficia né gli obiettivi né gli obblighi. Si, le funzioni HR devono tenere conto del GDPR.

e via scemenzando ne ho sentite fin troppe, anche da sedicenti personaggi che si offrono come esperti. Ok Ok loro dicono lo stesso di me 🙂

GDPR e Processi

Il primo che dovrebbe preoccuparsi del GDPR non è altri che il Board della azienda. La corretta implementazione del GDPR richiede infatti la esplicita presa in carico della azienda della implementazione della conformità alla nuova legge.

Nel dettato del GDPR viene esplicitato diverse volte che spetta all Data Controller di fare le valutazioni inerenti a quale sia il rischio legato alla getione dei dati personali tenendo presente da un lato le esigenze del business dall’altro le libertà individuali da proteggere.

In altre parole il motore della analisi è il Business. e questo non è un dominio che attiene all’IT ma al board della azienda.

l’implementazione del GDPR richiede che si sia in grado di fare una valutazione di Business dell’impatto del processo di raccolta ed elaborazione di dati personali. è il business che determina anche come devono essere gestiti e protetti questi dati.

Il soggetto utilizzato nella nomenclatura GDPR per fare queste valutazioni è il Data Controller. Il responsabile ultimo del trattamento, il CEO della azienda.

in altre parole chiedere alle funzioni IT di gestire il GDPR è come chiedere ad un pilota di progettare una macchina.

Alla fine della fiera la corretta implementazione della normativa richiede la definizione di processi definiti tracciabili e sicuri che consentano di gestire tutta la vita del dato personale all’interno della azienda. questo comporta:

1. la definizione delle responsabilità all’interno della struttura (ruolo che spetta per definizione al management)
2. la definizione del livello di rischio accettabile in relazione all’attività aziendale ed alla natura dei dati raccolti (che secondo il GDR spetta al management aziendale)
3. la implementazione di misure correttive atte a minimizzare il rischio ANCHE dal punto di vista informatico, cosa che richiede l’intervento delle funzioni IT e di sicurezza

Data Controller e Data Processor

Non si può capire cosa sia il GDPR senza aver capito appieno chi è il Data controller, chi è il Data processor e come gira il fumo 🙂

Data Controller

chi cavolo è il data controller?

Il Data controller secondo il GDPR è il responsabile del trattamento dei dati, insomma quello che decide:

• che dati raccogliere
• per cosa utilizzarli
• valutare e gestire il rischio (attraverso lo strumento della DPIA)

In quanto responsabile, spetta al Data Controller (il CEO aziendale o chi per lui) definire quale sia il livello di rischio accettabile e quindi quali siano le misure di mitigazione corrette da mettere in piedi tenendo presente i vincoli dettati dal GDPR.

Questo non significa che altre funzioni aziendali non siano coinvolte nel processo di definizione; HR, MKTG, Sales ed IT sono componenti attive del processo. Ma alla fine la decisione spetta a chi ha la responsabilità, e questa ricade, secondo il GDPR, sul Data Controller in quanto è l’owner delle attività di business e quindi l’unico che possa valutare, come richiede GPR esposizione e rischio.

Data Processor

Ma allora chi o cosa cavolo è un data processor?

Il data Processor altri non è che chi materialmente si occupa delle attività di raccolta e processo dei dati. In quest’ottica, ad esempio, il data processor può essere sia l’operatore marketing che fa le interviste telefoniche e raccoglie i dati, che la struttura IT che gestisce la struttura informatiche che questi dati manipola e gestisce seguendo le istruzioni impartite dal Data Controller..

Mentre il Data controller è una funzione aziendale interna, il data processor può essere anche una entità esterna. è il caso di servizi offerti da terzi: dai cloud providers, alle agenzie di marketing la variabilità dei data processor dipende da come i dati ed il business è stato disegnato ed implementato.

Essendo il Data controller chi decide quale sia il livello di rischio accettabile e quindi le opportune misure di mitigazione il processo di implementazione del GDPR non può partire dai data processor che invece sono le funzioni “implementative”.

Per esemplificare al data controller spetta la definizione dei parametri di business e il livello di rischio accettabile. questo comporta assumersi la responsabilità di come i dati vengono raccolti, gestiti e protetti.

Al Data processor invece spetta l’implementazione operativa delle misure di sicurezza richieste dal Data controller e le operazioni generiche di gestione dei dati.

Insomma il GDPR non dice che devi usare encryption, ma dice che spetta al Data Controller decidere se questa sia una misura adatta a proteggere le libertà individuali associate an un non corretto uso dei dati raccolti in funzione degli imperativi di business.

ovviamente il Data Controller è libero di andare dalle funzioni IT per chiedere:

1. si può fare?
2. quanto costa?

ma non spetta all’IT decidere in seno alla implementazione o meno della misura.

Altri aspetti del GDPR richiedono attività che coinvolgono un corretto disegno della struttura manageriale e di reporting che sono di delicata implementazione vista la storica sclerosi delle strutture manageriali italiane storicamente avverse a qualsiasi cambiamento. ma questo è un punto su cui il GDOR non transige, pur non dando indicazioni specifiche richiede l’esplicita responsabilità aziendale nei confronti della implementazione del dettato di legge. alcuni vincoli tuttavia sono esplicitati in termini di legislazione locale anche in italia, ad esempio come si sta definendo la figura del DPO che, è chiaro dal dettato del GDPR, non ha responsabilità diretta sulla implementazione del GDPR che rimane in toto al data controller, e che deve avere il garantito livello di autonomia ed indipendenza dalle altre funzioni aziendali (il che taglia fuori, ad esempio, it managers, sales managers o ruoli simili).

L’inversione dell’onere della prova

Un aspetto probabilmente non ancora ben digerito della nuova normativa è il concetto sottointeso di inversione dell’onere della prova.

Spetta al Data controller dimostrare di essere compliant al GDPR in caso di controlli e o di incidenti.

in altre parole:

sei colpevole se non dimostri la tua innocenza

Questo significa che gli obblighi indicati dal GDPR non sono formali ma sostanziali, e la loro implementazione deve essere formalmente dimostrabile, altrimenti, indipendentemente che ci si sia comportati bene o meno, si è formalmente e sostanzialmente non conformi e quindi perseguibili a termini della normativa.

Insomma non possiamo “ciurlare nel manico” più di tanto, ma siamo obbligati a mettere in piedi processi dimostrabili in maniera chiara, attraverso documentazione, reporting, funzioni aziendali correttamente definite.

 

 

 

 

Caro CISO, ti suggerisco di parlare d'affari con il tuo CdA, evita tecnicismi.

Caro consiglio di amministrazione e caro CISO

Penso che dovremmo sempre considerare il nostro lavoro come una parte del business. Abbiamo finalmente iniziato a prendere in considerazione la sicurezza informatica e la protezione dei dati come un problema serio, ma ora la domanda è come valutare un rischio nei nostri piani di analisi e di business…

Usualmente la documentazione e le relazioni per l’analisi di rischio, presentati nelle aziende (se e quando vengono presentati ovvio) si limitano, per la maggior parte, all’uso di valori generici (rischio alto, medio, basso), ma non sembra che si usi specificare qualsiasi metrica. Senza metrica è difficile fare una valutazione che abbia senso e parimenti impossible fare confronti;

così alla eventuale questione sollevata da un qualsiasi membro del Consiglio:

“il rischio XYZ è grave come il rischio ABC?”

non si può avere una risposta credibile se non sulla “percezione”, che è soggettiva, se non supportata da fatti…

Costruire metriche di sicurezza è un lavoro complesso e sono oggetto di studio, interpretazione e discussione anche in sede universitaria tutt’oggi, ma nonostante questa complessità possiamo semplificare l’approccio per fare analisi di sicurezza in qualche modo comprensibili e credibili.

Prima di tutto, per rispondere alla domanda presentata dal membro del CdA è necessario avere un quadro comune e condiviso di valutazione, che includa metriche di facile lettura per permettere di fare confronti comprensibili anche ai non esperti di cyber sicurezza, caratteristica comune alla maggior parte dei membri del Consiglio di Amministrazione che, però, devono prendere decisioni basate su tali dati.

Lo so, questo è qualcosa che va oltre le attività di un Cyber e Information Security Officer, questo richiede che l’intera azienda a iniziare a pensare alla cyber sicurezza e alle risorse digitali in campo ma, a meno che l’approccio sia quello di procedere in modo reattivo in caso di problemi (tipo: “mi sono beccato il ransomware…e adesso? che faccio? quanto mi costa? …”), indicazioni da parte del CISO sono indispensabili per delineare il quadro e aiutare nella definizione delle metriche.

Haimè l’analisi del rischio per la sicurezza informatica è tutto tranne che semplice, soprattutto se le analisi sono relative all’impatto aziendale di un incidente, poiché è richiesta tanto la comprensione del problema di sicurezza dal punto di vista cyber così come la comprensione delle ricadute sul business in cui il rischio è analizzato.

Ci sono due aspetti principali che hanno bisogno di metriche leggibili:

1. Valutazione del rischio
2. Conseguenze di rischio

Il primo elemento viene utilizzato per definire quanto “rischioso” è qualcosa.

La misura del rischio richiede, per semplificare una questione complessa, di essere in grado di valutare la probabilità che qualcosa accada, l’entità del danno e il costo per aggiustare le cose.

La dimensione economica dei danni e dei costi occorrenti per sistemare le cose sono legati alle conseguenze identificate per uno specifico rischio. Queste sono, fondamentalmente, le metriche che possono essere utilizzate in una riunione col consiglio di amministrazione per descrivere il rischio in termini comprensibili ad un pubblico non-consapevole in termini di cyber sicurezza.

Non voglio qui entrare nel dettaglio della valutazione del rischio, sono sicuro che come CISO avrai una profonda conoscenza e comprensione del problema e non voglio annoiarti con le mie riflessioni al riguardo, ma permettimi di osservare come non ci sia, apparentemente, ancora un quadro comune di valutazione diffuso tra gruppi e Business Unit della tua azienda. Trovo difficile credere che la percezione del rischio del dipartimento HR sia analogo a quello del dipartimento IT o del Marketing, o della produzione o vendita,  se cosi fosse probabilmente non staresti leggendo questo articolo mentre io starei quasi sicuramente leggendo il tuo.

La valutazione del rischio è una attività prevalentemente tecnica: la comprensione delle tecniche di attacco e difesa, le risorse necessarie sono ambiti dove CISO e management IT dovrebbero essere in grado di dare risposte sensate e credibili. Discorso diverso invece è l’analisi dell’impatto dell’incidente sul business. Questo impatto richiede sia la comprensione di cosa avvenga tecnicamente, almeno a grandi linee, ma anche la comprensione di quali siano i meccanismi legati al business che sono danneggiati dall’incidente. Va da se che le metriche da usarsi devono essere comprensibili al business, altrimenti sono inutili.

Le conseguenze di un incidente ed il suo livello di rischio sono ovviamente correlate cosi come sono correlate le dimensioni che definiscono il problema, l’obiettivo è capire, nella ipotesi che si verifichi un incidente di sicurezza, quali possano essere le misure che consentono alla vostra azienda di descriverlo e effettuare un confronto con un altro evento per determinare, ad esempio, priorità di intervento e di budget.

Avrebbe senso, dal mio punto di vista, presentare qualsiasi analisi di rischio al consiglio di amministrazione e altri manager e dirigenti in questi termini:

1) costo monetario in termini di perdita di ricavi

2) costo monetario in termini di costi effettivi sostenuti o da sostenere

3) impatto sulla penetrazione del mercato

4) impatto sulla percezione del marchio

Utilizzare queste 4 dimensioni permette di confrontare un incidente “ABC” ad un avvenimento “XYZ” e rispondere in qualche modo alla domanda del membro del consiglio fatta prima e, inoltre, a dare una metrica per capire dove e perché investire in un’area invece in un’altra.

Permettimi di descrivere rapidamente i 4 punti.

1) costo monetario in termini di perdita di ricavi

Si tratta di una dimensione che può essere facilmente percepita dai responsabili commerciali e finanziari. Comporta l’essere in grado di stimare quanta attività di vendita sarà influenzata dall’incidente. Il lasso di tempo preso in considerazione è, ovviamente, una delle criticità chiave, dal momento che gli eventi possono avere un effetto diverso in termini di intervallo di tempo breve, medio e lungo termine.

La valutazione può essere presentata sia in termini di importo netto di denaro o % rispetto al bilancio. Entrambi sono utili per capire l’impatto dell’evento.

2) costo monetario in termini di costi effettivi sostenuti o da sostenere

Questo significa mettere in considerazione tutti i costi vivi relazionati all’incidente come multe, questioni legali, interventi di sostituzione o aggiornamento del parco HWSW , persone che lavorano sull’incidente e così via. È importante separare i costi collegati all’incidente, dalle perdite economiche collegate all’incidente stesso, perché la natura degli interventi correttivi è estremamente diversa nei diversi casi.

3) impatto sulla penetrazione del mercato

Si tratta di una metrica che ha senso per un fornitore che sta cercando di espandere la sua presenza nel mercato come la tua azienda sta probabilmente cercando di fare. È strettamente connesso ai ricavi diretti, ma anche con le aspettative di crescita. Ciò può essere rappresentato come una % della quota di mercato.

4) impatto sulla percezione del marchio

Questo ultimo elemento è il più difficile da misurare, ma dato che dipende dalla metrica utilizzata per valutare il valore del Brand all’interno dell’azienda, dal momento che non mi è stato detto quali parametri vengono utilizzati qui posso solo suggerirti di presentare la variazione % correlata al valore stimato prima dell’incidente.

Per quello che so se questo non è stato fatto prima potrebbe essere qualcosa di intelligente da presentare in un futuro Business Plan o un’attività per il Cyber e Information Security Office da effettuarsi quest’anno in maniera da essere in grado, in futuro, di fare presentazioni e proiezioni che abbiano un senso.

Con quei 4 punti sarebbe possibile per entrambi (tu ed il consiglio di amministrazione):

a) fare confronto tra rischi

e

b) fornire al Consiglio una serie di elementi che possono essere oggettivamente utilizzati per prendere decisioni strategiche e di indirizzo.

Prendiamo come esempio la analisi dei rischi concernenti ad una violazione delle normative sulla privacy europea, il famigerato GDPR

L’approccio che ti ho proposto consentirebbe di presentare nel BP un insieme di dati comprensibili ed adatti a giustificare le spese e gli investimenti per ogni tipologia di rischio presentato; qualcosa di simile alla seguente tabella:

Permettimi di spiegare la tabella, considera naturalmente che i valori sono fittizi e il lasso di tempo considerato può essere regolato in base alla tua realtà.

Non conformità al GDPR

1) violazione di dati personali del cliente: intestazioni di colonne

Impatto a breve termine (1-3 mesi)

È cosa succedere immediatamente dopo il problema, quando è necessario intraprendere le operazioni necessarie per riprendere la operatività. Se hai un Emergency Response Team (dovresti) va computato qui…

Impatto di medio termine (3 mesi – un anno)

Permettimi di essere onesto, se è un problema di minore entità può accadere che le cose si possano risolvere rapidamente, ma se il problema è più grande, come ad esempio il tuo database di marketing esposto al pubblico su internet, devi iniziare a considerare anche le spese legali, multe e l’impatto sul tuo mercato…

Impatto a lungo termine (1-3 anni)

Le cose hanno un impatto anche dopo il tuo Business Plan, la vita non è limitata alla tua arbitraria finestra temporale, il business non si limita a finestre temporali limitate, tu dovresti essere in grado di fare previsione e analisi di più lungo periodo, oltre alla visione, orrore, trimestrale o annuale. È una esigenza comune in qualsiasi attività commerciale, e qui è o stesso.

2) violazione dei dati personali cliente: intestazioni di riga

Perdita di entrate

Questa è la perdita di gettito, legata all’incidente, che si dovrà affrontare rispetto le vostre aspettative di bilancio.

Costi diretti

Questo contiene ciò che si deve pagare per causa diretta  dell’incidente ad esempio:

• Sostituzione, aggiornamento, implementazione soluzioni HWSW
• Multe
• Stima dell’eventuale costo legato alla richiesta di risarcimento di eventuali parti lese
• riscatto pagato (ad esempio in caso di ransomware)
• aumento di costo di eventuali polizze assicurative sulla cyber security
• costi di fermo porduzione
• persone che lavorano sulla questione per risolvere il problema (eventuali analisti forensi, esperti informatici, avvocati…)
• …

Impatto sulla penetrazione del mercato

Questo è il posto dove mettere come l’incidente danneggerà il vostro business in termini della vostra presenza sul mercato (quote di mercato) e le prospettive future.

Impatto sulla percezione del marchio

Questo indica quanto la tua credibilità risentirà dell’incidente

Con questo tipo di matrice sarebbe facile fare valutazioni corrette e confronti sensati. Non so se questo è, al momento, qualcosa che può essere fatto con gli attuali strumenti di analisi in tuo possesso, ma sarebbe un elemento utile da mettere in un BP e per un futuro corretto approccio alla valutazione del rischio per la sicurezza informatica (cyber security, data seurity e data privacy).

ciao

Antonio