Privacywetten bepalen het ontwerp
Ook beschikbaar in 28 talen
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Module 4 van 6 in het hoofdstuk Datakwaliteit en governance, hoofdstuk 5 van de cursus Data Architect. Elke module staat op zichzelf. Vorige: Ken je gegevens · Volgende: Toestemming en het recht om vergeten te worden
De vraag die deze module beantwoordt: Wat vragen privacy- en sectorregels van een Salesforce-ontwerp?
Toen ik in Australië werkte, ontmoette ik genoeg aankomende architecten die nog nooit van de GDPR (in het Nederlands de AVG) gehoord hadden. Europeanen hebben vaak nog nooit gehoord van de privacywet van Californië, of die van Canada, of van Brazilië. Dat is logisch: je kent de regels waar je werkt. Maar deze wetten reiken over grenzen heen, en ze bepalen het systeemontwerp, ook al gaat geen enkele over Salesforce. Dus horen ze in een cursus data-architectuur.
Je hoeft geen advocaat te worden. Je moet wel zien dat een regel kan veranderen waar data opgeslagen wordt, wat je verzamelt, wie het ziet, waarom je het mag gebruiken, hoe lang je het bewaart, waar je het heen stuurt, of je het kunt verwijderen, welke historie je bewaart, en wat je later kunt bewijzen. Dat zijn niet alleen juridische vragen. Het zijn data-architectuurvragen.
Deze module is architectuurbegeleiding, geen juridisch advies. Juridische en compliance-teams beslissen welke wetten van toepassing zijn en wat ze vereisen. De architect zet die eisen om in een afdwingbaar ontwerp.
Wetten stoppen niet bij de grens
Section titled “Wetten stoppen niet bij de grens ”Eerst het grootste misverstand: “we zitten niet in Europa, dus de AVG is niet van toepassing.” Misschien, misschien niet. Het territoriale toepassingsgebied van de AVG reikt tot organisaties buiten de EU die goederen of diensten aanbieden aan mensen in de EU, of hun gedrag daar volgen (artikel 3, Verordening (EU) 2016/679 (opens in a new tab)). Dus waar het hoofdkantoor van je bedrijf staat, is niet het einde van de vraag. Waar zijn je klanten, medewerkers, de mensen van wie je data bewaart, je systemen, je verwerkers? Waar reist de data heen? Dat is weer het landschap van hoofdstuk 4. Je kunt geen goede privacybeslissingen nemen zonder te weten waar de data heen gaat.
De regels die je moet herkennen
Section titled “De regels die je moet herkennen ”Dit zijn de namen die een architect moet kennen, met wat elk ervan dekt. Het is een tabel om te herkennen, geen toepasbaarheidsmatrix: lees haar niet en beslis “we hebben klanten in Californië, dus eis X is van toepassing.” Dat is aan Legal. Jouw taak is genoeg weten om de vraag te stellen voordat het systeem gebouwd is.
| Wet of standaard | Waar of wat | Waarom een architect haar moet herkennen |
|---|---|---|
| AVG (GDPR) (opens in a new tab) | Europese Unie | Persoonsgegevens, rechtmatige verwerking, individuele rechten, bewaren, doorgifte, privacy by design |
| CCPA, gewijzigd door de CPRA (opens in a new tab) | Californië | Rechten van consumenten over de persoonlijke informatie die bedrijven over hen verzamelen |
| PIPEDA (opens in a new tab) | Canada | Hoe organisaties in de private sector met persoonlijke informatie omgaan |
| LGPD (opens in a new tab) | Brazilië | De algemene wet van Brazilië voor de bescherming van persoonsgegevens |
| Privacy Act 1988 (opens in a new tab) | Australië | Hoe organisaties met persoonlijke informatie omgaan, volgens de Australian Privacy Principles |
| HIPAA (opens in a new tab) | Amerikaanse zorg | Beschermde gezondheidsinformatie in de situaties die eronder vallen |
| PCI DSS (opens in a new tab) | Betaalkaarten | Bescherming van rekeninggegevens van betaalkaarten |
| Sarbanes-Oxley (SOX) (opens in a new tab) | Amerikaanse beursgenoteerde bedrijven | Controles en bewijs achter financiële verslaggeving |
| COPPA (opens in a new tab) | VS, kinderen online | Persoonlijke informatie die online van kinderen verzameld wordt |
De lijst groeit (meer Amerikaanse staten hebben eigen wetten), en de wetten veranderen. Daarom wil ik niet dat je een tabel uit je hoofd leert en denkt dat je privacyarchitectuur geleerd hebt. Leer de namen, en leer dan de vragen die ze overleven.
Wat de wetten gemeen hebben
Section titled “Wat de wetten gemeen hebben ”De details verschillen, maar de grote privacywetten komen steeds terug op dezelfde paar dingen, en elk ervan komt op de architectuur terecht.
Rechten. Mensen kunnen vragen hun data in te zien, te corrigeren, te verwijderen en mee te nemen; onder de wetten van Californië en Brazilië kunnen ze ook bezwaar maken tegen de verkoop ervan (opt-out). Elk van die verzoeken betekent dat je de data van de persoon moet vinden, alles ervan.
Doorgifte. De AVG en de LGPD controleren persoonsgegevens die hun rechtsgebied verlaten en vragen om passende bescherming waar die heen gaan; PIPEDA verwacht hetzelfde beschermingsniveau als een derde partij de data verwerkt, waar die ook is. Dat is weer het landschap: welke pijlen steken een grens over?
Melding van datalekken. Als persoonsgegevens blootgesteld worden, verwachten de wetten dat je de autoriteiten inlicht, en soms de betrokken mensen, binnen een termijn die per wet verschilt. Je kunt geen melding doen over data waarvan je niet wist dat je die had, of zeggen wat er blootgesteld is als je de kopieën niet kunt vinden.
Verantwoordingsplicht. Je moet compliance kunnen aantonen: registers van wat je verwerkt en waarom, effectbeoordelingen voor verwerking met een hoog risico, en, onder de AVG en de LGPD, een functionaris voor gegevensbescherming. De architectuur moet die registers opleveren.
Begin bij wat persoonlijk is
Section titled “Begin bij wat persoonlijk is ”Voordat je persoonlijke informatie beschermt, moet je haar vinden. Sommige is duidelijk: naam, huisadres, telefoon, e-mail. Sommige niet: locatie, apparaat-ID’s, IP-adressen, afbeeldingen, gedragsdata, alles wat terug te koppelen is aan een persoon. En context doet ertoe. Een levering van Steve Trucking bevat de naam, het adres, het telefoonnummer, leveringsnotities en foto’s van de ontvanger. Een foto kan een doos op een veranda laten zien, of een persoon, of de binnenkant van een huis. De levering is operationele data, maar sommige attributen ervan zijn persoonlijk. Daarom classificeerde module 3 velden: privacy begint met weten wat je hebt.
Waar staat het?
Section titled “Waar staat het? ”“Salesforce.” Waarschijnlijk niet alleen Salesforce. Kwam het van een retailpartner? Is het naar Snowflake gekopieerd, door Data 360 opgenomen, in een integratielog geschreven, door een gebruiker geëxporteerd, achtergebleven in veldhistorie, gearchiveerd, naar een sandbox gekopieerd, aan een partner doorgegeven, gebruikt in een gesprek met een agent? Persoonsgegevens verspreiden zich. Dus als Legal vraagt “waar bewaren we de informatie van deze persoon?”, is “we weten waar de huidige waarde staat” geen antwoord. Ik wil het landschap en de herkomst: waar de kopieën heen gingen.
Eén telefoonnummer, veel kopieën. Privacy geldt ook voor de kopieën.
Waarom mag je het gebruiken?
Section titled “Waarom mag je het gebruiken? ”Data hebben en haar mogen gebruiken is niet hetzelfde. Steve Trucking heeft het telefoonnummer van een ontvanger om de levering van vandaag af te stemmen. Maakt dat het een marketinglijst? Nee. De rechtsgrond hangt af van het rechtsgebied en de situatie, en Legal begeleidt dat, maar de architectuur moet het antwoord dragen: waarom het verzameld is, welk gebruik toegestaan is, of toestemming nodig was, gegeven, ingetrokken, en voor welk kanaal, adres en doel. Toestemming om data te gebruiken moet als data weer te geven zijn, want een beleidsdocument kan tijdens runtime geen beslissing nemen. De volgende module modelleert het.
Minder verzamelen is een architectuurbeslissing
Section titled “Minder verzamelen is een architectuurbeslissing ”Een van de sterkste privacycontroles is de data niet verzamelen, of haar niet kopiëren waar ze niet nodig is. Heeft Snowflake het telefoonnummer van de ontvanger nodig? Heeft analytics het volledige straatadres nodig? Heeft de sandbox echte leveringsfoto’s nodig? Heeft een agent de persoonlijke gegevens van de ontvanger nodig om deze vraag te beantwoorden? Zo niet, dan is de sterkste controle misschien ze daar niet neerzetten. Elke kopie die je niet maakt, hoef je niet te beveiligen, te bewaren, te verwijderen, toestemming voor bij te houden, te auditen of te melden bij een datalek. De goedkoopste gevoelige data om te besturen is de data die je nooit gekopieerd hebt.
Bewaren hoort bij het model
Section titled “Bewaren hoort bij het model ”“We bewaren voorlopig alles” is een bewaarbeleid. Alleen een slecht. Voor belangrijke data wil ik bij het ontwerp weten hoe lang we haar nodig hebben en waarom; of een regel een minimum stelt of een andere een maximum; wanneer de klok begint; en wat er aan het eind gebeurt: verwijderen, archiveren, de-identificeren, en waar zijn de kopieën? Financiële administratie moet misschien een vaste periode bewaard blijven. De toegangscode van een ontvanger heeft jaren na de levering geen doel meer. Die beslissingen wachten niet tot de database groot is.
Geanonimiseerd, gepseudonimiseerd, versleuteld, gemaskeerd
Section titled “Geanonimiseerd, gepseudonimiseerd, versleuteld, gemaskeerd ”Vervang “Jane Smith” door 7F92A1. Is Jane geanonimiseerd? Niet als een andere tabel nog zegt 7F92A1 = Jane Smith. Dat is pseudonimisering: de directe identificator is vervangen, maar de data kan opnieuw gekoppeld worden met informatie die apart bewaard wordt, en onder de AVG zijn gepseudonimiseerde gegevens nog steeds persoonsgegevens (artikel 4, punt 5). Anonimisering gaat verder: de data kan redelijkerwijs niet meer aan de persoon gekoppeld worden (overweging 26). Dus als iemand zegt “we hoeven het niet te verwijderen, we halen alleen de naam weg”, wees dan voorzichtig. Als de persoon nog redelijkerwijs te identificeren is, ben je die grens niet overgestoken. Of een resultaat aan de wet voldoet, is aan Legal; de taak van de architect is precies zeggen wat het systeem doet: kan het opnieuw gekoppeld worden, welke sleutels blijven er over, waar staan de mappings?
Gebruik de woorden precies, want ze lossen verschillende problemen op. Versleuteling beschermt data tegen onbevoegde openbaarmaking; een bevoegde gebruiker kan haar nog ontsleutelen. Maskering verandert wat bepaalde gebruikers of omgevingen zien. Pseudonimisering scheidt de directe identiteit, maar houdt een weg terug. Anonimisering haalt het redelijke vermogen weg om de persoon te identificeren. Alleen de laatste haalt data uit “persoonlijk”.
Regelgeving wordt eisen
Section titled “Regelgeving wordt eisen ”Legal hoeft me niet te vertellen dat ik een machtigingenset moet maken; dat is mijn kant van de lijn. Legal zegt misschien “alleen medewerkers met een legitieme zakelijke noodzaak mogen deze categorie persoonlijke informatie inzien.” Dan vertaal ik: wie zijn dat, hoe herkennen we de categorie, hoe wordt toegang verleend, wat gebeurt er als iemand van functie wisselt, mag een integratie het lezen, mag een agent het, mag het geëxporteerd worden, en hoe bewijzen we wie het zag? Eigenaren bepalen het beleid; architecten dwingen het af. Juridische zaken en compliance stellen de verplichting vast, data-eigenaren bepalen het bedrijfsbeleid, en de architect ontwerpt de handhaving.
Van regelgeving naar bewijs: Legal interpreteert, de eigenaar bepaalt het beleid, de architect laat het werken en maakt het bewijsbaar.
En compliance is geen product. Je kunt geen “compliance: aan” kopen. Versleuteling kan een eis ondersteunen, auditfuncties leveren bewijs, bewaartools voeren beleid uit, toestemmingsdata ondersteunt toegestaan gebruik, maar een functie licentiëren maakt een architectuur niet compliant. Compliance komt uit het hele ontwerp: mensen, beleid, proces, data, controles en bewijs. Salesforce is er een deel van, niet alles. En als beleid belangrijk genoeg is om af te dwingen, vraag dan of het belangrijk genoeg is om te bewijzen: wie heeft dit record op 17 maart ingezien, wie heeft dit veld gewijzigd, wat zat er in die export? Module 6 behandelt het bewijs.
Privacy verandert het landschap
Section titled “Privacy verandert het landschap ”Bij Steve Trucking komen de persoonsgegevens van de ontvanger binnen via drie partnerintegraties. Salesforce heeft ze nodig om leveringen te draaien; ploegen hebben er een deel van nodig, alleen voor hun eigen stops, alleen op die dag; Snowflake wil leveringsanalytics; finance heeft genoeg nodig om te factureren, maar niet wat de ploeg ziet. En de ene retailpartner mag nooit de ontvangers van een andere zien. Privacy verandert de pijlen: bepaalde velden gaan niet naar Snowflake, analytics krijgt een minder identificeerbare versie, ploegen zien alleen hun stops, het bewaren verderop verschilt van het operationele bewaren. De privacy-eis staat niet naast het landschapsdiagram. Hij verandert het.
Vragen die de regels overleven
Section titled “Vragen die de regels overleven ”Regels veranderen, dus neem een duurzame set vragen mee voor alle gevoelige of gereguleerde data:
- Wat is het? Persoonlijk, gevoelig, financieel, gezondheid, betaling, van kinderen of anderszins gereguleerd?
- Waar staat het? Elke kopie: integraties, historie, analytics, archieven, sandboxes, logs, AI-gebruik.
- Waarom mogen we het gebruiken? Welk doel en welke rechtsgrond gelden? Speelt toestemming een rol?
- Wie mag het gebruiken? Mensen, systemen, partners, integraties, agents.
- Hoe lang bewaren we het, en wat gebeurt er aan het eind?
- Kan de persoon zijn rechten erover uitoefenen? Inzage, correctie, verwijdering, overdraagbaarheid, bezwaar, zoals de wet voorziet.
- Kunnen we bewijzen wat er gebeurde? Toegang, wijzigingen, exports, toestemming, verwijdering, bewaren.
AI-governance wordt wet
Section titled “AI-governance wordt wet ”AI voegt nog een afnemer van bestuurde data toe. Mag een AI-systeem deze data gebruiken, voor welk doel, als grounding, gecombineerd met wat, herhaald in zijn output, gelogd waar, voor hoe lang? Governance van AI verschuift van bedrijfsbeleid naar wetgeving: de AI-verordening van de Europese Unie (Verordening (EU) 2024/1689 (opens in a new tab)) is het eerste brede voorbeeld. Wat ze vereist hangt af van het systeem en het gebruik. De richting voor architecten is duidelijk: AI staat niet buiten governance; het is nog een afnemer van bestuurde data.
Wat een architect hier beslist
Section titled “Wat een architect hier beslist ”- Waar gereguleerde of gevoelige data binnenkomt, staat, beweegt en gekopieerd wordt in het landschap.
- Hoe juridisch en compliancebeleid afdwingbare eisen wordt, zonder dat de architect de wet interpreteert.
- Of elk systeem dat gevoelige data ontvangt haar nodig heeft, of dat een minder identificeerbare versie zou volstaan.
- Hoe bewaren, verwijderen, anonimiseren, pseudonimiseren, beschermen en bewijs de levenscyclus van de data vormen.
- Welk bewijs er moet zijn om te laten zien dat de belangrijke controles echt werkten.
Regels worden geen architectuur door hun namen op een slide te zetten. Ze worden architectuur als ze veranderen hoe data verzameld, geclassificeerd, verplaatst, beschermd, bewaard, verwijderd en bewezen wordt.
Verder lezen
Section titled “Verder lezen ”- De officiële bronnen van de regels staan in de tabel hierboven gelinkt (gecontroleerd op 2026-10-14).
- Verordening (EU) 2016/679 (AVG/GDPR) (opens in a new tab): artikel 3 (territoriaal toepassingsgebied), artikel 4, punt 5 (pseudonimisering), overweging 26 (anonieme informatie).
- Verordening (EU) 2024/1689 (de AI-verordening) (opens in a new tab), EUR-Lex.