Uw Salesforce-org voorbereiden op een audit

Kort antwoord: een auditor wil geen rondleiding door uw org. Hij wil drie bewijspakketten: wie toegang had en wie dat goedkeurde, wat er in productie veranderde en wie daarvoor tekende, en hoe lang u gegevens bewaart voordat u ze verwijdert. Zijn die drie exports routine, dan is een audit een vergadering. Zo niet, dan is het twee weken brandblussen.

Wat vraagt een auditor een Salesforce-team echt?

De meeste adviezen over Salesforce-audits beschrijven een interne health check: dode velden, ongebruikte rapporten, opslag opruimen. Nuttig huishoudelijk werk, maar niet wat een externe auditor toetst. Onder SOX, SOC 2 of ISO 27001 nemen zij een steekproef en vragen u een control te bewijzen:

• Toegangsbewijs. Een gebruikerslijst met profielen, permission sets en rollen, plus wie elke toekenning goedkeurde en wanneer die voor het laatst is beoordeeld.
• Wijzigingsbewijs. Voor een steekproef van productiewijzigingen: het verzoek, de goedkeuring, het testresultaat en het deployrecord.
• Bewaar- en verwijderbewijs. Welke persoonsgegevens u hebt, hoe lang u ze bewaart, en bewijs dat verwijderverzoeken zijn uitgevoerd.

Vrijwel elke bevinding die wij zien komt uit een van die drie, niet uit een rommelige page layout.

Wat valt binnen scope, en wie bepaalt dat?

U bepaalt het eerst en verdedigt het daarna. Scope volgt risico, niet het organogram:

• Financiële verslaggeving (SOX): offertes, orders, facturatie, omzetobjecten en elke automatisering die die waarden kan wijzigen, inclusief integratiegebruikers.
• Persoonsgegevens (AVG en vergelijkbaar): Contact, Lead, Case, Person Account, chattranscripties en elke sandboxkopie.
• Verhoogde rechten: Modify All Data, View All Data, Manage Users, Author Apex, en iedereen die kan deployen.

Leg dit vast in een scopememo van een pagina voor de kickoff. Een auditor die de scope voor u moet bepalen, doet dat ruimhartig.

Hoe levert u toegangsbewijs zonder screenshots?

Screenshots verouderen snel en zeggen niets over de andere 51 weken van het jaar. Exporteer in plaats daarvan, volgens een schema:

1. Bevraag de permissieobjecten. PermissionSetAssignment, ObjectPermissions en FieldPermissions geven het echte beeld, inclusief alles wat via permission set groups is toegekend.
2. Exporteer Login History. Salesforce bewaart zes maanden online en laat u die als CSV downloaden. Slapende accounts met actieve rechten zijn de klassieke bevinding.
3. Draai Security Health Check en Optimizer en bewaar de uitkomst. Auditors accepteren een gedateerde zelfbeoordeling als bewijs dat er monitoring is.
4. Doe de review per kwartaal, met een benoemde goedkeurder. Een toegangsreview die niemand tekende is geen control. Leg reviewer, datum en uitzonderingen vast.

Integratiegebruikers verdienen een eigen regel. Zij dragen meestal de ruimste rechten en de minste aandacht, en auditors kijken daar inmiddels als eerste.

Hoe levert u wijzigingsbewijs?

Hier doen change sets pijn. Ze scheiden bouwer en deployer niet en laten geen gekoppelde goedkeuring achter. Een pipeline antwoordt met links: het work item met de zakelijke reden, de commit die precies laat zien welke metadata bewoog, de pull request met een reviewer die niet de auteur is, het testresultaat en het deployrecord.

Twee eigenschappen bepalen of het slaagt. Het bewijs moet onveranderlijk zijn en volledig, dus er bestaat geen route naar productie die eromheen gaat. Een proces dat de meeste wijzigingen dekt zakt alsnog, want de steekproef kan op de uitzondering vallen.

Native historie helpt, maar draagt niet alles. Setup Audit Trail houdt 180 dagen vast en is via het object SetupAuditTrail te bevragen voordat het wordt opgeschoond. Field History Tracking bewaart ongeveer 18 maanden in de UI en 24 via de API, tenzij u Field Audit Trail met Salesforce Shield licentieert en een bewaarbeleid instelt. Auditcycli zijn jaarlijks, dus houd uw eigen kopie in Git en uw DevOps-platform.

Hoe bewijst u bewaring en verwijdering?

Bewaartermijnen worden het slechtst beantwoord, omdat niemand er eigenaar van is. Drie artefacten lossen het op:

• Een datamap: welke objecten en velden persoonsgegevens bevatten, en de grondslag per stuk.
• Een bewaarschema per object, met het verwijdermechanisme erbij (geplande job, archief, hard delete).
• Een verwijderlog die laat zien dat wisverzoeken zijn uitgevoerd, ook in sandboxes en back-ups.

Die sandboxregel verrast mensen het vaakst. Een full sandbox die uit productie is ververst is een kopie van dezelfde persoonsgegevens in een minder gecontroleerde omgeving. Seed een subset en maskeer persoonsvelden als onderdeel van de refresh, zodat de control zichzelf bewijst.

Hoe bereidt u zich in twee weken voor in plaats van twee maanden?

1. Dag 1-2: schrijf de scopememo en wijs per bewijspakket een eigenaar aan.
2. Dag 3-5: exporteer toegangsdata, draai Health Check, lijst elke integratiegebruiker en elk verhoogd profiel.
3. Dag 6-8: pak willekeurig 10 recente productiewijzigingen en volg ze van begin tot eind. Wat u niet kunt traceren is uw echte bevinding.
4. Dag 9-10: schrijf het bewaarschema en controleer de omgang met sandboxdata.
5. Automatiseer daarna wat u zojuist handmatig deed, zodat volgend jaar een export is en geen project.

Die laatste stap is het hele spel. Teams die schoon doorkomen hebben niet de netste org, maar controls die vanzelf draaien en een spoor achterlaten. Tekunda bouwt Salesforce op die manier als gecertificeerd SI, ISV en PDO, en we hebben managed packages door de AppExchange security review gebracht in zorg, logistiek en maakindustrie, waar iemand anders de bewijslat bepaalt.

FAQ

Hoe lang bewaart Salesforce de setup-wijzigingshistorie?

Setup Audit Trail bewaart 180 dagen en schoont daarna op. Exporteer volgens schema of houd hetzelfde record in uw DevOps-platform.

Hebben we Salesforce Shield nodig om een audit te halen?

Niet per se. Shield verlengt de bewaartermijn van veldhistorie en voegt Event Monitoring toe, maar de controls en hun bewijs wegen zwaarder dan de licentie.

Hoe vaak moeten we toegangsreviews doen?

Per kwartaal voor verhoogde rechten en integratiegebruikers, minimaal jaarlijks voor de rest, met elke keer een benoemde goedkeurder.

Is een full sandbox met productiedata een probleem?

Dat kan. Behandel het als een verwerking: seed een subset in plaats van klonen, maskeer persoonsvelden tijdens de refresh en beperk toegang zoals in productie.