SOX- en AVG-compliance in een Salesforce-releaseproces

Kort antwoord: SOX vraagt u aan te tonen dat wie een wijziging bouwde die niet zelf heeft vrijgegeven, en dat elke productiewijziging terug te voeren is op een goedgekeurd verzoek. De AVG vraagt u aan te tonen dat persoonsgegevens geminimaliseerd en beschermd zijn, ook in sandboxes. Een normale pipeline levert dat bewijs al grotendeels op. Het werk zit in het afdwingen van de controls in de pipeline, in plaats van ze jaarlijks met de hand te reconstrueren.

Wat vragen SOX en de AVG precies van een releaseproces?

Twee verschillende wetten met een overlappende eis: controls die zijn ontworpen, afgedwongen en aantoonbaar zijn.

• SOX (Sarbanes-Oxley) geldt voor Amerikaans beursgenoteerde ondernemingen. Sectie 404 verplicht het management de interne beheersing rond de financiële verslaggeving te beoordelen. In de praktijk toetst uw auditor de IT general controls: wie de systemen mag wijzigen die financiële cijfers produceren, hoe die wijzigingen worden goedgekeurd en of de toegang passend is.
• De AVG geldt zodra u persoonsgegevens van mensen in de EU verwerkt. Voor een releaseproces gaat het om dataminimalisatie (artikel 5), gegevensbescherming door ontwerp en door standaardinstellingen (artikel 25) en beveiliging van de verwerking (artikel 32).

Geen van beide wetten noemt een tool. Beide vragen om dezelfde drie dingen: een control, bewijs dat die is uitgevoerd, en bewijs dat die elke keer is uitgevoerd.

Welke delen van een Salesforce-org vallen binnen scope?

Niet alles, en dit vroeg vaststellen houdt de audit klein. De SOX-scope volgt de financiële cijfers:

• Objecten en automatisering rond omzetverantwoording, facturatie, offertes en forecasting: Opportunity, Order, Product, Price Book, CPQ- of Revenue Cloud-configuratie, goedkeuringsprocessen voor kortingen.
• Alles wat die waarden zonder tussenkomst van een mens kan wijzigen: Flows, Apex-triggers, validatieregels, integratiegebruikers.
• Profielen, permission sets en permission set groups die bewerkrechten op het bovenstaande geven.

De AVG-scope heeft de omgekeerde vorm: die volgt persoonsgegevens waar ze ook staan, dus meestal Contact, Lead, Case, Person Account, chattranscripties en elke sandboxkopie daarvan.

Leg de scope vast vóór de audit begint. Die vraag voor het eerst beantwoorden tijdens een auditgesprek is hoe een review verandert in twee weken brandblussen.

Hoe dwingt u functiescheiding af zonder releases te vertragen?

Functiescheiding betekent dat wie een wijziging maakt, die niet zelf naar productie mag brengen. Change sets kunnen dat niet afdwingen: wie kan deployen, kan ook bouwen. Leg de control daarom in de pipeline:

1. Haal deployrechten weg bij mensen in productie. Alleen de integratie-identiteit van de pipeline deployt. Modify All Data en Modify Metadata in productie horen bij die identiteit, niet bij ontwikkelaars of beheerders.
2. Maak de pull request het controlepunt. Eis minstens één goedkeurende review van iemand anders dan de auteur en zet zelfgoedkeuring uit in de branch protection.
3. Splits goedkeuring per omgeving. Een promotie naar UAT kan de tech lead aftekenen. Een productierelease vraagt daarnaast de business owner van het geraakte proces.
4. Log het noodpad in plaats van het te verbieden. Break-glass deployments komen voor. Bepaal wie er een mag starten, eis binnen 24 uur een work item achteraf en registreer het als uitzondering. Auditors accepteren gedocumenteerde uitzonderingen, geen onzichtbare.

Welk wijzigingsbewijs accepteert een auditor?

Auditors werken met steekproeven. Ze kiezen een handvol productiewijzigingen en vragen u elke wijziging te volgen van verzoek tot release. Een pipeline antwoordt met links, niet met screenshots:

• Het work item, met de zakelijke reden en de aanvrager.
• De commits, die precies laten zien welke metadata is gewijzigd.
• De pull request, met de identiteit van de reviewer en een tijdstempel.
• Het testbewijs: Apex-tests, dekking, statische analyse of de uitkomst van geautomatiseerde code review.
• Het deployrecord: doelorg, deploy-ID, wie het startte en de uitkomst.

Twee eigenschappen laten dat bewijs slagen: het moet onveranderlijk zijn en volledig, dus geen route naar productie gaat eromheen. Een pipeline die 90% van de wijzigingen dekt, zakt alsnog, want de steekproef kan in de overige 10% vallen.

Hoe gaat u om met persoonsgegevens in sandboxes zonder de AVG te schenden?

Een volledige sandboxrefresh kopieert persoonsgegevens uit productie naar een omgeving met ruimere toegang en meer gebruikers. Dat is een verwerking en vraagt dezelfde onderbouwing als elke andere.

• Seeden, niet klonen. Neem een representatieve selectie in plaats van de hele database. Minder data is minder blootstelling en een snellere refresh.
• Maskeer bij binnenkomst. Anonimiseer of pseudonimiseer persoonsvelden als onderdeel van de refresh, nooit als taak achteraf die iemand op vrijdag moet onthouden. Salesforce Data Mask dekt de standaardpatronen.
• Beperk sandboxtoegang zoals in productie. Dezelfde profielen, dezelfde discipline met permission sets, dezelfde offboarding. Een partial sandbox met echte e-mailadressen en een ruim profiel is de bevinding die wij het vaakst zien.

Hoe lang moet u het bewijs bewaren?

Langer dan Salesforce het voor u bewaart. De Setup Audit Trail houdt een rollend venster van 180 dagen bij en is als CSV te downloaden. Field History Tracking bewaart ongeveer 18 maanden in de UI en 24 via de API, tenzij u Field Audit Trail met Shield licentieert en een bewaarbeleid instelt. SOX-cycli zijn jaarlijks en bewijs wordt meestal over de hele periode opgevraagd, dus de standaardvensters dekken u niet.

Git plus uw DevOps-platform lost dat op: repositoryhistorie is permanent en deployrecords staan buiten de org.

Hoe ziet zo'n pipeline er van begin tot eind uit?

1. Elke wijziging begint als work item met een zakelijke reden en landt in versiebeheer.
2. Geautomatiseerde review en tests draaien op de pull request, vóór een mens kijkt.
3. Een goedkeurder die niet de auteur is tekent af, met een tweede goedkeurder bij de productiepoort.
4. Alleen de pipeline-identiteit deployt, en elke deploy schrijft een onveranderlijk record.
5. Sandboxrefreshes worden geseed en gemaskeerd door dezelfde automatisering, en bewijs is exporteerbaar op verzoek.

Hiervoor is geen apart complianceproduct nodig, maar het releaseproces dat u toch al wilde, zo ingericht dat de controls de enige route zijn. De meeste platformen ondersteunen dat, waaronder Copado, Gearset, AutoRABIT, Flosum en Serpent. Meer gidsen vindt u in onze SF Guides-bibliotheek.

FAQ

Geldt SOX voor onze hele Salesforce-org?

Nee. De scope volgt de financiële verslaggeving: offertes, orders, facturatie en omzetobjecten plus de automatisering die eraan raakt. Leg de grens zelf vast, voordat de auditor hem ruimer trekt.

Kunnen we SOX-compliant zijn met change sets?

Dat is erg lastig. Change sets scheiden auteur en deployer niet en laten geen gekoppeld goedkeuringsrecord achter, dus u bouwt er een handmatige bewijslaag naast.

Is een full sandbox met productiedata een AVG-overtreding?

Niet automatisch, maar het is een verwerking die u moet onderbouwen, minimaliseren en beveiligen. Een subset seeden en persoonsvelden maskeren bij refresh is de praktische route.

Wie moet een productierelease goedkeuren?

Iemand anders dan de auteur, plus de business owner van het geraakte proces voor alles binnen SOX-scope. Leg beide goedkeuringen vast bij de wijziging.