SOX- und DSGVO-Compliance im Salesforce-Release-Prozess

Kurze Antwort: SOX verlangt den Nachweis, dass wer eine Änderung gebaut hat, sie nicht selbst freigegeben hat, und dass jede Produktionsänderung auf eine genehmigte Anforderung zurückführt. Die DSGVO verlangt den Nachweis, dass personenbezogene Daten minimiert und geschützt wurden, auch in Sandboxes. Eine normale Pipeline erzeugt den Großteil dieser Nachweise bereits. Die Arbeit besteht darin, die Kontrollen in der Pipeline zu erzwingen, statt sie jährlich von Hand zu rekonstruieren.

Was verlangen SOX und DSGVO wirklich von einem Release-Prozess?

Zwei verschiedene Gesetze mit einer gemeinsamen Forderung: Kontrollen, die entworfen, erzwungen und belegt sind.

• SOX (Sarbanes-Oxley) gilt für in den USA börsennotierte Unternehmen. Section 404 verpflichtet das Management, die interne Kontrolle über die Finanzberichterstattung zu beurteilen. Praktisch prüft Ihr Auditor die IT General Controls: wer die Systeme ändern darf, die Finanzzahlen erzeugen, wie diese Änderungen genehmigt werden und ob die Berechtigungen angemessen sind.
• Die DSGVO gilt, sobald Sie personenbezogene Daten von Menschen in der EU verarbeiten. Für einen Release-Prozess sind Datenminimierung (Artikel 5), Datenschutz durch Technikgestaltung und Voreinstellungen (Artikel 25) und Sicherheit der Verarbeitung (Artikel 32) relevant.

Keines der beiden Gesetze nennt ein Werkzeug. Beide verlangen dieselben drei Dinge: eine Kontrolle, den Nachweis, dass sie gelaufen ist, und den Nachweis, dass sie jedes Mal gelaufen ist.

Welche Teile einer Salesforce-Org sind im Prüfungsumfang?

Nicht alle, und das früh zu entscheiden hält das Audit klein. Der SOX-Umfang folgt den Finanzzahlen:

• Objekte und Automatisierung rund um Umsatzrealisierung, Abrechnung, Angebote und Forecast: Opportunity, Order, Product, Price Book, CPQ- oder Revenue-Cloud-Konfiguration, Genehmigungsprozesse für Rabatte.
• Alles, was diese Werte ohne menschliches Zutun ändern kann: Flows, Apex-Trigger, Validierungsregeln, Integrationsbenutzer.
• Profile, Permission Sets und Permission Set Groups, die Schreibrechte darauf gewähren.

Der DSGVO-Umfang hat die umgekehrte Form: Er folgt personenbezogenen Daten überall hin, also meist Contact, Lead, Case, Person Account, Chat-Transkripten und jeder Sandbox-Kopie davon.

Schreiben Sie den Umfang vor dem Audit auf. Diese Frage zum ersten Mal im Audit-Termin zu beantworten, ist der Weg von einer Prüfung zu zwei Wochen Feuerwehr.

Wie erzwingen Sie Funktionstrennung, ohne Releases zu bremsen?

Funktionstrennung heißt: Wer eine Änderung schreibt, darf sie nicht selbst nach Produktion bringen. Change Sets können das nicht erzwingen, denn wer deployen kann, kann auch bauen. Verlagern Sie die Kontrolle in die Pipeline:

1. Nehmen Sie Menschen die Deploy-Rechte in Produktion. Nur die dedizierte Integrationsidentität der Pipeline deployt. Modify All Data und Modify Metadata in Produktion gehören dieser Identität, nicht Entwicklern oder Admins.
2. Machen Sie den Pull Request zum Kontrollpunkt. Fordern Sie mindestens ein genehmigendes Review von jemand anderem als dem Autor und deaktivieren Sie Selbstfreigabe im Branch Protection.
3. Trennen Sie die Freigabe nach Umgebung. Eine UAT-Promotion kann der Tech Lead abzeichnen. Ein Produktions-Release braucht zusätzlich den Business Owner des betroffenen Prozesses.
4. Protokollieren Sie den Notfallpfad, statt ihn zu verbieten. Break-Glass-Deployments passieren. Legen Sie fest, wer sie auslösen darf, fordern Sie binnen 24 Stunden ein nachgereichtes Work Item und erfassen Sie es als Ausnahme. Auditoren akzeptieren dokumentierte Ausnahmen, keine unsichtbaren.

Welche Änderungsnachweise akzeptiert ein Auditor?

Auditoren arbeiten mit Stichproben. Sie greifen sich eine Handvoll Produktionsänderungen und lassen sich jede von der Anforderung bis zum Release erklären. Eine Pipeline antwortet mit Links statt mit Screenshots:

• Das Work Item mit fachlicher Begründung und Anforderer.
• Die Commits, die genau zeigen, welche Metadaten sich geändert haben.
• Der Pull Request mit Identität des Reviewers und Zeitstempel.
• Der Testnachweis: Apex-Tests, Coverage, statische Analyse oder das Ergebnis automatisierter Code-Reviews.
• Der Deployment-Datensatz: Ziel-Org, Deploy-ID, auslösende Person und Ergebnis.

Zwei Eigenschaften lassen diesen Nachweis bestehen: Er muss unveränderlich und vollständig sein, es darf also keinen Weg in die Produktion geben, der ihn umgeht. Eine Pipeline, die 90% der Änderungen abdeckt, fällt trotzdem durch, weil die Stichprobe in den übrigen 10% landen kann.

Wie behandeln Sie personenbezogene Daten in Sandboxes DSGVO-konform?

Ein Full-Sandbox-Refresh kopiert personenbezogene Produktionsdaten in eine Umgebung mit weiteren Rechten und mehr Nutzern. Das ist eine Verarbeitung und braucht dieselbe Begründung wie jede andere.

• Seeden statt klonen. Ziehen Sie einen repräsentativen Ausschnitt statt der ganzen Datenbank. Weniger Daten heißt weniger Risiko und ein schnellerer Refresh.
• Maskieren beim Eintreffen. Anonymisieren oder pseudonymisieren Sie personenbezogene Felder als Teil des Refresh, nie als Nacharbeit, an die sich jemand erinnern muss. Salesforce Data Mask deckt die Standardmuster ab.
• Beschränken Sie Sandbox-Zugriffe wie in Produktion. Gleiche Profile, gleiche Permission-Set-Disziplin, gleiches Offboarding. Eine Partial Sandbox mit echten E-Mail-Adressen und großzügigem Profil ist der Befund, den wir am häufigsten sehen.

Wie lange müssen Sie die Nachweise aufbewahren?

Länger, als Salesforce sie für Sie aufbewahrt. Der Setup Audit Trail hält ein rollierendes Fenster von 180 Tagen und lässt sich als CSV herunterladen. Field History Tracking behält rund 18 Monate in der UI und 24 über die API, sofern Sie nicht Field Audit Trail mit Shield lizenzieren und eine Aufbewahrungsrichtlinie setzen. SOX-Zyklen sind jährlich und Nachweise werden für den gesamten Zeitraum angefragt, die nativen Fenster reichen also nicht.

Git plus Ihre DevOps-Plattform lösen das: Die Repository-Historie ist dauerhaft, und Deployment-Datensätze liegen außerhalb der Org.

Wie sieht eine konforme Pipeline von Anfang bis Ende aus?

1. Jede Änderung beginnt als Work Item mit fachlicher Begründung und landet in der Versionskontrolle.
2. Automatisiertes Review und Tests laufen auf dem Pull Request, bevor ein Mensch hinsieht.
3. Ein Freigeber, der nicht der Autor ist, zeichnet ab, mit zweitem Freigeber am Produktions-Gate.
4. Nur die Pipeline-Identität deployt, und jedes Deployment schreibt einen unveränderlichen Datensatz.
5. Sandbox-Refreshes werden geseedet und maskiert, und Nachweise sind auf Abruf exportierbar.

Nichts davon verlangt ein separates Compliance-Produkt, sondern den Release-Prozess, den Sie ohnehin wollten, so konfiguriert, dass die Kontrollen der einzige Weg sind. Die meisten Plattformen können das, darunter Copado, Gearset, AutoRABIT, Flosum und Serpent. Weitere Leitfäden finden Sie in unserer SF-Guides-Bibliothek.

FAQ

Gilt SOX für unsere ganze Salesforce-Org?

Nein. Der Umfang folgt der Finanzberichterstattung: Angebote, Aufträge, Abrechnung, Umsatzobjekte und die Automatisierung, die sie berührt. Dokumentieren Sie die Grenze selbst, bevor der Auditor sie weiter zieht.

Kann man mit Change Sets SOX-konform sein?

Nur sehr mühsam. Change Sets trennen Autor und Deployer nicht und hinterlassen keinen verknüpften Freigabedatensatz, also bauen Sie daneben eine manuelle Nachweisebene.

Ist eine Full Sandbox mit Produktionsdaten ein DSGVO-Verstoß?

Nicht automatisch, aber es ist eine Verarbeitung, die Sie begründen, minimieren und absichern müssen. Eine Teilmenge zu seeden und personenbezogene Felder beim Refresh zu maskieren ist der praktische Weg.

Wer sollte ein Produktions-Release freigeben?

Jemand anderes als der Autor, plus der Business Owner des betroffenen Prozesses für alles im SOX-Umfang. Erfassen Sie beide Freigaben an der Änderung.