Privacy bepaalt waarom persoonsgegevens worden verzameld, gebruikt en bewaard; security bepaalt vooral hoe die gegevens worden beschermd. Security wil gegevens beschermen tegen ongeoorloofde toegang of verlies; privacy vraagt eerst of die gegevens wel nodig zijn, waarvoor ze worden gebruikt, hoelang ze blijven bestaan en welke rechten betrokkenen daarover hebben.
Die nuance is belangrijk voor Belgische en Europese organisaties die met persoonsgegevens werken. Een dataset kan sterk versleuteld zijn, achter degelijke IAM-controles zitten en toch problematisch blijven als de verwerking geen duidelijke grondslag heeft, te ruim is opgezet of langer loopt dan nodig. Privacy-slim zijn betekent daarom meer dan weten wat de GDPR is. Het betekent dat juridische principes, technische architectuur en dagelijkse productbeslissingen elkaar versterken.
Een korte zelftest voor privacyvaardigheid
Een goede privacyzelftest begint niet met definities, maar met keuzes. Neem een nieuwe feature die klantgedrag analyseert, een datawarehouse met verkoopgegevens of een HR-tool die buiten de EU wordt gehost. De vraag is niet alleen of de omgeving veilig is, maar ook of het doel scherp genoeg is, of minder data volstaat, of betrokkenen correct geïnformeerd worden en of de verwerking in het register van verwerkingsactiviteiten past.
De volgende scenario’s geven een snelle indicatie van privacyvolwassenheid. Ze zijn geen juridisch advies en vervangen geen beoordeling door de DPO, juridische dienst of bevoegde verantwoordelijke. Ze helpen wel om te zien waar privacykennis in de dagelijkse praktijk standhoudt en waar ze vooral theoretisch blijft.
- Scenario 1: Een productteam wil alle interacties van gebruikers onbeperkt bewaren voor toekomstige analyse. Een privacy-slim antwoord onderzoekt doelbinding, dataminimalisatie en retentie vóór de logging technisch wordt uitgebreid.
- Scenario 2: Een leverancier biedt een AI-functie aan waarbij persoonsgegevens buiten de EU kunnen worden verwerkt. Een volwassen aanpak kijkt naar verwerkersafspraken, doorgifte-instrumenten zoals SCC’s, aanvullende maatregelen en de feitelijke toegang tot data.
- Scenario 3: Een marketingteam wil toestemming gebruiken voor bijna elke verwerking. Privacykennis betekent herkennen wanneer toestemming niet vrij, specifiek of praktisch beheersbaar is, en wanneer een andere grondslag onderzocht moet worden.
- Scenario 4: Een organisatie voert een DPIA pas uit wanneer de applicatie bijna live gaat. Dat is meestal te laat om ontwerpkeuzes nog zonder hoge kosten aan te passen.
Wie in deze scenario’s vooral aan encryptie, firewalls of toegangsrechten denkt, heeft een degelijk securityreflex. Wie daarnaast vraagt welke data noodzakelijk is, wie verwerkingsverantwoordelijke is, welke rechten betrokkenen hebben en welke documentatie nodig is, denkt privacygerichter. In de praktijk is precies die combinatie waardevol.
Privacy en security werken samen, maar lossen elkaars problemen niet automatisch op
Securitymaatregelen zijn essentieel voor GDPR-naleving, maar ze kunnen een buitensporige of onduidelijke verwerking niet rechtzetten. Een bedrijf kan bijvoorbeeld sterke versleuteling toepassen op gedetailleerde gedragsdata, maar als het doel te vaag is of de bewaartermijn onbeperkt blijft, is het privacyprobleem niet opgelost. Omgekeerd is een dataminimalisatiebeslissing weinig waard als de resterende gegevens slecht beveiligd zijn.
Dat verschil komt vaak naar boven bij logging. Securityteams willen voldoende logs voor detectie, onderzoek en incidentrespons. Privacyteams willen voorkomen dat logs uitgroeien tot een schaduwdatabank met IP-adressen, gebruikers-ID’s, query’s en gedragsgegevens die veel langer bewaard worden dan het oorspronkelijke systeem. De werkbare oplossing ligt meestal in gerichte logging, pseudonimisering waar passend, duidelijke bewaartermijnen en toegang op basis van rol en noodzaak.
Ook testdata is een terugkerend aandachtspunt. In veel organisaties worden productiedata gekopieerd naar ontwikkel- of acceptatieomgevingen omdat dat snel werkt en realistische testresultaten geeft. Vanuit privacyoogpunt is dat riskant wanneer persoonsgegevens onnodig worden verspreid. Privacy-slimme teams koppelen daarom dataclassificatie aan ontwikkelprocessen, gebruiken gesaniteerde of synthetische testdata waar mogelijk en automatiseren verwijdering wanneer data niet langer nodig is.
De Belgische en Europese context die teams niet mogen overslaan
Voor organisaties in België blijft de GDPR het centrale kader, met de Gegevensbeschermingsautoriteit, ook APD/GBA genoemd, als nationale toezichthouder. Praktisch gezien gaat het vaak om drie terugkerende verplichtingen: het register van verwerkingsactiviteiten, DPIA’s voor verwerkingen met een waarschijnlijk hoog risico, en passende waarborgen bij internationale doorgiften. Deze verplichtingen zijn geen administratieve bijzaak; ze dwingen teams om ontwerpkeuzes expliciet te maken.
Een ROPA, gebaseerd op artikel 30 GDPR, is alleen nuttig als het actueel en concreet genoeg is. Een register dat enkel applicatienamen bevat, maar geen doeleinden, categorieën betrokkenen, bewaartermijnen, ontvangers of doorgiften, helpt weinig bij audits, incidenten of rechtenverzoeken. Het register moet aansluiten op de realiteit van systemen, leveranciers en datastromen.
Een DPIA, onder artikel 35 GDPR, hoort vroeg genoeg te starten om architectuur en procesontwerp te beïnvloeden. Denk aan grootschalige monitoring, gevoelige gegevens, profilering of nieuwe technologie die gevolgen kan hebben voor betrokkenen. Het grootste misverstand is dat een DPIA een formulier is dat aan het einde wordt ingevuld. In een volwassen organisatie is het een besluitvormingsproces dat risico’s zichtbaar maakt voordat ze ingebouwd raken.
Bij doorgiften buiten de EU blijft extra aandacht nodig, vooral wanneer cloudleveranciers, supportteams of subverwerkers toegang kunnen krijgen tot persoonsgegevens. Standaardcontractbepalingen kunnen onderdeel zijn van de oplossing, maar teams moeten ook naar de feitelijke verwerking, toegangsrechten, technische maatregelen en leveranciersketen kijken. Na Schrems II is alleen vertrouwen op een contract vaak onvoldoende als de operationele risico’s niet zijn beoordeeld.
Waar privacykennis vaak tekortschiet
Veel organisaties hebben mensen die de basisbegrippen kennen, maar moeite hebben om ze toe te passen in projecten. Een veelvoorkomende valkuil is te veel leunen op toestemming omdat die bekend klinkt. In werkelijkheid kan toestemming lastig zijn in arbeidsrelaties, gebundelde diensten of situaties waarin intrekken de dienst onwerkbaar maakt. Dan is een grondslaganalyse nodig in plaats van een standaard checkbox.
Een andere zwakke plek is leveranciersbeheer. Een verwerkersovereenkomst is belangrijk, maar zegt weinig als niemand heeft onderzocht welke subverwerkers worden gebruikt, waar data wordt verwerkt, welke logging de leverancier uitvoert of hoe verwijdering na contracteinde werkt. Due diligence moet daarom verder gaan dan contracttaal en ook technische en organisatorische controles omvatten.
Daarnaast wordt privacy vaak te laat gekoppeld aan productontwikkeling. Wanneer privacy pas in de laatste compliance-review verschijnt, zijn keuzes over datamodel, bewaartermijnen, analytics en toegangsrechten al gemaakt. Praktischer is om privacy-eisen zichtbaar te maken in productbacklogs en Definition of Done-afspraken, bijvoorbeeld door dataclassificatie, minimale dataset, retentieregels en rechtenafhandeling per feature te beoordelen.
Van kennis naar werkbare gewoonten
Privacyvolwassenheid groeit wanneer teams terugkerende routines ontwikkelen. Een kwartaalreview van het ROPA, een vroege DPIA-triage bij nieuwe initiatieven en een vaste privacycheck bij leveranciersselectie zijn vaak nuttiger dan een eenmalige bewustmakingssessie. Het doel is dat privacyvragen op het juiste moment worden gesteld, door mensen die dicht bij de systemen en processen staan.
Meten helpt om die routines scherp te houden. Niet elke metric bewijst naleving, maar goede indicatoren tonen of het privacyprogramma werkt. Denk aan de doorlooptijd van inzage- en verwijderverzoeken, het aandeel nieuwe projecten met DPIA-triage, het aantal features waarbij dataminimalisatie aantoonbaar is besproken, de naleving van retentieregels en het percentage kritieke verwerkers dat opnieuw beoordeeld is. Zulke metingen geven vroeg zicht op risico’s voordat ze als incident of klacht zichtbaar worden.
Ook de arbeidsmarkt beweegt in die richting. Organisaties zoeken steeds vaker T-shaped profielen: engineers en productmanagers die voldoende GDPR begrijpen om betere ontwerpbeslissingen te nemen, en privacyprofessionals die genoeg van data-architectuur begrijpen om technische keuzes realistisch te beoordelen. Een certificaat alleen maakt iemand niet privacy-slim, maar gestructureerde opleiding kan wel helpen wanneer kennis versnipperd is of wanneer teams naar een gemeenschappelijke taal zoeken.
Wanneer formele opleiding zinvol is
Formele training is vooral nuttig wanneer professionals privacykennis moeten toepassen in beslissingen, niet alleen termen willen herkennen. Voor wie twijfelt tussen IAPP-richtingen is een eenvoudig kader bruikbaar: CIPP/E past vooral bij EU-wet- en regelgeving, CIPM bij governance en privacyprogramma’s, en CIPT bij technologische implementatie in IT- en engineeringcontexten. De beste eerste keuze ligt meestal dicht bij de dagelijkse verantwoordelijkheden.
De CIPT-certificering van de IAPP werd oorspronkelijk geïntroduceerd voor professionals die privacy in technologie en operationele processen moeten vertalen. Voor IT-, security-, data- en productteams is dat relevant omdat privacy daar vaak vorm krijgt in logging, identity, analytics, datamodellen, testomgevingen, retentie en deletion workflows. Een Readynez-training rond CIPT kan in dat kader zinvol zijn wanneer een team niet alleen GDPR-begrippen wil leren, maar ze wil oefenen op technische en organisatorische scenario’s.
Een veelgemaakte fout bij voorbereiding is uitsluitend studieteksten doornemen. Kennis blijft sterker hangen wanneer ze wordt gekoppeld aan eigen systemen: maak een mini-ROPA voor één applicatie, schets een DPIA voor een nieuwe feature, beoordeel één verwerker op feitelijke controles en test hoe een verwijderverzoek technisch wordt uitgevoerd. Daardoor wordt duidelijk waar beleid, contracten en architectuur elkaar raken.
Privacy-slimmer worden in de praktijk
De snelste vooruitgang komt meestal uit kleine, consequente verbeteringen. Begin met één product, dataset of proces waar persoonsgegevens een duidelijke rol spelen. Breng het doel, de data, de bewaartermijn, de toegang, de leveranciers en de rechtenafhandeling in kaart. Vergelijk daarna wat op papier staat met wat het systeem werkelijk doet.
Wie hiaten vindt, hoeft niet alles tegelijk te herstellen. Prioriteit hoort te liggen bij verwerkingen met hoge impact, onduidelijke grondslag, gevoelige gegevens, internationale doorgiften, lange bewaartermijnen of veel betrokkenen. Betrek daarbij de DPO of juridische functie, zeker wanneer grondslagen, DPIA-uitkomsten of doorgiften beoordeeld moeten worden.
De kernvraag is dus niet of iemand privacytermen kan uitleggen, maar of die kennis betere beslissingen oplevert in ontwerp, inkoop, beheer en incidentrespons. Readynez kan daarbij een opleidingsroute ondersteunen, maar de echte toets blijft het dagelijkse werk: minder onnodige data, beter gedocumenteerde keuzes, vroegere risicoanalyse en systemen die rechten van betrokkenen uitvoerbaar maken. For a deeper dive, see Guide to Passing AZ-305 Exams and Becoming a Microsoft Certified.
