Datenqualität und Governance

🌐 Auch in 28 Sprachen

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada)

Mit KI erstelltes Bild

Von KI übersetzt. Noch nicht von der Community geprüft. Auf Englisch lesen

Lernleitfaden zu Kapitel 5 des Kurses Data Architect. Lesen Sie zuerst die sechs Module; diese Seite hilft Ihnen zu prüfen, was hängen geblieben ist.

Über diesen Lernleitfaden. Er beruht ausschliesslich auf den Inhalten dieses Kurses und der veröffentlichten Liste der Prüfungsziele im Prüfungsleitfaden von Salesforce. Er basiert niemals auf echten Prüfungsfragen und behauptet nicht zu wissen, was in der Prüfung vorkommt. Wenn Sie die Prüfung abgelegt haben, schicken Sie mir bitte keine Fragen daraus: Die Zertifizierungsvereinbarung verbietet es, sie weiterzugeben, und Antworten auswendig zu lernen ist ohnehin der falsche Weg in die Architektur.

Dieses Kapitel trägt den Prüfungsbereich Data Governance (10 %) und Teile von Data Modeling (Metadaten) und Salesforce Data Management (Konsistenz). Hier trifft auch das Datenschutzrecht auf das Datenmodell. Das ist Architektur, keine Rechtsberatung: Die Rechtsabteilung entscheidet, was gilt, und die Architektur macht es durchsetzbar. Die Zahlen der Plattform ändern sich, also prüfen Sie die aktuellen, bevor Sie sich darauf verlassen.

Für die Prüfung

Haken Sie die Punkte ab. Jeder verweist auf die Stelle, an der er behandelt wird.

GOV-2: ein Governance-Programm entwerfen

• Ich weiss, dass der Datensatzeigentümer (ein Zugriffsmechanismus der Plattform) nicht die Dateneigentümerschaft ist (verantwortlich für die Daten als Geschäftswert) und dass jedes Feld einen Data Owner festhalten kann. (Datensatzeigentümer ist nicht gleich Dateneigentümer:in)
• Ich kann Dateneigentümer:innen (legen die Richtlinie fest), Data Stewards (halten sie am Laufen) und Verwaltende (betreiben das System) unterscheiden. (Eigentümer:in, Steward, Verwaltende)
• Prüfungswissen: Ich kenne die drei Arten, ein Governance-Programm zu führen, zentralisiert, föderiert (dezentral) und hybrid, und weiss, was jede davon dafür bedeutet, wer Richtlinien festlegt und wo die gemeinsamen Definitionen liegen. (Wie das Programm läuft)
• Ich kann eine RACI nutzen, um zu beantworten, wo Daten angelegt, bearbeitet und referenziert werden. (Die RACI muss sich ihren Platz verdienen)
• Ich kann für eine Governance-Richtlinie einen Durchsetzungspunkt benennen (Berechtigungen, Validierung, Felder nur für die Integration, Feldverlauf), nicht nur Schulung. (Governance muss mechanisch werden)
• Ich weiss, dass die Qualitätssignale, die es wert sind, gemessen zu werden, die sind, auf die jemand handeln wird. (Messen Sie, worauf jemand handeln wird)

SDM-2 und MDM-4: schlechte Daten fernhalten

• Ich kann entscheiden, ob das Anlegen von Accounts offen oder gesperrt sein sollte, und ich kenne den Weg über einen vorläufigen Datensatztyp für Accounts, die in einem ERP als Stammdaten geführt werden. (Offen oder gesperrt?, Der Mittelweg)
• Ich kann gesteuerte Attribute (eine ERP-ID, einen rechtlichen Namen) schützen und die eigenen Felder von Salesforce bearbeitbar lassen: ein hybrider Golden Record. Und ich weiss, dass ein schreibgeschütztes Feld auf einer Seite mit Dynamic Forms keine Durchsetzung ist; die Sicherheit auf Feldebene oder eine Validierungsregel ist es. (Schützen Sie den gesteuerten Datensatz, Ein Datensatztyp pro Datenfluss)
• Ich weiss, dass Datenflüsse in beide Richtungen am schwierigsten sind: Wenn das ERP ein Feld als Stammdatum führt, beantragt Salesforce die Änderung, und eine Kollision braucht eine Regel (das ERP gewinnt, ablehnen, wenn geändert, oder ein Mensch klärt sie). (Schützen Sie den gesteuerten Datensatz)
• Ich weiss, dass Pflichtfelder falsche Daten erzeugen können (N/A, 999999), und kenne die Alternativen. (Lassen Sie Pflichtfelder keine falschen Daten erzeugen)
• Ich kann entscheiden, was mit eingehenden Daten passiert, die Prüfungen nicht bestehen: annehmen, ablehnen oder in Quarantäne stellen, und wem die Ausnahme gehört. (Jede Datengrenze braucht eine Qualitätsentscheidung)
• Ich weiss, dass auch Referenzdaten Metadaten brauchen: Definitionen, einen Eigentümer, eine Quelle und Zuordnungen zwischen Systemen. (Auch Referenzdaten brauchen Metadaten)

DM-3: geschäftliche und technische Metadaten

• Prüfungswissen: Ich unterscheide geschäftliche Metadaten (Bedeutung, Definitionen, Eigentümer:innen, Regeln, Sensibilität) von technischen Metadaten (Objekte, Felder, Typen, API-Namen, Schemas, Zuordnungen, Datenherkunft). (Zwei Arten von Metadaten)
• Ich kenne den Unterschied zwischen einem Geschäftsglossar (was es bedeutet), der Datenherkunft (woher es kommt) und der Klassifizierung (wie es behandelt werden muss). (Kennen Sie Ihre Daten)
• Ich kenne die Klassifizierungsfelder von Salesforce: Data Owner, Field Usage, Data Sensitivity Level, Compliance Categorization, an Standard- und benutzerdefinierten Feldern. (Die Klassifizierung beantwortet eine andere Frage)
• Ich weiss, dass man die sensiblen Felder klassifiziert, nicht jedes Feld, und dass Klassifizierung ohne Durchsetzung Dekoration ist. (Klassifizierung ohne Durchsetzung ist Dekoration)

GOV-1: personenbezogene und sensible Daten

• Ich erkenne die wichtigsten Gesetze (DSGVO, CCPA/CPRA, PIPEDA, LGPD, den australischen Privacy Act, HIPAA, PCI DSS, SOX, COPPA), ich weiss, dass die DSGVO Organisationen ausserhalb der EU erfassen kann, und was die Gesetze gemeinsam haben: Rechte, Übermittlungen, Meldung von Datenschutzverletzungen und Rechenschaftspflicht. (Die Vorschriften, die Sie kennen sollten, Gesetze hören nicht an der Grenze auf)
• Ich kenne den Unterschied zwischen Verschlüsselung, Maskierung, Pseudonymisierung und Anonymisierung, und ich weiss, dass pseudonymisierte Daten weiterhin personenbezogene Daten sind. (Anonymisiert, pseudonymisiert, verschlüsselt, maskiert)
• Ich weiss, dass weniger erheben eine Datenschutzkontrolle ist und dass die Aufbewahrung von Anfang an entworfen wird. (Weniger erheben ist eine Architekturentscheidung, Aufbewahrung ist Teil des Modells)
• Ich kenne das Einwilligungsdatenmodell: globale Einwilligung auf der Einzelperson, Einwilligung je Engagement-Kanal, Einwilligung je Kontaktpunkt und Datenverwendungszweck. (Nutzen Sie das Modell, das Salesforce schon gebaut hat)
• Ich weiss, dass Anfragen Fristen haben (DSGVO: ein Monat, um zwei weitere verlängerbar), also muss die Karte der Kopien schon vorher existieren. (Die Uhr läuft)
• Ich weiss, dass das Recht auf Vergessenwerden bedeutet, jede Kopie zu finden (Historie, Archive, Analytik, Protokolle, Dateien, Freitext), und dass die Richtlinien von Privacy Center pro Objekt gegen einen Kundendatensatz laufen. (Jetzt sagt die Person: Vergessen Sie mich, Privacy Center ist ein Werkzeug)
• Ich kenne die Abwägungen von Shield Platform Encryption: Probabilistisch verschlüsselte Felder können in SOQL nicht gefiltert, gruppiert oder sortiert werden; deterministische Verschlüsselung erlaubt das Filtern; verschlüsselte Felder können keine kriterienbasierte Freigabe steuern. (Verschlüsselung ist eine Kontrolle, keine Compliance)
• Ich weiss, dass man sensible Produktionsdaten nicht in Sandboxes kopiert und dass Data Mask durch Data Mask & Seed ersetzt wird. (Kopieren Sie das Risiko der Produktion nicht in die Sandbox)
• Ich kenne den Feldverlauf (bis zu 20 Felder pro Objekt; 18 Monate, 24 nur über die API; bei langen Textfeldern wird nur die Bearbeitung festgehalten) gegenüber Field Audit Trail (bis zu 200 Felder, aufbewahrt, bis Sie ihn löschen). (Auch Historie ist Daten)
• Ich kenne die Aufbewahrung der Protokolle von Event Monitoring (1 Tag ohne das Zusatzprodukt für einige Ereignisse, 30 Tage standardmässig damit, bis zu 365 verlängert), und ich weiss, dass man Ereignisse in ein SIEM exportiert, bevor man sie braucht: Kostenpflichtige Protokolle lassen sich nicht für die Zeit vor Vertragsbeginn abrufen. (Prüfen und Überwachen sind nicht dasselbe)

Über die Prüfung hinaus

Die Prüfung ist der Boden, nicht die Decke. Das sind die Gewohnheiten aus diesem Kapitel, die Architekt:innen brauchen, ob eine Frage je danach fragt oder nicht.

• Eine Richtlinie ohne Durchsetzungspunkt ist meist ein Wunsch.
• Eigentümer:innen legen die Richtlinie fest; Architekt:innen setzen sie durch. Erfinden Sie die Richtlinie nicht, und spielen Sie nicht die Rechtsabteilung.
• Governance ist nie fertig. Sie verläuft in Ebbe und Flut; entwerfen Sie die Rückmeldung.
• Verlassen Sie sich nicht auf gutes Benehmen. Bauen Sie die Kontrolle: Menschen, Integrationen und Agenten machen alle Fehler.
• Steuern Sie genug, nicht alles.
• Verhindern Sie zuerst die teuren Fehler. Ein Duplikat mit zwei Jahren Historie ist ein grosses Problem.
• Unterscheiden Sie, was Menschen lesen, von dem, worauf Maschinen entscheiden.
• Breit dokumentieren; bewusst klassifizieren.
• Die billigsten sensiblen Daten zu steuern sind die, die Sie nie kopiert haben.
• Einwilligung ist Daten, und die Erlaubnis, Daten zu verwenden, muss sich als Daten darstellen lassen.
• Kontrollieren Sie zuerst, wohin personenbezogene Daten gehen, denn Löschen ist selten und schwer.
• Compliance ist kein Produkt.
• Erfassen → Klassifizieren → Schützen → Nutzen → Aufbewahren → Löschen → Prüfen.
• Erfassen Sie die Nachweise, bevor jemand danach fragt.

Wichtige Begriffe

Begriff	In einer Zeile
Daten-Governance	Die Richtlinien für Daten und die Architektur, die sie wahr macht
Dateneigentümer:in	Die Person oder Funktion, die für eine Art von Daten verantwortlich ist
Data Steward	Die Person, die die Daten im Alltag gesund hält
Verwaltende (Custodian)	Das Team, das die Systeme betreibt, die die Daten halten
RACI	Responsible, Accountable, Consulted, Informed
Vorläufiger Datensatz	Ein Datensatz, angelegt, bevor das massgebliche System ihn angenommen hat
Geschäftsglossar	Vereinbarte Definitionen der wichtigen Begriffe des Geschäfts
Datenherkunft (Lineage)	Woher ein Wert kommt und was unterwegs mit ihm passiert ist
Datenklassifizierung	Daten nach Sensibilität und Compliance-Kategorie kennzeichnen, damit sie die richtigen Kontrollen bekommen
Taxonomie	Der Satz an Bezeichnungen, mit dem eine Organisation Daten klassifiziert
Personenbezogene Daten	Informationen, die eine Person identifizieren oder ihr zugeordnet werden können
Pseudonymisierung	Kennungen ersetzen, während ein Weg zurück noch existiert; weiterhin personenbezogene Daten
Anonymisierung	Die vernünftige Möglichkeit beseitigen, die Person zu identifizieren
Einwilligungsdatenmodell	Die Salesforce-Objekte für Einwilligungen nach Person, Kanal, Kontaktpunkt und Zweck
Recht auf Vergessenwerden	Das Recht einer Person, wo das Gesetz es vorsieht, ihre personenbezogenen Daten löschen zu lassen
Hybrider Golden Record	Ein Datensatz mit den Feldern des Stammdatensystems und den eigenen Feldern von Salesforce, jede Art mit einer Quelle
Geschäftliche / technische Metadaten	Was die Daten bedeuten und wem sie gehören / wie sie gebaut sind und sich bewegen
Field Audit Trail	Längerer Feldverlauf: bis zu 200 Felder pro Objekt, aufbewahrt bis zur Löschung
Event Monitoring	Protokolle von Anmeldungen, Exporten, API-Aufrufen und Ansichten, für begrenzte Zeit aufbewahrt
SIEM	Ein Sicherheits-Repository, in dem Ereignisprotokolle aufbewahrt und analysiert werden

Prüfen Sie sich

Kurze Szenarien im Stil des Kurses. Entscheiden Sie sich für Ihre Antwort, bevor Sie sie aufklappen.

1. Die Richtlinie sagt, nur die Finanzabteilung darf den rechtlichen Namen eines Kunden ändern. Das Team will das in der Schulung abdecken. Was fehlt?

Ein Durchsetzungspunkt. Schulung ist keine Kontrolle: Nutzen Sie Zugriff auf Feldebene, ein Feld, das nur die Integration schreibt, eine Validierungsregel oder einen kontrollierten Prozess. Eigentümer:innen legen die Richtlinie fest; die Architektur macht sie mechanisch wahr. Lesen Sie noch einmal Governance muss mechanisch werden.

2. Kunden werden im ERP als Stammdaten geführt. Der Vertrieb muss sofort an neue Interessenten verkaufen können. Wie ermöglichen Sie das, ohne dass zwei Systeme den Stammdatensatz anlegen?

Lassen Sie den Vertrieb den Account mit einem vorläufigen Datensatztyp anlegen und wandeln Sie ihn dann über einen kontrollierten Prozess um: Die Finanzabteilung genehmigt, oder die Integration übergibt ihn dem ERP, das den Kunden zuordnet oder anlegt und die massgebliche ID zurückschickt. Lesen Sie noch einmal Der Mittelweg.

3. Ein neues Pflichtfeld füllt sich mit «N/A» und «999999». Was ist passiert, und was würden Sie stattdessen tun?

Die Benutzer wurden gezwungen zu antworten, bevor sie es wussten. Verlangen Sie es später im Prozess, lassen Sie ein anderes System es liefern, nutzen Sie einen vorläufigen Zustand oder erlauben Sie ein ausdrückliches Unbekannt, wenn das eine echte Antwort ist. Lesen Sie noch einmal Lassen Sie Pflichtfelder keine falschen Daten erzeugen.

4. Das Team hat Namen durch Token ersetzt und sagt, die Daten seien anonymisiert, die Löschanfrage also erledigt. Ist sie das?

Nicht, wenn die Token der Person wieder zugeordnet werden können: Das ist Pseudonymisierung, und die Daten sind weiterhin personenbezogen. Sagen Sie genau, was das System tut, wo die Zuordnung liegt, und lassen Sie die Rechtsabteilung entscheiden, ob das die Anforderung erfüllt. Lesen Sie noch einmal Anonymisiert, pseudonymisiert, verschlüsselt, maskiert.

5. Ein Empfänger willigt in Liefer-SMS ein, aber nicht in Marketing. Wie sollte das Modell das halten?

Mit dem Einwilligungsdatenmodell, nicht mit einem Kontrollkästchen: die Person, der Kanal (SMS), die bestimmte Nummer und der Datenverwendungszweck (Lieferbenachrichtigungen, nicht Marketing). Und entscheiden Sie, welches System für die Einwilligung massgeblich ist, damit ein Widerruf jedes System erreicht, das darauf handelt. Lesen Sie noch einmal Nutzen Sie das Modell, das Salesforce schon gebaut hat.

6. Die Compliance muss Berichte nach einem verschlüsselten Feld mit der Sozialversicherungsnummer filtern. Das Feld nutzt das standardmässige Verschlüsselungsschema. Wo liegt das Problem?

Probabilistische Verschlüsselung erlaubt kein Filtern in SOQL-WHERE-Klauseln oder Filtern der Datenverwaltung. Deterministische Verschlüsselung erlaubt das Filtern, auf Kosten von etwas Stärke. Verschlüsselung ist eine Entwurfsentscheidung mit Abwägungen, kein Kontrollkästchen am Ende. Lesen Sie noch einmal Verschlüsselung ist eine Kontrolle, keine Compliance.

7. Sechs Monate nach einem Vorfall fragt jemand, wer eine Reihe von Datensätzen exportiert hat. Niemand hat die Speicherung für Event Monitoring eingerichtet. Was können Sie sagen?

Wahrscheinlich nichts: Ereignisprotokolle werden nur begrenzt aufbewahrt (höchstens ein Jahr, selbst verlängert), also ist alles Ältere weg, wenn es nicht exportiert wurde. Richten Sie Event Monitoring ein und schicken Sie die Ereignisse in ein SIEM, bevor Sie sie brauchen. Lesen Sie noch einmal Prüfen und Überwachen sind nicht dasselbe.

8. Jemand aus dem Vertrieb will in Salesforce den rechtlichen Namen eines Kunden ändern, den das ERP als Stammdatum führt. In denselben Minuten ändert ihn jemand im ERP. Was sollte der Entwurf vorsehen?

Dass Salesforce eine Änderung beantragt, nicht vornimmt: Das ERP führt das Feld als Stammdatum. Legen Sie die Kollisionsregel vorab fest (das ERP gewinnt, ablehnen, wenn sich der Wert geändert hat, oder ein Mensch klärt sie) und ob zusammengehörige Felder gemeinsam reisen. Lesen Sie noch einmal Schützen Sie den gesteuerten Datensatz.

9. Der Löschantrag einer Person kommt an. Das Team will jetzt anfangen zu kartieren, wo ihre Daten liegen. Wo liegt das Problem?

Die Uhr läuft bereits: nach der DSGVO ein Monat, bei komplexen Anträgen um zwei weitere verlängerbar. Die Karte der Kopien muss existieren, bevor der Antrag kommt. Lesen Sie noch einmal Die Uhr läuft.

Weiterlesen

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce-Hilfe (auf Englisch, geprüft am 2026-09-25): die offizielle Liste der Ziele und ihrer Gewichtung. Prüfen Sie immer die aktuelle Fassung, bevor Sie die Prüfung buchen.
• Der Abschnitt Weiterlesen jedes Moduls nennt die Salesforce-Dokumentation und die Gesetze hinter seinen Fakten, mit dem Prüfdatum.