Gli ingegneri che cercano controlli di code review GDPR di solito vogliono una cosa: un elenco breve di obblighi legali che possono effettivamente essere violati in una pull request normale, non un manuale completo di un programma di privacy. Il Regolamento riguarda principalmente processi, registri e misure organizzative. Una minoranza consistente di obblighi finisce comunque nel codice: cosa si memorizza, per quanto tempo lo si conserva, se un percorso di eliminazione raggiunge ogni copia, cosa espongono le impostazioni predefinite, come viene protetto il trattamento e dove vengono ospitati i dati.
Questa guida è quella mappa. Non è volutamente una spiegazione passo-passo di un singolo bug di limitazione della conservazione (che si trova in /guides/catching-a-gdpr-retention-bug-in-code-review) né un approfondimento sui controlli (che si trovano in /frameworks/gdpr). È la checklist per la code review: quali articoli citare, come appare la modifica e cosa un revisore può chiedere senza diventare un consulente legale.
Gli articoli che tendono a modificarsi in una diff
Art. 5(1)(c) minimizzazione dei dati: una modifica inizia a raccogliere o registrare più dati personali di quanto necessario allo scopo (corpi completi delle richieste, record di identità completi copiati in un archivio secondario). Art. 5(1)(e) limitazione della conservazione: un nuovo archivio o cache di dati personali viene distribuito senza un limite di conservazione, o una finestra di eliminazione viene allargata senza uno scopo. Art. 17 diritto alla cancellazione: un percorso di eliminazione non raggiunge una cache, un indice di ricerca, un'esportazione di analisi o una copia del responsabile del trattamento. Art. 25 protezione dei dati fin dalla progettazione e per impostazione predefinita: un campo personale diventa visibile o condiviso con ogni utente per impostazione predefinita, o un'impostazione predefinita protettiva viene disattivata. Art. 32 sicurezza del trattamento: la crittografia, il controllo degli accessi o le misure di integrità sui dati personali vengono indebolite (livello minimo TLS ridotto, archiviazione di token in testo in chiaro, apertura di un percorso admin). Art. 44 capitolo sui trasferimenti: i dati personali vengono spostati in una nuova regione o verso un responsabile del trattamento di un paese terzo senza la documentazione di trasferimento prevista dal programma.
Esempio pratico: protezione dei dati per impostazione predefinita invertita per "comodità del supporto"
Un team di supporto vuole una triage più rapida dei ticket. Un ingegnere apre una pull request che modifica l'API del profilo cliente in modo che ogni ruolo dello staff autenticato riceva nome completo, email, telefono e ultime quattro cifre del pagamento nell'endpoint di lista predefinito, non solo su una richiesta esplicita "expand=pii". La modifica è minima: una flag del serializzatore passata da false a true. I test vengono aggiornati per aspettarsi il payload più ricco. La code review discute di dimensione della risposta e intestazioni della cache. Nulla sembra un bug di sicurezza: l'autenticazione funziona ancora.
Ciò che è cambiato riguarda l'Art. 25 protezione dei dati fin dalla progettazione e per impostazione predefinita: i dati personali sono ora esposti per impostazione predefinita a un insieme più ampio di consumatori interni rispetto alla precedente configurazione a privilegi minimi. La configurazione più sicura mantiene l'impostazione predefinita ristretta e richiede un'espansione esplicita e auditata per gli strumenti di supporto. Questo è un tipo di errore diverso dal bug di conservazione (Art. 5(1)(e) su un nuovo archivio senza eliminazione) e da un esempio di registrazione di minimizzazione pura (Art. 5(1)(c) sui corpi delle richieste). Una revisione consapevole della conformità cita l'Art. 25 (e spesso l'Art. 5(1)(c) come principio di supporto) nella PR finché la flag è ancora facile da invertire.
Cosa chiedere nella revisione senza diventare un DPO
Per qualsiasi modifica che coinvolge dati personali: quali campi sono nuovi, chi può vederli per impostazione predefinita, per quanto tempo rimangono, e se un percorso di eliminazione o esportazione li raggiunge ancora. Per modifiche di regione o fornitore: dove vanno i dati e la privacy ha già tracciato quel responsabile del trattamento o trasferimento. Per PR di "pulizia": abbiamo rimosso crittografia, controlli di accesso o righe di audit che proteggevano dati personali (Art. 32 correlato).
Non è necessario citare il Regolamento. È necessario rifiutare il merge quando la risposta è "sconosciuto" finché qualcuno non si assume la responsabilità del passaggio di privacy, o ripristinare l'impostazione predefinita più sicura.
Dove si inserisce heygrc e il confine dell'onestà
heygrc è progettato per analizzare ogni pull request rispetto ai framework selezionati, inclusa la GDPR quando abilitata, e per indicare l'articolo che una modifica sembra interessare (ad esempio Art. 25 su un payload predefinito allargato). Non decide la base giuridica, esegue DPIA, mantiene il RoPA, approva i trasferimenti o sostituisce il DPO. Una revisione verde non è un'approvazione da parte dell'autorità di vigilanza.
I revisori di bug e qualità rimangono sulla stessa PR. Chiedono se il codice è corretto. Le domande GDPR chiedono se gli obblighi sui dati personali sono ancora rispettati. Eseguire entrambe.