FAQ - GDPR per Software Builder

> Disclaimer: Questo contenuto è destinato esclusivamente a fini educativi e di riferimento per i costruttori di software. Non costituisce consulenza medica, legale, finanziaria o normativa. Consultare un professionista qualificato prima di prendere decisioni basate su questo contenuto.

Memorizza come minimo: subject_id, purpose_id, lawful_basis, consent_given (booleano), consent_timestamp (UTC con fuso orario), consent_ip, consent_method (es. "web-form-v2.1"), consent_text_hash (SHA-256 del testo esatto del consenso mostrato) e withdrawn_at (nullable). Mantieni i record di consenso immutabili; non aggiornare le righe, aggiungi nuove righe quando il consenso cambia. Crea un indice su (subject_id, purpose_id, consent_given) per una ricerca rapida durante l'elaborazione delle richieste. (GDPR Art. 7, EUR-Lex 2016/679)

Come implemento il flusso di lavoro di notifica della violazione entro 72 ore nel mio sistema?

Implementa una pipeline di rilevamento delle violazioni con tre fasi: (1) Rilevamento - regole di allerta nel tuo SIEM o piattaforma di osservabilità che si attivano su pattern anomali di accesso ai dati, indicatori di esfiltrazione o violazioni di integrità; (2) Triage - un runbook on-call con un gate decisionale a 4 ore per classificare la violazione per gravità e determinare se i dati personali sono stati coinvolti; (3) Notifica - se è probabile che i dati personali siano stati coinvolti, notifica all'autorità di vigilanza entro 72 ore dalla "conoscenza" da parte del titolare. Traccia breach_id, detected_at, controller_aware_at, dpa_notified_at e subjects_notified_at nel registro delle violazioni. Imposta SLO di allerta a 24h, 48h e 68h da controller_aware_at. (GDPR Art. 33, EUR-Lex 2016/679)

Quando è richiesta una DPIA per il mio progetto software?

Una DPIA è obbligatoria prima di avviare trattamenti ad alto rischio. I trigger obbligatori includono: valutazione sistematica ed estensiva di aspetti personali mediante trattamento automatizzato (profilazione), trattamento su larga scala di categorie particolari di dati, monitoraggio sistematico di aree accessibili al pubblico su larga scala, e qualsiasi trattamento incluso nell'elenco obbligatorio dell'autorità di vigilanza nazionale. Come costruttore, valuta rispetto ai nove criteri dell'EDPB (WP248 rev.01): tecnologia innovativa, trattamento su larga scala, monitoraggio sistematico, dati sensibili, soggetti vulnerabili, combinazione di dati, rischio di diniego del servizio, profilazione e trasferimento verso paesi terzi. Due o più criteri = DPIA raccomandata. (GDPR Art. 35(3), EUR-Lex 2016/679)

Come gestisco una DSAR in cui l'utente richiede tutti i suoi dati e ho molti data store?

Costruisci un flusso di lavoro di adempimento DSAR: (1) Verifica dell'identità - autentica il richiedente per prevenire divulgazioni fraudolente; (2) Inventario dei dati - interroga una mappa dati centrale che identifica tutti i sistemi che contengono dati per quel subject_id (DB relazionale, indice di ricerca, cache, analytics, log, backup, responsabili terzi); (3) Estrazione dei dati - esegui script di estrazione per sistema che restituiscono i dati del soggetto in formato strutturato; (4) Compilazione - aggrega in un formato portatile (JSON o PDF); (5) Revisione - redigi dati di terzi o informazioni legalmente privilegiate; (6) Consegna - invia in modo sicuro al richiedente verificato. Registra la data di ricezione della richiesta; il termine di risposta è di un mese di calendario dalla ricezione. Automatizza il tracciamento dello stato. (GDPR Art. 15, EUR-Lex 2016/679)

Il GDPR si applica a qualsiasi operazione strutturata su dati personali di residenti UE/SEE, indipendentemente da dove sia stabilito il titolare/responsabile. Le operazioni includono: lettura di un record utente da un database, registrazione di una richiesta con un indirizzo IP, invio di un'email, memorizzazione di un cookie, esecuzione di un algoritmo di raccomandazione su dati comportamentali e generazione di report di analytics. Anche se i tuoi server sono fuori dall'UE, il GDPR si applica se offri beni o servizi a residenti UE o ne monitori il comportamento. (GDPR Art. 3, 4(2), EUR-Lex 2016/679)

Come implemento un flusso di lavoro automatizzato di conservazione ed eliminazione dei dati?

Progetta un servizio di conservazione che: (1) definisce una RetentionPolicy per data_category con retention_days e disposal_action (DELETE, ANONYMISE, ARCHIVE); (2) viene eseguito ogni notte o settimana come job in background; (3) interroga ogni data store per i record in cui (created_at + retention_days) <= now() E legal_hold = false; (4) applica l'azione di smaltimento in modo atomico; (5) registra la cancellazione in una tabella deletion_log (cosa è stato cancellato, quando, quale policy applicata). I flag di blocco legale devono impedire la cancellazione automatica dei record coinvolti in contenziosi in corso o indagini normative. Testa la propagazione della cancellazione alle repliche di lettura e ai percorsi di ripristino dei backup. (GDPR Art. 5(1)(e), EUR-Lex 2016/679)

Qual è la differenza tra titolare e responsabile del trattamento, e perché è importante per la costruzione di SaaS?

Un titolare determina perché e come vengono trattati i dati personali; un responsabile tratta i dati solo secondo le istruzioni del titolare. In un modello SaaS tipico: il fornitore SaaS è il responsabile e ogni azienda cliente è il titolare. Il fornitore SaaS deve: (a) firmare un DPA con ogni cliente titolare; (b) trattare i dati solo secondo istruzioni documentate; (c) non coinvolgere sub-responsabili senza autorizzazione; (d) assistere il titolare con le DSAR e le DPIA; (e) cancellare o restituire i dati alla risoluzione del contratto. Per le architetture multi-tenant, la segregazione dei dati tra tenant-titolari deve essere imposta tecnicamente. (GDPR Art. 28, EUR-Lex 2016/679)

Come struttura un'informativa sulla privacy per rispettare gli Art. 13/14?

Per l'Art. 13 (dati raccolti direttamente): fornire al momento della raccolta - identità e contatti del titolare, contatti del DPO (se applicabile), finalità e base giuridica per ogni attività di trattamento, interessi legittimi (se invocati), destinatari o categorie di destinatari, dettagli dei trasferimenti verso paesi terzi, periodi di conservazione, tutti i diritti degli interessati, diritto di revocare il consenso, diritto di proporre reclamo all'autorità di vigilanza, e se la fornitura dei dati è obbligatoria/contrattuale. Per l'Art. 14 (dati ottenuti indirettamente): fornire entro un mese. Usa un approccio stratificato: informativa in formato breve al punto di raccolta, informativa sulla privacy completa collegata da essa. (GDPR Art. 13-14, EUR-Lex 2016/679)

Come funziona tecnicamente il diritto alla portabilità e in quale formato devo esportare?

Il diritto alla portabilità si applica ai dati che il soggetto ha fornito attivamente e dove il trattamento è basato sul consenso o su un contratto, ed è automatizzato. Implementa un endpoint /api/v1/users/{id}/export che: si autentica tramite JWT (solo proprietario), raccoglie tutti i dati forniti direttamente (campi del profilo, contenuti caricati, input espliciti), li formatta come file leggibile da dispositivo strutturato (JSON o CSV, non PDF), e li consegna tramite un link di download sicuro con TTL breve. Escludi i dati derivati/inferiti (punteggi, segmenti) dall'esportazione per la portabilità - tali dati sono stati generati dal titolare. (GDPR Art. 20, EUR-Lex 2016/679)

Quali sono i requisiti tecnici per implementare la Privacy by Design?

Implementa la conformità all'Art. 25 attraverso: (1) Minimizzazione dei dati ai confini API - valida che ogni campo della richiesta abbia una necessità documentata; (2) Impostazioni predefinite di privacy - i nuovi account utente sono predefiniti come privati/opt-out per la condivisione di dati opzionale; (3) Controllo degli accessi - principio del minimo privilegio per ogni servizio che accede al database; (4) Cifratura - a riposo (AES-256) e in transito (TLS 1.2+); (5) Pseudonimizzazione - sostituisci gli identificativi diretti con token nelle pipeline di analytics/logging; (6) Automazione della conservazione - cancellazione automatica dei dati oltre il loro periodo di conservazione; (7) Segnali di consenso - tutti i sistemi di trattamento ricevono e rispettano i flag di consenso prima del trattamento. (GDPR Art. 25, EUR-Lex 2016/679)

Come gestisco i trasferimenti internazionali di dati nell'architettura della mia applicazione?

Classifica ogni flusso di dati per tipo di trasferimento: (1) SEE-to-SEE - nessuna restrizione; (2) SEE-verso-paese adeguato - nessuna garanzia aggiuntiva richiesta (controlla la lista EDPB); (3) SEE-verso-paese non adeguato - richiede garanzia adeguata (SCC, BCR, deroga). Per i trasferimenti SCC, conduci una Transfer Impact Assessment valutando il quadro giuridico del paese di destinazione. Usa la selezione del modulo: SCC C2P quando un titolare trasferisce a un responsabile, C2C per controller-to-controller. Implementa misure supplementari tecniche per i paesi di destinazione ad alto rischio (es. cifratura end-to-end dove solo la parte SEE detiene le chiavi). (GDPR Art. 44-49, EUR-Lex 2016/679)

Quali informazioni devono essere catturate nel Registro delle Attività di Trattamento (RoPA)?

Per i titolari: (a) nome e recapiti del titolare; (b) recapiti del DPO; (c) finalità del trattamento per ogni attività; (d) descrizione delle categorie di interessati; (e) categorie di dati personali; (f) categorie di destinatari; (g) trasferimenti verso paesi terzi e loro garanzie; (h) periodi di conservazione; (i) descrizione delle misure di sicurezza tecniche/organizzative. Implementa il RoPA come tabella di database o documento strutturato con una riga per attività di trattamento. Collega ogni voce RoPA a un record di base giuridica, DPA pertinenti e DPIA. (GDPR Art. 30, EUR-Lex 2016/679)

Come implemento una richiesta di cancellazione che si propaghi a tutti i data store?

Costruisci un ErasureOrchestrator che: (1) riceve una richiesta di cancellazione validata con subject_id; (2) verifica i blocchi legali in una tabella legal_hold_register - rifiuta se esiste qualsiasi blocco attivo; (3) identifica tutti i data store dalla mappa dei dati (DB primario, analytics, ricerca, cache, CDN, log, job di backup); (4) emette comandi di cancellazione a ogni store in un pattern fan-out; (5) attende la conferma da ogni store; (6) imposta erasure_completed_at nella tabella di tracciamento DSR; (7) notifica ai responsabili a valle dell'obbligo di cancellazione. I log devono registrare cosa è stato cancellato e quando. (GDPR Art. 17, EUR-Lex 2016/679)

L'Art. 32 richiede misure tecniche e organizzative adeguate al rischio, includendo ad esempio: (a) pseudonimizzazione e cifratura; (b) capacità di garantire la continua riservatezza, integrità, disponibilità e resilienza dei sistemi e dei servizi di trattamento; (c) capacità di ripristinare tempestivamente la disponibilità e l'accesso ai dati personali in caso di incidente fisico o tecnico; (d) procedura per testare, verificare e valutare regolarmente l'efficacia delle misure tecniche e organizzative. Tradotto in implementazione: TLS 1.2+ per i dati in transito; AES-256 per i dati a riposo; RTO/RPO documentati e testati; WAF e protezione DDoS; programma di penetration testing; revisione annuale della sicurezza. (GDPR Art. 32, EUR-Lex 2016/679)

Come gestisco la revoca del consenso e mi assicuro che si propaghi correttamente?

Quando un utente revoca il consenso: (1) registra il timestamp withdrawn_at sul record di consenso (log immutabile); (2) imposta consent_given = false nella cache di consenso attiva; (3) propaga il segnale di revoca a tutti i sistemi di trattamento che dipendono da questo consenso - usa un event bus (Kafka, RabbitMQ o simile) che pubblica un ConsentWithdrawnEvent{subjectId, purposeId, withdrawnAt}; (4) ogni consumer a valle deve cessare il trattamento per quella finalità entro un tempo ragionevole; (5) i dati raccolti esclusivamente sulla base del consenso revocato devono essere cancellati (a meno che non si applichi un'altra base giuridica); (6) conferma la revoca all'utente. (GDPR Art. 7(3), EUR-Lex 2016/679)