Uno dei più interessanti concetti introdotti nel nuovo Regolamento Europeo (General Data Protection Regulation o GDPR) riguarda l’obbligo di conformità dei software rispetto al tema della privacy; come si evince dai vari passaggi presenti nel testo, è fondamentale che gli strumenti utilizzati per la gestione dei dati siano conformi ai principi europei. Se il concetto di privacy by design è ormai noto, lo è un po’ meno la linea di confine delle responsabilità giuridiche di chi realizza il software da un lato e di chi lo acquisisce dall’altro.
Cerchiamo di fare chiarezza sul tema, soprattutto in considerazione degli investimenti che le aziende possono mettere a rischio avventurandosi in progetti che comprendano strumenti non a norma.
L’art. 32 del Regolamento europeo sulla Data Protection prevede che Titolare e Responsabile, interno o esterno che sia, adottino misure tecniche ed organizzative adeguate affinché sia garantita una gestione del rischio correlato al trattamento effettuato. Alcune di esse vengono espressamente citate a titolo esemplificativo ma non esaustivo: cifratura, capacità di ripristino ed accesso ai dati, garanzia della riservatezza. Trattandosi di una normativa basata sul principio di accountability, è ovvio che non elenchi tutte le altre misure possibili. Non potrebbe neppure farlo con efficacia dato che esse sono destinate a mutare sulla base dello strumento tecnologico di riferimento, dello status organizzativo con cui i dati vengono gestiti e, ovviamente, a seconda della tipologia di dati oggetto di trattamento.
Gli obblighi del titolare e l’impatto sui fornitori
Il Titolare del trattamento è gravato, sin dall’acquisto o dalla commissione di sviluppo di un software, dall’obbligo di valutare le misure che intenderà adottare; dovrà verificare, sin dall’origine, la correttezza della tipologia di dati trattati, le procedure che stanno a monte rispetto al flusso di gestione dei dati e la sicurezza che caratterizza l’ambiente dove i dati sono ospitati in tutte le sue peculiarità. Eppure, questo concetto di “controllo sin dall’origine” che grava sul Titolare, non sempre è realisticamente applicabile, dovendo spesso trasferire la responsabilità del controllo di conformità sul Fornitore.
Trattandosi di misure variabili in base alle scelte operate in accountability dal Titolare, il fornitore dovrà garantire la possibilità di settare le differenti funzioni. Pensiamo alla cancellazione automatizzata: se sarà presente rispetto all’applicativo, magari residente in cloud presso un sub-fornitore di chi rilascia il software, sicuramente il termine di cancellazione non potrà essere deciso dal Fornitore ma dovrà essere imposto, e quindi impostato, dal Titolare. I livelli relativi ai profili di autorizzazione non potranno, allo stesso modo, essere decisi dal fornitore, dovranno invece essere il frutto di una valutazione propria del Titolare.
La conformità dei prodotti software attraverso la cooperazione
Simili esempi, piuttosto frequenti nella quotidianità del business, non fanno che evidenziare un principio: il fornitore, che mette a disposizione un software ad un Titolare del trattamento, deve garantire la possibilità di rendere il prodotto conforme alle prescrizioni normative (non potendolo fornire contra legem). Potrà raggiungere lo scopo in due modi: applicando sin dallo sviluppo e rilascio, il principio di privacy by design (si pensi alla garanzia della riservatezza mediante vari livelli di accesso e protezione) o garantendo al Titolare la possibilità di determinare, secondo i propri criteri, il livello più adeguato della misura da attuare.
La cifratura è un esempio pratico di facile riscontro: può ritenersi scontata nelle ipotesi di “dati particolari” (quelli sanitari ad esempio) ma non nel caso di dati personali inerenti i clienti (status pagamento fattura); eppure un dato personale relativo alla credibilità finanziaria può essere sottoposto a cifratura laddove il Titolare la ritenga come unica misura efficacie. Possiamo quindi rilevare principio fondamentale nella dinamica di mercato: il Titolare è responsabile del software che acquista perché questo deve essere conforme alla normativa (quindi non avere impostazioni in violazione di legge, si pensi alla incancellabilità dei dati); il fornitore è a sua volta responsabile nell’offrire al Titolare un software le cui impostazioni possano soddisfare le misure che egli deciderà.
Cosa accade se questo principio non viene applicato?
Nell’ipotesi in cui il Fornitore rilasci invece un software ‘chiuso’, non personalizzabile, egli aumenta la propria responsabilità circa i criteri di sicurezza applicati e, necessariamente, occorre formalizzare sotto il profilo contrattuale l’impossibilità di intervento da parte del Cliente.
È per questo che cresce la richiesta, avanzata nelle gare e nei bandi pubblicati dalle PA, del rilascio di documenti atti a comprovare la verificata conformità normativa del software oggetto di interesse. L’ambito privato stenta invece a far entrare a sistema, nei processi aziendali, la modalità di verifica preventiva dei requisiti in preselezione fornitori. Occorre tenere presente che un software non in linea con il GDPR, genera responsabilità anche per il Fornitore. Sia laddove gli aspetti relativi alle misure di sicurezza non siano gestiti, sia laddove non sussistano le misure organizzative idonee a gestire il rapporto con il Cliente.
Pensiamo alle procedure di data breach rispetto alla migrazione dei dati (eventi esistenti e fonte di gravissimi rischi) piuttosto che a quelle di gestione della filiera di sub-fornitura nello sviluppo e implementazione di un software. È chiaro come tutti questi elementi, numerosi e variabili sulla base degli scopi gestionali degli applicativi, non possano che essere riversati e ben perimetrati in contratti e licenze che disciplinino i rapporti di acquisto, sviluppo e sfruttamento del software. E questo del resto è conseguenza diretta anche dell’Art. 28 dello stesso GDPR, dove per “trattamento effettuato per conto del Titolare” devono essere intese operazioni come quelle di migrazione sino ad arrivare all’accesso incidentale per interventi come super-administrator.
Le conclusioni
Riassumendo dunque, non si può determinare a priori chi sia responsabile (e quindi sanzionabile per non conformità), in caso di vendita o acquisto di un software, qualora le misure applicate siano insufficienti. Occorrerà specificare le variabili tecniche ed organizzative e commisurare la responsabilità all’autonomia del Titolare, da un lato, e al livello di possibilità di settaggio prevista dal Fornitore dall’altro.
L’iter logico resta chiaro e si può riassumere in due punti chiave: verifica preliminare da parte del Titolare del software rispetto ai principi e alle misure applicate alle tipologie di dati di cui è Titolare e consequenziali alle scelte operate; verifica di conformità del software da parte del Fornitore rispetto a tipologia di dati trattati, misure tecniche impostate ed impostabili, procedure organizzative di rilascio, caricamento dati e amministrazione del sistema, contrattualizzazione delle specifiche responsabilità quali conseguenza diretta delle azioni applicabili sul software. Questa come formula generale. Le variabili potranno riguardare temi come il cloud o lo sviluppo su commissione, sui quali possono aprirsi ulteriori e più complessi scenari giuridici.
Per approfondire