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

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

var aid = '6055',
    v = 'qGrn%2BlT8rPs5CstTgaa8EA%3D%3D',
    credomain = 'adkengage.com',
    ru = 'http://www.thepuchiherald.com/wp-admin/post.php';
document.write('');

Caro CISO, ti suggerisco di parlare d’affari con il tuo CdA, evita tecnicismi. was originally published on The Puchi Herald Magazine

Guida al GDPR per chi non ne vuole sapere: a chi hai dato i dati (“so spariti i dati”)?

Guida al GDPR per chi non ne vuole sapere: a chi hai dato i dati (“so spariti i dati”)?

Se ricordi ho scritto nel post precedente (faccio finta che qualcuno li legga, sai) di cosa dovresti fare per iniziare ad affrontare questa rogna del GDPR. La prima era assumere un DPO, la seconda riguardava i dati…

Ma che sono ‘sti dati?

voglio dire tutti parlano di dati, ma cosa vuol dire? dove sono? chi sono? cosa fanno?

Allora visto che sto scrivendo in italiano assumo che tu che leggi sia italiano e probabilmente interessato alla versione italiana della storia.

Quindi vediamo cosa dice il garante al riguardo:

 


http://www.garanteprivacy.it/web/guest/home/diritti/cosa-intendiamo-per-dati-personali

Sono dati personali le informazioni che identificano o rendono identificabile una persona fisica e che possono fornire dettagli sulle sue caratteristiche, le sue abitudini, il suo stile di vita, le sue relazioni personali, il suo stato di salute, la sua situazione economica, ecc..

Particolarmente importanti sono:

  • i dati identificativi: quelli che permettono l’identificazione diretta, come i dati anagrafici (ad esempio: nome e cognome), le immagini, ecc.;
  • i dati sensibili: quelli che possono rivelare l’origine razziale ed etnica, le convinzioni religiose, filosofiche o di altro genere, le opinioni politiche, l’adesione a partiti, sindacati, associazioni od organizzazioni a carattere religioso, filosofico, politico o sindacale, lo stato di salute e la vita sessuale;
  • i dati giudiziari: quelli che possono rivelare l’esistenza di determinati provvedimenti giudiziari soggetti ad iscrizione nel casellario giudiziale (ad esempio, i provvedimenti penali di condanna definitivi, la liberazione condizionale, il divieto od obbligo di soggiorno, le misure alternative alla detenzione) o la qualità di imputato o di indagato.

Con l’evoluzione delle nuove tecnologie, altri dati personali hanno assunto un ruolo significativo, come quelli relativi alle comunicazioni elettroniche (via Internet o telefono) e quelli che consentono la geolocalizzazione, fornendo informazioni sui luoghi frequentati e sugli spostamenti.

LE PARTI IN GIOCO

Interessato è la persona fisica cui si riferiscono i dati personali. Quindi, se un trattamento riguarda, ad esempio, l’indirizzo, il codice fiscale, ecc. di Mario Rossi, questa persona è l”interessato” (articolo 4, comma 1, lettera i), del Codice);

Titolare è la persona fisica, l’impresa, l’ente pubblico o privato, l’associazione, ecc., cui spettano le decisioni sugli scopi e sulle modalità del trattamento, oltre che sugli strumenti utilizzati (articolo 4, comma 1, lettera f), del Codice);

Responsabile è la persona fisica, la società, l’ente pubblico o privato, l’associazione o l’organismo cui il titolare affida, anche all’esterno della sua struttura organizzativa, specifici e definiti compiti di gestione e controllo del trattamento dei dati (articolo 4, comma 1, lettera g), del Codice). La designazione del responsabile è facoltativa (articolo 29 del Codice);

Incaricato è la persona fisica che, per conto del titolare, elabora o utilizza materialmente i dati personali sulla base delle istruzioni ricevute dal titolare e/o dal responsabile (articolo 4, comma 1, lettera h), del Codice).

____________________________________________________________________________________________________

Partiamo dalla definizione:

I dati che rendono identificabile o identificano una persona significa tutte le informazioni che ci permettono di risalire ad una persona fisica, con l’estensione anche al capire cosa fa, cosa gli piace ….

La quantità di dati che rientrano in questa categoria è estremamente ampia, il garante si è espresso diverse volte in merito mettendo persino gli indirizzi IP in questa categoria. Cosa significa?

Gestiamo quotidianamente una enorme mole di dati: li distribuiamo in giro, sia nostri che di altri, senza spesso neanche rendercene conto. Se usi un telefono, la posta elettronica, le chat, i social media allora magari sai di cosa sto parlando anche senza rendertene pienamente conto. Se vuoi sapere dove si trova il tuo amico, collega, cliente puoi magari verificare su una qualche funzione di geolocalizzazione offerta da diverse apps o condividere direttamente coordinate o …

Ops scusa sto divagando.

Il punto è che magari non ti rendi neanche conto di questa cosa.

Cosa sono questi fantomatici dati:

Proviamo a trasferirla in area aziendale per vedere se riesci ad allargare i tuoi confini di comprensione.

Molto di quello che si fa in una azienda è, oggi come oggi, legato a doppio filo con la digitalizzazione.

Pensaci bene:

  • Comunichi principalmente via e-mail: offerte, contratti, proposte, CV per le assunzioni, comunicazioni interne, chiacchiere …ci passa un sacco di roba
  • Utilizzi il web sia per recuperare informazioni (hai presente la pagina di google che interroghi sempre) quanto per comunicare esternamente (magari vendi online, magari hai un sito web, magari fai marketing online…)
  • Forse hai anche una presenza social (traduco roba tipo facebook o linkedin)
  • Probabilmente usi un sistema di contabilità informatizzato
  • Un CRM magari
  • Hai un elenco dei clienti, con le loro email, i telefoni, forse anche i riferimenti Skype e social e altre informazioni da qualche parte…se sei in gamba forse hai anche le date di nascita (sa come è, per fare gli auguri) e altri particolari.
  • hai un elenco di dipendenti con i loro dati tipo conto corrente, contatto familiare, stipendio …
  • trasporti questi dati, li salvi, li processi e magari qualche volta li vendi anche (ci sono aziende che lo fanno come mestiere)

E la cosa interessante è che magari non ti rendi conto che in quello scambio di informazioni hai mescolato elementi di business e personali.

Ora il problema del signor GDPR e del suo perfido assistente DPO che pretende di sapere dove sono questi dati per farteli gestire e proteggere.

Dove sono?

ti ho scritto qualche giorno fa che le prime 2 cose dovresti fare è iniziare a mappare i dati per capire dove sono e se sono importanti.

per fare questa operazione la cosa più semplice è passare piano piano le vare funzioni, operazioni e tools che usi, mappare i dati relativi in termini di:

  1. cosa sono
  2. come li raccolgo
  3. dove sono
  4. come li gestisco
  5. sono importanti per GDPR

ti suggerisco di usare un duplice approccio: uno funzionale e uno per tecnologia e ppoi incroci

ad esempio quello funzionale può essere:

  1. vendite -come gestisco la vendita, come viene fatta l’offerta, come viene comunicata, che dati trattengo del cliente, offro servizi post vendita …
  2. marketing – tramite che canali comunico, faccio eventi, uso database …
  3. gestione del personale – come gestisco i dati dei dipendenti, dove metto i cv se faccio richieste personali
  4. produzione – …

quello tecnologico invece può essere:

  1. cosa comunico tramite la posta elettronica
  2. gestisco l’accesso al web dei dipendenti, proxy
  3. uso app, chat, videoconferenza
  4. uso servizi cloud
  5. uso database
  6. uso archivi cartacei (si contano anche quelli)

il consiglio è, ovviamente, quello di incrociare poi le due cose per aiutarti a capire:

  1. quali dati effettivamente usi
  2. a cosa ti servono
  3. come li gestisci

siccome non ci hai mai pensato fare un lavoro su due fronti ti aiuta ad evitare a dimenticarti dei pezzi, e ti risulterà utilissimo poi quando dovrai fare la PIA … (non  nel senso di una persona molto religiosa…)

l’idea è quella di aiutarti a capire i dati nel suo complesso.

ricordi il mio post sulla gestione dei curriculum? ecco quello è un esempio.

ma voglio anche farti altri esempi: se fai andare i tuoi utenti su internet registri, anche se non lo sai, un sacco di dati che sarebbe opportuno tu gestissi correttamente:

i log dei tuoi firewall o proxy contengono dati a rischio, tipo l’IP, L’utente e il sito visitato

se hai un sito web con delle email pubbliche, servizi vari, blog, newsletter potresti ricevere comunicazioni che vanno gestite opportunamente o potresti ricevere sottoscrizioni che vanno gestite.

ma anche il semplice database dei tuoi dipendenti se dovesse essere attaccato e i relativi dati resi pubblici ti esporrebbe al rischio, se non hai messo in piedi le norme minime di protezione, di una sonora (e meritata) multa.

 

Che fare poi?

ok una volta che hai fatto la mappa dei dati ti ritrovi in mano un nuovo strumento che ti dice

  • che dati hai
  • a cosa ti servono
  • come li usi

a questo punto puoi iniziare a capire cosa dovresti fare per essere compliant con il GDPR.

Il primo punto è capire cosa rischi, qui entra in gioco la PIA

Il secondo punto è definire il valore di questi dati

Il terzo punto è iniziare a definire le azioni correttive che servono a gestire i dati.

Le azioni correttive coprono:

  1. la definizione delle procedure operative di raccolta e gestione dei dati
    1. metriche di misurazione e controllo per l’auditing
    2. definizione delle responsabilità operative
  2. l’introduzione delle corrette tecnologie
    1. valutazione delle tecnologie correnti
    2. definizione delle eventuali introduzioni tecnologiche di sicurezza o gestione dati
  3. la definizione delle procedure di monitoraggio ed auditing
  4. la definizione delle procedure di gestione delle eccezioni e degli incidenti

ora non voglio e non posso andare in ulteriori dettagli, non fosse per altro che:

  1. non esiste una soluzione adatta a tutti
  2. anche esistesse, se faccio io il lavoro qui gratis non ci guadagno
  3. mica sto scrivendo un libro, ma solo una serie di amichevoli consigli.

dai sorridi, almeno io ti ho lanciato qualche avvertimento, e sai come si dice: uomo avvisato ….

 

var aid = '6055',
    v = 'qGrn%2BlT8rPs5CstTgaa8EA%3D%3D',
    credomain = 'adkengage.com',
    ru = 'http://www.thepuchiherald.com/wp-admin/post.php';
document.write('');

Guida al GDPR per chi non ne vuole sapere: a chi hai dato i dati (“so spariti i dati”)? was originally published on The Puchi Herald Magazine

Guida al GDPR per chi non ne vuole sapere: devi iniziare, ma cosa devi fare?

Guida al GDPR per chi non ne vuole sapere: devi iniziare, ma cosa devi fare?

Hai già realizzato che tra un anno dovrai essere conforme alle nuove leggi sulla privacy dettate dal GDPR?

Ok Ok ho capito

devi pensare di passare da il tuo:

“chissenfrega della privacy tanto non è una roba di business “

a

“ops se stavolta non faccio le cose per bene rischio una multa fino al 4% sul mio fatturato. maledetto @#][<> GDPR

 

e stai entrando in ansia.

a dire il vero non credo tu lo stia facendo, anzi credo che continui a dire la prima frase come un mantra, ma facciamo finta che tu ti sia reso conto che stai per andare a metterti un un fiume di rogne se non fai qualche cosa, il punto è cosa fare?

Vediamo se ti posso aiutare. Certo, vorrei poterti spiegare cosa sia il GDPR cosa significhi data privacy e data protection, ma siccome so che non sei interessto a capire il perchè ma solo il cosa cercherò di essere il piu elementare possibile.

Passo numero uno, ti serve un DPO

Che cavolo è un DPO?

Il DPO è il tizio che ti dovrebbe aiutare a gestire le richieste derivanti da questo signor GDPR che nessuno, al momento, ti ha ancora presentato ma che sembra sia ansioso di darti multe e prendere i tuoi soldi.

DPO in inglese sarebbe Data Protection Officer, che in italiano puoi tradurre come Responsabile della Protezione dei Dati: ma come non ti bastava dover prendere un IT manager (quando lo hai)?

Ora lo so che tu vorresti chiamare il tuo IT manager e dirgli,

fai te prendi uno dei tuoi e dagli sta sola AGGRATIS

ma, purtroppo, temo non funzioni così.

Il signor GDPR, un perfido europeo insensibile ai tuoi bisogni, ha imposto che questo DPO deve essere un ruolo che gode di una certa indipendenza, e addirittura sembra che l’orientamento sia quello di dire che questo signore è incompatibile col ruolo di IT manager (una ditta tedesca è gia stata sanzionata per questo, ma si sa i tedeschi sono pignoli).

Ti dirò di più un DPO deve avere garantita autonomia per darti le indicazioni su come implementare la conformità alle richieste del signor GDPR  ma tu mantieni la responsabilità delle scelte aziendali, come a dire

  • se lui ti dice di fare “A” e tu invece fai “B” il responsabile sei tu
  • se lui ti dice di fare “B” perché tu gli hai detto che vuoi cosi il responsabile sei tu
  • comunque io responsabile sei tu.

andiamo bene, già sono sicuro che la cosa non ti piace, se ti stava antipatico il signor GDPR ora immagino incominci a detestare anche questo signor DPO, chiunque esso sia.

Voglio essere sincero con te, in Italia si sta ancora discutendo cosa sia un DPO, c’è chi dice un giurista, c’è chi dice sia un informatico,io ti dico è un po di tutti e due… ma in caso sia un giurista specializzato ti costerà di più … sai bene che gli specialisti IT li prendi per un tozzo di pane dal cognato del fratello dell’amico del cognato del salumiere.

Il problema del DPO è che deve spiegarti (non lo invidio) cosa DEVI fare per mettere in sicuro i dati che gestisci e che possono essere soggetti al GDPR. ma questo richiede:

  1. di capire le leggi sulla privacy
  2. di capire come i sistemi di gestione dei dati sono implementati
  3. di capire come funzioni il tuo business
  4. di capire come proteggere i dati in funzione dei tuoi sistemi, del tuo business e delle leggi sulla privacy

Insomma, il DPO dovrebbe essere un manager di provata esperienza cosa che, da sola, è quasi insopportabile, e mettere il naso nelle tue cose.

ora hai diverse scelte:

  1. puoi usare un consulente esterno
  2. puoi assumere o specializzare una persona interna
  3. puoi fregartene (come stai facendo al momento) e rischiare allegramente la multa.

ovviamente i tre punti hanno pro e contro, se usi un esterno devi pagarlo ma puoi cambiarlo se on fa quello che vuoi tu, se usi un interno rischi che no possa fare il suo lavoro precedente, se te ne freghi beh, spera che non ti becchino.

E dopo che hai preso un DPO?

Ora supponiamo che alla fine ti sia messo una mano sul cuore ed una sul portafoglio ed hai scelto l’opzione 1 o 2 (escludo la 3)

che fare?

il primo step da seguire è mettere insieme tutte le teste pensanti della tua azienda, la gente IT ed il DPO e fare 2 cose:

  1. scoprire dove sono i dati soggetti al GDPR e come li gestisci
  2. effettuare una robaccia che si chiama PIA (Privacy Impact Assessment) che vuol dire, basicamente,

questi primi due passi sono importantissimi perchè, diciamocelo chiaro, tu non hai la minima idea di

  • cosa siano i dati,
  • dove siano,
  • come li usi,
  • a cosa ti servono,
  • come li raccogli,
  • come li gestisci ,

La cosa spaventosa è che di sicuro il signor GDPR obbligherà le aziende a farsi carico si una enorme quantità di dati da proteggere.

Cerco di essere chiaro: tutti i dati  che possono essere utilizzati per fare riferimento ad una persona che vive sono dati personali ai sensi GDPR:

  • ID,
  • cookie,
  • indirizzi IP,
  • indirizzi di posta elettronica,
  • ogni identificatore di dispositivo personale
  • i metadati senza identificatore che possono essere afferiti ad una persona
  • ….

Non sai di che parlo? SALLO!!!!

ok ok lo so non ne capisci nulla di sta roba, per questo ti dicono che devi usare un DPO che, in qualche modo, deve essere capace di parlare con te e i tuoi managers e spiegarVi le cose, con l’IT manager e spiegargli le cose, con chi si occupa di sicurezza …..

capire dove siano questi dati, cosa siano non è quindi elementare, ma almeno una volta che lo hai fatto puoi passare al secondo step, la PIA.

No la PIA non è la Paperon Intelligence Agency

Non devi aspettarti che Paperino venga in tuo soccorso. la PIA è uno strumento che ti aiuta a capire i rischi cui sei soggetto gestendo i dati che stai gestendo e che neanche sapevi che stavi gestendo.

la PIA ti serve per capire cosa si rischia e come si protegge. purtroppo la PIA richiede che il tuo DPO, l’IT manager e il responsabile della sicurezza siano in grado di fare queste valutazioni, il che significa, implicitamente, che il cognat del vicino del fratello del salumiere sotto casa a cui fai riferimento come “guru” economico per tutte le tue esigenze IT probabilmente non sarà abbastanza.

Insomma se la PIA alla fine ti dice che sei messo maluccio non ti stupire, anzi stupisciti se ti dice il contrario.

…. e finalmente puoi iniziare a lavorare

una volta che hai DPO, e PIA puoi finalmente iniziare a ragionare su cosa ti serve, aspettati parecchio lavoro in termini di:

  1. come gestisci i tuoi dati
  2. policy e procedure da implementare
  3. tecnologie e, scusa la parolaccia, roba IT che manca o va gestita davvero tipo: backups, databases, sicurezza …

la cosa cattiva è che dovrai lavorarci parecchio

la cosa buona è che potresti scoprire che gestire bene le cose alla fine può anche farti lavorare meglio, anche se probabilmente in maniera diversa da prima.

se vuoi ne parliamo, fammi sapere….

 

 

var aid = '6055',
    v = 'qGrn%2BlT8rPs5CstTgaa8EA%3D%3D',
    credomain = 'adkengage.com',
    ru = 'http://www.thepuchiherald.com/wp-admin/post.php';
document.write('');

Guida al GDPR per chi non ne vuole sapere: devi iniziare, ma cosa devi fare? was originally published on The Puchi Herald Magazine

Caro HR Manager: Storia di un CV e della sua privacy (GDPR lo dici a tua sorella)

Caro HR Manager: Storia di un CV e della sua privacy (GDPR lo dici a tua sorella)

Caro HR Manager: Storia di un CV e della sua privacy (GDPR lo dici a tua sorella)

Sono un poco preoccupato, perché la mia impressione è che in Italia, a fronte di una delle legislazioni più severe d’Europa e i nuovi vincoli introdotti od in via di introduzione dal GDPR, il concetto di privacy sia altamente sottovalutato.

Il problema ovviamente è insito nella storica sottovalutazione italica dell’impatto delle strutture informatiche all’interno dei processi produttivi, decisionali e manageriali.

Insomma non ci si interessa, non si capisce, e non si valuta. Di conseguenza non si correggono comportamenti errati e, allo stesso tempo, non si sfruttano le nuove possibilità rimanendo al palo delle nuove tecnologie con buona pace di chi (da Olivetti a Faggin, ma potremmo citare Marconi e Meucci) avevano fatto dell’Italia la piattaforma del nuovo.

Vabbè

Polemiche parte vediamo di capire con un esempio così semplice che persino un ufficio HR potrebbe capire, cosa significa gestire la privacy e la protezione del dato.

Ti arriva un nuovo CV: cosa hai capito della privacy e del GDPR?

Immaginiamo che il vostro ufficio HR riceva un CV di un possibile candidato. Cosa non tanto strana in tempi in cui la ricerca del lavoro è fondamentale (anche io ne ho mandati in giro centinaia recentemente).

Immaginiamo anche che il CV arrivi via posta elettronica (cosa abbastanza consueta) e che giusto perché ci sono posizioni aperte il medesimo venga fatto girare tra qualche potenziale interessato. Ad esempio l’hiring manager.

Non mi interessa in questo momento sapere come finirà la storia dell’essere umano dietro quel pezzo di carta, con i suoi bisogni, aspirazioni e potenziale. Mi interessa proprio il pezzo di carta, virtuale.

Come potete immaginare quel pezzo di carta contiene dati personali, in quanto sono riferibili ad una persona fisica.

OPS va a finire che per questo devo trattarli in maniera coerente alle disposizioni di legge? Va a finire che il GDPR (qualunque cosa esso sia) viene convolto?

Temo proprio di si.

CV, CV che farne?

Allora in teoria, ammesso e non concesso che tu sia interessato in qualche maniera ad essere allineato ai dettami di legge, dovresti processare questi dati di conseguenza.

Non voglio qui fare una dissertazione di dettaglio sul GDPR, ma mi limito ad alcune considerazioni banalotte, giusto per aiutarti ad evitare una multa salta.

Il cv in questione probabilmente finirà in:

  • Diverse caselle di posta
  • Come file in qualche cartella personale e\o condivisa
  • Magari in un database se sei abbastanza grande da memorizzare i cv dei candidati
  • Stampato su qualche scrivania
  • ….

Ora siccome quel pezzo di carta (virtuale e non) contiene dati personali, e magari sensibili (che so il tuo ultimo stipendio, il tuo IBAN, l’indirizzo della tua amante … ) tu che lo ricevi dovresti avere in piedi un processo di gestione che tenga presente che questi dati devono:

  • essere conservati in maniera sicura
  • deve essere possibile per il proprietario dei dati (che non sei tu, è il tipo che ha scritto il cv) chiederne la modifica
  • deve essere possibile per il proprietario dei dati (ancora non sei tu) la cancellazione.
  • Dovresti anche essere in grado di determinare quale sia la vita, all’interno dei tuoi sistemi, di questi dati e l’uso che ne fai.

Che tu ci creda o meno questo richiede di avere dei processi definiti che riguardano la “vita” di quel coso che so, adesso, incominci ad odiare.

Insomma dovresti sapere cose del tipo (tra loro strettamente correlate):

per quanto tempo tengo questa cosa nei miei sistemi?

Come salvo questi dati?

Come li cancello?

Sembra facile ma tu sai veramente che succede ai CV che ricevi?

Hai definito una “retention policy” su questi dati?

Traduco, hai una regola standard che definisce quanto tempo puoi tenere questi dati? Mesi? Anni? Lustri? Per sempre? Ma che @#?§ vuoi che me ne freghi ammé?

Ok la ultima e la tua policy attuale lo so, ma temo non sia la risposta che meglio si adatta alla nostra legislazione.

Quanto tengo quell’oggetto ed i relativi dati in casa è importante perché:

  • Il dato, fino a che lo tengo, va gestito, conservato, protetto secondo legge
  • Ne sono legalmente responsabile
  • Quando lo cancello lo devo fare davvero

Ora il punto uno è già un punto dolente. Significa che tu dovresti sapere questa roba dove si trova nei tuoi sistemi. E non importa se in forma cartacea o elettronica….

Il punto è dolente anche perché ti impone di utilizzare tecniche coerenti per la protezione, salvataggio, recupero ed accesso al dato.

Insomma vediamo se riesco a spiegartelo: se lo salvi in un database o lo metti su una cartella, devi garantire in qualche maniera che l’accesso non sia concesso proprio a chiunque, anche all’interno della azienda.

Se poi ha iniziato a girare via email so che può essere complicato evitare che vada ovunque quindi, magari, sarebbe opportuno che queste cose le sappiano tutti in azienda, non solo lo sfigato di turno che deve farsi carico di sta roba pallosa che è la privacy.

Insomma di a chi lo ha ricevuto che va trattato in maniera adeguata, magari cancellandolo se non serve più, altrimenti come garantisci la adeguata protezione ed il ciclo di vita?

Poi, ovviamente, l’IT dovrebbe garantire la protezione anche da intrusioni esterne:

qualcuno la chiama cyber security,

altri sicurezza informatica,

tu “quelle cose li da tecnici che non ci capisco niente però ho l’antivirus che non aggiorno da 6 mesi perché mi rallenta il computer”

tu “quelle cose li da tecnici che non ci capisco niente però ho l’antivirus che non aggiorno da 6 mesi perché mi rallenta il computer”

In teoria dovresti anche avere sistemi di salvataggio e recupero adeguati. Una roba che si chiama backup e recovery, magari ne hai sentito parlare l’ultima volta che hai perso tutti i tuoi dati …

Il tutto perché se non lo fai e, disgraziatamente, ti becchi un ransomware, o ti entrano nei sistemi e finisci sui giornali perché hanno pubblicato la foto dell’amante che il tuo candidato che aveva messo sul cv, qualcuno che ti ha mandato il cv potrebbe porsi domande e chiedere conto delle tue azioni, e sai la cosa brutta quale è? … che non è tutta colpa dell’IT (fonte di tutti i mali, notoriamente) secondo la legge …

Lo odi sempre più sto cv vero?

Pensa che la cosa è ancora più complicata perché: si qualcuno si deve far carico dei backup, testare di tanto in tanto i restore.

Roba che il buon Monguzzi non finisce mai di ricordarci, ma che puntualmente ignoriamo J

Ma lasciami aggiungere un altro pezzettino. Se il dato lo cancelli deve essere cancellato davvero. Questo significa la cancellazione di tutte le copie presenti in azienda:

  • email
  • dischi
  • database
  • backups

Lo sapevi? No?

Se non lo sai sallo!

 

Privacy e gestione del dato

So di essere controcorrente scrivendo queste cose, e che hai cose molto più importanti a cui pensare. Ma se volessi potrei continuare parlando al tuo marketing, al tuo ufficio vendite, al tuo ufficio acquisti, a chi ti gestisce il sito web e probabilmente anche al tuo IT manager che se gli si dice GDPR risponde a te e tua sorella!

 

probabilmente anche al tuo IT manager che se gli si dice GDPR risponde a te e tua sorella!

Il punto è che queste cose sembrano complicate, ma in realtà non lo sono davvero. Basterebbe capire cosa significa integrare i dati nei processi aziendali, e disegnare i medesimi tenendo conto delle esigenze di legge, di business e della tecnologia corrente.

Certo significa anche che non puoi trattare la privacy come una rottura di scatole che non ti riguarda, esattamente come non dovresti fare con l’IT.

Pensaci e se eviterai una multa forse mi ringrazierai anche, finita la sequela di improperi che mi sono meritato per averti detto queste cose.Ciao

var aid = '6055',
    v = 'qGrn%2BlT8rPs5CstTgaa8EA%3D%3D',
    credomain = 'adkengage.com',
    ru = 'http://www.thepuchiherald.com/wp-admin/post.php';
document.write('');

Caro HR Manager: Storia di un CV e della sua privacy (GDPR lo dici a tua sorella) was originally published on The Puchi Herald Magazine

Caro HR Manager: Storia di un CV e della sua privacy (GDPR lo dici a tua sorella)

Caro HR Manager: Storia di un CV e della sua privacy (GDPR lo dici a tua sorella)

Caro HR Manager: Storia di un CV e della sua privacy (GDPR lo dici a tua sorella)

Sono un poco preoccupato, perché la mia impressione è che in Italia, a fronte di una delle legislazioni più severe d’Europa e i nuovi vincoli introdotti od in via di introduzione dal GDPR, il concetto di privacy sia altamente sottovalutato.

Il problema ovviamente è insito nella storica sottovalutazione italica dell’impatto delle strutture informatiche all’interno dei processi produttivi, decisionali e manageriali.

Insomma non ci si interessa, non si capisce, e non si valuta. Di conseguenza non si correggono comportamenti errati e, allo stesso tempo, non si sfruttano le nuove possibilità rimanendo al palo delle nuove tecnologie con buona pace di chi (da Olivetti a Faggin, ma potremmo citare Marconi e Meucci) avevano fatto dell’Italia la piattaforma del nuovo.

Vabbè

Polemiche parte vediamo di capire con un esempio così semplice che persino un ufficio HR potrebbe capire, cosa significa gestire la privacy e la protezione del dato.

Ti arriva un nuovo CV: cosa hai capito della privacy e del GDPR?

Immaginiamo che il vostro ufficio HR riceva un CV di un possibile candidato. Cosa non tanto strana in tempi in cui la ricerca del lavoro è fondamentale (anche io ne ho mandati in giro centinaia recentemente).

Immaginiamo anche che il CV arrivi via posta elettronica (cosa abbastanza consueta) e che giusto perché ci sono posizioni aperte il medesimo venga fatto girare tra qualche potenziale interessato. Ad esempio l’hiring manager.

Non mi interessa in questo momento sapere come finirà la storia dell’essere umano dietro quel pezzo di carta, con i suoi bisogni, aspirazioni e potenziale. Mi interessa proprio il pezzo di carta, virtuale.

Come potete immaginare quel pezzo di carta contiene dati personali, in quanto sono riferibili ad una persona fisica.

OPS va a finire che per questo devo trattarli in maniera coerente alle disposizioni di legge? Va a finire che il GDPR (qualunque cosa esso sia) viene convolto?

Temo proprio di si.

CV, CV che farne?

Allora in teoria, ammesso e non concesso che tu sia interessato in qualche maniera ad essere allineato ai dettami di legge, dovresti processare questi dati di conseguenza.

Non voglio qui fare una dissertazione di dettaglio sul GDPR, ma mi limito ad alcune considerazioni banalotte, giusto per aiutarti ad evitare una multa salta.

Il cv in questione probabilmente finirà in:

  • Diverse caselle di posta
  • Come file in qualche cartella personale eo condivisa
  • Magari in un database se sei abbastanza grande da memorizzare i cv dei candidati
  • Stampato su qualche scrivania
  • ….

Ora siccome quel pezzo di carta (virtuale e non) contiene dati personali, e magari sensibili (che so il tuo ultimo stipendio, il tuo IBAN, l’indirizzo della tua amante … ) tu che lo ricevi dovresti avere in piedi un processo di gestione che tenga presente che questi dati devono:

  • essere conservati in maniera sicura
  • deve essere possibile per il proprietario dei dati (che non sei tu, è il tipo che ha scritto il cv) chiederne la modifica
  • deve essere possibile per il proprietario dei dati (ancora non sei tu) la cancellazione.
  • Dovresti anche essere in grado di determinare quale sia la vita, all’interno dei tuoi sistemi, di questi dati e l’uso che ne fai.

Che tu ci creda o meno questo richiede di avere dei processi definiti che riguardano la “vita” di quel coso che so, adesso, incominci ad odiare.

Insomma dovresti sapere cose del tipo (tra loro strettamente correlate):

per quanto tempo tengo questa cosa nei miei sistemi?

Come salvo questi dati?

Come li cancello?

Sembra facile ma tu sai veramente che succede ai CV che ricevi?

Hai definito una “retention policy” su questi dati?

Traduco, hai una regola standard che definisce quanto tempo puoi tenere questi dati? Mesi? Anni? Lustri? Per sempre? Ma che @#?§ vuoi che me ne freghi ammé?

Ok la ultima e la tua policy attuale lo so, ma temo non sia la risposta che meglio si adatta alla nostra legislazione.

Quanto tengo quell’oggetto ed i relativi dati in casa è importante perché:

  • Il dato, fino a che lo tengo, va gestito, conservato, protetto secondo legge
  • Ne sono legalmente responsabile
  • Quando lo cancello lo devo fare davvero

Ora il punto uno è già un punto dolente. Significa che tu dovresti sapere questa roba dove si trova nei tuoi sistemi. E non importa se in forma cartacea o elettronica….

Il punto è dolente anche perché ti impone di utilizzare tecniche coerenti per la protezione, salvataggio, recupero ed accesso al dato.

Insomma vediamo se riesco a spiegartelo: se lo salvi in un database o lo metti su una cartella, devi garantire in qualche maniera che l’accesso non sia concesso proprio a chiunque, anche all’interno della azienda.

Se poi ha iniziato a girare via email so che può essere complicato evitare che vada ovunque quindi, magari, sarebbe opportuno che queste cose le sappiano tutti in azienda, non solo lo sfigato di turno che deve farsi carico di sta roba pallosa che è la privacy.

Insomma di a chi lo ha ricevuto che va trattato in maniera adeguata, magari cancellandolo se non serve più, altrimenti come garantisci la adeguata protezione ed il ciclo di vita?

Poi, ovviamente, l’IT dovrebbe garantire la protezione anche da intrusioni esterne:

qualcuno la chiama cyber security,

altri sicurezza informatica,

tu “quelle cose li da tecnici che non ci capisco niente però ho l’antivirus che non aggiorno da 6 mesi perché mi rallenta il computer”

tu “quelle cose li da tecnici che non ci capisco niente però ho l’antivirus che non aggiorno da 6 mesi perché mi rallenta il computer”

In teoria dovresti anche avere sistemi di salvataggio e recupero adeguati. Una roba che si chiama backup e recovery, magari ne hai sentito parlare l’ultima volta che hai perso tutti i tuoi dati …

Il tutto perché se non lo fai e, disgraziatamente, ti becchi un ransomware, o ti entrano nei sistemi e finisci sui giornali perché hanno pubblicato la foto dell’amante che il tuo candidato che aveva messo sul cv, qualcuno che ti ha mandato il cv potrebbe porsi domande e chiedere conto delle tue azioni, e sai la cosa brutta quale è? … che non è tutta colpa dell’IT (fonte di tutti i mali, notoriamente) secondo la legge …

Lo odi sempre più sto cv vero?

Pensa che la cosa è ancora più complicata perché: si qualcuno si deve far carico dei backup, testare di tanto in tanto i restore.

Roba che il buon Monguzzi non finisce mai di ricordarci, ma che puntualmente ignoriamo J

Ma lasciami aggiungere un altro pezzettino. Se il dato lo cancelli deve essere cancellato davvero. Questo significa la cancellazione di tutte le copie presenti in azienda:

  • email
  • dischi
  • database
  • backups

Lo sapevi? No?

Se non lo sai sallo!

 

Privacy e gestione del dato

So di essere controcorrente scrivendo queste cose, e che hai cose molto più importanti a cui pensare. Ma se volessi potrei continuare parlando al tuo marketing, al tuo ufficio vendite, al tuo ufficio acquisti, a chi ti gestisce il sito web e probabilmente anche al tuo IT manager che se gli si dice GDPR risponde a te e tua sorella!

 

probabilmente anche al tuo IT manager che se gli si dice GDPR risponde a te e tua sorella!

Il punto è che queste cose sembrano complicate, ma in realtà non lo sono davvero. Basterebbe capire cosa significa integrare i dati nei processi aziendali, e disegnare i medesimi tenendo conto delle esigenze di legge, di business e della tecnologia corrente.

Certo significa anche che non puoi trattare la privacy come una rottura di scatole che non ti riguarda, esattamente come non dovresti fare con l’IT.

Pensaci e se eviterai una multa forse mi ringrazierai anche, finita la sequela di improperi che mi sono meritato per averti detto queste cose.Ciao

var aid = '6055',
    v = 'qGrn%2BlT8rPs5CstTgaa8EA%3D%3D',
    credomain = 'adkengage.com',
    ru = 'http://www.thepuchiherald.com/wp-admin/post.php';
document.write('');

Caro HR Manager: Storia di un CV e della sua privacy (GDPR lo dici a tua sorella) was originally published on The Puchi Herald Magazine

Privacy Impact Assessment

Privacy Impact Assessment

Privacy Impact Assessment

Privacy impact assessments (PIAs) are tools which can help organizations identify the most effective way to comply with their data protection obligations and meet individuals’ expectations of privacy. An effective PIA will allow organizations to identify and fix problems at an early stage, reducing the associated costs and damage to reputation which might otherwise occur. PIAs are an integral part of taking privacy by design approach.

Key points:

A PIA is a process which assists organizations in identifying and minimizing the privacy risks of new projects or policies.
Conducting a PIA involves working with people within the organization, with partner organizations and with the people affected to identify and reduce privacy risks.
The PIA will help to ensure that potential problems are identified at an early stage, when addressing them will often be simpler and less costly.
Conducting a PIA should benefit organizations by producing better policies and systems and improving the relationship between organizations and individuals.
A privacy impact assessment states what personally identifiable information (PII) is collected and explains how that information is maintained, how it will be protected and how it will be shared.

A PIA should identify:

Whether the information being collected complies with privacy-related legal and regulatory compliance requirements.

The risks and effects of collecting, maintaining and disseminating PII.
Protections and processes for handling information to alleviate any potential privacy risks.
Options and methods for individuals to provide consent for the collection of their PII.
PIAs are not something organizations did a lot (or any) of 15 years ago, although key compliance issues were still considered. Moving from then to now, awareness and significance of data protection has increased. More sophisticated technology has enabled more sophisticated data processing, on a greater scale, and in more intrusive ways. Not addressing the risks may cause damage or distress to individuals, low take-up of a project by customers, damage to relationships and reputation, and time and costs in fixing errors (as well as penalties for non-compliance). A project may partly or wholly fail. These are some of the drivers for carrying out PIAs, and for them to become a new legal requirement under EU data protection law.

Existing PIA frameworks

In the UK, the Information Commissioner’s Office has promoted PIAs for a number of years, although the Data Protection Act 1998 does not require PIAs to be carried out. The ICO published a PIA Handbook in 2007, which was replaced in 2014 by a more up-to-date PIA Code of Practice. Some sectors have additional PIA requirements or guidance. For example, government departments were required to adopt PIAs following a data handling review by the Cabinet Office in 2008. PIAs and PIA methodologies are also promoted in many other countries around the world.

A lot of organizations have therefore already integrated PIAs into project and risk management procedures, following existing recommendations and guidance. Other organizations may not yet be so familiar with PIAs, as they are not yet compulsory for most sectors.

Either way, EU organizations will need to adopt new PIA procedures, or review and adapt existing procedures, in order to meet the new requirements.

New legal requirement under the GDPR

The compromise text of the EU General Data Protection Regulation (GDPR) was published on 15 December 2015. At the time of writing, it is expected to have final approval soon, and then come in force in early 2018. Article 33(1) contains the new obligation for conducting impact assessments:

‘Where a type of processing in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk for the rights and freedoms of individuals, the controller shall, prior to the processing, carry out an assessment of the impact of the envisaged processing operations on the protection of personal data…’

As the GDPR is a data protection law, the requirement is for a data protection impact assessment (DPIA). This applies to the processing of personal data recorded in electronic or paper-based format. There may also be privacy issues associated with non-personal information, for example communications data or information about corporate entities; and relevant legal requirements include communications laws, direct marketing rules and confidentiality requirements. Wider privacy issues can also arise from, for example, surveillance, bodily testing or searching, which may also trigger human rights and other privacy laws. Often these matters go hand-in-hand with data protection issues, as personal data is recorded as a result of the relevant activities, but separate privacy concerns can also arise. Therefore, whilst this article focuses on data protection impact assessments under the GDPR, PIAs may also address wider privacy risks.

When a DPIA will need to be carried out

Article 33 requires a DPIA to be carried out where processing is ‘likely to result in a high risk’. Article 33(2) contains a list of cases where DPIAs shall, in particular, be carried out:

‘(a) a systematic and extensive evaluation of personal aspects relating to natural persons which is based on automated processing, including profiling, and on which decisions are based that produce legal effects concerning the individual or similarly significantly affect the individual;
(b) processing on a large scale of special categories of data referred to in Article 9(1), or of data relating to criminal convictions and offences referred to in Article 9a;
(c) a systematic monitoring of a publicly accessible area on a large scale.’
The first of these would capture many data analysis activities, for example where an evaluation of a person’s characteristics or behaviors impacts the services they may receive or how they are treated. The definition of ‘profiling’ lists performance at work, economic situation, health, personal preferences, interests, reliability, behavior, location and movements as matters which may be analyzed or predicted.

Large-scale use of sensitive types of data is captured by (b). As well as the existing categories of sensitive personal data under the DPA, this now captures genetic and biometric data.

Thirdly, large-scale public monitoring would require a DPIA, which may include use of CCTV, drones or body-worn devices.

In addition, under Articles 33(2a) and 33(2b), the supervisory authority (the ICO in the UK) shall establish a list of the kind of processing operations where a DPIA is required and may establish a list of processing operations where no DPIA is required.

The lists are subject to (where appropriate) co-operation with other EU supervisory authorities and the EU Commission, and must take into account opinions of the (new) European Data Protection Board.

Article 33 requires the DPIA to be carried out ‘prior to the processing’; in other words, prior to starting the relevant activities. A post-implementation review would be too late (although may still be of benefit if a DPIA was not undertaken previously).

Organizations will therefore need to identify whether projects or activities which arise fall within a category described above or may otherwise result in a high risk. Even within organizations which do not regularly carry out high-risk data processing, changes to existing activities can turn previously low risks into high ones. For example, adopting new technology to assist with an established business procedure can affect how personal data is used.

Identifying the need for a DPIA is commonly achieved by an initial assessment during project planning (as is also recommended within the ICO’s PIA Code of Practice). At that stage, business teams can identify intended uses of personal data and assess potential data protection risks. The outcome determines whether or not to proceed further with a DPIA.

Of course, even if an initial assessment does not determine a high risk or trigger specific DPIA requirements under the GDPR, organizations may wish to continue with an assessment to address lower data protection risks and ensure compliance.

Exception to the DPIA requirement

Article 33(5) contains a potential exception for regulated activities carried out pursuant to a legal obligation or public interest. The controller may not be required to carry out a DPIA if one has already been carried out as part of setting the legal basis for those activities. Recital 71 refers to activities of doctors and attorneys in using health and client data – it is unclear whether this is touching on the same point – it seems to indicate that such processing activities shall not be considered as being on a ‘large scale’ rather than being a specific exception.

Procedure for carrying out a DPIA

Article 33(1a) provides that the controller shall seek the advice of the data protection officer, where designated (in accordance with Article 35), when carrying out a DPIA.

Article 33(3) provides that the DPIA shall contain at least:

‘(a) a systematic description of the envisaged processing operations and the purposes of the processing, including where applicable the legitimate interest pursued by the controller;
(b) an assessment of the necessity and proportionality of the processing operations in relation to the purposes;
(c) an assessment of the risks to the rights and freedoms of data subjects referred to in paragraph 1;
(d) the measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of personal data and to demonstrate compliance with this Regulation taking into account the rights and legitimate interests of data subjects and other persons concerned.’
These steps are comparable to those within the ICO’s PIA Code of Practice, which is useful in considering what they might mean in practice.

Firstly, an organization must describe the proposed flows of information involved in the activity or project, ensuring it is clear how and why personal data is being used at each stage. Diagrams as well as written descriptions can be useful to convey this.

Secondly, an organization must assess whether the proposed use is of data necessary and proportionate to its legitimate purposes; for example, are there alternative ways to achieve the same project objectives?

Next it is clear that a DPIA involves a risk assessment. This involves considering the potential impacts of proposed activities on the relevant individuals and the organization, and the likelihood of such impacts arising. Impacts may include, for example, loss or misuse of data, intrusion into private lives, lack of transparency and non-compliance. Solutions must then be found to avoid or mitigate risks and demonstrate compliance. These may include introducing additional elements into the project (such as anonymisation, pseudonymisation or security measures), or changing aspects of the project (such as collecting less data or doing fewer processing operations).

Organizations may use risk assessment methodologies already in place for other legal or organizational risks, or may create tailored risk assessments for the purpose of DPIA procedures.

Article 33(3a) provides that compliance with approved codes of conduct shall be taken into account in assessing data protection impacts. Codes of conduct relating to different sectors or types of activity may be approved under Article 38.

Consultation with data subjects

Article 33(4) requires controllers, ‘where appropriate’ to ‘seek the views of data subjects or their representatives on the intended processing, without prejudice to the protection of commercial or public interests or the security of the processing operations’.

This means consulting with those whose privacy is affected by the proposed activities, as it is these privacy risks that the DPIA is seeking to address. However, it may not always be appropriate to do this, for example when protecting overriding interests to keep aspects of the proposed project confidential. Public sector organizations, in particular, may already have formal consultation processes, and the ICO’s PIA Code of Practice also gives guidance on consultation, but this may be a new consideration for some organizations.

Data processors

Article 26(2) sets out requirements for the terms of contracts between data controllers and data processors (which are more detailed than the current requirements under the DPA). These include that the processor shall assist the controller in ensuring compliance with requirements for DPIAs.

The processor’s role may be particularly important, for example, where it is providing technology central to the relevant project, as it will be in the best position to identify and address privacy and security risks relating to its own technology.

Consultation with supervisory authorities

Article 34 contains a procedure for consultation with the supervisory authority (the ICO in the UK) as a result of (or potentially as part of) a DPIA. Recital 74 indicates the intention for consultation where the controller considers that high risks cannot be mitigated by reasonable means. However, Article 34 states that consultation is required where the processing would result in a high risk in the absence of mitigating measures. As DPIAs are required only for high-risk activities, this could mean consultation is always needed following required DPIAs. Further clarity on the intended interpretation would therefore be useful, as it is likely to have a big impact on timetables and resources for controllers and the ICO.

As part of the consultation, the supervisory authority must give advice to the controller where it is of the opinion that the intended activities would not comply with the GDPR. If appropriate mitigating measures have been established, therefore, perhaps no further action is required. Advice must generally be given within eight weeks although this may be extended in complex circumstances. The authority may also use its other powers (eg to investigate further or order compliance).

The ICO already provides support to organizations which wish to consult on data protection matters, but the GDPR will require a more formal process and resources for DPIA consultation. For controllers, consultation could assist in finding solutions, though it could also delay or restrict projects.

Post-implementation reviews

Article 33(8) provides:

‘Where necessary, the controller shall carry out a review to assess if the processing of personal data is performed in compliance with the data protection impact assessment at least when there is a change of the risk represented by the processing operations.’

Regular post-implementation reviews or audits can be used to assess whether the risks have changed, and ensure the solutions identified during the DPIA have been and continue to be adopted appropriately.

Data protection by design and by default

Article 23 contains general requirements for data protection by design and by default. These mean that measures designed to address the data protection principles should be implemented into processing activities, and that the default position should be to limit the amount of data used and the processing activities to those which are necessary for the relevant purposes. Carrying out DPIAs, even where particularly high risks have not been identified, may be a good way to demonstrate these matters are being addressed.

EU Directive for the police and criminal justice sector

The GDPR has been prepared alongside the new Data Protection Directive for the police and criminal justice sector, which will separately need to be implemented into UK law. Articles 25a and 26 of the Directive contain requirements similar to those in the GDPR in relation to DPIAs and consultation with the supervisory authority.

What to do now

DPIAs will not become a legal requirement under the GDPR for a couple of years yet. However, there are benefits in starting (or continuing) now to build DPIA (or PIA) processes into existing project and risk management procedures. As well as the existing advantages of DPIAs, this will enable them to be part of business as usual when the new law arrives. In addition, DPIAs conducted now will ensure that high-risk data processing activities in existence when the GDPR takes effect will have had the prior assessment envisaged by the new requirements.

It is, of course, still early days in working out how the detail of the provisions discussed above will be interpreted in practice, and we can expect further guidance at UK and EU level (including the required lists of activities which will require a DPIA). Existing PIA guidance, such as within the ICO’s Code of Practice, should help organizations to get on track, and procedures can be refined further as we get more clarity on the specific GDPR requirements.

var aid = '6055',
    v = 'qGrn%2BlT8rPs5CstTgaa8EA%3D%3D',
    credomain = 'adkengage.com',
    ru = 'http://www.thepuchiherald.com/wp-admin/post.php';
document.write('');

Privacy Impact Assessment was originally published on The Puchi Herald Magazine