So bereiten Sie Ihre Salesforce-Org auf ein Audit vor

Kurze Antwort: Ein Auditor will keine Führung durch Ihre Org. Er will drei Nachweispakete: wer Zugriff hatte und wer ihn genehmigt hat, was sich in der Produktion geändert hat und wer es freigegeben hat, und wie lange Sie Daten aufbewahren, bevor Sie sie löschen. Sind diese drei Exporte Routine, ist ein Audit ein Termin. Sind sie es nicht, sind es zwei Wochen Feuerwehr.

Was verlangt ein Auditor wirklich von einem Salesforce-Team?

Die meisten Ratgeber zum Salesforce-Audit beschreiben einen internen Health Check: tote Felder, ungenutzte Berichte, Speicher aufräumen. Nützliche Hausarbeit, aber nicht das, was ein externer Auditor prüft. Unter SOX, SOC 2 oder ISO 27001 zieht er eine Stichprobe und lässt Sie eine Kontrolle beweisen:

• Zugriffsnachweis. Eine Nutzerliste mit Profilen, Permission Sets und Rollen, dazu wer jede Vergabe genehmigt hat und wann sie zuletzt geprüft wurde.
• Änderungsnachweis. Für eine Stichprobe von Produktionsänderungen: die Anforderung, die Freigabe, das Testergebnis und der Deployment-Datensatz.
• Aufbewahrungs- und Löschnachweis. Welche personenbezogenen Daten Sie halten, wie lange, und der Beleg, dass Löschanfragen ausgeführt wurden.

Fast jeder Befund, den wir sehen, stammt aus einem dieser drei Punkte, nicht aus einem unaufgeräumten Page Layout.

Was ist im Umfang, und wer entscheidet das?

Sie entscheiden zuerst und verteidigen es danach. Der Umfang folgt dem Risiko, nicht dem Organigramm:

• Finanzberichterstattung (SOX): Angebote, Aufträge, Abrechnung, Umsatzobjekte und jede Automatisierung, die diese Werte ändern kann, inklusive Integrationsbenutzer.
• Personenbezogene Daten (DSGVO und ähnliche): Contact, Lead, Case, Person Account, Chat-Transkripte und jede Sandbox-Kopie.
• Privilegierte Rechte: Modify All Data, View All Data, Manage Users, Author Apex und jeder, der deployen kann.

Schreiben Sie das vor dem Kickoff in ein einseitiges Scope-Memo. Ein Auditor, der den Umfang für Sie festlegen muss, legt ihn großzügig fest.

Wie erzeugen Sie Zugriffsnachweise ohne Screenshots?

Screenshots altern schlecht und sagen nichts über die anderen 51 Wochen des Jahres. Exportieren Sie stattdessen, nach Plan:

1. Fragen Sie die Berechtigungsobjekte ab. PermissionSetAssignment, ObjectPermissions und FieldPermissions liefern das echte Bild, inklusive allem über Permission Set Groups.
2. Exportieren Sie die Login History. Salesforce hält sechs Monate online bereit und lässt sie als CSV herunterladen. Ruhende Accounts mit aktiven Rechten sind der Klassiker.
3. Führen Sie Security Health Check und Optimizer aus und heben Sie das Ergebnis auf. Eine datierte Selbstbewertung gilt als Nachweis, dass überwacht wird.
4. Machen Sie die Prüfung quartalsweise, mit benanntem Freigeber. Eine Zugriffsprüfung, die niemand unterschrieben hat, ist keine Kontrolle. Halten Sie Prüfer, Datum und Ausnahmen fest.

Integrationsbenutzer verdienen eine eigene Zeile. Sie tragen meist die weitesten Rechte und die geringste Aufmerksamkeit, und Auditoren schauen inzwischen zuerst dorthin.

Wie erzeugen Sie Änderungsnachweise?

Hier tun Change Sets weh. Sie trennen den Erbauer nicht vom Deployer und hinterlassen keine verknüpfte Freigabe. Eine Pipeline antwortet mit Links: das Work Item mit fachlicher Begründung, der Commit mit genau den bewegten Metadaten, der Pull Request mit einem Reviewer, der nicht der Autor ist, das Testergebnis und der Deployment-Datensatz.

Zwei Eigenschaften entscheiden. Der Nachweis muss unveränderlich und vollständig sein, es darf also keinen Weg in die Produktion geben, der ihn umgeht. Ein Prozess, der die meisten Änderungen abdeckt, fällt trotzdem durch, weil die Stichprobe auf die Ausnahme treffen kann.

Native Historie hilft, trägt aber nicht alles. Der Setup Audit Trail hält 180 Tage und ist über das Objekt SetupAuditTrail abfragbar, bevor er bereinigt wird. Field History Tracking behält rund 18 Monate in der UI und 24 über die API, sofern Sie nicht Field Audit Trail mit Salesforce Shield lizenzieren und eine Aufbewahrungsrichtlinie setzen. Audit-Zyklen sind jährlich, halten Sie also Ihre eigene Kopie in Git und Ihrer DevOps-Plattform.

Wie belegen Sie Aufbewahrung und Löschung?

Aufbewahrung wird am schlechtesten beantwortet, weil sie niemandem gehört. Drei Artefakte klären das:

• Eine Datenkarte: welche Objekte und Felder personenbezogene Daten enthalten und die Rechtsgrundlage je Feld.
• Ein Aufbewahrungsplan pro Objekt, mit benanntem Löschmechanismus (geplanter Job, Archiv, endgültiges Löschen).
• Ein Löschprotokoll, das zeigt, dass Löschanfragen ausgeführt wurden, auch in Sandboxes und Backups.

Die Sandbox-Zeile überrascht am meisten. Eine aus der Produktion aktualisierte Full Sandbox ist eine Kopie derselben personenbezogenen Daten in einer weniger kontrollierten Umgebung. Seeden Sie eine Teilmenge und maskieren Sie personenbezogene Felder im Refresh, damit sich die Kontrolle selbst belegt.

Wie bereiten Sie sich in zwei Wochen statt zwei Monaten vor?

1. Tag 1-2: Scope-Memo schreiben und pro Nachweispaket einen Verantwortlichen benennen.
2. Tag 3-5: Zugriffsdaten exportieren, Health Check laufen lassen, jeden Integrationsbenutzer und jedes privilegierte Profil auflisten.
3. Tag 6-8: zehn zufällige Produktionsänderungen nehmen und komplett nachverfolgen. Was Sie nicht nachweisen können, ist Ihr echter Befund.
4. Tag 9-10: Aufbewahrungsplan schreiben und den Umgang mit Sandbox-Daten prüfen.
5. Danach automatisieren, was Sie gerade von Hand getan haben, damit nächstes Jahr ein Export statt eines Projekts wird.

Dieser letzte Schritt ist das ganze Spiel. Teams, die sauber durchkommen, haben nicht die aufgeräumteste Org, sondern Kontrollen, die von selbst laufen und eine Spur hinterlassen. Tekunda baut Salesforce so, als zertifizierter SI, ISV und PDO, und wir haben Managed Packages durch die AppExchange Security Review in Gesundheitswesen, Logistik und Fertigung gebracht, wo jemand anders die Nachweislatte legt.

FAQ

Wie lange speichert Salesforce die Setup-Änderungshistorie?

Der Setup Audit Trail hält 180 Tage und bereinigt danach. Exportieren Sie ihn planmäßig oder halten Sie den gleichen Datensatz in Ihrer DevOps-Plattform.

Brauchen wir Salesforce Shield, um ein Audit zu bestehen?

Nicht zwingend. Shield verlängert die Feldhistorie und bringt Event Monitoring, aber Kontrollen und ihre Nachweise wiegen schwerer als die Lizenz.

Wie oft sollten Zugriffsprüfungen laufen?

Quartalsweise für privilegierte und Integrationsbenutzer, mindestens jährlich für alle anderen, jedes Mal mit benanntem Freigeber.

Ist eine Full Sandbox mit Produktionsdaten ein Problem?

Sie kann es sein. Behandeln Sie sie als Verarbeitung: eine Teilmenge seeden statt klonen, personenbezogene Felder im Refresh maskieren und Zugriffe wie in der Produktion beschränken.