Ontwikkelaars die zoeken naar GDPR-codecontroles willen meestal één ding: een korte lijst met juridische verplichtingen die daadwerkelijk kunnen worden geschonden in een normale pull request, niet een volledige handleiding voor een privacyprogramma. De verordening draait vooral om processen, registraties en organisatorische maatregelen. Een klein maar consistent deel van de verplichtingen belandt in code: wat je opslaat, hoe lang je het bewaart, of een verwijderingspad alle kopieën bereikt, wat standaard wordt blootgesteld, hoe verwerking wordt beveiligd en waar gegevens worden gehost.
Deze gids is die kaart. Het is bewust geen stapsgewijze uitleg van een enkele bewartermijnfout (die vind je op /guides/catching-a-gdpr-retention-bug-in-code-review) en geen diepgaande analyse van controls (die vind je onder /frameworks/gdpr). Het is de checklist voor codecontroles: welke artikelen je kunt noemen, hoe de wijziging eruitziet en wat een reviewer kan vragen zonder juridisch adviseur te worden.
De artikelen die vaak in een diff veranderen
Art. 5(1)(c) dataminimalisatie: een wijziging begint meer persoonsgegevens te verzamelen of te loggen dan nodig is voor het doel (volledige verzoeklichamen, volledige identiteitsgegevens gekopieerd naar een nevenopslag). Art. 5(1)(e) bewaartermijnbeperking: een nieuwe opslagplaats of cache voor persoonsgegevens wordt geïntroduceerd zonder bewaartermijn, of een verwijderingsvenster wordt verruimd zonder reden. Art. 17 recht op vergetelheid: een verwijderingspad bereikt niet een cache, zoekindex, analytics-export of verwerkerkopie. Art. 25 gegevensbescherming door ontwerp en standaardinstellingen: een persoonsveld wordt standaard zichtbaar of gedeeld met elke gebruiker, of een beschermende standaardinstelling wordt uitgeschakeld. Art. 32 beveiliging van de verwerking: encryptie, toegangcontrole of integriteitsmaatregelen voor persoonsgegevens worden verzwakt (TLS-niveau verlaagd, tokens in plaintext opgeslagen, admin-pad geopend). Art. 44 hoofdstuk over doorzending: persoonsgegevens worden verplaatst naar een nieuwe regio of een verwerker in een derde land zonder de doorzendingscontext die je programma verwacht.
Deze uitleg is bedoeld voor ontwikkelaars in begrijpelijke taal, niet de letterlijke tekst van de verordening. Wanneer een bevinding een artikel noemt, is dat een signaal voor de auteur en de privacycontactpersoon, niet een vaststelling dat de verwerking onrechtmatig is.
Uitgewerkt voorbeeld: privacy door standaardinstellingen omgedraaid voor "ondersteuningsgemak"
Een ondersteuningsteam wil tickets sneller kunnen sorteren. Een ontwikkelaar opent een pull request die de customer profile API wijzigt, zodat elke geauthenticeerde medewerkersrol standaard full_name, e-mail, telefoonnummer en de laatste vier cijfers van het betaalmiddel ontvangt in het standaard lijst-endpoint, niet alleen bij een expliciete "expand=pii"-aanvraag. De wijziging is klein: één serializer-vlag wordt van false naar true gezet. Tests worden bijgewerkt om de rijkere payload te verwachten. De codecontrole gaat over responsgrootte en cache-headers. Niets lijkt op een beveiligingsfout; authenticatie werkt nog steeds.
Wat hier verandert, is Art. 25 gegevensbescherming door ontwerp en standaardinstellingen: persoonsgegevens worden nu standaard blootgesteld aan een grotere groep interne gebruikers dan voorheen, in strijd met het principe van minimale toegang. De veiligere variant houdt de smalle standaardinstelling aan en vereist een expliciete, geauditeerde uitbreiding voor ondersteuningstools. Dit is een andere foutmodus dan de bewartermijnfout (Art. 5(1)(e) bij een nieuwe opslag zonder verwijdering) en dan een zuivere minimalisatiefout bij logging (Art. 5(1)(c) bij verzoeklichamen). Een compliance-bewuste review noemt Art. 25 (en vaak ook Art. 5(1)(c) als ondersteunend principe) op de PR zolang de vlag nog gemakkelijk kan worden teruggedraaid.
Wat je in een review kunt vragen zonder DPO te worden
Voor elke wijziging die persoonsgegevens raakt: welke velden zijn nieuw, wie kan ze standaard zien, hoe lang ze bestaan en of een verwijderings- of exportpad ze nog bereikt. Voor wijzigingen in regio of leverancier: waar gaan de gegevens naartoe en volgt privacy deze verwerker of doorzending al? Voor "opruim"-PR's: hebben we encryptie, toegangcontroles of auditregels verwijderd die persoonsgegevens beschermden (gerelateerd aan Art. 32).
Je hoeft de verordening niet te citeren. Je moet de merge weigeren als het antwoord "onbekend" is, tot iemand de privacytaak op zich neemt of de veiligere standaardinstelling herstelt.
Waar heygrc past, en de eerlijkheidsgrens
heygrc is ontworpen om elke pull request te scannen op basis van de door jou geselecteerde frameworks, inclusief de GDPR als deze is ingeschakeld, en om het artikel te noemen dat een wijziging lijkt aan te raken (bijvoorbeeld Art. 25 bij een uitgebreidere standaardpayload). Het neemt geen beslissingen over de rechtsgrondslag, voert geen DPIA's uit, onderhoudt geen RoPA, keurt geen doorzendingen goed en vervangt je DPO niet. Een groene review is geen goedkeuring van de toezichthouder.
Bug- en kwaliteitsreviewers blijven op dezelfde PR. Zij vragen of de code correct is. GDPR-vragen vragen of de verplichtingen voor persoonsgegevens nog gelden. Voer beide uit.