Privacy by Design

Privacy by Design (GDPR)

1) Di cosa si tratta e perché

Privacy by Design (PbD) è il principio in base al quale la privacy viene inserita nel prodotto fin dall'inizio: requisiti aziendali, architettura, codice, processi e operazioni. In termini GDPR, ciò si manifesta in privacy by design e by default (riducendo al minimo gli incassi, le impostazioni predefinite sono la massima privacy, trasparenza e responsabilità).

• Ridurre al minimo la raccolta e il trattamento dei dati personali (PDN).
• Garantire la legalità, la trasparenza, la correttezza, limitare obiettivi e tempi.
• Ridurre i rischi (tecnici e legali), semplificare il controllo e dimostrare la conformità.

2) Ruoli, fondamenti legali e principi GDPR

2. 1 Ruoli

Controllore (Controller) - Consente di definire obiettivi/strumenti di elaborazione.
Processore (Processor) - Gestisce il PDN per conto del controllore DPA.
Oggetto dati (Data Subject) - Il fisico a cui appartengono i PDN.
DPO (ufficiale di protezione dei dati): su richiesta, controllo e consulenza indipendenti.

2. 2 Fondamenti legali (scegliamo e documentiamo)

Consenso, contratto, legittimo interesse, dovere legale, interesse vitale, compito pubblico. Per ciascuno: scopo, dati, ritenzione, possibilità di ritiro (per consenso).

2. 3 Principi di lavorazione (articolo 5)

Legittimità, giustizia, trasparenza

Limitazione obiettivo

Ridurre al minimo i dati

Precisione

Limitazione dello storage

Integrità e riservatezza

Responsabilità (accountability) - Capacità di dimostrare la conformità.

3) Processo di PbD in SDLC (reference framework)

1. Iniziazione: formulazione degli obiettivi di elaborazione e delle basi legali, assegnazione owner'ove dati e DPO-point.
2. Mappatura dati (Data Mapping) - Le sorgenti del campo il modello di fiducia in cui scorre l'utente che legge il in cui è memorizzato il termine.
3. Valutazione dei rischi/DPIA: Modello LINDDUN di minacce alla privacy, valutazione dell'impatto, misure di riduzione.
4. Soluzioni architettoniche: scelta di diagrammi di minimizzazione, alias, crittografia, separazione.
5. Requisiti UX/accettazioni/notifiche: testo comprensibile, granulo consent, impostazione predefinita.
6. Implementazione: default privato, telemetria sicura, logica senza segreti/PII.
7. Verifica: test di privacy, analisi statiche, test unit privati, protocolli DPIA.
8. Funzionamento: processi DSAR, reticenze e rimozione, monitoraggio degli incidenti, gelosia dei fornitori.
9. Revisione regolare: re-DPIA per la modifica degli obiettivi/tecnologie.

4) Pattern di ingegneria

4. 1 Minimizzazione e decomposizione

Raccogli solo i campi necessari applica progressive profiling.
Separa ID e contenuto: memorizza la chiave di comunicazione separatamente (token/reference).

4. 2 Alias e anonimato

Alias: memorizzare l'ID reale separatamente; il livello di lavoro vede il token.
Anonimato: utilizzare k-anonimato, l-diversity, t-closeness; per gli analisti, la privacy differenziale.

4. 3 Controllo degli accessi e separazione dei ruoli

PoLP, ABAC/RBAC, segregation of patties, tracciati separati per ammiragli e analisti.
Di quelli. misure: mTLS, SSO/OIDC, token scoped, schede temporanee per l'accesso al PDN.

4. 4 Crittografia e isolamento

In Transit: TLS 1. 3/mTLS; At Rest: AEAD/Envelope + KMS/HSM.
Chiavi separate per locatore/dataset; crypto-rimozione per «diritto all'oblio».

4. 5 Ritenzione e rimozione

Criteri espliciti TTL per campo/obiettivo; auto-purge in pipline; Rimozione «bifase» (logica → fisica).
Per i backup, chiavi separate e finestre brevi di conservazione di snapshot personali.

4. 6 Telemetria privata e logica

Per impostazione predefinita, senza PII; utilizzare token/hash con sale.
Maschera/tornizza i campi sensibili sul produttore.

4. 7 UX privacy e consenso

Grande consent per categoria (analisi, marketing, personalizzazione).
«Default privato», tutto non critico, spento finché non ha accettato.
L'opzione «Revoca consenso» e la notifica just-in-time sono chiare quando viene utilizzato.

5) DPIA e LINDDUN (breve)

DPIA (Valutazione dell'Impatto sulla Protezione dei Dati): è necessario con elevata rischiosità (monitoraggio, valutazione, nuova tecnologia). Consiste in una descrizione di elaborazione, necessità/proporzionalità, valutazione dei rischi, misure di riduzione.
LINDDUN угрозы: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance. Per ogni minaccia sono contromisure (minimizzazione, alias, DOP, trasparenza, gestione dei consensi, controllo).

6) Trasferimenti transfrontalieri

Scopri le posizioni di storage/accesso dei fornitori.
Utilizzare SCC (clausole contrattuali standard) e eseguire Transfer Impact Assessment.
Tecnologie: crittografia end-to-end, crittografia client per dati sensibili, limitazione dell'accesso remoto.

7) Fornitori e processori (Vendor Management)

DPA/processori nidificati, interventi tecnici e organizzativi, sottoprocessori sotto controllo.
Ringhiera e verifiche regolari; il diritto di ispezione; piano di uscita/migrazione (data export).

8) Diritti dei soggetti dati (DSAR)

Accesso, correzione, rimozione, vincolo, portabilità, obiezione, non essere un oggetto AADM (profiling/automazione).
SLA e automazione: tracking delle richieste, prova di identificazione, registro delle risposte.
Gancio tecnico nel prodotto: ricerca rapida ed esportazione tramite ID; rimozione a cascata per retaggi.

9) Soluzioni automatizzate e profilassi (articolo 22)

Se le decisioni a «impatto significativo» sono prese dal distributore automatico - garantire il diritto di intervento umano, la spiegabilità, la trasparenza dei segni.
Percorso e versioning dei modelli il meccanismo d'appello.

10) Sicurezza del trattamento (articolo 32) e incidenti (articolo 33/34)

Misure orientate al rischio: crittografia, integrità, sostenibilità, piani di ripristino (RTO/RPO).
Gli incidenti con il PDN sono un processo di rilevamento del triage, una valutazione del rischio, una notifica del regolatore entro 72 ore (se necessario) e dei soggetti (se ad alto rischio).
Playbook separato, foglio di contatto DPO/avvocati, modelli di notifica.

11) Privacy e ML/analista

Data Governance set: data-righello, licenze/basi, consenso.
Tecniche: privacy differenziale, federated learning, secure aggregation, minimizzazione dei fiocchi.
Protezione da attacchi: membership/model eversion - Valutazioni regolari delle perdite, regolazione di un'unità, rumore/clip.
I dati sintetici sono solo per verificare la mancata riparazione delle persone.

12) Schemi architettonici (pattern)

12. 1 Architettura ID a doppio contorno

Tracciato A (PDS - Personal Data Store) - Dati di identificazione reali (REED), accesso rigidamente limitato, chiavi/crittografia/controllo.
Contorno B (Operational) - Dati aziendali con token comunicazioni attraverso un broker di token con limiti e un controllo.

12. 2 Bus di consenso (Consent Service)

Servizio centralizzato che memorizza le versioni di consenso e cronologia.
SDK: 'can _ use (category, purpose)' - decide al volo; Tutto è logico.

12. 3 Criteri di ritenzione come codice

Configurazione YAML - L'entità del campo di TTL viene attivata alla scadenza (anonimizzazione/rimozione/ritaglio).
Il pianificatore esegue job e il report è disponibile per il DPO.

13) Mini-ricette

def collect(field, purpose):
if not is_required(field, purpose):
return None # do not collect v = read_input (field)
return truncate(v, policy. max_length(field))

yaml dataset: users fields:
email: { ttl: P18M, on_expire: pseudonymize }
phone: { ttl: P12M, on_expire: delete }
session_logs: { ttl: P3M, on_expire: aggregate }
consent: { ttl: P7Y, on_expire: archive }

analytics:
default: deny legal_basis: consent scope: anonymous_metrics marketing:
default: deny legal_basis: consent scope: email,push

GET /privacy/export? subject_id=... -> zip:
- profile. json (metadata, legal basis)
- activity. ndjson (events, aggregates)
- consents. json (consent history)
- processors. json (list of processors and transfers)

14) Documentazione e responsabilità

ROPA (Records of Processing Activities) - Registro delle attività: obiettivo, base legale, categorie di dati/soggetti, trasferimenti, conservazione, misure.
Policy: privacy, cookie, notifiche informative nel prodotto (in lingua comprensibile).
Formazione del personale e gelosia annuale.

15) Errori frequenti

Raccogliere «per sicurezza» e conservare «per sempre».
Il consenso è l'unica ragione, anche se è un accordo/legittimo interesse.
I cookie vuoti sono privi di pulsanti reali.
Nessuna mappatura dei dati e nessuna preparazione per DSAR.
Logi PII, backup non protetti, combinazione di RID e dati operativi.
Nessun controllo dei fornitori o dei trasferimenti transfrontalieri.

16) Assegno fogli

• È stato definito lo scopo dell'elaborazione e la base legale; ROPA aggiornato.
• Mappatura dei dati e DPIA eseguita (se necessario).
• Ridurre al minimo, alias, crittografia (nel percorso/a riposo).
• Il consenso è granulare, con UX comprensibile; i default sono privati.
• I criteri di ritenzione sono configurati come codice; rimozione/anonimato verificata.
• Logi/telemetria - senza PII; occultamento attivato.
• È stato preparato un gancio DSAR ed esportato.
• Addestramento del comando e approvazione del DPO.

• Revisione trimestrale delle retene e delle basi legali.
• Controllo periodico dei processori/sottoprocessori.
• Monitoraggio degli incidenti e preparazione della notifica di 72 ore
• Revisione DPIA per i cambiamenti di processo/tecnologia.
• Memorizzazione degli artefatti di conformità (DPIA, ROPA, report di prova).

17) FAQ

Si può «scappare» completamente dal consenso?
O: A volte sì (contratto/obbligo legale/interesse legittimo), ma solo se necessario e con una valutazione dell'equilibrio degli interessi. Il marketing e l'analista non critico richiedono spesso il consenso.

C: L'alias è sufficiente?
No, sono ancora dati personali. Per uscire dalla sfera GDPR è necessaria un'anonimizzazione affidabile (verificabile per non poter essere nuovamente identificata).

C: Come funziona l'ML e la personalizzazione?
O: Minimizza i fili, usa gli approcci DOP/federated, logifica le soluzioni, garantisce il diritto di intervento umano e rifiuta la profilassi.

C: Cosa fare in caso di conflitto tra affari e privacy?
O: Riprogettare la raccolta (progressive professing), passare a aggregati/sintetici, rivalutare la base legale, suggerire un'opzione senza tracking.

• «Gestione dei segreti»
• Crittografia At Rest'
• Crittografia in transit
• Controllo e registri invariati
• Firma e verifica query
• Gestione e rotazione delle chiavi