Quando un'azienda decide di commissionare un'applicazione software, le domande tipiche riguardano funzionalità, tempi, costi e tecnologie. Il GDPR raramente è in cima alla lista. Eppure, se quell'applicazione tratta dati personali, il Regolamento Europeo sulla protezione dei dati non è un dettaglio da sistemare a fine progetto: è un vincolo architetturale che va considerato fin dal primo giorno.
Questo articolo non è pensato per i DPO o per chi studia diritto. È pensato per chi commissiona software: imprenditori, responsabili IT, product manager che devono capire cosa chiedere al proprio fornitore e quali domande fare prima di firmare un contratto.
Chi è responsabile di cosa: una distinzione che conta
Il GDPR introduce una distinzione fondamentale che molte aziende ancora sottovalutano: quella tra titolare del trattamento e responsabile del trattamento.
Il titolare è chi decide perché e come vengono trattati i dati. Nella pratica, quasi sempre è l'azienda che commissiona il software. Il responsabile è chi tratta quei dati per conto del titolare, ovvero spesso la software house che sviluppa e gestisce l'applicazione.
Questa distinzione ha implicazioni concrete. Se qualcosa va storto, se c'è una violazione dei dati o un trattamento non conforme, il titolare risponde nei confronti dell'autorità di controllo e degli interessati. Il responsabile risponde nei confronti del titolare, sulla base di un contratto specifico che il GDPR chiama DPA, Data Processing Agreement. Senza questo accordo scritto, l'intera catena di responsabilità è fragile, e in caso di ispezione o sanzione la posizione dell'azienda committente diventa molto difficile da difendere.
La prima cosa concreta da fare, quindi, è assicurarsi che nel contratto con il proprio fornitore software sia incluso un DPA in regola. Non è burocrazia: è la base legale che definisce chi fa cosa con i dati.
Privacy by design: non è uno slogan
L'articolo 25 del GDPR parla esplicitamente di privacy by design e privacy by default. In italiano: la protezione dei dati deve essere progettata dentro il sistema, non aggiunta dopo come una patch.
Questo ha effetti pratici immediati su come si sviluppa software. Significa, per esempio, che un'applicazione non dovrebbe raccogliere più dati di quelli strettamente necessari allo scopo dichiarato. Significa che i dati sensibili devono essere cifrati sia in transito che a riposo. Significa che gli utenti devono poter esercitare i propri diritti, dal diritto di accesso alla cancellazione, e che il sistema deve essere in grado di supportare queste operazioni in modo strutturato.
Quando si commissiona un'applicazione, vale la pena chiedere esplicitamente al fornitore come intende implementare questi principi. Non è una domanda trabocchetto: un team tecnico serio sa rispondere concretamente. Se la risposta è vaga, è un segnale da non ignorare.
Cosa deve contenere un'applicazione conforme
Non esiste una lista universale, perché dipende dal tipo di dati trattati e dal contesto. Ma ci sono alcuni elementi che compaiono quasi sempre quando si costruisce un'applicazione che rispetta il GDPR.
Gestione dei consensi. Se l'applicazione raccoglie dati attraverso form, registrazioni o interazioni utente, serve un sistema per raccogliere, registrare e gestire i consensi in modo documentabile. Un checkbox spuntato non basta: bisogna sapere quando è stato dato, per quale scopo, e bisogna poterlo revocare.
Log degli accessi. Chi ha visto quali dati, quando e da quale sistema. In un contesto aziendale, dove più figure accedono allo stesso database, questa tracciabilità è spesso obbligatoria e sempre utile in caso di audit.
Controllo degli accessi basato sui ruoli. Non tutti i dipendenti devono poter accedere a tutti i dati. Un sistema ben progettato limita l'accesso in base al ruolo e alla necessità operativa.
Gestione delle violazioni. Il GDPR impone di notificare le violazioni di dati all'autorità entro 72 ore dalla scoperta. Questo significa che il sistema deve essere monitorato, e che devono esistere procedure interne per individuare, valutare e segnalare gli incidenti.
Diritti degli interessati. L'applicazione deve supportare concretamente le richieste degli utenti: accesso ai propri dati, rettifica, cancellazione, portabilità. Se queste operazioni richiedono interventi manuali lunghi e complessi, il sistema non è realmente conforme, lo è solo sulla carta.
Il ruolo della DPIA
Per certi tipi di trattamento, il GDPR richiede una DPIA, ovvero una valutazione d'impatto sulla protezione dei dati. Non è un adempimento per tutte le applicazioni, ma scatta quando il trattamento è ad alto rischio: sistemi che profilano utenti su larga scala, applicazioni che trattano categorie particolari di dati come dati sanitari o biometrici, sistemi di sorveglianza o monitoraggio.
Se la vostra applicazione rientra in questi scenari, la DPIA deve essere fatta prima che il sistema vada in produzione, non dopo. È un'analisi strutturata che identifica i rischi, valuta le misure di mitigazione e documenta le decisioni prese. In Redergo affrontiamo questo tipo di analisi in collaborazione con il cliente nelle fasi iniziali di progettazione, proprio per evitare di costruire qualcosa che poi deve essere smontato e riprogettato.
Fornitori terzi e trasferimento dati
Quasi nessuna applicazione moderna è un'isola. Ci sono servizi cloud, CDN, piattaforme di analytics, sistemi di pagamento, API esterne. Ognuno di questi soggetti che entra in contatto con i dati degli utenti è potenzialmente un sub-responsabile, e deve essere coperto da accordi adeguati.
Un punto che spesso crea problemi è il trasferimento di dati verso Paesi extra-UE. Se l'applicazione utilizza un servizio cloud con server negli Stati Uniti, o una piattaforma di analytics che elabora dati fuori dall'Europa, bisogna verificare su quale base giuridica avviene quel trasferimento. Le Standard Contractual Clauses sono lo strumento più diffuso, ma non sono un foglio da firmare meccanicamente: devono essere valutate caso per caso.
Quando scegliamo lo stack tecnologico per un progetto, teniamo conto di questi aspetti fin dalla fase di pianificazione. Cambiare un fornitore cloud a progetto avanzato perché non è conforme al GDPR è costoso e frustrante, per tutti.
Come affrontare il tema con il proprio fornitore
Non serve diventare esperti di diritto per fare le domande giuste. Bastano alcune verifiche concrete prima e durante il progetto.
Prima di iniziare, è utile chiedere al fornitore se ha esperienza pregressa con progetti che richiedevano conformità GDPR, se propone l'uso di strumenti certificati o riconosciuti per la gestione dei dati, e se prevede la firma di un DPA. Durante lo sviluppo, vale la pena chiedere come vengono gestiti i dati di test, visto che spesso i team di sviluppo lavorano con copie di database reali senza adeguate misure di anonimizzazione. E prima del go-live, è opportuno verificare che siano stati predisposti i meccanismi per gestire i diritti degli utenti e che esista un piano per la gestione degli incidenti.
In Redergo affrontiamo questi temi in modo sistematico nei progetti di sviluppo software su misura, perché la conformità non è un ostacolo allo sviluppo: è parte integrante di un prodotto fatto bene. Un'applicazione che ignora il GDPR non è solo a rischio di sanzioni, è un'applicazione con debito tecnico e legale che prima o poi si presenterà a riscuotere.
Sanzioni e rischi concreti
Le sanzioni previste dal GDPR possono arrivare fino a 20 milioni di euro o al 4% del fatturato mondiale annuo, se superiore. Ma al di là della cifra massima, che riguarda le violazioni più gravi, il punto è che anche le infrazioni minori comportano conseguenze: richieste di adeguamento, diffide, danni reputazionali.
Il Garante per la protezione dei dati personali italiano ha mostrato negli ultimi anni una crescente attenzione verso le applicazioni software, in particolare nei settori sanitario, finanziario e dei servizi digitali. Aspettare che arrivi un'ispezione per occuparsi del GDPR è una strategia che non conviene a nessuno.
Investire in conformità durante la progettazione costa sempre meno che correggere dopo. E spesso, affrontare il tema con serietà porta a costruire sistemi migliori: più sicuri, più affidabili, più facili da mantenere nel tempo.
