← All insights

Kann das bei uns passieren? Wenn sensible Kundendaten in der falschen Abteilung landen – und wie Data Governance in Salesforce Data 360 das verhindert

Could this happen to us? Sensitive data, wrong department — examples from pharma and banking, and the Salesforce Data 360 rules that decide who sees which customer data.

Geprüft anhand von Salesforce Help, dem Salesforce-Blog und den Trailhead-Modulen Data 360 Setup und Data Governance Strategies, September 2026. Data Cloud heißt inzwischen Data 360.

Die meisten Datenlecks sehen nicht aus wie ein Hackerangriff. Sie sehen aus wie ein normaler Arbeitstag: Der Außendienst öffnet ein Kundenprofil, jemand im Callcenter liest eine Nummer vor, das Marketing baut ein Segment. Niemand macht absichtlich etwas falsch. Die Daten landen einfach dort, wo keine Regel sie aufgehalten hat.

Dieser Artikel hat zwei Teile. Erstens: Was kann konkret schiefgehen? Dazu vier kurze Beispiele aus Pharma und Banking. Zweitens: Welche Regeln bietet Salesforce Data 360 dagegen – und welche Standardeinstellung erwischt viele Teams kalt?

OHNE REGELMIT DATA-360-REGEL Außendienst Pharma-Vertrieb NEBENWIRKUNGSMELDUNG „Dr. Weber meldet Schwindelnach der zweiten Dosis“ Kein ZugriffACCESS POLICY Callcenter externer Dienstleister KUNDEN-IBAN DE89 3704 0044 0532 0130 00 KUNDEN-IBANDE89 •••• •••• •••• •••• 00MASKING Regionalleitung Region Süd KUNDENDATENSÄTZE NordSüdOstWest KUNDENDATENSÄTZENordSüdOstWestROW-LEVEL SECURITY
Die Kurzfassung: dieselben Kundendaten, drei Mitarbeitende – und was jede Person sehen darf, sobald eine Data-360-Regel greift. Namen und Daten sind frei erfunden.

Was schiefgehen kann

1. Pharma: Der Außendienst sieht eine Nebenwirkungsmeldung

Eine Ärztin meldet dem Medical-Team, dass ein Patient nach der zweiten Dosis Schwindel hatte. Die Meldung landet im zusammengeführten Kundenprofil. Zwei Wochen später besucht der Außendienst dieselbe Ärztin und spricht sie darauf an.

Viele Pharmaunternehmen trennen Medical und Vertrieb bewusst. Sobald die Daten in einem gemeinsamen Profil liegen, gibt es diese Trennung nur noch, wenn eine Regel sie durchsetzt.

Kann das bei uns passieren? Welche Teams können heute das komplette Profil einer Ärztin öffnen – inklusive dessen, was Medical weiß?

2. Banking: Ein externer Mitarbeiter liest die volle IBAN vor

Eine Bank arbeitet mit einem externen Callcenter. Die Mitarbeitenden müssen den richtigen Kunden finden, brauchen aber nicht die volle Kontonummer. Ohne Regel sehen sie sie trotzdem – und einer liest sie in einem aufgezeichneten Gespräch vor.

Kann das bei uns passieren? Was sieht ein externer Mitarbeiter auf dem Bildschirm, wenn er einen Kunden öffnet?

3. Banking: Ein sensibles Feld landet in einer Kampagne

Jemand im Marketing baut ein Cross-Selling-Segment und filtert auf ein Feld „Inkasso-Status“, weil es eben da war. Die Kunden in diesem Segment bekommen ein Angebot, an dem sie merken, dass das Marketing der Bank von ihren Zahlungsrückständen weiß.

Kann das bei uns passieren? Welche Felder darf das Marketing für Segmente nutzen, und wer hat das entschieden?

4. Pharma: Eine Ärztin ohne Einwilligung bekommt eine E-Mail

Dieser Fall ist anders, und das ist wichtig. Hier geht es nicht darum, wer die Daten sehen darf, sondern ob das Unternehmen die Person überhaupt kontaktieren darf. Zugriffsregeln lösen das nicht. Dafür ist das Einwilligungsmanagement zuständig.

Kann das bei uns passieren? Wird die Einwilligung in dem Moment geprüft, in dem ein Segment versendet wird – oder nur beim Eingang der Daten?

Warum das passiert

  1. Niemand hat die Daten als sensibel markiert. Ist ein Feld nicht als medizinisch oder finanziell gekennzeichnet, weiß keine Regel, dass es Schutz braucht.
  2. Es gibt Regeln, aber eine Standardeinstellung hebelt sie aus. Dazu unten mehr – das ist die häufigste Überraschung.
  3. Das zusammengeführte Profil übernimmt ein unmarkiertes Feld. Data 360 führt Daten aus mehreren Quellen zu einem Profil zusammen. Wurde ein sensibles Feld an der Quelle nie markiert, wandert es ungeschützt ins Profil.

Das Regelwerk in Salesforce Data 360

Dieser Teil ist für Admins und Architekten. Wer das Team leitet, dem reicht der Selbsttest am Ende.

Schritt 1: Sensible Daten mit Tags markieren

In Data 360 hängen Sie Tags an Felder, zum Beispiel E-Mail-Adresse oder Kreditkartennummer. Tags können einen übergeordneten Tag haben: Personenbezogene Daten → E-Mail-Adresse, Telefonnummer.

Diese Hierarchie erledigt die eigentliche Arbeit. Setzen Sie einen untergeordneten Tag auf ein Feld, wird der übergeordnete automatisch mitgesetzt. Jede Regel für Personenbezogene Daten schützt dieses Feld dann ohne zusätzlichen Aufwand.

  • Weitergabe (Propagation): Tags an einem Quellobjekt können auf verbundene, nachgelagerte Objekte übertragen werden, etwa auf das zusammengeführte Profil. Das schließt die Lücke aus Ursache 3.
  • KI-Vorschläge: Suggest Tags schlägt Tags vor. Die Funktion liest nur Metadaten – Feldnamen und Beschreibungen –, nicht die Inhalte der Felder. Ein Admin gibt jeden Vorschlag frei. Das ist die Antwort, wenn Compliance fragt, ob die KI Patientendaten sieht.
  • Nicht alles taggen. Beginnen Sie mit Daten, die Datenschutz, Compliance oder wichtige Entscheidungen betreffen. Alles zu taggen macht Arbeit, ohne mehr zu schützen.

Schritt 2: Festlegen, wer was sieht

Data 360 nutzt attributbasierte Zugriffskontrolle (ABAC). Eine Regel verbindet Merkmale der Person (Abteilung, Rolle) mit Merkmalen der Daten (ihren Tags). Sie formulieren die Absicht einmal, und sie gilt für jedes Feld mit diesem Tag – auch für Felder, die später dazukommen.

Was Sie brauchenPolicy-ArtBeispiel von oben
Bestimmte Personen dürfen es gar nicht sehenData Access PolicyDer Vertrieb hat keinen Zugriff auf Felder mit dem Tag Medizinische Informationen
Die Person braucht den Datensatz, aber nicht den vollen WertDynamic Data MaskingDas externe Callcenter sieht DE89 •••• •••• •••• •••• 00
Jede Person soll nur ihren Ausschnitt sehenRow-Level SecurityDie Regionalleitung sieht nur ihre Region
Drei Policy-Arten, drei der vier Beispiele. Die Einwilligung (Beispiel 4) ist eine eigene Aufgabe.

Laut Salesforce werden Governance-Policies über alle Data-360-Funktionen hinweg durchgesetzt, auch in der Segmentierung. In der Praxis heißt das: Sperrt eine Policy ein Feld für jemanden im Marketing, steht es beim Segmentbau nicht zur Verfügung (Beispiel 3).

  • Deny schlägt Allow. Erlaubt eine Regel den Zugriff und verbietet ihn eine andere, wird er verweigert.
  • Einfach halten. Wenige, klare Regeln sind besser als viele, die sich überschneiden. Zu strenge Regeln verleiten dazu, sie zu umgehen.
  • Mit echten Rollen testen, bevor Sie für alle ausrollen.

Schritt 3: Die Standardregel „Allow All“ entfernen – mit Plan

Hier liegt der Haken. Jede Data-360-Org, ob neu oder bestehend, startet mit einer aktiven „Allow All“-Policy. Sie sorgt dafür, dass nichts kaputtgeht, während Sie Ihre Regeln entwerfen.

Die Folge: Solange Allow All aktiv ist, haben neue Allow-Regeln keine Wirkung – alle haben ohnehin Zugriff. Nur Deny-Regeln greifen. Ein Team kann also ein sauberes Regelwerk bauen und trotzdem komplett offen sein. Allow All ohne Plan zu löschen ist aber genauso schlecht: Dann verlieren womöglich alle Nutzer auf einen Schlag ihren Zugriff.

Trailhead beschreibt fünf Phasen:

  1. Prüfen und entwerfen. Die Policy bleibt. Klären Sie, wer wirklich worauf Zugriff braucht.
  2. Bauen und testen. Legen Sie die neuen Allow- und Deny-Regeln an, während Allow All noch aktiv ist.
  3. Kommunizieren. Sagen Sie den Nutzern, was sich wann ändert. Planen Sie ein Wartungsfenster.
  4. Umschalten. Löschen Sie in diesem Fenster Allow All und aktivieren Sie die neuen Regeln.
  5. Prüfen und begleiten. Klären Sie mit den Nutzern, ob alle den Zugriff haben, den sie brauchen.

Hinweise zur Einrichtung, die später Ärger sparen

  • Home-Org vor dem Lizenzkauf festlegen. Wer mehrere Salesforce-Orgs hat, entscheidet vorher, mit welcher Data 360 verbunden wird – die Bereitstellung startet automatisch.
  • Datenresidenz: Müssen Daten in einer Region bleiben, planen Sie eine Data 360 pro Region.
  • Permission Sets: Starten Sie mit den Standard-Sets (Data Cloud Architect, Activation Manager, Activation Specialist, User). Ein neuer Nutzer bekommt seine Login-Mail, sobald das Permission Set gespeichert ist – das Konto sollte dann bereit sein.
  • Verbindung zur Marketing Cloud: Data 360 legt im Automation Studio eigene Automationen an, um Daten zu übertragen. Sagen Sie Ihren Marketing-Cloud-Nutzern, dass sie diese nicht bearbeiten sollen.

Selbsttest: Kann das bei uns passieren?

Fünf Fragen. Dafür braucht es kein Projekt, nur zehn Minuten mit Ihrem Admin.

  1. Ist die „Allow All“-Policy in unserer Data-360-Org noch aktiv?
  2. Welche Felder haben wir als sensibel markiert, und welche haben wir vergessen?
  3. Wer kann das komplette zusammengeführte Kundenprofil sehen?
  4. Was sieht ein externer Partner, wenn er einen Kunden öffnet?
  5. Welche Felder darf das Marketing in Segmenten nutzen, und wird die Einwilligung vor dem Versand geprüft?

Wenn Sie eine davon nicht beantworten können, fangen Sie genau dort an.

Wie ich das gerade lerne

Ich arbeite gerade an der Zertifizierung zum Salesforce Data 360 Consultant. Die Inhalte stammen aus den Trailhead-Modulen Data 360 Setup und Data Governance Strategies. Wer tiefer einsteigen will, beginnt mit dem Trail „Prepare for your Salesforce Data 360 Consultant Certification“ und dem unten verlinkten Help-Artikel zur Data Governance in Data 360.

Ebenfalls lesenswert: MarTech unter der Haube, Teil 3 – die Adobe-Seite, auf der jede Data Usage Policy ausgeschaltet ausgeliefert wird.

Die Beispiele in diesem Artikel sind frei erfunden. Produktverhalten laut Salesforce-Dokumentation, Stand September 2026. Salesforce, Data 360 und Trailhead sind Marken der Salesforce, Inc. Dies ist eine unabhängige Analyse; es besteht keine Partnerschaft mit oder Empfehlung durch Salesforce.

Quellen

Christopher Dettinger

Written by

Christopher Dettinger

Omnichannel Orchestration Architect · omnichannel24.de

Independent martech architect focused on Adobe Experience Platform, Journey Optimizer, Salesforce Marketing Cloud and Real-Time CDP – building the data foundations behind digital marketing in regulated industries. Adobe Certified Expert (AJO Developer), Scrum Product Owner (Scrum.org).

LinkedIn →  About →