Il Codice di Condotta per il trattamento dei dati personali nei software gestionali
L’Autorità Garante per la Protezione dei Dati Personali ha approvato, lo scorso 17 ottobre 2024, un Codice di condotta destinato a regolare il trattamento dei dati personali effettuato dalle imprese di sviluppo e produzione di software gestionale.
L’adozione del Codice è stata promossa dalle imprese produttrici aderenti ad Assosoftware per assicurare che tutte le attività svolte nello sviluppo e nella produzione del software siano conformi ad elevati livelli di protezione dei dati personali.
Perché è importante
Sembra del tutto evidente, anche al di là della formale pubblicazione quale Codice di Condotta, rilevare che il documento costituirà a breve, anche per le aziende che non aderiranno e, quindi, sostanzialmente per il mercato dei produttori di software gestionali (ma non solo), un benchmark di riferimento: produrre software senza rispettare le previsioni in materia di progettazione, sviluppo e gestione by design, by default o fornire assistenza e manutenzione senza seguire principi di sicurezza e protezione significherà, con tutta probabilità, produrre software destinati ad andare preso fuori produzione, a motivo della scarsa fiducia che essi genereranno, e prestare servizi insicuri e scadenti.
Cosa c’è di nuovo?
Detto quanto sopra, v’è da sottolineare che le previsioni non fanno altro che precisare ulteriormente e definire ciò che già era ed è scritto nelle disposizioni data protection e information security: ben venga, peraltro, una ulteriore, autorevole precisazione; ancora troppi applicativi sono pensati e costruiti senza troppi riguardi verso norme cogenti ormai da tempo.
Altrettanto, diverse indicazioni per coloro che operano nella gestione, manutenzione e assistenza dei sistemi e degli applicativi, forniranno linee guida e indicazioni essenziali per rendere il proprio lavoro più sicuro e più conforme.

Lo scopo del Codice
Lo scopo del Codice è quello di definire un sistema uniforme ed avanzato di regole di condotta e misure tecniche e organizzative volte ad assicurare che i software prodotti e resi disponibili sul mercato siano sviluppati nel rispetto dei principi di protezione dei dati fin dalla progettazione (by design) e per impostazione predefinita (by default).
Rientrano nelle disposizioni attività come:
- progettazione e sviluppo (che di regola non comportano il trattamento di dati personali);
- installazione, test, collaudo, assistenza, manutenzione e aggiornamento dei gestionali (es.: attività di migrazione dati finalizzata all’installazione del sw, attivita’ di assistenza e aggiornamento con accesso da remoto, acquisizione o esportazione di copia di dati per verifica di problematiche tecniche, ecc.),
- eseguite on premise (sw installato su infrastrutture, apparati e sistemi del cliente o di fornitori di questo) e
- in cloud (il cliente utilizza il sw del produttore attraverso infrastrutture rese disponibili direttamente o da subfornitori).
Da rilevare che il codice non disciplina eventuali attività di trattamento dati che il cliente demandi al produttore o sviluppatore di software, che restano regolate da aspetti contrattuali (SLA, penali, ecc.), data protection (addendum ex art. 28 Gdpr) o di sicurezza informatica.
Il software come prodotto
Vale la pena sottolineare che una recente Direttiva (2853/2024) dello scorso 23 ottobre, “sulla responsabilità per danno da prodotti difettosi” precisa che il software è sempre un prodotto, a prescindere da come viene distribuito o utilizzato.
Il testo è importante per diverse ragioni.
Innanzitutto perché se il software causa danni, il suo produttore è responsabile, anche se non ha agito con dolo o colpa.
In secondo luogo si applica non solo ai software installati on premise, presso il cliente, ma anche ai “servizi” Saas, ossia in cloud: la conseguenza è che deve essere considerato “un prodotto” anche un applicativo Saas che, di fatto, fornisce servizi.
Open Source ed esclusioni
Un altro aspetto che merita sottolineare è quello per il quale benché la Direttiva escluda la propria applicabilità al c.d. software “open source”, tale esclusione vale solo per il software libero e open source sviluppato o fornito nel corso di un’attività non commerciale, dal momento che i prodotti così sviluppati o forniti non sono, per definizione, immessi sul mercato.
Al contrario, nell’ipotesi in cui la messa a disposizione del software avvenga nel corso di una attività commerciale, le previsioni della Direttiva tornano applicabili.
Ciò avviene, di conseguenza, anche nelle tante, frequentissime ipotesi in cui il software open source, fornito al di fuori di una attività commerciale, viene “successivamente integrato da un fabbricante come componente di un prodotto nel corso di una attività commerciale ed è quindi immesso sul mercato”.
In tali casi, pertanto, la responsabilità per il difetto dovrà essere posta a carico del produttore “commerciale” e non del fabbricante del software libero.
Ne deriva, inoltre, che laddove un produttore integri servizi digitali, open source o comunque di terzi, nei propri “prodotti”, come servizi correlati o interconnessi, essi debbano ritenersi “sotto il controllo del fabbricante” se questi ne abbia autorizzato o comunque voluto l’integrazione o l’interconnessione o la fornitura nel contesto del proprio prodotto – servizio principale.
Gli allegati del Codice di Condotta
Merita evidenziare che il codice dispone di alcuni Allegati che sono assolutamente importanti, in quanto contengono indicazioni essenziali, quasi a mo’ di check list, per gestire adeguatamente i servizi.
L’allegato A
Definisce i principi fondamentali per lo sviluppo di software gestionale secondo i criteri di privacy by design e by default.
Si articola in otto macro-aree che coprono l’intero ciclo di vita del software:
- analisi delle funzionalità,
- protezione accesso ai dati,
- gestione degli accessi,
- autenticazione,
- protezione degli archivi del cliente,
- sicurezza del codice,
- requisiti sistemistici,
- ambienti di test.
Ogni area prevede controlli specifici.
L’allegato B
Le misure del documento delineano i requisiti di sicurezza che il produttore deve implementare nell’erogazione dei servizi di assistenza, sia in ambiente on premise che cloud.
Per le installazioni on premise, i controlli si concentrano sulla gestione degli accessi, sicurezza logica, monitoraggio, supporto remoto e governance degli archivi.
Nel contesto cloud, l’attenzione si sposta sulla sicurezza dell’infrastruttura del data center, connettività, protezione della rete e requisiti sistemistici. In entrambi gli scenari, la governance assume un ruolo centrale per garantire la corretta applicazione delle misure di sicurezza.
L’Allegato C
Fornisce, in aderenza alle previsioni dell’art. 28 del Gdpr, un modello di addendum contrattuale con il quale il produttore del software può gestire i trattamenti di dati personali che, nel contesto della assistenza, manutenzione e gestione degli applicativi, gli consente di definire, ovviamente in accordo con il cliente, il perimetro delle proprie obbligazioni.
Codice di Condotta Software House_signed
