GDPR e software custom: checklist tecnica per developer e DPO di PMI italiane

Quando una PMI italiana sviluppa un software custom — sia per uso interno sia da rivendere come SaaS — il regolamento GDPR si applica nei punti in cui il software tratta dati personali. Si tratta di un perimetro più ampio di quello che molti pensano: include nome ed email di dipendenti, foto su badge digitali, indirizzi IP nei log, dati biometrici di autenticazione, dati di geolocalizzazione, audio/video di meeting registrati.

Questa checklist è il riferimento tecnico unico per il responsabile compliance (DPO, CISO, IT manager) o il developer che si deve assicurare che un software custom sia GDPR-compliant. Si concentra su cosa concretamente serve nel software — non sulla parte legale (privacy policy, consensi sui form) che è ben coperta altrove. Copre 25 controlli operativi, suddivisi in 6 aree.

Per il framework di scelta build vs buy vedi anche Software su misura vs SaaS verticale. Per la cybersecurity correlata (NIS2) vedi la guida NIS2 D.Lgs 138/2024.

Disclaimer: questa guida è operativa, non è consulenza legale. Per la valutazione formale della conformità alla normativa privacy vigente serve un DPO qualificato. La checklist serve a coprire le aree tecniche, non a sostituire il parere legale.

Indice

1. Area 1 — Data minimization e raccolta dati (controlli 1-4)
2. Area 2 — Retention e cancellazione (controlli 5-8)
3. Area 3 — Diritti dell’interessato (controlli 9-13)
4. Area 4 — Sicurezza tecnica e organizzativa (controlli 14-18)
5. Area 5 — Audit, accountability e trasferimenti (controlli 19-22)
6. Area 6 — Breach notification e DPIA (controlli 23-25)
7. Come usare la checklist in pratica

Area 1 — Data minimization e raccolta dati (controlli 1-4)

Il principio cardine GDPR (art. 5 § 1 lett. c): trattare solo i dati personali strettamente necessari per la finalità dichiarata. La maggior parte delle violazioni inizia con la raccolta di dati che il software non aveva motivo di chiedere.

Controllo 1 — Mappare i dati personali trattati

Cosa serve: un documento (o sezione dell’architettura) che elenca per ogni tipologia di dato personale: scopo del trattamento, base giuridica, periodo di conservazione, destinatari interni ed esterni, residenza fisica del dato (region cloud).

Implementazione tecnica: tag a livello di schema database (es. commenti SQL sulle colonne) che identifica dati personali, cosi che chiunque legga lo schema sappia che users.tax_id è un dato personale soggetto a regime speciale, mentre products.sku no.

Indicatore di non-conformità: lo sviluppatore non sa rispondere a “quali campi di questa tabella contengono dati personali?”.

Controllo 2 — Form di raccolta: solo i campi necessari

Cosa serve: ogni campo di un form (registrazione, profilo, contattaci) deve essere giustificato dalla finalità. Email per identificare l’utente? Sì. Data di nascita per registrarsi a un portale B2B di approvvigionamento? Difficilmente. Sesso per ordinare componenti industriali? No.

Implementazione tecnica: code review obbligatoria su nuovi campi che raccolgono dati personali. Workflow di approvazione: chi vuole aggiungere un campo personale al form deve giustificarlo nella PR.

Indicatore di non-conformità: il form di registrazione raccoglie 12 campi e il software usa solo 4.

Controllo 3 — Consenso granulare per finalità multiple

Cosa serve: se il software tratta gli stessi dati per finalità diverse (es. erogazione del servizio + marketing + analytics), serve un consenso separato per ogni finalità. Il consenso “bundle” è invalido.

Implementazione tecnica: il record utente in DB ha colonne separate per ogni consenso (consent_marketing_at, consent_analytics_at, consent_profiling_at) con timestamp esatto + IP + user agent al momento della prestazione del consenso. Possibilità di revocare ogni consenso separatamente.

Indicatore di non-conformità: una sola checkbox “accetto le condizioni” che copre tutto.

Controllo 4 — Categorie speciali (art. 9 GDPR): trattamento sotto regime rafforzato

Cosa serve: se il software tratta categorie speciali (salute, biometria, orientamento sessuale, opinioni politiche, religione, dati giudiziari), serve base giuridica specifica (consenso esplicito, obbligo legale, finalità di interesse pubblico) e misure di sicurezza rafforzate.

Implementazione tecnica: encryption-at-rest specifica per le colonne con categorie speciali (transparent data encryption o column-level encryption), audit log dettagliato di chi accede a quei dati, principio del minor privilegio applicato in modo strict.

Indicatore di non-conformità: dati sanitari nel software che vengono trattati con lo stesso livello di sicurezza dei dati anagrafici standard.

Area 2 — Retention e cancellazione (controlli 5-8)

Il principio: i dati personali non possono essere conservati indefinitamente. Devono essere cancellati o anonimizzati quando la finalità per cui sono stati raccolti è esaurita (art. 5 § 1 lett. e).

Controllo 5 — Retention policy esplicita per ogni tipologia di dato

Cosa serve: un documento che definisce per ogni tipologia di dato personale per quanto tempo viene conservato e cosa succede al termine (cancellazione fisica, anonimizzazione, archiviazione separata). I periodi tipici dipendono dalla finalità: dati fiscali 10 anni (obbligo legale), dati di marketing 24 mesi dopo l’ultima interazione (orientamento Garante), log di accesso 6-12 mesi.

Implementazione tecnica: ogni record ha una colonna retention_until o equivalente, popolata alla creazione con created_at + retention_period. Job notturno che identifica i record scaduti e li tratta (cancellazione o anonimizzazione, secondo policy).

Indicatore di non-conformità: il software cresce indefinitamente in database e nessuno sa quanto tempo dovrebbero stare i dati.

Controllo 6 — Cancellazione fisica vs anonimizzazione vs archiviazione

Cosa serve: distinzione operativa fra tre approcci:

• Cancellazione fisica: il record sparisce, anche dai backup (alla loro naturale scadenza). Default per dati che non servono mai più.
• Anonimizzazione: il record resta ma i campi identificativi vengono sostituiti con valori non riconducibili (hash one-way, valori fittizi). Utile per analytics aggregati.
• Archiviazione separata: il record viene spostato in un database off-line con accesso vincolato, mantenuto per obbligo legale. Tipico per dati fiscali.

Implementazione tecnica: scelta documentata per tipologia di dato. Funzioni di anonimizzazione testate (verifica che il dato anonimizzato non sia re-identifiabile combinando altri dati nel sistema).

Indicatore di non-conformità: cancellazione e archiviazione confusi (i dati sono ancora accessibili a tutti gli utenti del sistema dopo la “cancellazione”).

Controllo 7 — Soft delete con scadenza vs hard delete

Cosa serve: il pattern “soft delete” (record marcato come cancellato ma fisicamente presente) è utile per recovery operativo, ma deve avere una scadenza chiara dopo la quale il record viene davvero cancellato (hard delete). Tipicamente 30-90 giorni.

Implementazione tecnica: colonna deleted_at per soft delete + job che converte soft delete in hard delete dopo X giorni. Le query operative escludono WHERE deleted_at IS NULL; le query di compliance/audit includono il soft-deleted con visibility ristretta.

Indicatore di non-conformità: soft delete senza scadenza (i dati restano per sempre nel sistema).

Controllo 8 — Cascading delete sui dati derivati

Cosa serve: quando l’interessato viene cancellato, tutti i suoi dati derivati (log, audit trail, file caricati, commenti, messaggi) devono essere trattati coerentemente. Lasciarne in giro frammenti è una non-conformità.

Implementazione tecnica: foreign key constraint ON DELETE CASCADE dove appropriato, oppure procedura di cancellazione applicativa che percorre tutte le tabelle correlate. Test della cancellazione su ambiente di staging.

Indicatore di non-conformità: utente cancellato dal sistema principale, ma il suo nome appare ancora nei log o nei vecchi audit trail.

Area 3 — Diritti dell’interessato (controlli 9-13)

Il GDPR dà all’interessato 8 diritti (artt. 15-22). Il software deve permettere di rispondere a queste richieste entro 30 giorni (art. 12 § 3). Cinque controlli tecnici per gestirli operativamente.

Controllo 9 — Diritto di accesso (art. 15): export dei propri dati

Cosa serve: l’utente deve poter ricevere una copia completa di tutti i suoi dati personali in formato strutturato e leggibile (CSV, JSON, PDF).

Implementazione tecnica: endpoint API o funzione admin che, dato l’identificativo utente, esporta in un unico file tutti i suoi dati personali raccolti da ogni tabella del sistema. Test automatici che verificano la completezza dell’export.

Indicatore di non-conformità: richiesta di accesso che richiede 3 giorni di lavoro manuale per estrarre dati da 15 tabelle diverse.

Controllo 10 — Diritto di rettifica (art. 16): self-service di modifica

Cosa serve: l’utente deve poter modificare in autonomia i propri dati personali errati. Non tutto è self-service (i dati fiscali tipicamente richiedono validazione), ma la maggior parte deve esserlo.

Implementazione tecnica: area profilo utente con campi editabili. Per i campi non editabili in self-service (es. P.IVA), processo di richiesta interna documentato.

Indicatore di non-conformità: l’utente deve aprire un ticket per cambiare il proprio indirizzo email.

Controllo 11 — Diritto all’oblio (art. 17): procedura di cancellazione

Cosa serve: l’utente deve poter richiedere la cancellazione dei propri dati, e il sistema deve eseguirla entro 30 giorni (o spiegare per quale motivo non può, es. obbligo legale di conservazione). La procedura tecnica deve coprire tutti i sistemi: applicazione, database, backup, log, cache, sistemi di terze parti.

Implementazione tecnica: funzione admin “Right to be forgotten” che:

1. Identifica tutti i record dell’utente in tutto il sistema (mappa pre-fatta in fase di design)
2. Esegue cancellazione/anonimizzazione coerente
3. Genera un report di esecuzione per audit
4. Notifica eventuali sistemi terzi (CRM, mail provider, analytics)

Indicatore di non-conformità: la cancellazione viene fatta solo sul DB principale, dimenticando log, backup, sistemi connessi.

Controllo 12 — Diritto alla portabilità (art. 20): export in formato interoperabile

Cosa serve: l’utente deve poter ricevere i propri dati in un formato strutturato e di uso comune che permetta di importarli in un altro sistema. Differisce dall’export per accesso (controllo 9) per finalità (portabilità verso altro provider) e formato (più rigoroso).

Implementazione tecnica: export in formato JSON o CSV che segue dove possibile schemi standard (es. vCard per contatti, iCal per eventi). Documentazione dello schema di export.

Indicatore di non-conformità: export disponibile solo in PDF (non riutilizzabile in altri sistemi).

Controllo 13 — Diritto di opposizione e revoca consenso (artt. 21-7)

Cosa serve: l’utente deve poter revocare il consenso al marketing, al profiling, alle decisioni automatizzate, in qualsiasi momento e con la stessa facilità con cui l’ha prestato.

Implementazione tecnica: pagina centro preferenze accessibile dall’area utente. Ogni email di marketing ha link “annulla iscrizione” funzionante (one-click se il sistema riconosce l’utente, two-click max altrimenti). Revoca immediata, non “entro 7 giorni”.

Indicatore di non-conformità: revoca del consenso che richiede di scrivere a un’email aziendale e attendere risposta.

Area 4 — Sicurezza tecnica e organizzativa (controlli 14-18)

Art. 32 GDPR: il titolare del trattamento adotta misure tecniche e organizzative adeguate al rischio. Cinque controlli che coprono il minimo accettabile per il 2026.

Controllo 14 — Encryption at rest e in transit

Cosa serve: i dati personali devono essere cifrati sia quando memorizzati (disco, DB, file storage) sia quando viaggiano sulla rete (HTTPS/TLS).

Implementazione tecnica:

• At rest: encryption by default del DB cloud (Azure SQL TDE, AWS RDS encryption, Cosmos DB encryption — sono attivi by default su tutti i cloud moderni).
• In transit: TLS 1.2+ obbligatorio sia client-server sia server-server (microservizi che parlano fra loro).
• Column-level encryption opzionale per dati ultra-sensibili (es. dati di salute, biometria).

Indicatore di non-conformità: dati personali memorizzati in chiaro su file storage. HTTP senza TLS in produzione.

Controllo 15 — Autenticazione multi-factor (MFA)

Cosa serve: accesso al software con MFA per gli utenti interni e per gli admin. Per gli utenti finali in self-service, MFA opzionale ma fortemente raccomandato.

Implementazione tecnica: integrazione con identity provider che supporta MFA nativamente (Microsoft Entra ID, Auth0, AWS Cognito). TOTP via app authenticator (Microsoft Authenticator, Google Authenticator). Bonus: passkey FIDO2.

Indicatore di non-conformità: admin che accedono solo con password senza secondo fattore.

Controllo 16 — RBAC (Role-Based Access Control) granulare

Cosa serve: ogni utente accede solo ai dati che gli servono per il suo ruolo (principio del minor privilegio). Il consulente fiscale non accede ai dati dei clienti del consulente legale dello stesso studio. Il commerciale Nord Italia non accede ai dati dei clienti del Sud.

Implementazione tecnica: model RBAC chiaro fin dall’architettura iniziale, applicato in modo consistent in tutto il software (non solo nell’UI ma anche nelle API e nelle query database). Row-level security dove necessario (es. PostgreSQL RLS, SQL Server RLS).

Indicatore di non-conformità: ruolo “admin” che vede tutto, ruolo “user” che vede tutto tranne le pagine admin. Granularità troppo grossolana.

Controllo 17 — Audit log immutabile delle attività sensibili

Cosa serve: ogni accesso a dati personali, ogni modifica, ogni cancellazione viene loggata in modo immutabile, con timestamp, utente, IP, dato toccato. Senza audit log non si possono dimostrare le misure di sicurezza ad un eventuale ispezione Garante.

Implementazione tecnica:

• Log applicativi su Application Insights / CloudWatch con retention 12-24 mesi
• Tabella audit_log in DB applicativo per eventi business-critical (login, modifica dati sensibili, accesso categoria speciale, export dati, cancellazione)
• Append-only, no UPDATE/DELETE (immutabilità garantita a livello DB)

Indicatore di non-conformità: nessun log delle modifiche; oppure log esistente ma editabile da chi vuole nascondere le tracce.

Controllo 18 — Gestione segreti e credenziali

Cosa serve: niente credenziali (database password, API key, certificati) hardcoded nel codice sorgente. Niente credenziali condivise via email/Teams. Niente credenziali nei log applicativi.

Implementazione tecnica: secret management con Azure Key Vault, AWS Secrets Manager, HashiCorp Vault. Rotazione automatica delle credenziali (almeno annuale). Code scanning per credenziali accidentalmente committate (es. GitHub Secret Scanning).

Indicatore di non-conformità: file appsettings.json o .env con password in chiaro nel repository Git.

Area 5 — Audit, accountability e trasferimenti (controlli 19-22)

Il principio di accountability (art. 5 § 2) richiede al titolare del trattamento di dimostrare la conformità, non solo di essere conforme. Quattro controlli per i casi più frequenti.

Controllo 19 — Registro dei trattamenti (art. 30)

Cosa serve: documento (interno, non pubblico) che elenca tutti i trattamenti di dati personali con: finalità, categorie di interessati, categorie di dati, destinatari, trasferimenti extra-UE, periodi di conservazione, misure di sicurezza. Il software che tratta dati personali è una voce del registro.

Implementazione tecnica: documento mantenuto dal DPO/responsabile compliance. Sezione del registro dedicata al software custom, descritta in modo tecnico (schema dati, flussi, sistemi connessi).

Indicatore di non-conformità: registro non esistente, o non aggiornato al software custom da quando è andato in produzione.

Controllo 20 — DPA (Data Processing Agreement) con tutti i sub-processor

Cosa serve: ogni fornitore esterno che tratta dati personali per conto del titolare (cloud provider, SMTP provider, partner di sviluppo che ha accesso ai dati in produzione, analytics provider) deve essere coperto da un DPA firmato (art. 28 GDPR).

Implementazione tecnica: i provider cloud principali (Azure, AWS, GCP, Microsoft 365) hanno DPA standard accettabili by default. Verificare per ogni fornitore minore: SMTP transazionale (es. Azure Communication Services, SendGrid), CDN (Cloudflare), analytics (Google Analytics, Plausible), error tracking (Sentry).

Indicatore di non-conformità: il software invia email via servizio terzo senza DPA firmato.

Controllo 21 — Trasferimenti extra-UE: SCC + DPF

Cosa serve: se i dati personali finiscono fuori UE (es. servizio cloud USA), serve una base giuridica per il trasferimento. Le due principali sono:

• DPF (Data Privacy Framework) EU-USA: applicabile a fornitori USA certificati
• SCC (Standard Contractual Clauses) + valutazione TIA: applicabili a paesi terzi non coperti da DPF

Implementazione tecnica: privacy policy + cookie policy che dichiarano i trasferimenti extra-UE e la base giuridica. Verifica annuale che i fornitori USA usati siano ancora certificati DPF.

Indicatore di non-conformità: la privacy policy dice “non trasferiamo dati extra-UE” ma il software usa AWS region us-east-1.

Controllo 22 — Backup: cifratura, retention, residenza

Cosa serve: i backup contengono dati personali e sono soggetti allo stesso regime dei dati di produzione. Devono essere cifrati, conservati per il tempo necessario (non indefinitamente), e residenti in region accettabili.

Implementazione tecnica: backup gestiti dal cloud provider con encryption attiva by default. Retention configurata (es. 30 giorni di backup giornalieri, 12 mesi di backup mensili). Region di backup esplicita (es. Italy North backup geo-replicato su West Europe).

Indicatore di non-conformità: backup salvati su disco esterno non cifrato dell’amministratore IT.

Area 6 — Breach notification e DPIA (controlli 23-25)

Gli scenari di emergenza e i processi di valutazione preventiva.

Controllo 23 — Breach notification: capacità di rilevare e notificare entro 72 ore

Cosa serve: in caso di data breach (perdita, furto, accesso non autorizzato a dati personali), il titolare deve notificare il Garante entro 72 ore (art. 33) e gli interessati senza ingiustificato ritardo (art. 34). Il software deve supportare questa capacità tecnicamente.

Implementazione tecnica:

• Monitoraggio attivo su tentativi di accesso sospetti (failed login, accessi da IP inusuali, query di massa)
• Alert immediati al team operativo in caso di anomalia
• Procedura interna documentata di response al breach
• Capacità tecnica di identificare velocemente cosa è stato esposto (audit log + retention adeguata)

Indicatore di non-conformità: il team scopre il breach dopo 2 settimane perché un cliente si lamenta.

Controllo 24 — DPIA (Data Protection Impact Assessment) per trattamenti ad alto rischio

Cosa serve: se il software fa trattamenti ad alto rischio (profiling automatizzato di larga scala, monitoraggio sistematico di aree pubbliche, trattamento categorie speciali su larga scala, decisioni automatizzate con effetti significativi sull’interessato), serve fare un DPIA preventivo (art. 35).

Implementazione tecnica: la DPIA è un documento di analisi, non una funzionalità del software. Va fatto prima del go-live, da DPO + team tecnico. Identifica i rischi specifici, le misure di mitigazione, decide se è necessario consultare il Garante.

Indicatore di non-conformità: software con AI che prende decisioni sull’utente (es. credit scoring, screening automatizzato) senza DPIA documentata.

Controllo 25 — Privacy by Design e by Default (art. 25)

Cosa serve: la protezione dei dati deve essere integrata fin dalla progettazione, non aggiunta dopo. Le impostazioni di default devono essere quelle più conservative (es. profilo utente privato by default, non pubblico; opt-in al marketing, non opt-out).

Implementazione tecnica:

• Review compliance in fase di design (prima della scrittura del codice)
• Setting di default conservatori in tutto il software
• Test che verificano i default per ogni release

Indicatore di non-conformità: nuove funzionalità rilasciate con default permissivi, e poi si chiede al DPO se è ok.

Come usare la checklist in pratica

Tre consigli operativi per applicare la checklist senza trasformarla in burocrazia paralizzante.

1. Valuta i 25 controlli in fase di design. Il momento in cui la checklist costa meno è prima di scrivere codice. Una sessione di 2-3 ore con DPO + tech lead + product owner permette di identificare i controlli che richiedono lavoro di sviluppo specifico, e di pianificarli come tasks invece che come fix tardivi.

2. Verifica annuale come audit ricorrente. Una review annuale della checklist (idealmente fatta da una persona diversa da chi ha sviluppato) permette di catturare i drift: nuove feature aggiunte senza controllo privacy, dipendenze esterne aggiunte senza DPA, retention policy non più rispettata.

3. Per progetti business-critical, considera audit esterno. Un audit esterno annuale (firma di consulenza legale specializzata + penetration test) costa 3-8 k€ ma è la singola assicurazione più efficace contro l’ispezione Garante. Per software custom che gestisce categorie speciali (sanità, dati biometrici) lo consideriamo necessario.

Conclusione

GDPR e software custom: la pessima notizia è che ci sono 25 controlli concreti da implementare. La buona notizia è che la maggior parte sono scelte architetturali fatte una volta che poi vivono nel codice, non rituali quotidiani.

Se stai costruendo un nuovo software custom, tre passi pratici:

1. Fai il design GDPR-aware: porta questa checklist nella prima sessione di design con il partner di sviluppo, valutate quali controlli richiedono lavoro specifico.
2. Verifica il partner sul fronte privacy: nella selezione del partner usa la checklist 15 domande pre-vendita — domande 4-6 e 9 sono direttamente collegate al GDPR.
3. Inserisci il DPO nel processo, non solo a delivery: il DPO che vede il software solo a go-live non può chiedere modifiche senza far slittare il progetto. Coinvolgilo dal design.

Quando hai bisogno di un partner di sviluppo strutturato sui temi GDPR sin dal design, scrivici. La checklist sopra è il riferimento che applichiamo internamente su ogni progetto custom.