GDPR domanda rapida

General
1

Buongiorno a tutti!

ho un potenziale, grosso problema con GDPR. Dovrei collaborare alcuni mesi
con un'azienda per programmare Arduino e Raspberry Pi.

Questo richiede l'accesso al loro server per scambio file con password
che mi darebbero loro.

Il problema e' che una volta che ho accesso al loro server da esterno devo
anche garantire loro la "compliance" secondo quello che GDPR chiama
"data processor".

Dovrei cioe' garantire sulle mie attrezzature, metodi di gestione dati,
competenze tecniche ecc.

Mi sembra sproporzionato per il solo fatto di conoscere i nomi delle persone
con le quali scambierei file, ma l'applicazione formale delle regole passo
per passo porta a questa situazione. Loro non possono dichiarare di dare la
password a persone esterne "non compliant".

Qualcuno conosce alternative pragmatiche per scambi di dati piccoli,
contenuti e riferiti a un ristrettissimo ambito di persone, le quali
sono ovviamente d'accordo a scambiare mail con me e senza dovere
rispettare regole pensate per Google e Facebook? Grazie!

Gianguido

2

Gianguido buongiorno.

Necessita qualche dettaglio: quali sono le modalità protocolli di accesso
che ti vengono aperte sui server?
In ogni caso, a mio vedere, se tu usi per te un sistema "sicuro" non
dovresti faticare molto a soddisfare la compliance prevista nel GDPR.
Ma serve entrare nel dettaglio dei requisiti "data-processor".

Saluti,
diego

attachment.htm (3.14 KB)

3

Diego, ciao,
con loro non ne abbiamo parlato in dettaglio. Ma dopo avere letto un
po' la questione GDPR e trovati altri commenti in rete l'impressione e'
proprio che manchi una "modulazione". O tutto o nulla. In nessun caso
GDPR viene incontro alla piccola azienda con gestioni semplificate,
dicharazioni di buona fede ecc.

Gianguido

attachment.htm (3.96 KB)

4

Intanto qui GDPR - Garante Privacy una
versione aggiornata, ufficiale e commentata della normativa.
Poi serve entrare in dettagli: una discriminante fondamentale è se [ sono |
devono obbligatoriamente essere ] in gioco dati personali.
Se l'accesso ai "server" può essere limitato allo stretto necessario (e qui
la responsabilità non è tua), evitando dati personali, la cosa si
semplifica da subito.

attachment.htm (6.07 KB)

5

Ancora un punto Gianguido: sulla base del link precedente, vedi per prime
le considerazioni (13), (81) e (82), che si rivolgono anche ai casi di
relazione tra "titolare del trattamento" e "responsabile del trattamento"
di dimensioni modeste.
diego

attachment.htm (7.59 KB)

6

Un altra fonte basilare (e multilingua) per la normativa EU:
https://eur-lex.europa.eu/legal-content/EN-IT/TXT/?qid=1581926648056&uri=CELEX:32016R0679&from=EN

attachment.htm (9.12 KB)

7

Buongiorno a tutti!

ho un potenziale, grosso problema con GDPR. Dovrei collaborare
alcuni mesi
con un'azienda per programmare Arduino e Raspberry Pi.

Questo richiede l'accesso al loro server per scambio file con
password
che mi darebbero loro.

Il problema e' che una volta che ho accesso al loro server da
esterno devo
anche garantire loro la "compliance" secondo quello che GDPR
chiama
"data processor".

Dovrei cioe' garantire sulle mie attrezzature, metodi di gestione
dati,
competenze tecniche ecc.

Mi sembra sproporzionato per il solo fatto di conoscere i nomi
delle persone
con le quali scambierei file, ma l'applicazione formale delle
regole passo
per passo porta a questa situazione. Loro non possono dichiarare
di dare la
password a persone esterne "non compliant".

Qualcuno conosce alternative pragmatiche per scambi di dati
piccoli,
contenuti e riferiti a un ristrettissimo ambito di persone, le
quali
sono ovviamente d'accordo a scambiare mail con me e senza dovere
rispettare regole pensate per Google e Facebook? Grazie!

Gianguido

Ciao,

premesso che non conosco i dettagli di quello che state facendo...

Non vedo come tu diventi un "data processor" solo perche` ti danno
accesso a un server con delle password?

Diventeresti un data processor se tu elabori - per loro - dati personali
suoi tuoi sistemi.

Trovo la GDPR alquanto confusa, quindi forse la sto interpretando male
io? Nel tuo caso una cosa piu` adeguata potrebbe essere un semplice
NDA? Veramente data processor mi sembra piuttosto assurdo.

Bye,
Chris.

8

Ciao, Chris!

Il problema e' proprio questo. GDPR non definisce limiti ragionevoli e
quantificati. Quindi se entro nel sistema per inviare venti righe di
codice Arduino a Mario Rossi e ricevo una risposta automatica che e'
ammalato e torna domani, di fatto mi trovo a conoscere dati personali
sensibili sulla salute di Mario Rossi e l'elaborazione e' implicita
perche' la posta elettronica e' gestita dalla mia CPU, fosse anche solo
per via del browser.

Distopia? Qualsiasi giurista direbbe di starci molto attento.

Ho gia' proposto all'azienda di comunicare per scambio pennette usb e
messaggi su carta. L'interattivita' operativa va a farsi benedire...

Atro dettaglio tecnico. La legge italiana riconosce (ancora) la
differenza tra responsabile e incaricato del trattamento dati, che
opera sotto la tutela del responsabile. GDPR non fa la differenza nel
caso di lavoratori esterni, solo per avere una password aziendale
diventerei "data processor". Con tutte le conseguenze che ora mi
preoccupano.

NDA? troppo semplice...

Gianguido

9

Grazie, Diego! ho dato una scorsa rapida, forse nei punti da te
indicati si trova la soluzione. La studio piu' tardi con calma.

Gianguido

attachment.htm (8.04 KB)

10

problema della mail citato: una casella impersonale di progetto, che
comunichi in modo sicurop e NON comunichi informazioni personali può
risolvere agevolmente il punto. Anche canali differenti (Telegram) e sicuri
non vedo creino problemi.

attachment.htm (3.8 KB)

11

solo per avere una password aziendale diventerei "data processor"

E allora tutti i dipendenti interni e esterni diventerebbero automaticamente
"data processor" (i.e. "Responsabile del trattamento") secondo l'art 28?

Dai, non funziona cosi`.

Guarda qui:
https://www.garanteprivacy.it/web/guest/regolamentoue/titolare-responsabile-incaricato-del-trattamento

La GDPR non parla esplicitamente di un "incaricato", ma non lo esclude neanche.

Il tuo ruolo dovrebbe essere questo: cioe` il "data processor" ti autorizza
ad accedere ai sistemi di cui e` responsabile e ti da` l'incarico di fare certi lavori
dopo averti spiegato come devi comportarti.

Altrimenti, se tutti sono responsabili, nessuno lo e` :wink:

Ovviamente qui sto argomentanto basandomi su logica e common sense, spesso in
contrasto con la legislazione, quindi magari un avvocato mi direbbe che la mia
interpretazione e` sbagliata. Non mi meraviglerei.

Bye,
Chris.

PS: continuo a dire che la GDPR e` fatta male e spero in una riformata GDPR 2.
Sto seguendo come si muove la California con il suo CCPA che sembra essere
migliore.

12

Grazie di nuovo, ora ho piu' chiarezza.
Il problema e' stratificato e molto piu' culturale che tecnico. La
tecnologia e' la parte piu' semplice. Ma se ci si mettono leggi poco
chiare, il giurista aziendale, il certificatore esterno che ha definito
"workflow" molto rigidi, quello della qualita' e un responsabile IT per
natura sospettosissimo anche modificare una virgola diventa impresa
titanica. Piu' semplice con lo scaricabarile e innumerevoli
dichiarazioni di conformita'. Poi se chiedi conformita' esattamente a
che cosa, li mandi in tilt.
Forse il problema centrale, certamente "uno dei", di GDPR e' la
mancanza di linee guida semplici e pragmatiche. Hanno scaricato su
milioni di utilizzatori il "mapping" tra il regolamento europeo e la
loro vita quotidiana.
Cercando in rete il commento piu' sagace che ho trovato sull'argomento
e' il seguente. La cameriera al ristorante che si ricorda il nome dei
clienti abituali e le loro preferenze culinarie e' in infrazione del
GDPR e potenzialmente potrebbe dovere pagare una multa di 20 milioni
EUR. GDPR stesso non pone freno a questa follia.
Per il momento possiamo considerare chiuso l'argomento. Studio i
materiali.

ciao,Gianguido

attachment.htm (5.55 KB)

13

Anche canali differenti (Telegram) e sicuri
non vedo creino problemi.

Oh, qui come forte critico di telegram abbocco subito :slight_smile:

Telegram e` automaticamente squalificato dal solo fatto che
offuscano la posizione dei loro server e quindi non sai se sono
UE oppure paese terzo con agreement oppure paese vietato.

(E` si`, anche se usi i secret chat sei fregato perche` Telegram
salva il cell che e` un dato personale).

Questo e` il bello della GDPR - se vuoi rompere le scatole alle
persone ti da` infiniti modi :wink:

Nota bene che sono assolutamente NON d'accordo con il
vincolo di localita` dei dati che la GDPR impone. Secondo me
crea inutili confini per nulla. Ma se si tratta di rompere le scatole
agli utenti telegram ben venga :wink:

(non te la prendere, sto semi-scherzando :wink:

Bye
Chris.

14

Hallo, Chris!

il solo fatto che dobbiamo discutere l'argomento in questi termini
conferma che GDPR e' fatto male.

Riguardo la questione dell' "incaricato del trattamento" avanzero' la
proposta. Ma temo che siccome dal punto di vista dell'organizzazione io
sarei collaboratore esterno, loro vorranno applicare le regole piu'
rigide. Rischiando di mettermi in una situazione tale da non firmare il
contratto.

Ciao,
Gianguido

> solo per avere una password aziendale diventerei "data processor"

E allora tutti i dipendenti interni e esterni diventerebbero
automaticamente
"data processor" (i.e. "Responsabile del trattamento") secondo l'art
28?

Dai, non funziona cosi`.

Guarda qui:

15

Veramante Chris:
quando lavoravo "in ditta" (sino al 31.01.2020 ;), sottostavo ad un
regolamento aziendale rivisto in logica GDPR; ciascun dipendente aveva
ricevuta formazione specifica GDPR ed era riguardato come "responsabile del
trattamento", avendo accesso ad informazioni di clienti anche personali.
Per operare occasionalmente da casa via VPN, mi ero in + dovuto impegnare a
garantire la riservatezza e integrità della struttura con cui accedevo alla
VPN; in questo caso però l'accesso via VPN mi veniva fornito tramite un
client che, installato, blindava la mia LAN locale per la durata
dell'accesso VPN; in questo senso in "titolare del trattamento" mi forniva
alcuni strumenti per ganatire il rispetto del GDPR.

Quindi Guido ha ragione ad essere attento; va detto che non vi è una logica
assoluta ma relativa: fermo restando l'obbligo di riservatezza che dovrà
essere incluso in un eventuale contratto, occorre poter dimostrare
aposteriore, se necessario, di aver fatto il massimo possibile per limitare
il rischio di accesso ai dati ricevuti e visibili da parte di terzi; come
prima regola: avere accesso solamente ai dati necessari per il tempo
minimo necessario ad eventuale processamento/elaborazione; evitare ogni
salvataggio in locale (proprie strutture) oltre il necessario, badando ad
effettiva cancellazione del dato.

Ciao,
diego

attachment.htm (4.29 KB)

16

"incaricato al trattamento" non è contemplato nel GDPR: se un "responsabile
al trattamento" delega [in modo espresso] altra persona per una parte del
trattamento, questa diviene a sua volte un "responsabile del trattamento".
Dal GDPR:
8) «responsabile del trattamento»: la persona fisica o giuridica,
l'autorità pubblica, il servizio o altro organismo che tratta dati
personali per conto del titolare del trattamento;

attachment.htm (4.4 KB)

17

Veramante Chris:
[...]

Tutto quello che dici va benissimo. L'unico punto su cui a questo punto
non so se mi sbaglio io e` il discorso su chi esattamente assume questo
ruolo di responsabili del trattamento secondo l'articolo 28.

Tu eri il o uno dei responsabili del trattamento secondo l'articolo 28
per il tuo ex datore di lavoro? Lo erano tutti nel tuo ruolo?

Cfr anche:

https://www.garanteprivacy.it/web/guest/regolamentoue/titolare-responsabile-incaricato-del-trattamento

Ero dell'idea che poteva esistere un "Fussvolk" sotto il titolare e il responsabile,
altrimenti non avrebbe molto senso (messo che si possa parlare di senso in questioni
legali...).

Ma ribadisco che e` facilissimo che sbagli io (e in quel caso qualcuno mi
corregga).

Bye,
Chris.

18

Sto leggendo il Regolamento UE e il nocciolo del problema e' il
seguente.

Il regolamento prevede e rimanda a "Codici di condotta" proprio per
venire incontro alle esigenze delle "micro, piccole e medie imprese"
che lavorano per imprese maggiori.

Regolamento UE, Sezione 5, Codici di condotta e certificazione,
Articolo 40, Codici di condotta (C98, C99, C167-C168)

"1. Gli Stati membri, le autorità di controllo, il comitato e la
Commissione incoraggiano 'elaborazione di codici di condotta destinati
a contribuire alla corretta applicazione del presente regolamento, in
funzione delle specificità dei vari settori di trattamento e delle
esigenze specifiche delle micro, piccole e medie imprese."

Nel nostro caso tale "codice di condotta" non esiste perche' la materia
e' troppo recente.

Invece di scrivere "fai attenzione a non perdere le chiavette USB" o
"non fare riferimento a dati personali nelle tue email" mi chiedono di
essere pronto a dimostrare di avere competenze da gestore dati GDPR e
di avere messo in pratica adeguate misure operative (sul mio PC di
casa???) e tecniche (forse un nuovo antivirus Microsoft???)

Il tutto proprio perche' finora nessuno ha messo in relazione i
requisiti del Regolamento UE con la vita pratica di milioni di low-
level clerks.

Nessuno e' in grado di dirmi esattamente di che cosa si tratti e a cosa
fare attenzione nella gestione dei dati aziendali, a maggior ragione in
quanto esterno, ma devo garantirne lo stesso l'osservanza. Gia' usare
la email manda tutto in tilt.

Repubblica ha appena pubblicato questo

sperarci, oppure no? Ridere o piangere?

Gianguido

> Veramante Chris:
> [...]

Tutto quello che dici va benissimo. L'unico punto su cui a questo
punto
non so se mi sbaglio io e` il discorso su chi esattamente assume
questo
ruolo di responsabili del trattamento secondo l'articolo 28.

Tu eri il o uno dei responsabili del trattamento secondo l'articolo
28
per il tuo ex datore di lavoro? Lo erano tutti nel tuo ruolo?

Cfr anche:

19

Ciao Gianguido.
Io mi muoverei in questo modo.
Andrei per gradi, rifacendomi sul committente (che presumo più "grosso" di
te).
- Nel contratto/accordo prevederi un allegato/appendice sicurezza in cui
venga definito chiaramente il confine dei dati che passeranno dalle tue
mani.
- la delega in quanto "Responsabile del trattamente" sarà espressa in
dettaglio e limitata ai dati essenziali; accessi non discriminati a aree
dati ampie sono da evitare.
- Dove possibile questi saranno spersonalizzati (ovvero: dotati di una
chiave univoca nota al committente e privati per il tuo uso dei dati che li
rendano attribuibili ad una pesona fisica.
- Il formato dati in I/O sarà definito; questo ti libera dalla definizione
degli strumenti di elaborazione
- se operi con Linux, adotterai per i dati del committente un file system
criptato
- l'accesso ai dati del committente dovrebbe avvenire attraverso un canale
sicuro: vpn, condivisione sftp, ssh, ... in base alle possibilità; ridotto
all'essenziale.
Queste alcune prime idee tecniche.

diego

attachment.htm (6.32 KB)

20

Nello specifico caso ritengo si ricada in:

- consente la *nomina di sub-responsabili del trattamento* da parte di un
responsabile *(si veda art. 28, paragrafo 4)*, per specifiche attività di
trattamento, nel rispetto degli stessi obblighi contrattuali che legano
titolare e responsabile primario; quest'ultimo *risponde dinanzi al
titolare dell'inadempimento dell'eventuale sub-responsabil**e*, anche ai
fini del risarcimento di eventuali danni causati dal trattamento, salvo
dimostri che l'evento dannoso "non gli è in alcun modo imputabile" *(si
veda art. 82, paragrafo 1 e paragrafo 3)*;
Evidente la rilevanza di definire molto bene i confini delle "specifiche
attività di trattamento".

:point_up:Sul tema sarebbe interessante, trovando un relatore, organizzare un
Workshop specifico, rivolto a piccole realtà | singoli che si trovino a
dover operare in questo ambito :wink:

diego

attachment.htm (3.58 KB)