Datenschutzgesetze prägen den Entwurf
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)
Modul 4 von 6 im Kapitel Datenqualität und Governance, Kapitel 5 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Kennen Sie Ihre Daten · Weiter: Einwilligung und das Recht auf Vergessenwerden
Die Frage, die dieses Modul beantwortet: Was verlangen Datenschutz- und Branchenvorschriften von einem Salesforce-Entwurf?
Als ich in Australien gearbeitet habe, traf ich viele, die in die Architektur wollten und nie von der DSGVO gehört hatten. In Europa hat man oft nicht vom Datenschutzgesetz Kaliforniens gehört, oder von dem Kanadas oder Brasiliens. Das ist natürlich: Man kennt die Regeln dort, wo man arbeitet. Aber diese Gesetze reichen über Grenzen hinweg, und sie prägen den Systementwurf, obwohl keines davon von Salesforce handelt. Also gehören sie in einen Kurs zur Datenarchitektur.
Sie müssen nicht Jura studieren. Sie müssen aber sehen, dass eine Vorschrift ändern kann, wo Daten gespeichert werden, was Sie erheben, wer sie sieht, wozu Sie sie verwenden dürfen, wie lange Sie sie aufbewahren, wohin Sie sie schicken, ob Sie sie löschen können, welche Historie Sie behalten und was Sie später nachweisen können. Das sind nicht nur rechtliche Fragen. Es sind Fragen der Datenarchitektur.
Dieses Modul ist Architekturberatung, keine Rechtsberatung. Rechts- und Compliance-Teams entscheiden, welche Gesetze gelten und was sie verlangen. Die Architektur verwandelt diese Anforderungen in einen durchsetzbaren Entwurf.
Gesetze hören nicht an der Grenze auf
Abschnitt betitelt „Gesetze hören nicht an der Grenze auf “Zuerst das grösste Missverständnis: «Wir sind nicht in Europa, also gilt die DSGVO nicht.» Vielleicht, vielleicht auch nicht. Der räumliche Anwendungsbereich der DSGVO erfasst Organisationen ausserhalb der EU, die Personen in der EU Waren oder Dienstleistungen anbieten oder deren Verhalten dort beobachten (Artikel 3, Verordnung (EU) 2016/679 (opens in a new tab)). Wo Ihr Unternehmen seinen Sitz hat, beendet die Frage also nicht. Wo sind Ihre Kunden, Ihre Mitarbeitenden, die Menschen, deren Daten Sie halten, Ihre Systeme, Ihre Auftragsverarbeiter? Wohin reisen die Daten? Das ist wieder die Landschaft aus Kapitel 4. Sie können keine guten Datenschutzentscheidungen treffen, ohne zu wissen, wohin die Daten gehen.
Die Vorschriften, die Sie kennen sollten
Abschnitt betitelt „Die Vorschriften, die Sie kennen sollten “Hier sind die Namen, die man in der Architektur kennen sollte, mit dem, was jede abdeckt. Es ist eine Tabelle zum Wiedererkennen, keine Anwendbarkeitsmatrix: Lesen Sie sie nicht und entscheiden «Wir haben Kunden in Kalifornien, also gilt Anforderung X». Das entscheidet die Rechtsabteilung. Ihre Aufgabe ist, genug zu wissen, um die Frage zu stellen, bevor das System gebaut ist.
| Gesetz oder Standard | Wo oder was | Warum man es in der Architektur kennen sollte |
|---|---|---|
| DSGVO (opens in a new tab) | Europäische Union | Personenbezogene Daten, rechtmässige Verarbeitung, Rechte der betroffenen Personen, Aufbewahrung, Übermittlungen, Datenschutz durch Technikgestaltung |
| CCPA, geändert durch den CPRA (opens in a new tab) | Kalifornien | Die Rechte von Verbrauchern an den personenbezogenen Informationen, die Unternehmen über sie erheben |
| PIPEDA (opens in a new tab) | Kanada | Wie Organisationen des Privatsektors mit personenbezogenen Informationen umgehen |
| LGPD (opens in a new tab) | Brasilien | Das allgemeine brasilianische Gesetz zum Schutz personenbezogener Daten |
| Privacy Act 1988 (opens in a new tab) | Australien | Wie Organisationen mit personenbezogenen Informationen umgehen, nach den Australian Privacy Principles |
| HIPAA (opens in a new tab) | US-Gesundheitswesen | Geschützte Gesundheitsinformationen in den betroffenen Kontexten |
| PCI DSS (opens in a new tab) | Zahlungskarten | Schutz der Kontodaten von Zahlungskarten |
| Sarbanes-Oxley (SOX) (opens in a new tab) | Börsennotierte US-Unternehmen | Kontrollen und Nachweise hinter der Finanzberichterstattung |
| COPPA (opens in a new tab) | USA, Kinder online | Personenbezogene Informationen, die online von Kindern erhoben werden |
Die Liste wächst (immer mehr US-Bundesstaaten haben eigene Gesetze), und die Gesetze ändern sich. Deshalb will ich nicht, dass Sie eine Tabelle auswendig lernen und glauben, Sie hätten Datenschutzarchitektur gelernt. Lernen Sie die Namen, dann lernen Sie die Fragen, die sie überdauern.
Was die Gesetze gemeinsam haben
Abschnitt betitelt „Was die Gesetze gemeinsam haben “Die Einzelheiten unterscheiden sich, aber die grossen Datenschutzgesetze kommen immer wieder auf dieselben wenigen Dinge zurück, und jedes davon landet in der Architektur.
Rechte. Menschen können verlangen, ihre Daten einzusehen, sie zu berichtigen, sie zu löschen und sie mitzunehmen; nach den Gesetzen Kaliforniens und Brasiliens können sie ausserdem dem Verkauf ihrer Daten widersprechen. Jede dieser Anfragen bedeutet, die Daten der Person zu finden, und zwar alle.
Übermittlungen. DSGVO und LGPD regeln, wann personenbezogene Daten ihren Geltungsbereich verlassen, und verlangen dort, wohin sie gehen, einen angemessenen Schutz; PIPEDA erwartet dasselbe Schutzniveau, wenn ein Dritter die Daten verarbeitet, wo auch immer das ist. Das ist wieder die Landschaft: Welche Pfeile überqueren eine Grenze?
Meldung von Datenschutzverletzungen. Wenn personenbezogene Daten offengelegt werden, erwarten die Gesetze, dass Sie die Behörden und manchmal die betroffenen Personen innerhalb einer Frist informieren, die je nach Gesetz verschieden ist. Sie können nicht über Daten informieren, von denen Sie nicht wussten, dass Sie sie haben, und nicht sagen, was offengelegt wurde, wenn Sie die Kopien nicht finden.
Rechenschaftspflicht. Sie müssen die Einhaltung nachweisen können: Verzeichnisse darüber, was Sie verarbeiten und warum, Datenschutz-Folgenabschätzungen für Verarbeitungen mit hohem Risiko und, nach DSGVO und LGPD, Datenschutzbeauftragte. Die Architektur muss die Verzeichnisse liefern.
Beginnen Sie mit dem, was personenbezogen ist
Abschnitt betitelt „Beginnen Sie mit dem, was personenbezogen ist “Bevor Sie personenbezogene Informationen schützen, finden Sie sie. Manches ist offensichtlich: Name, Wohnadresse, Telefon, E-Mail. Manches nicht: Standort, Gerätekennungen, IP-Adressen, Bilder, Verhaltensdaten, alles, was sich einer Person zuordnen lässt. Und der Kontext zählt. Eine Lieferung von Steve Trucking trägt Name, Adresse, Telefonnummer, Liefernotizen und Fotos des Empfängers. Ein Foto zeigt vielleicht einen Karton auf einer Veranda, oder eine Person, oder das Innere eines Zuhauses. Die Lieferung ist operative Daten, aber einige ihrer Attribute sind personenbezogen. Deshalb hat Modul 3 Felder klassifiziert: Datenschutz beginnt damit, zu wissen, was man hält.
Wo liegen sie?
Abschnitt betitelt „Wo liegen sie? “«In Salesforce.» Wahrscheinlich nicht nur in Salesforce. Kamen sie von einem Handelspartner? Wurden sie nach Snowflake kopiert, von Data 360 aufgenommen, in ein Integrationsprotokoll geschrieben, von einem Benutzer exportiert, im Feldverlauf belassen, archiviert, in eine Sandbox kopiert, an einen Partner weitergegeben, im Gespräch eines Agenten verwendet? Personenbezogene Daten verbreiten sich. Wenn also die Rechtsabteilung fragt «Wo halten wir die Informationen dieser Person?», ist «Wir wissen, wo der aktuelle Wert ist» keine Antwort. Ich will die Landschaft und die Herkunft: wohin die Kopien gegangen sind.
Eine Telefonnummer, viele Kopien. Datenschutz gilt auch für die Kopien.
Warum dürfen Sie sie verwenden?
Abschnitt betitelt „Warum dürfen Sie sie verwenden? “Daten zu haben und sie verwenden zu dürfen, ist nicht dasselbe. Steve Trucking hat die Telefonnummer eines Empfängers, um die heutige Lieferung abzustimmen. Macht sie das zu einer Marketingliste? Nein. Die Rechtsgrundlage hängt von der Rechtsordnung und der Situation ab, und die Rechtsabteilung leitet das an, aber die Architektur muss die Antwort tragen: warum die Daten erhoben wurden, welche Nutzung erlaubt war, ob eine Einwilligung nötig war, erteilt, widerrufen, und für welchen Kanal, welche Adresse und welchen Zweck. Die Erlaubnis, Daten zu verwenden, muss sich als Daten darstellen lassen, denn ein Richtliniendokument kann zur Laufzeit keine Entscheidung treffen. Das nächste Modul modelliert sie.
Weniger erheben ist eine Architekturentscheidung
Abschnitt betitelt „Weniger erheben ist eine Architekturentscheidung “Eine der stärksten Datenschutzkontrollen ist, die Daten nicht zu erheben oder sie nicht dorthin zu kopieren, wo sie nicht gebraucht werden. Braucht Snowflake die Telefonnummer des Empfängers? Braucht die Analytik die vollständige Strassenadresse? Braucht die Sandbox echte Lieferfotos? Braucht ein Agent die persönlichen Angaben des Empfängers, um diese Frage zu beantworten? Wenn nicht, ist die stärkste Kontrolle vielleicht, sie dort nicht abzulegen. Jede Kopie, die Sie nicht anlegen, ist eine, die Sie nicht absichern, aufbewahren, löschen, für die Einwilligung verfolgen, prüfen oder bei einer Datenschutzverletzung melden müssen. Die billigsten sensiblen Daten zu steuern sind die, die Sie nie kopiert haben.
Aufbewahrung ist Teil des Modells
Abschnitt betitelt „Aufbewahrung ist Teil des Modells “«Wir behalten vorerst alles» ist eine Aufbewahrungsrichtlinie. Nur eine schlechte. Für wichtige Daten will ich zur Entwurfszeit wissen, wie lange wir sie brauchen und warum; ob eine Vorschrift ein Minimum festlegt oder eine andere ein Maximum; wann die Uhr beginnt; und was am Ende passiert: löschen, archivieren, entidentifizieren, und wo sind die Kopien? Finanzunterlagen müssen vielleicht eine festgelegte Zeit aufbewahrt werden. Der Torcode eines Empfängers hat Jahre nach der Lieferung keinen Zweck mehr. Diese Entscheidungen warten nicht, bis die Datenbank gross ist.
Anonymisiert, pseudonymisiert, verschlüsselt, maskiert
Abschnitt betitelt „Anonymisiert, pseudonymisiert, verschlüsselt, maskiert “Ersetzen Sie «Jane Smith» durch 7F92A1. Ist Jane anonymisiert? Nicht, wenn eine andere Tabelle noch sagt 7F92A1 = Jane Smith. Das ist Pseudonymisierung: Die direkte Kennung wird ersetzt, aber die Daten können mithilfe getrennt aufbewahrter Informationen wieder zugeordnet werden, und nach der DSGVO sind pseudonymisierte Daten weiterhin personenbezogene Daten (Artikel 4 Nr. 5). Anonymisierung geht weiter: Die Daten können der Person vernünftigerweise nicht mehr zugeordnet werden (Erwägungsgrund 26). Wenn also jemand sagt «Wir müssen es nicht löschen, wir entfernen einfach den Namen», seien Sie vorsichtig. Wenn die Person vernünftigerweise noch identifiziert werden kann, haben Sie diese Linie nicht überschritten. Ob ein Ergebnis das Gesetz erfüllt, entscheidet die Rechtsabteilung; die Aufgabe der Architektur ist, genau zu sagen, was das System tut: Kann es wieder zugeordnet werden, welche Schlüssel bleiben, wo sind die Zuordnungen?
Verwenden Sie die Wörter genau, denn sie lösen verschiedene Probleme. Verschlüsselung schützt Daten vor unbefugter Offenlegung; ein befugter Benutzer kann sie trotzdem entschlüsseln. Maskierung ändert, was bestimmte Benutzer oder Umgebungen sehen. Pseudonymisierung trennt die direkte Identität ab und behält einen Weg zurück. Anonymisierung beseitigt die vernünftige Möglichkeit, die Person zu identifizieren. Nur die letzte holt Daten aus «personenbezogen» heraus.
Aus Vorschriften werden Anforderungen
Abschnitt betitelt „Aus Vorschriften werden Anforderungen “Die Rechtsabteilung muss mir nicht sagen, dass ich einen Berechtigungssatz anlegen soll; das ist meine Seite der Linie. Die Rechtsabteilung sagt vielleicht: «Nur Mitarbeitende mit berechtigtem geschäftlichem Bedarf dürfen auf diese Kategorie personenbezogener Informationen zugreifen.» Dann übersetze ich: Wer sind sie, wie erkennen wir die Kategorie, wie wird Zugriff gewährt, was passiert, wenn jemand die Stelle wechselt, kann eine Integration sie lesen, kann es ein Agent, kann sie exportiert werden, und wie weisen wir nach, wer sie gesehen hat? Eigentümer:innen legen die Richtlinie fest; Architekt:innen setzen sie durch. Rechts- und Compliance-Teams legen die Pflicht fest, die Dateneigentümer:innen legen die Geschäftsrichtlinie fest, und die Architektur entwirft die Durchsetzung.
Von der Vorschrift zum Nachweis: Die Rechtsabteilung legt aus, die Eigentümer:innen legen die Richtlinie fest, die Architekt:innen machen sie funktionsfähig und nachweisbar.
Und Compliance ist kein Produkt. Sie können «Compliance: an» nicht kaufen. Verschlüsselung kann eine Anforderung unterstützen, Prüffunktionen liefern Nachweise, Aufbewahrungswerkzeuge führen eine Richtlinie aus, Einwilligungsdaten unterstützen die erlaubte Nutzung, aber eine Funktion zu lizenzieren macht eine Architektur nicht konform. Compliance entsteht aus dem ganzen Entwurf: Menschen, Richtlinie, Prozess, Daten, Kontrollen und Nachweise. Salesforce ist ein Teil davon, nicht alles. Und wenn eine Richtlinie wichtig genug ist, um sie durchzusetzen, fragen Sie, ob sie wichtig genug ist, um sie nachzuweisen: Wer hat am 17. März auf diesen Datensatz zugegriffen, wer hat dieses Feld geändert, was enthielt dieser Export? Modul 6 behandelt die Nachweise.
Datenschutz verändert die Landschaft
Abschnitt betitelt „Datenschutz verändert die Landschaft “Bei Steve Trucking kommen die personenbezogenen Daten des Empfängers über drei Partnerintegrationen herein. Salesforce braucht sie, um die Lieferungen abzuwickeln; die Crews brauchen einen Teil davon, nur für ihre eigenen Stopps, nur am Tag selbst; Snowflake will Lieferanalytik; die Finanzabteilung braucht genug für die Fakturierung, aber nicht, was die Crew sieht. Und ein Handelspartner darf nie die Empfänger eines anderen sehen. Datenschutz verändert die Pfeile: Bestimmte Felder gehen nicht nach Snowflake, die Analytik bekommt eine weniger identifizierbare Version, die Crews sehen nur ihre Stopps, die nachgelagerte Aufbewahrung unterscheidet sich von der operativen. Die Datenschutzanforderung steht nicht neben dem Landschaftsdiagramm. Sie verändert es.
Fragen, die die Vorschriften überdauern
Abschnitt betitelt „Fragen, die die Vorschriften überdauern “Vorschriften ändern sich, also führen Sie für alle sensiblen oder regulierten Daten einen beständigen Satz Fragen mit:
- Was ist es? Personenbezogen, sensibel, finanziell, gesundheitlich, Zahlungsdaten, Daten von Kindern oder anderweitig reguliert?
- Wo liegt es? Jede Kopie: Integrationen, Historie, Analytik, Archive, Sandboxes, Protokolle, KI-Nutzung.
- Warum dürfen wir es verwenden? Welcher Zweck und welche Rechtsgrundlage gelten? Ist eine Einwilligung beteiligt?
- Wer darf es verwenden? Menschen, Systeme, Partner, Integrationen, Agenten.
- Wie lange bewahren wir es auf, und was passiert am Ende?
- Kann die Person ihre Rechte daran ausüben? Auskunft, Berichtigung, Löschung, Datenübertragbarkeit, Widerspruch, soweit das Gesetz es vorsieht.
- Können wir nachweisen, was passiert ist? Zugriff, Änderungen, Exporte, Einwilligung, Löschung, Aufbewahrung.
KI-Governance wird zum Gesetz
Abschnitt betitelt „KI-Governance wird zum Gesetz “KI fügt einen weiteren Abnehmer gesteuerter Daten hinzu. Darf ein KI-System diese Daten verwenden, zu welchem Zweck, als Grounding, kombiniert womit, wiedergegeben in seiner Ausgabe, protokolliert wo, wie lange? Die Governance von KI wandert von der Unternehmensrichtlinie ins Gesetz: Die KI-Verordnung der Europäischen Union (Verordnung (EU) 2024/1689 (opens in a new tab)) ist das erste umfassende Beispiel. Was sie verlangt, hängt vom System und der Nutzung ab. Die Richtung für die Architektur ist klar: KI steht nicht ausserhalb der Governance; sie ist ein weiterer Abnehmer gesteuerter Daten.
Was Architekt:innen hier entscheiden
Abschnitt betitelt „Was Architekt:innen hier entscheiden “- Wo regulierte oder sensible Daten in die Landschaft eintreten, wo sie liegen, wohin sie sich bewegen und wo sie kopiert werden.
- Wie Rechts- und Compliance-Richtlinien zu durchsetzbaren Anforderungen werden, ohne dass die Architektur das Gesetz auslegt.
- Ob jedes System, das sensible Daten erhält, sie braucht oder ob eine weniger identifizierbare Version genügen würde.
- Wie Aufbewahrung, Löschung, Anonymisierung, Pseudonymisierung, Schutz und Nachweise den Lebenszyklus der Daten prägen.
- Welche Nachweise existieren müssen, um zu zeigen, dass die wichtigen Kontrollen tatsächlich funktioniert haben.
Vorschriften werden nicht zur Architektur, indem man ihre Namen auf eine Folie schreibt. Sie werden zur Architektur, wenn sie verändern, wie Daten erhoben, klassifiziert, bewegt, geschützt, aufbewahrt, gelöscht und nachgewiesen werden.
Weiterlesen
Abschnitt betitelt „Weiterlesen “- Die offiziellen Quellen der Vorschriften sind in der Tabelle oben verlinkt, geprüft am 2026-10-14.
- Verordnung (EU) 2016/679 (DSGVO) (opens in a new tab): Artikel 3 (räumlicher Anwendungsbereich), Artikel 4 Nr. 5 (Pseudonymisierung), Erwägungsgrund 26 (anonyme Informationen).
- Verordnung (EU) 2024/1689 (KI-Verordnung) (opens in a new tab), EUR-Lex.