Beschermen, bewaren en bewijzen
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 6 van 6 in het hoofdstuk Datakwaliteit en governance, hoofdstuk 5 van de cursus Data Architect. Elke module staat op zichzelf. Vorige: Toestemming en het recht om vergeten te worden · Volgende: het volgende hoofdstuk, Stamgegevens en identiteit
De vraag die deze module beantwoordt: Hoe bescherm je data, bewaar je haar zo lang als nodig is, en bewijs je het?
We hebben eigenaren en beleid vastgesteld, slechte data buiten gehouden, het woordenboek geschreven, herkomst getraceerd, geclassificeerd wat ertoe doet, de wetten geleerd en toestemming gemodelleerd. Nu moeten we het draaien. Data komt binnen, wordt gebruikt, gekopieerd en gewijzigd, veroudert, en uiteindelijk moet een deel ervan weg. En ooit zal iemand vragen: bewijs wat er gebeurde.
Governance volgt de data
Section titled “Governance volgt de data ”Ik zie governance niet als één functie. Ik denk na over wat er met de data gebeurt vanaf het moment dat ze binnenkomt tot we klaar met haar zijn:
Vastleggen → Classificeren → Beschermen → Gebruiken → Bewaren → Verwijderen → Auditen
Geen zeven technische processen: zeven vragen die de architectuur moet beantwoorden. Vastleggen en classificeren hebben we behandeld: houd de dure fouten buiten (module 2), en weet welke data gevoelig is (module 3). De classificatie bepaalt wat er in elke latere fase gebeurt, dus deze module gaat vanaf daar verder.
Zeven vragen over het leven van de data. Tools ondersteunen het beleid; ze bepalen het niet.
Beschermen: stem de controle af op de data
Section titled “Beschermen: stem de controle af op de data ”Wie mag het zien, wijzigen, ontvangen? Moet het versleuteld worden, buiten productie gemaskeerd, exporteerbaar zijn, bereikbaar voor een agent? Hier wordt Salesforce-beveiliging deel van datagovernance: sharing, object- en veldrechten, versleuteling, maskering, integratietoegang. Die onderwerpen vullen hele cursussen, dus ik leg ze niet opnieuw uit. Het governancepunt: bescherming volgt de classificatie en het beleid. Niet elk veld heeft dezelfde bescherming nodig, niet elke gebruiker dezelfde toegang, niet elk downstream systeem elk veld.
Versleuteling is een controle, geen compliance
Section titled “Versleuteling is een controle, geen compliance ”Voor gereguleerde data kan versleuteling van opgeslagen data vereist zijn, en mijn standpunt is dat Shield het antwoord is op belangrijke wettelijke eisen zoals deze. Shield Platform Encryption versleutelt opgeslagen velden en bestanden. Maar “we hebben het versleuteld, dus we zijn compliant” is twee keer fout. Versleuteling is één controle naast toegang, bewaren, audit, toestemming, monitoring, minimalisatie en verwijdering. En ze heeft functionele afwegingen waarvoor je vooraf ontwerpt. Met het standaard probabilistische schema kan een versleuteld veld niet gebruikt worden in SOQL-clausules WHERE, GROUP BY of ORDER BY of in filters voor databeheer; deterministische versleuteling levert een beetje sterkte in zodat je op het veld kunt filteren. Versleutelde velden kunnen geen criteriagebaseerde deelregels sturen, en je kunt lijstweergaven er niet op sorteren (General Shield Platform Encryption Considerations (opens in a new tab); Filter Encrypted Data with Deterministic Encryption (opens in a new tab)). Dus versleuteling is geen vinkje aan het eind. Het is een architectuurbeslissing. Het hoofdstuk over databeveiliging gaat dieper.
Kopieer het risico van productie niet naar de sandbox
Section titled “Kopieer het risico van productie niet naar de sandbox ”Productie is afgesloten. Dan ververst iemand een full sandbox, en developers, testers, externe krachten en testintegraties hebben nu kopieën van echte persoonsgegevens die ze nooit nodig hadden. De omgeving veranderde; de gevoeligheid van de data niet. De maskeringstools van Salesforce bestaan precies hiervoor. Let op een wijziging: het managed package Data Mask bereikt het einde van zijn ondersteuning op 31 december 2026, en de opvolger is Data Mask & Seed (Data Mask (Legacy) (opens in a new tab)). Maar de tool ondersteunt het beleid, en de vraag komt eerst: heeft deze omgeving überhaupt echte gevoelige data nodig? Als realistische, niet-gevoelige data het testen kan doen, is dat het betere antwoord.
Gebruiken: toestemming gaat niet alleen over mensen
Section titled “Gebruiken: toestemming gaat niet alleen over mensen ”Gebruikers, integraties, analytics, partners, automatisering en agents gebruiken allemaal de data. Toestemming (module 5), eigenaarschap (module 1) en classificatie (module 3) komen hier tijdens runtime samen. Moet deze gebruiker het telefoonnummer van de ontvanger zien? Moet deze integratie het krijgen, of Snowflake, of deze agent als grounding? Het antwoord kan niet zijn “nou, technisch gezien kan het.” Dat is het verschil tussen mogelijkheid en governance: architectuur beslist of het zou moeten.
Bewaren: alles voor altijd bewaren is niet neutraal
Section titled “Bewaren: alles voor altijd bewaren is niet neutraal ”Veel organisaties hebben een toevallig bewaarbeleid: voor altijd. Niemand besloot het; er was opslag, dus de data bleef. Maar data bewaren kost opslag en prestaties, vergroot de blootstelling voor privacy en beveiliging, voegt verplichtingen toe bij juridische onderzoeken, en geeft je meer plekken om te doorzoeken als iemand vraagt om vergeten te worden. Voor elke belangrijke categorie: waarom bewaren, hoe lang, wat start de klok, is er een wettelijk minimum of een privacymaximum, en wat gebeurt er aan het eind: archiveren, verwijderen, de-identificeren?
En archiveren is niet hetzelfde als het bewaarvraagstuk oplossen. “We hebben het gearchiveerd.” Is de bewaareis weggegaan? De privacy-eis? Beveiliging? Je hebt veranderd waar de data staat, niet wat ze is. Een archief heeft toegangscontroles nodig, bewaar- en verwijderregels, doorzoekbaarheid en audit. Verplaats persoonsgegevens naar een archief dat iedereen vergeet, en governance is net slechter geworden.
Verwijderen: de levenscyclus heeft een uitgang nodig
Section titled “Verwijderen: de levenscyclus heeft een uitgang nodig ”Verwijderen is niet alleen voor individuele privacyverzoeken. Data bereikt het einde van haar bewaartermijn; tijdelijke records leven langer dan hun nut; archieven verlopen; een proces de-identificeert na een vaste tijd. Wat het beleid ook zegt, de architectuur heeft een uitgang nodig, niet vastleggen → opslaan → meer opslaan → voor altijd opslaan. En zoals module 5 liet zien, is het Salesforce-record verwijderen niet genoeg als er elders kopieën staan.
Historie is ook data
Section titled “Historie is ook data ”Soms is de huidige waarde niet genoeg. De juridische naam van een partner, de indeling van een klant, een toestemmingsstatus, een financieel attribuut: het bedrijf of een toezichthouder moet misschien weten wat het eerst was, wanneer het veranderde en wie het veranderde. Die historie is data, en ze heeft een eigen bewaarbeslissing nodig.
Standaard veldhistorie (field history tracking) volgt tot 20 velden per object en bewaart wijzigingen tot 18 maanden, en tot 24 maanden alleen via de API, met Data Loader of queryAll() (Field History Tracking Overview (opens in a new tab)). En voor lange tekstvelden legt ze alleen vast dat het veld bewerkt is, niet wat erin stond: een gat als dat je bewijs is. Field Audit Trail, deel van Shield of los te koop, volgt tot 200 velden per object en bewaart de historie tot je haar verwijdert, in een archief dat je via de API bereikt (Field Audit Trail (opens in a new tab)). Mijn standpunt: standaardveldhistorie is de standaard; gebruik Field Audit Trail als een regel of complianceverplichting langere, aantoonbare historie vraagt. Niet omdat “audit goed klinkt”.
Auditen en monitoren zijn niet hetzelfde
Section titled “Auditen en monitoren zijn niet hetzelfde ”Veldhistorie beantwoordt vragen over wijzigingen aan geselecteerde velden. Bredere vragen (wie logde in, wie exporteerde data, welke API’s werden aangeroepen, wie bekeek wat) zijn monitoring, en dat is Event Monitoring. In mijn ervaring is het meestal nodig bij meer gereguleerde klanten, en dit is mijn sterkste standpunt in dit hoofdstuk: zet het op voordat je het nodig hebt, en leid de events vooraf naar een opslagplaats, zoals Splunk of een andere SIEM.
Dit is waarom. Eventlogbestanden worden zonder de add-on 1 dag bewaard, en dan alleen voor sommige eventtypes; standaard 30 dagen met Shield of de add-on Event Monitoring, en tot 365 dagen als je het bewaren verlengt (Event Monitoring FAQ (opens in a new tab)). Alles wat ouder is, is weg, tenzij je het geëxporteerd hebt. En de betaalde logs kunnen niet opgehaald worden voor een periode vóór de start van je contract (dezelfde FAQ): de add-on kopen na het incident haalt het verleden niet terug. Dus een van de ergste gesprekken die een architect kan hebben gaat zo: “Kunnen we zien wat er zes maanden geleden gebeurde?” “Nee.” “Waarom niet?” “We legden het niet vast.” Je wilt niet tegen een probleem aanlopen en dan ontdekken dat je die events niet vastgelegd en opgeslagen hebt. Dan is het antwoord gewoon weg.
Richt het in voordat je het nodig hebt.
Maar sla niet door naar “log alles”. Wat probeer je te bewijzen? Welke events doen ertoe, wie heeft ze nodig, hoe lang, wie mag de logs lezen, en kunnen de logs zelf gevoelige data bevatten? Loggen maakt data, en die data heeft ook governance nodig. En bewijs heeft een eigenaar nodig: wie is eigenaar van de opslagplaats, bekijkt meldingen, controleert of bewaren werkt, merkt dat de feed drie maanden geleden stilletjes ophield? Technologie zonder eigenaarschap is geen governance; we zijn terug bij de eigenaar, steward en beheerder van module 1.
Bewijs de controle, niet alleen de configuratie
Section titled “Bewijs de controle, niet alleen de configuratie ”“Ontvangerdata is alleen beschikbaar voor de ploegen die aan de stop toegewezen zijn.” Hoe weten we dat? De beveiligingsconfiguratie laat zien wat er zou moeten gebeuren. Operationeel bewijs (wie het echt inzag, ongewone exports, een integratie die het ophaalt, gewijzigde toegangscontroles) laat zien wat er gebeurd is. Goede governance heeft vaak allebei nodig.
Voorbij het examen: wat AI verandert. Als agents van antwoorden naar handelen gaan, heeft governance bewijs nodig van wat de agent zag, wat hij besloot of genereerde, en wat hij deed, en wie of wat hem startte, onder welk beleid. De logmechanismen zullen veranderen; de eis niet: als een autonome actie ertoe doet, ontwerp dan nu hoe je haar later reconstrueert.
Steve Trucking: de levenscyclus op één veld
Section titled “Steve Trucking: de levenscyclus op één veld ”Neem het telefoonnummer van de ontvanger. Vastleggen: het komt binnen op de vrachtlijst van de partner; controleer of het bruikbaar is waar het proces het nodig heeft. Classificeren: persoonsgegeven. Beschermen: alleen mensen en systemen met een operationele noodzaak ontvangen het, en ploegen zien het alleen voor hun eigen stops, op die dag. Gebruiken: de ploeg stemt de levering af; messaging gebruikt het voor een goedgekeurd doel; een agent gebruikt het alleen als het beleid dat toestaat. Bewaren: zo lang als het goedgekeurde bedrijfs- en privacybeleid zegt. Verwijderen of de-identificeren: als die periode afloopt of er een geldig verzoek binnenkomt, in elke kopie in het landschap. Auditen: bewaar het bewijs dat de controles en acties plaatsvonden.
Neem nu een code van een distributiecentrum. Leg haar nauwkeurig vast, classificeer haar als niet-gevoelige referentiedata, bescherm haar met gewone operationele toegang, gebruik haar breed, bewaar haar zoals het bedrijf nodig heeft, en audit wijzigingen als ze ertoe doen. Dezelfde levenscyclus, andere controles. Daar is classificatie voor.
Governance is nooit af
Section titled “Governance is nooit af ”Er komt een nieuwe regel. Een nieuw systeem of een nieuwe integratie maakt nog een kopie. Een team verzint nog een veld. Een nieuw platform gaat live. Een agent krijgt toegang. Een bewaarregel verandert. Er komt een nieuwe retailpartner. De architectuur beweegt, en governance beweegt mee. Het doel is geen perfecte data, eindeloze controles of een governancedocument dat niemand leest. Het zijn bewuste beslissingen over de data, ingebouwd in de architectuur.
Wat een architect hier beslist
Section titled “Wat een architect hier beslist ”- Welke beschermingscontroles elke categorie data krijgt, op basis van classificatie, beleid en echt gebruik, inclusief de afwegingen van versleuteling.
- Hoe lang data en haar historie bewaard worden, wat de klok start, en wat er aan het eind gebeurt.
- Wanneer standaardveldhistorie genoeg is en wanneer een regel om Field Audit Trail vraagt.
- Welke events vastgelegd worden, waar het bewijs opgeslagen wordt voorbij de bewaartermijn van het platform, en wie er eigenaar van is.
- Hoe de architectuur belangrijke acties van mensen, integraties en agents achteraf bewijst.
Dit hoofdstuk begon met één idee: governance wordt in de org ontworpen, niet ernaast geschreven. Eigenaren bepalen het beleid en architecten dwingen het af. Houd slechte data buiten waar het ertoe doet. Weet wat je data betekent, waar ze vandaan komt en hoe gevoelig ze is. Respecteer de wetten, modelleer toestemming, controleer waar persoonsgegevens heen gaan. Bescherm, bewaar en verwijder volgens beleid. En leg het bewijs vast voordat iemand erom vraagt, want zes maanden na een incident is een vreselijk moment om te ontdekken dat het bewijs maar dertig dagen bestond.
Verder lezen
Section titled “Verder lezen ”- Salesforce Help, General Shield Platform Encryption Considerations (opens in a new tab) en Filter Encrypted Data with Deterministic Encryption (opens in a new tab) (Engels, gecontroleerd op 2026-10-14).
- Salesforce Help, Field History Tracking Overview (opens in a new tab) (Engels, gecontroleerd op 2026-10-14).
- Salesforce Help, Field Audit Trail (opens in a new tab) (Engels, gecontroleerd op 2026-10-14).
- Salesforce Help, Salesforce Event Monitoring Frequently Asked Questions (opens in a new tab) (Engels, gecontroleerd op 2026-10-14).
- Salesforce Help, Secure Your Sandbox Data with Salesforce Data Mask (Legacy) (opens in a new tab) (Engels, gecontroleerd op 2026-10-14).