nDSG und EDÖB – was bei SAP-Cloud-Workloads zu beachten ist
Worum es geht
Das revidierte nDSG (Datenschutzgesetz, in Kraft seit 1. September 2023) hat den Schweizer Datenschutz an die DSGVO angenähert, aber mit eigenen Akzenten. Die Aufsicht obliegt dem EDÖB (Eidgenössischer Datenschutz- und Öffentlichkeitsbeauftragter). Wer SAP in der Cloud betreibt und mit Daten von Schweizer Bürgern arbeitet, sollte fünf Themen verstehen.
1. Geltungsbereich
nDSG gilt für die Bearbeitung von Personendaten – auch dann, wenn der Verantwortliche im Ausland sitzt, sofern die Bearbeitung Wirkung in der Schweiz hat. Heisst konkret:
- SAP-Mandant in Frankfurt mit Schweizer Mitarbeiter-Daten → nDSG gilt
- SuccessFactors-Tenant in den USA mit Schweizer Reise-Daten → nDSG gilt
- SAP RISE in der Schweizer Region mit Schweizer Kunden-Daten → nDSG gilt (ist klar)
Auch besondere Personendaten (Gesundheits-, Glaubens-, Lohn-, Strafdaten) fallen unter erhöhten Schutz – relevant für SuccessFactors und HR-Daten generell.
2. Datenübermittlung ins Ausland
Drei Fallgruppen:
| Zielland | Voraussetzungen |
|---|---|
| Land mit angemessenem Schutz | direkt zulässig (EU/EWR-Länder, UK, andere mit Anerkennung) |
| Land ohne angemessenen Schutz | Standardvertragsklauseln + Risikobewertung |
| USA (Sonderfall) | Trans-Atlantic Data Privacy Framework + Standardvertragsklauseln |
SAP hat mit allen Hyperscalern und Sub-Providern die nötigen Standardvertragsklauseln; das ist nicht das eigentliche Problem. Das Problem ist die Risikobewertung:
- Welche Daten gehen wohin?
- Wer hat Zugriff?
- Welches Schutzniveau besteht im Zielland?
Für besonders schützenswerte Daten (Gesundheits-, Berufsgeheimnis-Daten) ist das eine ernsthafte Übung, kein Compliance-Theater.
3. Auskunftsrecht und Datenportabilität
Betroffene können Auskunft verlangen über die zu ihrer Person bearbeiteten Daten. In SAP-Setups ist das nicht trivial – Daten sind über mehrere Module und Mandanten verteilt:
- Stammdaten in S/4HANA
- HR-Daten in SuccessFactors
- Reisedaten in Concur
- Beschaffungsdaten in Ariba (für Mitarbeiter-bezogene Beschaffung)
- Logs in BTP, ETD, SIEM
Praktisch: ein Subject-Access-Request-Prozess definieren, der diese Quellen abdeckt. Frist nach nDSG: 30 Tage (DSGVO: auch 30 Tage, aber mit Verlängerung möglich).
Datenportabilität ist im nDSG nicht explizit verankert wie in der DSGVO, aber EDÖB empfiehlt sie als Best Practice.
4. Meldepflicht bei Datenschutzverletzungen
nDSG verlangt Meldung an EDÖB so rasch wie möglich bei erheblicher Verletzung – kein 72-Stunden-Cutoff wie bei DSGVO, aber praktisch ähnlich aggressive Erwartung.
Was zählt als Verletzung in einem SAP-Setup?
- Unauthorisierter Zugriff auf personenbezogene Daten (z.B. durch privilegierte Zugriffe ohne Geschäftsanlass)
- Ungewollter Daten-Export (z.B. CSV-Download und unsichere Mail-Weiterleitung)
- Versehentliche Veröffentlichung (z.B. Test-Daten mit Echtdaten in einem öffentlichen Repo)
- Cyber-Vorfall mit Daten-Exfiltration
Praktisch: SAP ETD oder gleichwertiges Logging ist nicht nur Sicherheits-, sondern Datenschutz-relevant.
5. Datenschutz-Folgenabschätzung (DSFA)
Bei "hohem Risiko" für die Persönlichkeit oder Grundrechte ist eine DSFA Pflicht. Was zählt als hohes Risiko in SAP-Setups?
- Profilbildung von Mitarbeitenden (z.B. Performance-Tracking, Sentiment-Analyse von E-Mails durch GenAI)
- Massendaten-Analysen mit personenbeziehbaren Daten
- Automatisierte Einzelentscheidungen (z.B. AI-gestützte Bewerber-Screening, Kreditentscheidungen)
- GenAI mit Trainings-Möglichkeit auf Personendaten
EDÖB bewertet GenAI-Anwendungen mit Profilbildungs-Charakter in der Regel als hochriskant – DSFA ist hier sicherheitshalber immer vorzunehmen.
Der Unterschied zur DSGVO – wo zählt er?
| Punkt | nDSG | DSGVO |
|---|---|---|
| Bussgeld-Höhe | bis 250.000 CHF (Person), strafrechtlich | bis 4 % Konzernumsatz, verwaltungsrechtlich |
| Verantwortliche Person | natürliche Person | Unternehmen |
| Meldepflicht-Frist | "rasch" | 72 Std |
| Verzeichnis Bearbeitungsaktivitäten | KMU-Erleichterung | KMU-Erleichterung mit Voraussetzungen |
| Datenschutzbeauftragter | optional, empfohlen | bei bestimmten Bedingungen Pflicht |
Der praktische Wirkungsunterschied ist nicht riesig – wer DSGVO-konform arbeitet, ist meist auch nDSG-konform. Aber: persönliche Strafhaftung im nDSG ist ein Punkt, der Verantwortliche oft unterschätzen.
Praktische Empfehlungen für SAP-Setups
a) Datenschutz-Inventar
Pro SAP-Service dokumentieren:
- Welche Personendaten werden bearbeitet?
- In welcher Region liegen sie?
- Wer hat Zugriff (intern und Sub-Provider)?
- Aufbewahrungsfrist?
- Lösch-Konzept?
Das ist unbequem, aber es ist die Grundlage für jede weitere Datenschutz-Frage.
b) Region-Pinning für sensible Workloads
Standard: Schweizer Region für alles, was Bürgerdaten enthält. Ausnahmen müssen begründet sein.
c) GenAI-DSFA als Standard
Vor jedem produktiven GenAI-Skill mit Personendaten eine DSFA durchführen. Das ist nicht überzogen – es ist Pflicht.
d) Subject-Access-Request-Prozess
Wer den Prozess noch nicht hat, sollte ihn jetzt aufsetzen. Ein Anfragen-Stau ist riskant.
e) ETD oder gleichwertiges Logging
Ohne Logging keine glaubwürdige Compliance-Story.
Was wir liefern
- Datenschutz-Inventar-Workshop für SAP-Landschaften
- DSFA-Begleitung für GenAI-Skills und Massendaten- Anwendungen
- Region-Migration zu Schweizer Tenants wenn nötig
- Subject-Access-Request-Tooling auf BTP
Was wir nicht tun
- Rechtsberatung. Wir sind keine Anwälte; konkrete Auslegungsfragen gehen an spezialisierte Kanzleien.
- Datenschutzbeauftragter im Mandat. Das ist eine Funktion, die intern oder bei einer spezialisierten Kanzlei besser aufgehoben ist.
Stand: 2026-05-10
