Profili soggettivi: titolarità del dato e responsabilità con nesse

L‟elemento caratterizzante il cloud computing, qualunque sia la configu- razione negoziale, è quella del trasferimento di dati (anche ma non necessa- riamente di carattere personale41) tra il soggetto (pubblico o privato) che ac- quista il servizio e il cloud provider.

A tale flusso, con riferimento al rapporto tra l‟informazione digitale ed i soggetti coinvolti, compie espresso riferimento l‟art. 58, comma 1, del D. Lgs. 7 marzo 2005, n. 82 (Codice dell'Amministrazione Digitale o sempli- cemente CAD), il quale dispone che: “il trasferimento di un dato da un si-

stema informativo ad un altro non modifica la titolarità del dato”.

La titolarità sul dato digitale, nel significato qui inteso, è riconducibile tanto al soggetto che lo ha creato a titolo originario, quanto a colui che lo ha raccolto, dal primo redattore, e poi lo ha trasferito. L‟accezione di titolare è ampia e non si riferisce esclusivamente al proprietario dell‟informazione di- gitale ma anche a chi ne ha semplicemente il possesso. Inoltre, tenuto conto che il flusso di dati trasferiti non è esclusivamente di natura personale, il ti- tolare del dato non coincide necessariamente con il titolare del trattamento dei dati personali42 contemplato dal D. Lgs. 30 giugno 2003, n. 196 (e anche dal Regolamento UE 2016/679).

In ambito sanitario, data la delicatezza e natura delle informazioni tratta- te, il corretto inquadramento della titolarità sul dato assume particolare im-

41 _{Nel presente paragrafo si tratta di dati intesi come informazioni digitali di qualunque natura,}

anche non personale. La nomenclatura utilizzata, relativamente ai dati ed ai soggetti, pertanto non è quella dell‟art. 4 del D.lgs. 196/03 (e del Regolamento UE 679/2016). Dei rapporti soggettivi relativamente al trattamento dei dati personali, si è già detto nella parte quarta, alla quale si rinvia anche per una lettura parallela finalizzata a comprendere la diversa prospettiva di analisi.

42 _{La titolarità di tale soggetto è relativa alle attività di trattamento, mentre la titolarità di cui qui}

si tratta è relativa alla posizione giuridica soggettiva sul bene digitale (dato), che può essere un vero e proprio diritto soggettivo ma può anche riferirsi semplicemente alla posizione di posses- sore. In alcuni casi, il titolare del trattamento ed il titolare del dato possono coincidere. Non si confonda, però, la titolarità, sul dato, tipica dell‟interessato al trattamento dei dati personali, che è colui al quale il dato si riferisce e non colui che ha creato il dato (come, ad esempio, nel caso della Pubblica Amministrazione sanitaria che genera un referto medico).

188 portanza in termini di responsabilità sulla sua sicurezza, esattezza e veridici- tà. La fattispecie diventa particolarmente problematica quando il contratto contiene clausole volte ad attribuire al fornitore del servizio il diritto di uti- lizzare, anche a fini commerciali43, i dati gestiti all‟interno dei propri servers ovvero disposizioni che, a vario titolo, ne limitano le responsabilità. Tale prassi, purtroppo, non è insolita nel mercato dei servizi di cloud computing, ove, come si è già avuto modo di illustrare, spesso non esistono trattative e i contratti sono predisposti (quindi imposti) dai cloud providers. In tali fatti- specie si presenta particolarmente debole la posizione del titolare che accetta servizi di cloud computing gratuiti, a fronte di un uso molto libero dei dati gestiti in remoto.

Si consideri, inoltre, che l‟esternalizzazione e la delocalizzazione dei da- ti, mediante gli accordi dal contenuto sopraccitato, comportano la perdita del controllo diretto sugli stessi. Infatti, nell‟ipotesi in cui vi siano dei guasti alla rete o, più in generale, dei malfunzionamenti (qualunque sia il tipo di servi- zio offerto), si potrebbe determinare l‟indisponibilità, l‟inacessibilità o, addi- rittura, la perdita dei dati, con conseguente responsabilità del fornitore del servizio per i danni causati.

La problematica suddetta è evidenziata anche nel vademecum su “cloud

e sanità” (di Federsanità-ANCI è Istituto Italiano Privacy del 2013), già pre-

sentato nella parte terza, nel quale si suggeriscono alcuni correttivi, tra cui quello di procedere al salvataggio in house di una copia dei dati gestiti in

cloud, anche laddove non siano personali, ma dalla cui perdita o indisponibi-

lità possano derivare danni economici, all‟immagine o, in generale, relativi alla missione e alle finalità perseguite. Una tale situazione, però, mortifica le potenzialità del cloud computing, che dovrebbe liberare il fruitore del servi- zio da tutti gli oneri relativi alla custodia e sicurezza delle informazioni digi- tali.

Una soluzione più agevole potrebbe essere quella che agisce esclusiva- mente a livello negoziale, senza caricare, come nella predetta soluzione, il

43 _{Si presenta particolarmente debole la posizione del titolare che accetta servizi di cloud}

computing gratuiti per la gestione di dati testi e materiali multimediali (foto e video), ma senza

alcuna possibilità di negoziazione delle clausole. In tali casi, sempre secondo Belisario, le amministrazioni devono valutare con estrema attenzione la tipologia dei dati, che una volta inseriti nella nuvola, non potranno più essere sotto il diretto controllo dell‟utente.

189 titolare di compiti dei quali si è spogliato (o ha cercato di spogliarsi) con il contratto di cloud.

Per far fronte a problemi di questo tipo sarebbe opportuno, quindi, inse- rire nell‟accordo con il provider i cosiddetti SLA (Service Level Agreement), mediante i quali si tenta di ottenere la misurazione, oggettiva e numerica, dei risultati raggiunti dal fornitore. Tipicamente, i parametri da considerare per tali misurazioni, sono i tempi di intervento assicurati dal fornitore a partire dalla chiamata del cliente, i tempi di risoluzione dei guasti, la percentuale di soluzione dei guasti, la percentuale di difettosità, il tempo medio tra due guasti consecutivi (MTBF, cioè Mean Time Between Failures) dell‟impianto, nonché la continuità operativa e il disaster recovery44. É, altresì, consigliabi-

44

Quando il cloud computing è adottato in ambito pubblico, la previsione di garanzia dei livelli di servizio e di sicurezza, di continuità operativa e di è disaster recovery sono previste dalla legge. In particolare, l‟Art. 68, co. 1-bis, lett. c, del Codice dell‟Amministrazione Digitale, di- spone che: “[…] le pubbliche amministrazioni prima di procedere all'acquisto, […] effettuano

una valutazione comparativa delle diverse soluzioni disponibili sulla base dei seguenti criteri: […] c) garanzie del fornitore in materia di livelli di sicurezza, conformità alla normativa in materia di protezione dei dati personali, livelli di servizio tenuto conto della tipologia di sof- tware acquisito”. La continuità operativa e il disaster recovery, sono stati introdotti, con il

D.Lgs 235/2010, che ha novellato il CAD con l‟art. 50-bis. In base ad esso è divenuto obbliga- torio per le Pubbliche Amministrazioni italiane la definizione di:

“a) il piano di continuità operativa, che fissa gli obiettivi e i principi da perseguire, descrive le

procedure per la gestione della continuità operativa, anche affidate a soggetti esterni. Il piano tiene conto delle potenziali criticità relative a risorse umane, strutturali, tecnologiche e contie- ne idonee misure preventive. Le amministrazioni pubbliche verificano la funzionalità del piano di continuità operativa con cadenza biennale; b) il piano di disaster recovery, che costituisce parte integrante di quello di continuità operativa di cui alla lettera a) e stabilisce le misure tec- niche e organizzative per garantire il funzionamento dei centri di elaborazione dati e delle pro- cedure informatiche rilevanti in siti alternativi a quelli di produzione. DigitPA, sentito il Ga- rante per la protezione dei dati personali, definisce le linee guida per le soluzioni tecniche ido- nee a garantire la salvaguardia dei dati e delle applicazioni informatiche, verifica annualmente il costante aggiornamento dei piani di disaster recovery delle amministrazioni interessate e ne informa annualmente il Ministro per la pubblica amministrazione e l'innovazione ”.

Sul disaster recovery in ambito pubblico si vedano anche le “Linee guida per il disaster reco- very delle pubbliche amministrazioni ai sensi del c. 3, lettera b) dell’art. 50bis del Codice-

dell’Amministrazione Digitale” pubblicate da AgID, la cui versione aggiornata al 2013 è con-

sultabile al seguente link: http://www.agid.gov.it/sites/default/files/linee_guida/linee-guida- dr.pdf.

Alle garanzie di fonte legale di cui sopra, se ne può aggiungere un‟altra di portata più generale, in quanto la sua applicazione non è limitata al settore pubblico. Si tratta dell‟obbligo di notifica-

190 le inserire specifiche clausole che contemplino la responsabilità del fornitore in caso di inadempimento degli obblighi contrattuali di affidabilità.

Un ulteriore aspetto critico, peraltro già affrontato nel paragrafo dedicato al contratto di deposito di dati digitali, è rappresentato dalla portabilità dei dati verso altre piattaforme. Con questo termine si vuole indicare l‟idoneità dei formati e delle tecnologie utilizzate da un fornitore di servizi ad essere utilizzabili da altri fornitori, senza che ciò comporti la perdita di informazio- ni o, addirittura, l‟impossibilità di utilizzo delle stesse. Data la delicatezza e l‟importanza del problema, per far fronte al crescente uso delle tecnologie proprietarie da parte dei cloud provider che favoriscono il sorgere di pro- blemi di portabilità, il legislatore ha previsto un obbligo per le Pubbliche Amministrazioni che utilizzano programmi sviluppati ad hoc per conto e a spese delle stesse, di prevederne la portabilità su altre piattaforme, al fine di favorire il riuso dei programmi informatici45. Alla luce di ciò, nei contratti tra i fornitori di servizi in cloud e le amministrazioni sanitarie e, prima anco- re al Garante le ipotesi di violazione dei dati personali in seguito al verificarsi di un incidente informatico (data breach). Tale obbligo è stato inserito, per la prima volta, limitatamente all‟ambito delle “comunicazioni elettroniche”, dal D. lgs. 69/2012 (con il quale è stato introdot- to l‟art. 32-bis del D.lgs. 196/03). Oggi il suddetto obbligo è stato esteso anche ad altri ambiti, quindi anche ai servizi cloud, con gli articoli 33 e 34 del Regolamento UE 679/2016. Essi di- spongono che in caso di violazione dei dati personali, il titolare del trattamento notifica la viola- zione all‟Autorità di controllo senza ingiustificato ritardo, ove possibile entro 72 ore dal mo- mento in cui ne è venuto a conoscenza, a meno che sia improbabile che la violazione dei dati personali presenti un rischio per i diritti e le libertà delle persone fisiche. Qualora non sia effet- tuata entro 72 ore, la notifica all‟autorità di controllo è corredata di una giustificazione motiva- ta. L‟art. 34, invece, prevede un‟altra importante incombenza collegata alla precedente e cioè la comunicazione di una violazione dei dati personali all‟interessato. Difatti, quando la violazione dei dati personali è suscettibile di presentare un rischio elevato per i diritti e le libertà delle per- sone fisiche, il responsabile del trattamento comunica la violazione all'interessato senza ingiu- stificato ritardo. La comunicazione all'interessato non è dovuta se: a) il responsabile del tratta- mento ha utilizzato le misure tecniche ed organizzative adeguate di protezione e tali misure era- no state applicate ai dati personali oggetto della violazione, in particolare quelle destinate a ren- dere i dati incomprensibili a chiunque non sia autorizzato ad accedervi, quali la cifratura, oppu- re b) il responsabile del trattamento ha successivamente adottato misure atte a scongiurare il so- praggiungere di un rischio elevato per i diritti e le libertà degli interessati di cui al paragrafo 1, oppure c) detta comunicazione richiederebbe sforzi sproporzionati. In una simile circostanza, si procede invece a una comunicazione pubblica o a una misura simile, tramite la quale gli interes- sati sono informati con analoga efficacia.

191 ra, nei capitolati di appalto o nelle specifiche di progetto, si dovrebbe inseri- re l‟esplicito obbligo di adottare standard internazionali per la codifica dei dati sanitari e, così, garantire l‟utilizzabilità degli stessi anche presso un di- verso fornitore del servizio.