GDPR Titolare del trattamento

[rino]

Molti di noi (utilizzatori di SC) realizziamo prodotti informatici che rientrano di forza nelle maglie del GDPR.
recentemente si è posta una interessante questione : chi è il vero titolare del trattamento?"
dal 1996 seguo questa norma , affascinato dal tentativo di una norma che tenta di "organizzare" ciò che ancora non esiste, difatti è la prima norma che ha tentato di organizzare il domani senza partire da un passato consolidato.
da tecnico informatico (analista) ho guardato alla norma in modo concreto , pragmatico, e mi sono concentrato sul cosa e sul come.
Un vecchio dibattuto dilemma riguarda il concetto di Titolare del trattamento . Oggi finalmente la nebbia si dirada .
Però questo non facilita il lavoro anzi per chi realizza prodotti informatici le cose posso diventare un po più complesse specie in termini di reale responsabilità.
Sicuramente questo porta ad una maggiore consapevolezza di chi produce prodotti informatici, si è realmente responsabili delle soluzioni, grandi o piccole che siano.
SC facilita la creazione di strumenti che trattano dati personali, aumenta il numero di soggetti che agiscono sui dati, il problema è che sino ad ora non l hanno fatto con le dovute attenzioni , adesso stop .
Che ne pensate?
https://www.linkedin.com/posts/agostino ... 8e3pPC2LF4

[Fabio]

Per anni il concetto di Titolare del trattamento è stato affrontato in modo quasi “automatico”:
il cliente = titolare,
il fornitore software = mero esecutore tecnico.

Il GDPR però ha rotto questa semplificazione, e oggi è chiaro che la titolarità non deriva dal contratto, ma dalle decisioni effettive su finalità e mezzi del trattamento.

Dal punto di vista di chi realizza prodotti informatici (e Scriptcase rientra pienamente nel tema), la questione è delicata perché:

• se progetto io la struttura dei dati,

• decido logiche di conservazione, profilazione, tracciamento,

• impongo o suggerisco flussi applicativi che incidono sul trattamento,

non sono più solo “quello che scrive codice”.

SC, come altri RAD, abbassa enormemente la soglia di accesso allo sviluppo di applicazioni che trattano dati personali. Questo è un bene, ma ha avuto un effetto collaterale:
molti sistemi sono nati senza una reale progettazione privacy-by-design, perché “tanto è solo un gestionale”.

Oggi quello spazio grigio non esiste più.
Il fornitore software può diventare:

• Responsabile del trattamento a pieno titolo

• oppure contitolare, nei casi in cui partecipa alle scelte sostanziali

e questo a prescindere da cosa c’è scritto nel contratto, se poi i fatti raccontano altro.

Concordo sul fatto che non faciliti il lavoro, anzi:

• più responsabilità,

• più documentazione,

• più consapevolezza progettuale.

Ma forse è anche un passaggio di maturità del nostro ruolo:
non solo esecutori, ma professionisti responsabili delle soluzioni che mettiamo in produzione, grandi o piccole che siano.

Non è più tempo di “io fornisco il software, poi arrangiati”.
Chi sviluppa deve iniziare a farsi (e fare al cliente) le domande giuste prima, non dopo.

[magre66]

Buonasera a tutti,
interessante discussione.
Concordo solo in parte su questa visione. E' vero che per la GDPR è titolare colui che definisce le finalità, ecc ma bisogna secondo me fare un distinguo fra chi esprime il concetto di finalità e il tecnico che progetta l'esecuzione della finalità.
Nella realizzazione di un gestionale:
- il cliente esprime le sue esigenze
- queste esigenze richiedono l'acquisizione e la gestione di dati
- il tecnico produce uno schema di flusso dei dati
- come trattare questi dati è materia del dpo, non del tecnico, al di là delle conoscenze che ognuno ha della materia
- il tecnico progetta e realizza i flussi dei dati in base alle indicazioni, il che lo colloca nella posizione di responsabile del trattamento e non titolare

Ad esempio io faccio sempre formale richiesta al cliente di un documento in cui mi specifica le policy di accesso (caratteristiche delle password, scadenze, 2fa, ecc) specificando che deve consultare il suo dpo per produrre tale documento.

Noi abbiamo una responsabilità pratica ed etica sulle procedure tecniche e sul codice che gestisce i dati. I requisiti minimi della GDPR per la progettazione dei database sono ridicoli, è necessario andare ben oltre per fornire qualcosa che abbia almeno un barlume di sicurezza

Una parte che mi interesserebbe approfondire è quella relativa ai data breach. A chi è in carico nella pratica? Al fornitore dell'hosting e del database o al titolare del software?