News

in questa pagina trovi le novità normative e segnalazioni su eventi e convegni, 

Data Breach: cosa fare prima

pubblicato 21 mar 2019, 15:56 da Paolo Calvi

Qualche mia breve riflessione sulle misure preventive da adottare prima che il data breach si verifichi; perchè, prima o poi, si verificherà...

Il diario del DPO #3

pubblicato 21 mar 2019, 15:38 da Paolo Calvi

pianificazione controlli: audit verticali e orizzontali, piano pluriennale, tempistiche.

Chi è il DPO?

pubblicato 1 mar 2019, 16:16 da Paolo Calvi   [ aggiornato in data 1 mar 2019, 16:16 ]

In questa intervista anche il mio illuminato parere

Il diario del DPO #2

pubblicato 20 gen 2019, 12:03 da Paolo Calvi

Ecco a voi la seconda imperdibile puntata del "diario del DPO", la rubrica da me curata con cadenza bimestrale.
Buona lettura.

Diario del DPO #2

Auguri 2019

pubblicato 1 gen 2019, 07:47 da Paolo Calvi


Il diario del DPO #1

pubblicato 6 dic 2018, 09:11 da Paolo Calvi   [ aggiornato in data 6 dic 2018, 10:53 ]

La mia prima uscita su una testata del gruppo Digital360.
Si tratta di una rubrica bimestrale, che vi invito a seguire.

Semplificazioni Registro per le PMI

pubblicato 9 mag 2018, 07:40 da Paolo Calvi   [ aggiornato in data 9 mag 2018, 07:54 ]

Ho sentito oggi al Congresso AssoDPO Luigi Montuori del Garante parlare di WP29. ha citato una recente "position paper" sull'esenzione dai registri (20180419_Art29WP_PositionpaperArt30_publishpdf).


ricordo che art 30(5) recita: "Gli obblighi di cui ai paragrafi 1 e 2 non si applicano alle imprese o organizzazioni con meno di 250 dipendenti, a meno che il trattamento che esse effettuano possa presentare un rischio per i diritti e le libertà dell'interessato, il trattamento non sia occasionale o includa il trattamento di categorie particolari di dati di cui all'articolo 9, paragrafo 1, o i dati personali relativi a condanne penali e a reati di cui all'articolo 10."

il wp29 ribadisce che l'esenzione non vale nei tre casi indicati (rischio per i diritti, trattamento non occasionale o dati sensibili/giudiziari), ma che le PMI sono tenute a mettere nei registri SOLO i trattamenti di quei tre tipi

However, such organisations need only maintain records of processing activities for the types of processing mentioned by Article 30(5).

For example, a small organisation is likely to regularly process data regarding its employees. As a result, such processing cannot be considered “occasional” and must therefore be included in the record of processing activities.1 Other processing activities which are in fact “occasional”, however, do not need to be included in the record of processing activities, provided they are unlikely to result in a risk to the right and freedoms of data subjects and do not involve special categories of data or personal data relating to criminal convictions and offences.

personalmente resto dell'opinione che non si possa fare data protection senza sapere quali dati si trattano, quindi bisogna avere un registro completo. confermato ieri dal col. Marco Menegazzo (resp. nucleo privacy GdF) : "la prima cosa che chiederemo è di parlare con il DPO, la seconda di vedere il registro".

però poi lo so che qualcuno mi accuserà di voler ingiustamente costringere le piccole imprese a sommergersi di burocrazia inutile…


Privacy negli Emendamenti alla Legge di Bilancio

pubblicato 20 dic 2017, 02:07 da Paolo Calvi   [ aggiornato in data 1 mar 2019, 16:17 ]

Avrete sicuramente già visto questa notizia. ve la segnalo nel caso vi fosse sfuggita.

Segnaliamo l’emendamento 88-bis.24 sul trattamento dei dati personali e digitale con il quale si demanda al Garante Privacy di adottare, entro due mesi dalla data di entrata in vigore della legge di bilancio,  un provvedimento al fine di:

- Disciplinare le modalità attraverso cui monitorare e vigilare sull’applicazione del Regolamento UE 2016/679 relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali;

- Disciplinare le modalità di verifica della presenza di adeguate infrastrutture per l’interoperabilità dei formati con cui i dati vengono messi a disposizione dei soggetti interessati;

- Predisporre un modello di informativa da compilare a cura dei titolari di dati personali che effettuino un trattamento fondato sull’interesse legittimo che preveda l’uso di nuove tecnologie o di strumenti automatizzati;

- Definire linee guida o buone prassi in tema di trattamento dei dati personali fondato sull’interesse legittimo del titolare.


Come fonte ho trovato il documento allegato, alle pagg 22-23 i temi di nostro interesse.

da una prima lettura noterei quanto segue:

597-ter:

  • comma a) "modalità attraverso cui monitorare e vigilare" direi che non ci sarebbe stato bisogno di alcuna delega, il garante ha esattamente questo compito...
  • comma b) "adeguate infrastrutture per l’interoperabilità dei formati" rimanda a verifiche sul tema della portabilità;
  • commi c) e d) "modello di informativa" e "linee guida o buone prassi" sul legittimo interesse sembrano indicare l'intenzione di fare chiarezza su questo tema altrimenti abbastanza nebuloso; attenzione: si parla di "informativa" ma non dovete pensare a quella rivolta agli interessati; si tratta invece di una specie di notifica da inviare al garante (vedi oltre)
597-quater e quinquies
  • si definisce un meccanismo di comunicazione al garante per ogni trattamento basato sul legittimo interesse "che preveda l’uso di nuove tecnologie o di strumenti automatizzati"  con possibilità per il garante di imporre moratoria, chiedere ulteriori info e (nel caso di lesione dei diritti e delle libertà dell'interessato) inibire il trattamento (NB vale il silenzio assenso).


Ma ???!!!
 così si scardina lo spirito del GDPR, basato sulla responsabilizzazione del titolare, che per trattamenti che rischiano di ledere diritti e libertà effettua una DPIA, e solo nel caso non riesca a mitigare i rischi si rivolge al garante con la consultazione prevista dall'art.36. qui invece sembra si voglia tornare al vecchio meccanismo della notificazione o richiesta di autorizzazione...

Data Breach: non solo "notifica"

pubblicato 13 nov 2017, 09:35 da Paolo Calvi   [ aggiornato in data 13 nov 2017, 10:51 ]

Fra le nuove discipline introdotte dal GDPR, quella sulla violazione dei dati personali (Data Breachè apparentemente una delle meno controverse. A differenza della pratica della DPIA o della figura del DPO, sulle quali sono fiorite ampie discussioni, sul Data Breach sembra tutto chiaro. Infatti non risultano tracce di dibattito. Persino le Linee Guida WP250 (adottate dal WP29 il 3/10/17) chiariscono e dettagliano ma aggiungono poco.

Ma vediamo se è proprio tutto così scontato. Partiamo da come viene normalmente chiamata questa materia: "Notifica del data breach". Corretto: infatti l'art.33 del GDPR si chiama appunto "Notifica di una violazione dei dati personali all'autorità di controllo". E il contenuto dell'articolo stesso, sin dal primo comma, di questo tratta: obbligo per il Titolare di notifica al Garante, obbligo per il Responsabile di informare il Titolare, contenuto della notifica, modalità di fornitura delle informazioni, documentazione delle violazioni. Poi c'è il 34, relativo alla comunicazione delle violazioni agli interessati. Nessuna prescrizione su misure tecniche e/o organizzative da adottare per prevenire, individuare o gestire le violazioni.

Non dimentichiamoci tuttavia che lo spirito dell'intero Regolamento è quello di esporre i principi, lasciando al Titolare la scelta delle modalità da adottare per rispettare i principi. Vogliamo quindi supporre che il legislatore abbia inteso dire qualcosa tipo "non c'è bisogno di fare nulla per prevenire o contrastare le violazioni, basta che quando accadono mi mandi la notifica"? Evidentemente no, anche perché gli artt. 33 e 34 (nell'ambito della Sezione 2 del GDPR, dedicata alla Sicurezza dei dati personali) sono preceduti dal 32, che prescrive al Titolare (ed al Responsabile) di mettere in atto "misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio".

Teniamo inoltre in considerazione il contesto nel quale il Titolare si troverà a dover predisporre ed inviare la famosa notifica al garante. Si tratta certamente di un contesto di crisi, per due diversi motivi:
1) se c'è stata una violazione della sicurezza, bisogna agire con tempestività;
2) il GDPR prescrive tempi strettissimi (72 ore) per l'invio della notifica.
In questa situazione il Titolare ha di fronte due possibilità: affrontare la questione solo nel momento in cui si verifica, improvvisando sul momento prassi e responsabilità, oppure predisporre ruoli e procedure.

Comprenderete allora perché sia opportuno adottare preventivamente alcune misure. Vediamo quali:
 Ambito   Descrizione
 Ruoli e Responsabilità
  • Individuare un Responsabile con competenze in Data Protection per valutare le  conseguenze sui diritti degli interessati e gestire la notifica delle violazioni.
  • Individuare un Responsabile IT con competenze sugli aspetti tecnici per  prevenire e gestire le violazioni.
  • Piano di formazione degli Incaricati al trattamento dei dati personali.
 Misure Organizzative  
  • Predisporre una procedura/regolamento.
  • Definire il livello di rischio in caso di  violazione per ogni trattamento di dati personali.
  • Verificare vincoli contrattuali con clienti.
  • Prevedere vincoli contrattuali con fornitori che trattano dati personali.
 Prevenzione delle   Violazioni
  •  In aggiunta ai sistemi di sicurezza già presenti, valutare l'adozione di sistemi atti a prevenire le violazioni.
 Prevenzione delle   conseguenze
  •  Valutare l'adozione di sistemi atti a prevenire rischi per i diritti degli interessati [es. crittografia].
 Rilevazione delle   Violazioni
  •  Definire gli eventi scatenanti la segnalazione di una violazione ed adottare strumenti atti a rilevarli

Fra le misure organizzative da prevedere in procedura, particolare rilevanza assume la Classificazione dei Rischi; si tratta di una distinzione niente affatto accademica, che ha invece conseguenze concrete ai fini della getione della violazione (e relativa notifica). 

Rischio ASSENTE: la notifica al Garante non è obbligatoria solo nei casi in cui è possibile comprovare la totale mancanza di rischi.

Rischio PRESENTE: in presenza di rischi per gli interessati, è necessaria la notifica al Garante.
Principali rischi per i diritti e le libertà degli Interessati conseguenti una violazione:

  • danni fisici, materiali o immateriali alle persone fisiche;
  • perdita del controllo dei dati personali;
  • limitazione dei diritti, discriminazione;
  • furto o usurpazione d'identità;
  • perdite finanziarie, danno economico o sociale.
  • decifratura non autorizzata della pseudonimizzazione;
  • pregiudizio alla reputazione;
  • perdita di riservatezza dei dati personali protetti da segreto professionale (sanitari, giudiziari).

Rischio ELEVATO: In presenza di rischi “elevati”, è necessaria la comunicazione agli interessati. Nel momento in cui il titolare del trattamento adotta sistemi di crittografia dei dati, e la violazione non comporta l’acquisizione della chiave di decrittografia, la comunicazione ai soggetti interessati non sarà un obbligo. I rischi per i diritti e le libertà degli interessati possono essere considerati “elevati” quando la violazione può, a titolo di esempio:

  • coinvolgere un rilevante quantitativo di dati personali e/o di soggetti interessati;
  • riguardare categorie particolari di dati personali;
  • comprendere dati che possono accrescere ulteriormente i potenziali rischi (es. dati di localizzazione, finanziari, relativi alle abitudini e preferenze);
  • comportare rischi imminenti e con un’elevata probabilità di accadimento (es. rischio di perdita finanziaria in caso di furto di dati relativi a carte di credito);
  • impattare su soggetti che possono essere considerati vulnerabili per le loro condizioni (es. pazienti, minori, soggetti indagati).

Risulta evidente che nel frangente di una violazione, poter ricorrere ad una preventiva classificazione del rischio relativo ad ogni trattamento sarà di grande aiuto per prendere le decisioni corrette nei tempi prescritti. La classificazione potrà essere opportunamente integrata nel Registro dei Trattamenti.

Vediamo come attrezzarsi per la gestione dell'evento, al momento del suo verificarsi. Il flusso di attività da seguire in caso di violazione ai dati può essere suddiviso in 5 fasi:

  1. Rilevazione della violazione
  2. Gestione e Valutazione della violazione
  3. Notifica al Garante
  4. (eventuali) Comunicazioni agli Interessati
  5. Registrazione delle violazioni
Come vedete anche dal diagramma, la famosa "notifica" non è che uno dei passi da compiere, che non può tuttavia prescindere dai passi precedenti e successivi. E la possibilità di rispettare la tempistica rigorosa prevista dal GDPR per lo step che qui abbiamo chiamato 3B dipende strettamente dalla tempestività con cui sarà possibile completare le fasi 2B e 3A; il che ancora una volta dipende dalla disponibilità di una procedura ed altre misure preventive (inclusa la formazione).

Cloud Transformation

pubblicato 4 ott 2017, 10:00 da Paolo Calvi   [ aggiornato in data 5 ott 2017, 01:04 ]


Sempre stimolanti le presentazioni delle ricerche degli Osservatori del Politecnico. 
Oggi era la volta dell'Osservatorio "Cloud & ICT as a service".
Il Direttore Alessandro Piva ha mostrato come il Cloud svolga il ruolo di piattaforma abilitante per l'innovazione digitale (anche per la PA): ad esempio è utilizzato in misura significativa (17% del public & hybrid) per la data intelligence. Il mercato cresce del 24%: le PMI +36% e le grandi +22%.

Le testimonianze delle aziende invitate alla tavola rotonda (Whirlpool lancia giusto oggi il suo SAP in cloud, con il quale gestisce bdg da alcuni miliardi; SMC ha messo in cloud la strategica piattaforma gestionale HR) mostrano una maturità ormai raggiunta da progetti impegnativi. L'on premise è visto come monolite statico, il cloud come elemento dinamico di innovazione. L'approccio graduale (hybrid) può aiutare l'accesso al cloud.

Gabriele Faggioli ha ricordato l'importanza della contrattualistica (con particolare attenzione alla termination, come ha sottolineato Ciccolini di Whirlpool). Con Mariano Corso poi ha lanciato un sondaggio sul ruolo del GDPR nei confronti del cloud: fra le risposte ha prevalso largamente quella di "fattore abilitante grazie alla maggiore sicurezza" (42%). Forse una maggiore presenza in platea di PMI avrebbe dato più peso alla risposta "fattore abilitante grazie alla maggiore responsabilizzazione del provider", che si è comunque piazzata seconda.

Fiorentino di KPNQwest ha rivendicato l'importanza di un provider europeo: non è tanto importante dove risiede il dato (basta che sia sicuro, come ha ricordato Faggioli), ma affidare i propri dati ad un soggetto che risponde all'autorità UE li allontana dal rischio di finire in mano alla NSA.

Il Responsabile Scientifico Stefano Mainetti ha presentato alcuni dati qualitativi della Ricerca: per la prima volta nella percezione delle imprese tutti i fattori sono considerati "migliorativi" compresa l'integrazione. Il campione, sicuramente rappresentativo di trendsetter e non della media, vede come fenomeni consolidati SAAS e IAAS; come emergenti Private cloud (55%) e PAAS (36%).

Il PAAS è "la cassetta degli attrezzi" del cloud, che aiuta a mascherare la complessità sottostante, grazie anche alla migliorata possibilità di integrazione grazie alla disponibilità di "connettori" (strumenti di gestione delle API ecc.). Fenomeno da tenere sotto osservazione il multi-cloud, già presente nel IAAS (9%) da qualche anno mentre è nuovo nel PAAS (5%)

Tutta questa innovazione porta inevitabilmente ad un gap nelle competenze, denunciato dall'80% delle aziende, principalmente nella gestione delle architetture. Inoltre l'allontanamento dei gestori dell'IT dalle incombenze tecniche li spinge a dover acquisire maggiore capacità di calarsi nel business, smettendo di starne a lato.

La presenza sullo stesso palco di Ragusa (IBM) e Santini (Microsoft) ha poi consentito di scoprire che nel mercato del Cloud storici competitor stanno cominciando a pensare di potersi considerare "co-petitor", anche perché i clienti (mondo bancario per primo) stanno chiedendo standard comuni e interoperabilità.

1-10 of 51

Comments