AVG-artikel 25: privacy by design een levenscyclusplicht

U moet elke privacyclaim in uw systeem kunnen onderbouwen met inspecteerbaar bewijs: documentatie van architectuurkeuzes, configuratiebeslissingen, leveranciersafspraken, testresultaten en operationele logs. Privacy by design is geen vroege beleidsevaluatie, maar een levenscyclusplicht die zich uitstrekt over bouw, levering, configuratie en bedrijf.

De aanleiding is een analyse van 9 oktober 2026 van privacy by design als engineeringplicht gedurende de hele levenscyclus, die stelt dat artikel 25 van de AVG verwerkingsverantwoordelijken verplicht verdedigbare technische en organisatorische keuzes te maken en deze opnieuw te bekijken zolang de verwerking doorloopt. De analyse onderzoekt hoe een vertrouwelijke juridische-documentworkflow die contracten inleest, geselecteerde context naar een taalmodel stuurt en bevindingen teruggeeft, privacy-relevante beslissingen moet documenteren op elk punt in die keten. In onze beoordeling betekent dit dat u niet kunt volstaan met het beschikbaarheid van beveiligingsfuncties bij een leverancier. U moet aantonen welke gegevens uw systeem verzamelt, hoe het die beperkt, wie ervan kan zien, en wat bewijst dat die beperkingen werkelijk zijn ingebouwd.

Wat vereist artikel 25 eigenlijk van uw ontwerp?

Artikel 25 stelt twee afzonderlijke verplichtingen. Onder artikel 25(1) moet u passende technische en organisatorische maatregelen treffen bij het bepalen van verwerkingsmiddelen en gedurende de verwerking zelf. Dit betekent dat dataminimalisatie, pseudonimisering en versleuteling in de architectuur moeten zijn ingebouwd, niet achteraf als aanvulling. Onder artikel 25(2) moet u ervoor zorgen dat standaard alleen de persoonsgegevens worden verwerkt die nodig zijn voor elk specifiek doel, en dat de hoeveelheid verzamelde gegevens, verwerkingsomvang, bewaartermijn en toegankelijkheid worden beperkt.

Het verschil is cruciaal. Een systeem kan sterke versleuteling gebruiken en toch niet voldoen aan artikel 25(2) als optionele velden zijn ingeschakeld, bewaring geen gedefinieerd doel heeft, of gegevens meer mensen bereiken dan nodig is. Een restrictieve interface kan een architectuur niet corrigeren die duidelijke identificatiegegevens naar een externe dienst stuurt. Deze afwegingen moeten zichtbaar zijn in configuratiebasislijnen, implementatiecontroles en uitzonderingsgoedkeuringen.

Welke vier factoren bepalen welke waarborgen u moet kiezen?

Artikel 25 vereist niet één architectuur voor elke verwerkingsverantwoordelijke. Het vereist een gedocumenteerde keuze op basis van vier factoren: de stand van de techniek, de implementatiekosten, de aard, omvang, context en doeleinden van de verwerking, en de risico's voor de rechten en vrijheden van personen.

De stand van de techniek betekent het identificeren van technische en organisatorische maatregelen die redelijkerwijs beschikbaar zijn voor uw verwerking, in plaats van de nieuwste functie van een leverancier te accepteren. Versleuteling, tokenisatie, segmentatie, toegangsbeperkingen, privacytests en gecontroleerde verwijdering kunnen allemaal relevant zijn. Uw ontwerpdossier moet uitleggen welke waarborgen u hebt geselecteerd, waarom zij bij uw verwerking passen en wat bouwers, leveranciers of implementatieteams moeten uitvoeren.

Kosten ondersteunen proportionaliteit, niet een algemene vrijstelling. U moet de implementatie-inspanning, operationele beperkingen, overwogen alternatieven en de reden voor uw gekozen controle vastleggen. Een beperkt budget maakt een voorzienbaar risico met grote impact niet aanvaardbaar. De resulterende beslissing moet zichtbaar zijn in goedkeuringsdocumentatie, inkoopdocumenten of een uitzonderingslog.

Arde, omvang, context en doeleinden bepalen welk probleem uw controles moeten aanpakken. Een vertrouwelijke juridische workflow, een systeem voor werknemersmonitoring en een openbaar contactformulier omvatten verschillende gegevens, betrokken personen, ontvangers, doeleinden en bedrijfsomstandigheden. Die details moeten verschijnen in uw verwerkingsbeschrijving, systeemontwerp, data-flow-kaart en leveranciersconfiguratie.

Risico's voor rechten en vrijheden hebben meer nodig dan een generiek dreigingslabel. Uw analyse moet mogelijke schade aan identificeerbare personen beschrijven, de waarschijnlijkheid en ernst beoordelen en elk risico koppelen aan een waarborg. U moet ook vastleggen wie een eventueel restrisico heeft aanvaard en wanneer die beslissing opnieuw moet worden bekeken.

Welke vier controlevlakken bepalen hoe u artikel 25(2) implementeert?

• Verzameling — formulieren en invoerinterfaces moeten een onderbouwing van noodzaak op veldniveau hebben; velden zonder vastgelegd doel moeten standaard worden weggelaten.
• Verwerkingsomvang — regels moeten attributen verwijderen of onderdrukken die de volgende bewerking niet nodig heeft; transformatieregels, testcases en resulterende payloads moeten kunnen worden beoordeeld.
• Bewaring — afdwingbare schema's moeten het doel identificeren, de gebeurtenis die de termijn start, het verantwoordelijke systeem en bewijs dat de regel is uitgevoerd.
• Toegankelijkheid — op rollen gebaseerde scopes, tenant-isolatie, goedkeuringspoorten en beperkte exports moeten voorkomen dat persoonsgegevens voor een onbepaald publiek beschikbaar komen.

Hoe implementeert u pseudonimisering als architectuur voor risicovermindering?

Pseudonimisering is geen omzetting van persoonsgegevens in anonieme gegevens. Het is een architectuur voor risicovermindering waarvan de bescherming afhangt van het beheersen van de informatie die omkering mogelijk maakt. Gepseudonimiseerde gegevens blijven persoonsgegevens wanneer afzonderlijk bewaarde informatie heridentificatie kan ondersteunen.

1. Vervang identificatoren door tokens — documenteer wat wordt vervangen, hoe botsingen worden afgehandeld en of de transformatie koppelbaarheid tussen gebeurtenissen behoudt.
2. Isoleer mappinggegevens fysiek of logisch — bewaar omkeringsinformatie gescheiden van de operationele dataset, met netwerksegmentatie waar passend.
3. Stel afzonderlijke toegangscontroles in — medewerkers of diensten die de mapping kunnen gebruiken moeten beperkte, geauthenticeerde toegang hebben met monitoring die losstaat van gewone toegang.
4. Documenteer heridentificatielimieten — test wanneer omkering is toegestaan, wie dit autoriseert, welke logging vereist is en hoe het koppelingsrisico opnieuw wordt beoordeeld na systeemwijzigingen.
5. Beveilig mappingmateriaal met encryptie — bepaal echter niet alleen wie het mag ontsleutelen, maar ook onder welke voorwaarden.
6. Behoud vier inspecteerbare artefacten — vervangingslogica, opslagtopologie, toegangsreviews en resultaten van heridentificatietests.

Hoe verdeelt u verantwoordelijkheid in een gedeelde architectuur?

Moderne verwerking bevindt zich zelden binnen de architectuur van één organisatie. Softwarebouwers creëren de applicatie, SaaS-leveranciers beheren componenten, modelaanbieders verzorgen inferentie of logging, en implementatieteams configureren integraties. U blijft verantwoordelijk voor uw verwerkingsbeslissingen, maar beheert mogelijk niet elke technische laag die het resultaat beïnvloedt.

Een leverancier kan privacy-instellingen aanbieden zonder restrictieve standaardinstellingen configureerbaar of persistent te maken. Een AI-aanbieder kan prompts of outputs bewaren in operationele logs onder voorwaarden die uw implementatieteam niet heeft onderzocht. Een integratielaag kan volledige records doorgeven aan een downstream-dienst omdat er geen lokale filtering plaatsvindt vóór de API-aanroep. Elke leemte kan artikel 25(2) ondermijnen.

Een praktische controlematrix moet elke waarborg aan een eigenaar toewijzen en het bewijs benoemen dat met de implementatie meereist. Dat bewijs kan geëxporteerde beleidsregels, configuratiesnapshots, leveranciersvoorwaarden, toegangslogs en testresultaten omvatten. In een gedeelde architectuur is documentatie geen administratief residu. Het is de manier waarop u aantoont welke partij elke privacyrelevante beslissing heeft genomen.

Functies voor gegevensbescherming, semantische filtering en lokale pseudonimisering kunnen het verzamelen van bewijs ondersteunen, maar zij vervangen niet uw juridische beoordeling van de verwerking, uw due diligence van leveranciers of uw professionele oordeel over welke risico's aanvaardbaar zijn. Inspecteerbaar bewijs vermindert de onzekerheid tijdens toezicht, maar u blijft verantwoordelijk voor het rechtmatig maken van uw keuzes.