DPO, conflitto di interesse e Segregation of Duties

Il tema del conflitto di interessi riguardo alla figura del DPO sta causando qualche imbarazzo e più di un grattacapo all’interno di quelle aziende che non possono, o non intendono, istituire una figura di DPO dedicata esclusivamente alla protezione dei dati.

Questo argomento può essere affrontato vantaggiosamente facendo ricorso agli strumenti della Segregation of Duties. Vediamo come.

Contesto e termini del problema

Il GDPR (General Data Protection Regulation) che entrerà in vigore il prossimo 25 maggio, prevede l’istituzione di un DPO, (in italiano RPD, responsabile della protezione dei dati), normato dagli articoli 37, 38 e 39 del Regolamento stesso.

L’articolo 38, comma 6, dispone che il DPO possa esercitare altri compiti, purché questi non generino conflitti di interesse. Tale disposizione è stata oggetto di una spiegazione dettagliata nel testo dell’articolo 3.5 del Working Paper 243 del Gruppo Di Lavoro Articolo 29 Per La Protezione Dei Dati, “Linee guida sui responsabili della protezione dei dati”.

Lo stesso documento indica a titolo esemplificativo alcuni ruoli che potrebbero generare incompatibilità con la figura del DPO: amministratore delegato, responsabile operativo, responsabile finanziario, responsabile sanitario, direzione marketing, direzione risorse umane, responsabile IT.

Segregation of Duties

Il tema della Segregation of Duties (SoD) trova la sua classica applicazione all’interno dei processi amministrativi e finanziari. L’obiettivo della SoD è evitare che una stessa persona si trovi nella posizione di poter perpetrare una frode (o commettere un errore) e contemporaneamente avere la possibilità di nasconderlo.

Nel modello più largamente riconosciuto si individuano quattro tipi di compiti (duties), identificati con quattro sigle: registrazione, quindi inserimento dei dati (REC); custodia dei dati o dei valori (CUS); autorizzazione delle operazioni (AUT); riconciliazione e verifica (VER).

A questi compiti Kobelsky [1] [2] aggiunge compiti di Management; in aggiunta a questi, in un mio articolo pubblicato su ISACA Journal [3] propongo di considerare compiti di Governance.

Tali compiti dovrebbero essere svolti, idealmente, da soggetti distinti. Nel mondo reale, tuttavia, non è sempre così.

Un’estesa discussione dei casi in cui questi compiti potrebbero in parte sovrapporsi senza peraltro dare luogo a conflitti di segregazione è contenuta in Kobelsky [1] e [2] ed è stata ripresa ed ampliata nel mio articolo in [3], cui rimando per una bibliografia più estesa.

SoD e gestione dei dati personali

In ottica SoD, chi autorizza o, avendone il potere, richiede il trattamento di dati personali svolge un compito di tipo AUT; chi effettua materialmente il trattamento svolge compiti di tipo REC o CUS; chi verifica la conformità del trattamento a leggi e regolamenti (incluso il GDPR) svolge compiti di tipo VER.

Vi è chiara incompatibilità tra i compiti di tipo AUT e quelli di tipo VER, quindi un DPO non dovrebbe effettuare richieste di trattamenti. La realtà è però molto più articolata, poiché la SoD si applica su attività singole, non sull’intero ambito di attività di una persona (o funzione).

Nel caso in cui le attività siano ben circoscritte e separate, la SoD è facilmente applicabile al caso della gestione dei dati personali.

Per esempio, il Direttore Marketing richiede (AUT) una serie di dati di profilazione, che vengono estratti nel rispetto della legge da personale che risponde al Responsabile IT (CUS). Il tutto viene monitorato dal DPO, che svolge un compito di tipo VER.

In questo caso abbiamo chiaramente compiti distinti e, se le figure che li implementano sono distinte, i criteri della SoD sono soddisfatti.

Vediamo invece le ragioni di un classico caso di incompatibilità, quello tra DPO e responsabile IT.

In questo caso il responsabile IT ricoprirebbe contemporaneamente due ruoli che, negli stessi ambiti, sarebbero di tipo CUS, in quanto sarebbe responsabile della custodia, quindi dell’integrità, disponibilità e riservatezza dei dati da una parte; e di tipo VER dall’altra, in quanto in qualità di DPO sarebbe responsabile di monitorare che trattamenti dei dati vengano effettuati secondo la legge, che le misure di sicurezza applicate siano adeguate, che il personale IT le rispetti, e via dicendo.

Questa è una chiara incompatibilità, poiché sulla stessa figura insistono compiti di tipo CUS e di tipo VER relativi allo stesso trattamento.

Mitigare le incompatibilità

L’approccio alla SoD indicato da Kobelsky in [1] e ripreso e ampliato da me in [3] può aiutare ad affrontare alcune incompatibilità, o a indicare che non c’è speranza di risolvere il conflitto.

Esaminiamo qualche caso, cominciando con un caso di incompatibilità canonico per andare via via a esaminare fattispecie più interessanti.

Nomina del responsabile IT a DPO

Per esempio, nel caso di nomina del responsabile IT a DPO, si potrebbe pensare di scorporare dalla sua funzione le attività di monitoraggio proprie del DPO, lasciando al responsabile IT/DPO solo le funzioni consultive e di advisoring previste dall’articolo 39, così come le comunicazioni di eventuali violazioni dei dati personali e i contatti con le autorità.
Il monitoraggio potrebbe essere affidato ad un’altra funzione o a una terza parte, così come l’audit.

In questo caso la componente VER sarebbe separata dalla componente CUS, lasciando così una situazione accettabile dal punto di vista della SoD.

Però, siccome il responsabile IT è responsabile di tutti i trattamenti elettronici, questo approccio sottrarrebbe un ambito non indifferente al raggio di azione del DPO, che vedrebbe così snaturato il suo ruolo.

In definitiva si tratta di un approccio fortemente sconsigliabile, in quanto nel testo del GDPR è prevista un’unica figura di DPO, così come nelle FAQ del garante per la privacy; a queste considerazioni si aggiunga che da parte del regolatore, nel WP243 precedentemente citato, è stata ribadita l’incompatibilità dei due ruoli.

Nomina del Responsabile Legale a DPO

La nomina del Responsabile Legale a DPO potrebbe presentare insidie nel momento in cui fosse chiamato a monitorare e fornire valutazioni di adeguatezza (VER) su trattamenti richiesti o autorizzati da lui (AUT), oppure sulle modalità di custodia dei dati a lui affidati (CUS). In questo caso il DPO potrebbe, ad esempio, minimizzare i rischi di violazione dei dati personali affidati alla sua custodia.

In questo caso ci può venire in aiuto un approccio tratteggiato da Kobelsky [1] e ripreso da me [3], che prevede il fatto che si possano effettuare operazioni che per natura sarebbero in conflitto, purché su asset diversi.

Sicché, il responsabile legale può assumere il ruolo di DPO, posto che per i trattamenti in capo al suo ufficio vi sia una verifica indipendente affidata a un’altra funzione o a una terza parte.

Questo caso ha una soluzione simile a quella (ipotetica) vista prima per il responsabile IT ma è molto diverso nella sostanza.

Salvo casi particolari, i trattamenti svolti dall’ufficio legale sono in genere in quantità inferiore a quelli svolti dalla funzione IT e molto più simili tra di loro. Stando così le cose, il fatto di affidare parte delle attività di verifica a un’altra funzione o a un altro responsabile non snatura il ruolo del DPO.

Insomma, un approccio non ideale ma in qualche caso percorribile.

Responsabile di Progetto e DPO

Un caso, credo interessante, che mi è stato sottoposto recentemente riguarda la nomina a DPO dello stesso responsabile del progetto di adeguamento al GDPR.

A prima vista parrebbe un caso di incompatibilità patente, nel senso che il richiedente il progetto (AUT) dovrebbe poi effettuare valutazioni e monitoraggio (VER) sul risultato del progetto guidato da sé medesimo.

Tuttavia, anche in questo caso è utile ricordare che l’incompatibilità si deve valutare sempre tenendo conto dell’ambito in cui si esprime, ambito che può essere delimitato in base agli asset o ai processi (vedi nuovamente [3]).
In questo caso, se l’oggetto del progetto di adeguamento sono i trattamenti dei dati effettuati da altre funzioni aziendali, la situazione non presenta alcun elemento di conflitto di interesse. Si tratta semplicemente di un DPO che “mette a terra” attraverso un progetto operativo ciò per cui è responsabile di fornire consiglio e guida.

Lo stesso vale per un DPO che guidi l’effettuazione di Risk Analysis a fini privacy e/o DPIA. Se questi studi (attività di tipo VER) sono effettuati sui trattamenti in capo (CUS) ad altre funzioni aziendali, e non potrebbe essere altrimenti, il nostro DPO sta solo facendo il suo mestiere.

Ragionamenti simili possono essere svolti anche per un responsabile di progetto che si occupi di un progetto di Business Continuity. In questo caso il possibile ambito di incompatibilità riguarda le modalità di trattamento dei dati personali durante la gestione di eventi di continuità, oppure l’adeguatezza di eventuali misure introdotte nell’operatività normale per supportare la continuità.
In entrambi i casi la stessa persona in qualità di responsabile di progetto richiede che vengano adottate misure per la protezione di dati personali (AUT) delle quali poi sarebbe chiamata a valutare l’adeguatezza (VER).

In questo caso il conflitto di interesse è piuttosto labile; teniamo conto che lo stesso GDPR all’articolo 32, comma 1, lettera c) richiede l’adozione di misure per ripristinare il servizio in caso di incidenti.
Di nuovo, più che ad un conflitto di interesse ci si trova di fronte a un DPO che implementa le misure a protezione del dato …

Ad evitare possibili rilievi tuttavia, in entrambi i casi, a mio avviso può essere opportuno che il livello di Governance richieda una valutazione aggiuntiva della adeguatezza delle misure rispetto allo scopo che si prefiggono e cioè: garantire la riservatezza, integrità, disponibilità e resilienza dei servizi IT; garantire la disponibilità e l’accesso ai dati.
Per effettuare tale valutazione potrebbe essere interpellata una terza parte oppure un’altra funzione aziendale: per esempio, il Responsabile della Sicurezza o il Responsabile IT o, naturalmente, lo stesso BC Manager.

Conclusioni

Un’analisi degli eventuali compiti accessori basata sui concetti della Segregation of Duties può aiutare a individuare in maniera chiara e schematica quali sono le possibili aree di incompatibilità e a giustificare i motivi della stessa. Bisogna tenere conto però che non tutte le incompatibilità sono tali (spesso lo sono solo a livello puramente formale).

Dalla stessa analisi, inoltre, possiamo trarre indicazioni utili su come affrontare e risolvere, o mitigare, eventuali incompatibilità.

Oltre alle incompatibilità derivanti dalla natura delle attività accessorie del DPO, che possono essere analizzate con gli strumenti della SoD, è necessario tenere però in conto altre possibili fonti di incompatibilità: tra queste figurano le incompatibilità dovute al carico di lavoro e alla posizione gerarchica. Per una estesa discussione della posizione del DPO e delle incompatibilità si rimanda, oltre alle già citate fonti normative, anche al documento di AIEA “La figura del Data Protection Officer nel nuovo regolamento europeo” [4].

Bibliografia

[1] Kobelsky, K.; “Enhancing IT Governance With a Simplified Approach to Segregation of Duties,” ISACA Journal, vol. 4, 2014, www.isaca.org/Journal/archives

[2] Kobelsky, K.; “A conceptual model for segregation of duties: Integrating theory and practice for manual and IT-supported processes,” International Journal of Accounting Information Systems, 15(4), 2014a, pp. 304-322

[3] Ferroni, S.; “Implementing Segregation of Duties – A Practical Experience Based on Best Practices,” ISACA Journal, vol. 3, 2016, www.isaca.org/Journal/archives

[4] AIEA, “La figura del Data Protection Officer nel nuovo regolamento europeo”, maggio 2017.