Tag Archivio per: sanzioni

, , , , , , ,

I Principi di Privacy by Design e Privacy by Default nella Progettazione Strategica dei Software Gestionali

Di Giacomo Conti – Titolare Studio Legale Conti


La crescente richiesta di compliance da parte di numerose Software House

Recentemente, il nostro Studio Legale registra un incremento significativo di richieste di consulenza specifica sulla compliance dei software gestionali, si rende quindi necessaria una sintesi dei ruoli e delle accortezze operative essenziali per strutturare un modello organizzativo GDPR adeguato alle Software House.
La Compliance Aziendale GDPR (General Data Protection Regulation – Regolamento UE 2016/679) relativa allo sviluppo e all’impiego di software gestionali è spesso percepita erroneamente come un mero e gravoso onere burocratico 💸. Questa percezione distorta induce molte Software House (SWH) a trascurare la creazione di processi intrinsecamente conformi ai principi di Privacy by Design e Privacy by Default e a non gestire correttamente i ruoli e le obbligazioni legali scaturenti dal Regolamento.
Tali omissioni, tuttavia, non pongono solo il rischio di incorrere in sanzioni GDPR, ma si riflettono in un chiaro svantaggio economico e competitivo che non è immediatamente percettibile in sede di progettazione e design del software. I clienti più strutturati che operano in contesti altamente regolamentati od alto rischio eviteranno, infatti, di integrare soluzioni software che non forniscano adeguate e dimostrabili tutele in materia di protezione dei dati personali.
Ne consegue che, per essere appetibili a clienti di un certo livello, le Software House devono garantire il rispetto del GDPR per l’intero ciclo di vita del software gestionale, dalla fase di progettazione e sviluppo sino alla sua installazione e messa in esercizio, conformandosi a elevati standard di protezione dei dati personali. Lungi dall’essere eccessivamente onerosi, questi adempimenti rappresentano un vantaggio competitivo strategico, ottenibile con un investimento economico, anche moderato, purché mirato e giuridicamente guidato, con una logica orientata ai processi aziendali.

Il Ruolo di Responsabile del Trattamento per le Software House e le conseguenti responsabilità GDPR

I produttori e gli sviluppatori di software gestionale, nella quasi totalità dei casi, si limitano a fornire al Cliente, il Titolare del Trattamento, un prodotto strumentale alla gestione dei processi organizzativi interni; pertanto la Software House opererà, nella stragrande maggioranza dei casi, come Responsabile del Trattamento o, in taluni casi, come Sub-Responsabile ai sensi dell’Art. 28 GDPR.
Il ruolo di Titolare del Trattamento è limitato, in genere, esclusivamente ai dati personali dei propri clienti, ad esempio per i dati di contatto e identificativi per finalità amministrative e contrattuali.

Il Data Protection Agreement e la Gestione dei Sub-Responsabili
All’interno del quadro sopra tracciato riveste un’importanza dirimente la corretta redazione e negoziazione del Contratto di Nomina a Responsabile del Trattamento, o Data Protection Agreement (DPA) che rappresenterà uno dei più importanti allegati, in uno a quello tecnico relativo ai service level agreemnt (SLA), al contratto di licenza sotware.
Bisogna, però, evitare che questo contratto sia visto come un mero adempimento cartolare. Pertanto, prima di formalizzare il DPA, la Software House deve mappare e registrare gli eventuali ulteriori fornitori (Sub-Responsabili), possibilmente nel ROPA (registro delle attività di trattamento) a cui si appoggia per l’erogazione del servizio (es. Cloud Providers come AWS, Google o Microsoft).
Questa mappatura è essenziale per garantire al Titolare la piena conoscenza della catena di trattamento e il rispetto delle clausole di autorizzazione preventiva o generale imposte dall’Art. 28, par. 2 GDPR.

Il Registro delle Attività di Trattamento del Responsabile di trattamento
Per adempiere a tale obbligo di comprensione e di prova (accountability), è indispensabile che la Software House sviluppi e mantenga un Registro delle Attività di Trattamento che dettagli i trattamenti che essa svolge per conto del Titolare. Nella redazione di questo adempimento, è opportuno che la SWH operi un ulteriore sforzo descrittivo dei propri processi, anche ulteriore rispetto a quanto previsto dall’art. 30 GDPR.

La contrattualizzazoine adeguata della gestione dei Data Breach
Un DPA che offra adeguate garanzie deve prevedere un obbligo contrattuale esplicito per la Software House di comunicare eventuali Data Breach subiti al Titolare con un preavviso notevolmente inferiore alle 72 ore previste dall’Art. 33 GDPR per la notifica all’Autorità, idealmente fissato a 48 ore o meno. Ciò garantisce al Titolare il tempo necessario per valutare l’evento e procedere alla notifica ed è valutato positivamente in sede di scelta del fornitore adeguato.

L’adozione di misure di Organizzazione e Sicurezza adeguate al rischio e al contesto: Software in Cloud vs. Software On-Premise
È ineludibile che le misure di organizzazione e sicurezza debbano essere valutate in relazione al contesto operativo specifico del gestionale.
Le misure di base, comuni a ogni sviluppo, includono l’implementazione documentata dei principi di Privacy by Design e by Default: la valutazione delle funzioni applicative in relazione ai principi di minimizzazione dei dati, la differenziazione dei profili di accesso, l’autenticazione robusta e la protezione logica degli archivi.
Tuttavia, bisogna avere chiaro il contesto del software, posto che se questo è in cloud piuttosto che on presmise, sarà opportuno adottare misure differenti con particolari aspetti ai rischi posti dal contesto specifico.

La Data Protection Impact Assessment (DPIA) fra adempimento ed opportunità
Anche se la finalità del trattamento e la raccolta dei dati restano prerogativa del Cliente/Titolare, la Software House, in qualità di Responsabile, deve dimostrare di comprendere il contesto operativo e il rischio generato dal software sui diritti e sulle libertà degli interessati.
Pertanto, è opportuno e potrebbe anche essere richiesto contrattualmente, che la Software House sia chiamata ad effettuare una valutazione di impatto (DPIA) su uno o più processi operativi.
Sebbene la DPIA sia formalmente un obbligo del Titolare, è prassi che i clienti, in particolare quelli di maggiore dimensione o quelli che trattano dati a rischio elevato, ne richiedano la prova o il supporto esplicito prima di sottoscrivere il contratto. È quindi strategicamente opportuno per la Software House condurre una Valutazione d’Impatto in house relativa al proprio software gestionale. Il Titolare potrà poi integrare questa valutazione con la propria DPIA aziendale, riducendo oneri e tempi.
Per la realizzazione di questo adempimento, gli operatori possono fare riferimento agli schemi e ai template ufficiali forniti da autorità di controllo europee, come la CNIL (Garante francese), che offrono una metodologia consolidata per la gestione del rischio.

Uno strumento utile per facilitare l’implementazione di un modello GDPR adeguato: Il codice di condotta di Assosoftware
Per aiutare le piccole medie imprese nella compliance GDPR, si segnala il Codice di condotta adottato secondo quanto prevede l’art. 40 GDPR per il trattamento dei dati personali effettuato dalle imprese di sviluppo e produzione di software gestionale pubblicato sulla gazzetta ufficiale serie generale del 278 del 27 novembre 2024 e reperibile al seguente link: https://www.assosoftware.it/servizi-offerti/codice-di-condotta/

/da
, , ,

LASCIATE OGNI SPERANZA VOI CHE TRATTATE DATI PERSONALI. CHE COSA DEVE REALMENTE TEMERE CHI NON RISPETTA IL GDPR?

di Giacomo Conti

 

Il GDPR è stata una norma, per molti aspetti, molto mal compresa che ha destato una significativa ed ingiustificata paura e incomprensione fra titolari e responsabili del trattamento nonché fra gli stessi consulenti ed operatori del diritto.

Si è assistito, infatti, a prassi poco virtuose – per usare un eufemismo – fra cui spiccano consulenze difensive finalizzate a creare inutili e vuoti scudi di carta e inutile formazione, nonché terrorismo psicologico operato al solo fine di lucrare sulla paura innestata da questa nuova norma. Molti hanno anche sospeso trattamenti pienamente legittimi per paura di improbabili sanzioni.

Questa paura è frutto, principalmente, di una cattiva interpretazione e, soprattutto, del temutissimo art. 83 GDPR il quale stabilisce che le sanzioni derivanti da una violazione della normativa possono raggiungere cifre molto significative che possono ammontare fino a 20 Milioni di Euro oppure al 4% del fatturato mondiale annuo.

Molti hanno interpretato la disposizione nel senso che anche la PMI con un fatturato annuo di qualche milione di Euro che si limita a trattare i dati dei propri dipendenti su scala non elevata potrebbe essere sanzionata per milioni e milioni di Euro in caso di violazione del GDPR e pertanto: “Guai a voi che non vi adeguate!”.

“Giusto?” In realtà non può esserci un’interpretazione peggiore della disposizione in esame e, è doveroso precisarlo, una veloce lettura delle Guidelines on Fines dell’EPBD (ai tempi Working Party 29) e una comprensione sommaria del case based aproach alla base dell’applicazione della sanzione avrebbe dovuto condurre chiunque a giungere a differenti conclusioni.

Come si evince da una lettura, sempre superficiale dei considerando al GDPR, emerge come la norma sia espressione di un basilare principio di civiltà e sia nata per garantire la circolazione del dato personale nel rispetto dei diritti fondamentali della persona fisica in una società sempre più tecnologica che si basa sempre di più su uno scambio di dati personali contro servizi.

Tenuto conto di queste coordinate interpretative è autoevidente come non sia la sanzione pecuniaria il principale pericolo che corrono titolari e responsabili di trattamento posto che il GDPR, evidentemente, non è nato per punire imprenditori ed operatori economici che trattano dati personali.

Del resto, è evidente come sia facile per grandi realtà e per operatori OTT accantonare fondi e risorse per fare fronte ad eventuali sanzioni oppure rincarare il prezzo di alcuni dei loro beni o servizi senza subire un grande danno.

Se, da un lato, l’art. 83 GDPR è sopravvalutato; dall’altro, si parla troppo poco dell’art. 58 GDPR e dei poteri conformativi e inibitori di cui sono dotate le Autorità Garanti che possono anche imporre una limitazione provvisoria o definitiva al trattamento, incluso il divieto di trattamento.

Una sanzione di questo tipo, al contrario di una sanzione pecuniaria, ha un effetto letteralmente paralizzante sul business e può determinare un vero e proprio fallimento di società e startup che si basano su un trattamento illecito dei dati personali.

Si pensi, ad esempio, ad un’applicazione che raccoglie online dati di natura medica senza chiedere il consenso per il trattamento di dati idonei a rivelare la salute dell’interessato e senza informare adeguatamente gli interessati (magari addirittura omettendo un’informativa in lingua italiana) e senza valutare in alcun modo i rischi per i soggetti coinvolti nel trattamento.

Inutile dire come nessuna sanzione economica potrebbe essere adeguatamente punitiva e come solo un divieto di trattamento, con conseguente chiusura del business, potrebbe tutelare adeguatamente gli interessati. Ugualmente, un eventuale ordine di sospendere i flussi di dati verso un destinatario in un paese terzo o un’organizzazione internazionale può avere conseguenze disastrose per un’organizzazione aziendale.

Si pensi, in secondo luogo a un grosso gruppo che perde il controllo dei dati dei propri clienti rischia di perdere la fiducia di questi e di vedere pregiudicata la sua immagine e reputazione se i clienti arrivano a percepire che le loro informazioni personali non sono adeguatamente protette.

Un pregiudizio reputazionale e una perdita di clientela, sicuramente, rappresenta un pregiudizio per il business più significativo di una qualunque sanzione pecuniaria.

/da