Articolo a cura di: Redazione - Studio Legale Calvello

Per una software house o un’azienda informatica la questione del DPO non dipende dal semplice fatto di sviluppare software o fornire servizi IT. Occorre capire quali dati personali vengono effettivamente trattati, per conto di chi, con quali tecnologie, su quale scala e con quale continuità. Una società che sviluppa applicazioni, gestionali, piattaforme SaaS, servizi cloud o infrastrutture digitali può trovarsi contemporaneamente a trattare i propri dati aziendali come titolare e i dati dei clienti come responsabile del trattamento.

È proprio questa sovrapposizione di ruoli a rendere spesso insufficiente una gestione della privacy limitata alle informative o alla documentazione standard. Nei rapporti con i clienti entrano in gioco contratti ex art. 28 GDPR, sub-responsabili, accessi degli sviluppatori ai database, servizi cloud, log, backup, trasferimenti di dati, misure di sicurezza, privacy by design e gestione degli incidenti. Quando le caratteristiche dei trattamenti rientrano nei presupposti previsti dal Regolamento, deve essere verificato anche se la nomina del DPO sia obbligatoria; negli altri casi va valutato se un DPO esterno possa comunque essere utile per organizzare e controllare in modo indipendente la compliance della società.

Quando una software house deve nominare il DPO

Il GDPR non prevede un obbligo generalizzato di nominare il DPO per tutte le aziende informatiche. L’art. 37 del Regolamento (UE) 2016/679 richiede la designazione, per quanto interessa le imprese private, quando le attività principali del titolare o del responsabile consistono in trattamenti che richiedono il monitoraggio regolare e sistematico degli interessati su larga scala oppure nel trattamento su larga scala di categorie particolari di dati o di dati relativi a condanne penali e reati.

Per una software house, quindi, la verifica deve partire dal modello concreto di servizio. Un’impresa che realizza occasionalmente software per clienti senza accedere ai dati utilizzati attraverso quei programmi presenta una situazione diversa da un provider SaaS che ospita stabilmente database di migliaia di utenti, registra accessi e attività, gestisce profili individuali oppure fornisce piattaforme destinate al trattamento continuativo di dati sanitari, HR o di altre informazioni particolarmente delicate.

Anche il fatto di operare prevalentemente come responsabile del trattamento per conto dei clienti non esclude l’obbligo di designazione. L’art. 37 riguarda espressamente sia il titolare sia il responsabile: occorre quindi valutare le attività principali svolte dalla software house e le caratteristiche complessive dei trattamenti effettuati nell’erogazione del servizio. Una società che gestisce infrastrutture, piattaforme o applicazioni attraverso le quali vengono effettuati trattamenti rilevanti non può limitarsi a verificare se sia titolare dei dati; deve considerare anche le attività che svolge stabilmente per conto dei propri clienti.

La valutazione non dovrebbe ridursi al numero dei dipendenti o alle dimensioni economiche dell’impresa. Devono essere considerati, tra gli altri elementi, la quantità degli interessati coinvolti, il volume e la varietà dei dati, la durata o continuità dei trattamenti, l’estensione dell’attività e le tecnologie utilizzate. Se la nomina non risulta obbligatoria, è opportuno documentare comunque il ragionamento seguito.

Quando viene nominato, il DPO può essere interno oppure esterno sulla base di un contratto di servizi. Per una società informatica la scelta richiede particolare attenzione ai possibili conflitti di interessi: chi determina finalità e mezzi dei trattamenti non può contemporaneamente svolgere una funzione che richiede indipendenza nel controllo della conformità. Il problema può riguardare, per esempio, responsabili IT o figure manageriali che assumono decisioni sostanziali sull’architettura dei sistemi e sul trattamento dei dati. Il DPO deve poter svolgere le proprie funzioni senza ricevere istruzioni sul contenuto delle proprie valutazioni.

Per le aziende che devono verificare la necessità della designazione o stanno valutando di affidare l’incarico all’esterno, abbiamo approfondito struttura, requisiti e modalità del servizio nella pagina dedicata al DPO esterno per aziende.

Software house, SaaS e servizi cloud: il nodo dei rapporti con i clienti e dell’art. 28 GDPR

Nelle aziende informatiche uno dei problemi più frequenti nasce dalla qualificazione dei ruoli privacy. La stessa società può essere titolare del trattamento per i dati dei propri dipendenti, candidati, clienti commerciali e fornitori e, nello stesso tempo, operare come responsabile del trattamento quando eroga un software o un servizio attraverso il quale tratta dati personali per conto di un cliente.

La distinzione non può essere stabilita semplicemente scrivendo nel contratto che la software house è “responsabile esterno”. Secondo i criteri del GDPR, il titolare determina finalità e mezzi del trattamento, mentre il responsabile tratta i dati per conto del titolare e secondo le sue istruzioni. La qualificazione dipende quindi dalle attività realmente svolte e dal livello decisionale esercitato sui trattamenti.

Quando la software house agisce come responsabile, il rapporto deve essere disciplinato conformemente all’art. 28 GDPR. Il contratto deve definire, tra gli altri aspetti, oggetto e durata del trattamento, natura e finalità delle operazioni, categorie di dati e interessati, istruzioni del cliente, obblighi di riservatezza, sicurezza, assistenza al titolare, gestione dei sub-responsabili, restituzione o cancellazione dei dati e disponibilità delle informazioni necessarie per dimostrare il rispetto degli obblighi applicabili. Il responsabile deve inoltre consentire e contribuire alle attività di verifica previste dal rapporto con il titolare.

Per una piattaforma SaaS questo significa verificare se il contratto commerciale, il DPA e l’architettura effettiva del servizio descrivano la stessa realtà. Non è raro che un contratto individui un unico fornitore mentre, nella pratica, il servizio dipende da hosting provider, servizi cloud, sistemi di assistenza, strumenti di monitoraggio, piattaforme di invio email o altri fornitori che possono trattare dati personali. Quando tali soggetti operano come sub-responsabili, il loro utilizzo deve essere organizzato secondo le condizioni previste dall’art. 28, compresa l’autorizzazione del titolare e l’imposizione al sub-responsabile di obblighi coerenti con quelli assunti dal responsabile principale.

Lo stesso controllo deve riguardare ciò che accade durante assistenza e manutenzione. Se sviluppatori, sistemisti o tecnici possono accedere ai database dei clienti per risolvere anomalie, effettuare migrazioni, ripristinare backup o intervenire sull’infrastruttura, tali accessi devono essere ricondotti a regole, autorizzazioni e misure organizzative effettive. Non basta che l’accesso sia tecnicamente possibile “solo in caso di necessità”: l’azienda deve sapere chi può accedere, in quali circostanze, con quali credenziali e secondo quali istruzioni.

Questi elementi incidono anche sull’accountability della software house. Registro delle attività o delle categorie di trattamento, contratti con clienti e fornitori, procedure di sicurezza, gestione degli accessi, conservazione dei log, trattamento dei backup e flussi verso servizi esterni devono essere coerenti con il funzionamento reale del prodotto. Per una verifica più ampia della struttura documentale aziendale rimandiamo anche alla nostra guida sull’adeguamento GDPR aziendale e all’approfondimento sulle differenze tra titolare, responsabile e autorizzato al trattamento.

In questo contesto il DPO, quando presente, non sostituisce il titolare o il responsabile nelle decisioni che competono all’organizzazione. Deve essere coinvolto tempestivamente nelle questioni che riguardano la protezione dei dati, fornire consulenza e sorvegliare l’osservanza del Regolamento mantenendo la propria indipendenza. Proprio nelle software house, dove molte decisioni tecniche determinano concretamente come i dati vengono raccolti, conservati, consultati e trasferiti, la separazione tra funzione decisionale e funzione di controllo deve essere definita con particolare attenzione.

Privacy by design, sicurezza e data breach: gli obblighi che incidono direttamente sul software

Per una software house la conformità al GDPR non riguarda soltanto i documenti contrattuali. Il modo in cui il prodotto viene progettato può determinare direttamente modalità, quantità e durata dei trattamenti. L’art. 25 GDPR richiede al titolare di applicare i principi di protezione dei dati fin dalla progettazione e per impostazione predefinita; quando la software house sviluppa il sistema per conto di un cliente, le scelte tecniche effettuate possono incidere concretamente sulla capacità di quest’ultimo di rispettare tali obblighi.

Un gestionale, una piattaforma SaaS o un’applicazione destinata a trattare dati personali dovrebbe quindi essere esaminata anche sotto il profilo privacy durante la progettazione e nelle successive evoluzioni. Devono essere valutati, in funzione del servizio, i dati realmente necessari, i profili di autorizzazione, la separazione degli ambienti, la conservazione e cancellazione delle informazioni, i log, i backup, le procedure di autenticazione e le possibilità di esportazione o restituzione dei dati al termine del rapporto. Se il prodotto consente profilazione, monitoraggio sistematico, trattamento di categorie particolari di dati o altre operazioni suscettibili di presentare un rischio elevato, può rendersi necessaria anche una valutazione d’impatto sulla protezione dei dati (DPIA), la cui responsabilità resta in capo al titolare quando ricorrono i presupposti dell’art. 35 GDPR.

Il rapporto tra software house e cliente assume particolare rilievo anche sul piano della sicurezza. L’art. 32 GDPR impone sia al titolare sia al responsabile di adottare misure tecniche e organizzative adeguate al rischio. Non esiste quindi una misura standard valida per qualsiasi piattaforma: devono essere considerate la natura dei dati, le modalità del trattamento, le vulnerabilità concretamente ipotizzabili e le conseguenze di una perdita di riservatezza, integrità o disponibilità delle informazioni.

Per un provider SaaS ciò può richiedere, secondo il caso concreto, una gestione rigorosa delle credenziali e dei privilegi, procedure per l’aggiornamento dei sistemi, controllo degli accessi amministrativi, protezione dei backup, tracciamento delle operazioni rilevanti e procedure di risposta agli incidenti. La presenza di misure tecniche non sostituisce quelle organizzative: un sistema può essere tecnologicamente avanzato e presentare comunque criticità se sviluppatori, tecnici o fornitori dispongono di accessi non adeguatamente regolamentati oppure se non sono definite responsabilità e procedure in caso di incidente.

La questione diventa immediatamente operativa quando si verifica un data breach. Un ransomware, l’accesso abusivo a un database, l’esposizione di informazioni causata da una vulnerabilità, il furto di credenziali, un errore di configurazione del cloud o la perdita accidentale di dati possono costituire una violazione dei dati personali. La prima verifica deve stabilire quali informazioni siano state coinvolte, quali interessati siano interessati dall’incidente, se vi sia stata perdita di riservatezza, integrità o disponibilità e quale ruolo ricopra la software house rispetto ai dati compromessi.

Se opera come responsabile del trattamento, la software house deve informare il titolare senza ingiustificato ritardo dopo essere venuta a conoscenza della violazione. Spetta poi al titolare valutare, sulla base degli artt. 33 e 34 GDPR, se ricorrano i presupposti per la notifica al Garante e, nei casi previsti, per la comunicazione agli interessati. È quindi rischioso attendere di avere ricostruito ogni dettaglio tecnico prima di attivare la procedura interna: l’incidente deve essere preso in carico rapidamente, conservando le informazioni necessarie a ricostruirne natura, portata e conseguenze.

La gestione dell’incidente deve inoltre essere coerente con i rapporti contrattuali. Una software house che utilizza cloud provider o altri sub-responsabili deve sapere come viene comunicata una violazione lungo la catena dei fornitori e quali informazioni riceverà per poter adempiere ai propri obblighi verso il cliente. Il tema deve essere affrontato prima dell’incidente, non quando il database è già stato compromesso. Una verifica complessiva della compliance può essere effettuata nell’ambito dell’adeguamento GDPR aziendale, coordinando documentazione, contratti e procedure con l’architettura effettivamente utilizzata dalla software house.

Il DPO, quando nominato, deve essere coinvolto anche in questi processi secondo le funzioni attribuitegli dal GDPR. Non assume la responsabilità operativa della sicurezza informatica e non decide al posto del titolare, ma può fornire consulenza sulla DPIA, sorvegliare l’osservanza del Regolamento e contribuire alla valutazione delle implicazioni privacy di nuovi prodotti, modifiche dell’infrastruttura e incidenti che coinvolgono dati personali.

Un caso pratico: riorganizzare la privacy di una software house che eroga servizi SaaS

Un esempio realistico può riguardare una software house che sviluppa e gestisce una piattaforma SaaS utilizzata da aziende clienti per trattare dati dei propri utenti e dipendenti. La società dispone di documentazione privacy predisposta negli anni, utilizza servizi cloud esterni e consente ai propri tecnici di intervenire sui sistemi dei clienti per attività di assistenza, manutenzione e risoluzione delle anomalie.

La verifica iniziale mostra che il problema non consiste in un singolo documento mancante, ma nella necessità di allineare la struttura giuridica dei trattamenti al funzionamento effettivo del servizio. Occorre distinguere le attività nelle quali la software house opera come titolare da quelle svolte come responsabile per conto dei clienti, verificare i contratti ex art. 28 GDPR, ricostruire la catena dei sub-responsabili e controllare le modalità con cui il personale tecnico può accedere ai dati ospitati sulla piattaforma.

L’attività richiede particolare attenzione ai servizi cloud e agli altri fornitori integrati nel prodotto, perché la ricostruzione dei flussi di dati deve corrispondere all’infrastruttura realmente utilizzata. Vengono quindi riesaminati ruoli, documentazione, procedure di accesso, gestione degli incidenti e rapporti contrattuali, valutando separatamente anche i presupposti per la nomina del DPO e l’eventuale presenza di trattamenti che richiedano una DPIA.

Il caso mostra perché, nelle aziende informatiche, la compliance non possa essere affrontata attraverso modelli standard separati dall’architettura tecnologica. Contratti, procedure privacy e misure organizzative devono descrivere ciò che accade realmente quando il cliente utilizza il software, quando un tecnico accede ai sistemi, quando viene coinvolto un fornitore esterno e quando si verifica un incidente sui dati.

FAQ sul DPO per aziende informatiche e software house

Una software house è sempre obbligata a nominare un DPO?
No. L’obbligo non deriva dalla qualifica di software house o azienda informatica, ma dalle caratteristiche dei trattamenti effettuati. Occorre verificare in particolare se le attività principali comportino monitoraggio regolare e sistematico degli interessati su larga scala oppure trattamento su larga scala di categorie particolari di dati o di dati relativi a condanne penali e reati. La verifica deve comprendere anche i trattamenti svolti dalla software house come responsabile per conto dei clienti.

Una società SaaS che tratta i dati dei clienti può essere responsabile del trattamento?
Sì, quando tratta dati personali per conto del cliente e secondo le sue istruzioni. La qualificazione deve però essere verificata sulle attività effettivamente svolte e non dipende soltanto dalla definizione utilizzata nel contratto. Una stessa società SaaS può essere titolare per alcuni trattamenti e responsabile per altri.

Il responsabile IT può essere nominato DPO della software house?
La nomina deve essere valutata considerando le funzioni concretamente esercitate. Se il responsabile IT determina finalità o mezzi essenziali dei trattamenti, può sorgere un conflitto di interessi incompatibile con l’indipendenza richiesta al DPO. Non è quindi sufficiente attribuire formalmente l’incarico: occorre verificare posizione organizzativa, poteri decisionali e attività effettivamente svolte.

Chi deve gestire il data breach quando vengono compromessi i dati ospitati per un cliente?
Dipende dai ruoli privacy. Se la software house opera come responsabile del trattamento, deve informare il titolare senza ingiustificato ritardo dopo essere venuta a conoscenza della violazione e fornirgli le informazioni disponibili necessarie alla gestione dell’incidente. Sarà il titolare a valutare la notifica al Garante e l’eventuale comunicazione agli interessati, fermo restando che la software house deve adempiere agli obblighi che le competono come responsabile.

Un DPO esterno può seguire anche una software house che utilizza cloud provider e sub-responsabili?
Sì. Il DPO può essere esterno e svolgere le proprie funzioni sulla base di un contratto di servizi. Nel settore informatico è particolarmente importante che abbia accesso alle informazioni necessarie per comprendere trattamenti, infrastruttura, rapporti con i clienti, fornitori e sub-responsabili, mantenendo l’indipendenza richiesta dal GDPR.

Richiedi una valutazione sul DPO e sulla gestione GDPR della software house

Per una software house, un provider SaaS o un’azienda informatica, stabilire se il DPO sia obbligatorio è soltanto una parte della verifica. Occorre considerare i trattamenti effettivamente svolti, il ruolo assunto nei confronti dei clienti, i contratti ex art. 28 GDPR, i sub-responsabili, gli accessi tecnici ai dati, le misure organizzative, la privacy by design e le procedure previste in caso di data breach.

Quando la struttura dei trattamenti rende necessaria la nomina oppure l’azienda intende affidare all’esterno una funzione indipendente di sorveglianza e consulenza, possiamo esaminare il modello operativo della società e verificare come organizzare l’incarico. Per sottoporre il caso allo Studio è possibile richiedere una valutazione per il servizio di DPO esterno per aziende.