Wer SAP-Lösungen aus der Cloud bezieht – ob SAP S/4HANA Cloud, RISE with SAP, SAP BTP oder einzelne SaaS-Lösungen wie SAP SuccessFactors –, gibt einen Teil des Betriebs ab. Die Verantwortung für Sicherheit, Datenschutz und Nachweise gegenüber Revision und Aufsicht gibt man dagegen nicht vollständig ab. In der Praxis sehen wir immer wieder dieselben vier Fragen: Wer ist wofür zuständig? Was steht eigentlich im Vertrag? Wo finde ich die Nachweise? Und was muss ich als Kunde selbst tun?
Dieser Leitfaden fasst die vier Themen zusammen, die wir früher in einzelnen Kurzbeiträgen behandelt haben – das geteilte Verantwortungsmodell, Cloud-Service-Status und Verträge, das SAP Trust Center sowie Datenschutz – und ergänzt sie um eine Checkliste aus unseren Projekten.
1. Das geteilte Verantwortungsmodell
In jeder Cloud gilt das Prinzip der geteilten Verantwortung (Shared Responsibility): Der Anbieter sichert die Plattform, der Kunde sichert, was er darauf konfiguriert, speichert und berechtigt. Wo genau die Grenze verläuft, hängt vom Servicemodell ab.
| Ebene | IaaS | PaaS (z. B. SAP BTP) | SaaS / RISE with SAP |
|---|---|---|---|
| Rechenzentrum, Netzwerk, Hardware | Anbieter | Anbieter | Anbieter |
| Betriebssystem und Datenbank | Kunde | Anbieter | Anbieter |
| Laufzeitumgebung, Patches der Plattform | Kunde | Anbieter | Anbieter |
| Anwendungen und Eigenentwicklungen | Kunde | Kunde | geteilt – je nach Vertrag |
| Benutzer, Rollen, Berechtigungen | Kunde | Kunde | Kunde |
| Daten und deren Klassifizierung | Kunde | Kunde | Kunde |
Die letzte Zeile ist die wichtigste: Benutzer, Berechtigungen und Daten bleiben in jedem Modell Sache des Kunden. Ein Anbieter kann ein Rechenzentrum zertifizieren lassen – er kann aber nicht verhindern, dass ein Mitarbeitender eine zu weit gefasste Rolle erhält oder dass ein technischer Benutzer mit Standardpasswort aktiv bleibt.
Bei RISE with SAP ist die Aufteilung besonders fein. SAP übernimmt Infrastruktur und grosse Teile des technischen Betriebs; welche Aufgaben im Detail bei SAP und welche beim Kunden liegen, regelt das «Roles and Responsibilities»-Dokument zum Vertrag. Unsere Empfehlung: Lesen Sie dieses Dokument nicht nur bei Vertragsabschluss, sondern gleichen Sie es mit Ihren internen Prozessen ab. Typische Lücken finden wir bei Notfallbenutzern, bei der Überwachung von Schnittstellen und bei der Frage, wer eingespielte Security Notes auf Anwendungsebene testet.
2. Cloud-Service-Status und Verträge
Was ein SLA wirklich regelt
Service Level Agreements legen fest, welche Verfügbarkeit ein Dienst erreichen soll und was passiert, wenn er sie verfehlt. Beim Lesen lohnt es sich, auf vier Punkte zu achten:
- Messgrösse: Wie wird Verfügbarkeit berechnet – pro Monat, pro System, pro Region?
- Ausnahmen: Geplante Wartungsfenster, Notfallwartungen und vom Kunden verursachte Störungen zählen in der Regel nicht als Ausfall.
- Rechtsfolge: Bei Unterschreitung gibt es meist Gutschriften (Service Credits), keinen Schadenersatz. Ein Ausfall Ihres Monatsabschlusses wird dadurch nicht kompensiert.
- Wiederherstellung: Recovery Point Objective (RPO, wie viele Daten dürfen verloren gehen) und Recovery Time Objective (RTO, wie lange darf die Wiederherstellung dauern) sind für den Notfall oft wichtiger als die reine Verfügbarkeitsquote.
Prüfen Sie diese Werte gegen Ihre eigenen Anforderungen. Wenn Ihr Business Continuity Management für einen kritischen Prozess vier Stunden RTO verlangt, der Vertrag aber nur einen längeren Wert zusichert, ist das ein Risiko, das bewusst akzeptiert oder anders abgesichert werden muss.
Den Status laufend im Blick behalten
SAP stellt Informationen zum Zustand der Cloud-Dienste, zu geplanten Wartungen und zu Störungen online bereit und bietet Benachrichtigungen dazu an. Richten Sie diese Benachrichtigungen nicht auf eine Einzelperson, sondern auf ein Funktionspostfach von Basis-Team oder Betrieb ein – sonst geht die Wartungsankündigung in den Ferien unter. Halten Sie zudem in Ihrem eigenen Incident-Prozess fest, wie eine Störung beim Anbieter intern kommuniziert wird und wer entscheidet, ob Fachbereiche informiert werden.
3. Das SAP Trust Center: Nachweise statt Versprechen
Für Revision, Datenschutz und Informationssicherheit genügt es nicht, dass ein Anbieter Sicherheit verspricht – man braucht Nachweise. Das SAP Trust Center bündelt dafür öffentlich zugängliche Informationen zu Sicherheit, Datenschutz, Compliance und Cloud-Betrieb. Dort finden Sie unter anderem:
- Zertifikate und Prüfberichte wie ISO/IEC 27001 oder SOC-Berichte (SOC 1 und SOC 2) sowie länderspezifische Nachweise. Welche Nachweise für welchen Dienst gelten, ist je Produkt unterschiedlich.
- Vertragsdokumente wie die Vereinbarung zur Auftragsverarbeitung und Listen der Unterauftragsverarbeiter.
- Informationen zu Rechenzentren und Standorten, an denen Daten verarbeitet werden.
Viele Detaildokumente – etwa Unterlagen, die Kunden bei regulatorischen Anforderungen wie DORA im Finanzsektor oder der NIS2-Richtlinie unterstützen – sind nicht öffentlich, sondern für Kunden im Portal SAP for Me abrufbar. Planen Sie dafür einen festen Ablauf: Wer lädt die aktuellen Berichte jährlich herunter, wer prüft die Ausnahmen («Exceptions») in einem SOC-2-Bericht, und wo wird das Ergebnis dokumentiert?
Ein Hinweis aus der Praxis: Ein SOC-Bericht enthält fast immer einen Abschnitt mit Kontrollen, die der Kunde selbst erfüllen muss (Complementary User Entity Controls). Diese Liste ist Gold wert – sie beschreibt aus Sicht des Anbieters, wo Ihre Verantwortung beginnt.
4. Datenschutz in der SAP-Cloud
Für Schweizer Unternehmen gilt das revidierte Datenschutzgesetz (DSG), das seit dem 1. September 2023 in Kraft ist; wer Daten von Personen in der EU bearbeitet, muss zusätzlich die DSGVO beachten. In beiden Fällen bleibt Ihr Unternehmen für die Bearbeitung verantwortlich – der Cloud-Anbieter ist Auftragsbearbeiter.
Daraus ergeben sich konkrete Aufgaben:
- Vertrag zur Auftragsbearbeitung abschliessen und ablegen, inklusive der Liste der Unterauftragsbearbeiter.
- Datenstandort und Datenübermittlung klären: In welcher Region werden Daten gespeichert, und gibt es Zugriffe aus Drittstaaten, etwa im Support?
- Technische und organisatorische Massnahmen dokumentieren. SAP setzt Verschlüsselung bei Übertragung und Speicherung, Zugriffskontrollen und regelmässige Prüfungen ein – Ihre eigenen Massnahmen (Rollen, Protokollierung, Löschkonzept) gehören aber genauso ins Verzeichnis.
- Löschen und Sperren personenbezogener Daten auch in der Cloud konzeptionell regeln. Das gilt besonders für Test- und Qualitätssysteme, die mit Kopien produktiver Daten befüllt werden.
5. Checkliste: Was Sie als Kunde selbst tun sollten
| Bereich | Aufgabe | Rhythmus |
|---|---|---|
| Verantwortung | Roles-and-Responsibilities-Dokument mit internen Prozessen abgleichen, Lücken einem Verantwortlichen zuweisen | bei Vertragsabschluss, danach jährlich |
| Berechtigungen | Rollen und kritische Berechtigungen prüfen, Notfallbenutzer befristen und protokollieren | quartalsweise |
| Benutzer | Inaktive und externe Benutzer sperren, technische Benutzer mit Standardpasswörtern beseitigen | monatlich |
| Nachweise | Zertifikate und SOC-Berichte herunterladen, Ausnahmen und Kundenkontrollen bewerten | jährlich |
| Verfügbarkeit | SLA, RPO und RTO gegen BCM-Anforderungen prüfen, Statusmeldungen auf Funktionspostfach leiten | jährlich bzw. einmalig |
| Datenschutz | Auftragsbearbeitungsvertrag, Unterauftragsbearbeiter und Datenstandort dokumentieren, Löschkonzept pflegen | bei Änderungen, mindestens jährlich |
| Security Notes | Für die eigenen Komponenten und Schnittstellen bewerten, Tests auf Anwendungsebene einplanen | monatlich zum SAP Security Patch Day |
Wie Sie On-Premise, Private Cloud und Public Cloud sinnvoll kombinieren, beschreiben wir auf unserer Seite zur SAP Hybrid-Cloud-Strategie; einen Blick auf die Sicherheit der SAP Business Technology Platform wirft unser Beitrag zu SAP BTP Security.
Fazit
Die Cloud verschiebt Verantwortung – sie nimmt sie nicht ab. Wer das Verantwortungsmodell kennt, die Verträge mit den eigenen Anforderungen abgleicht und die Nachweise aus dem Trust Center regelmässig auswertet, kann der Revision jederzeit belegen, dass die Cloud-Nutzung im Griff ist. Die grössten Risiken liegen dabei erfahrungsgemäss nicht in der Infrastruktur des Anbieters, sondern bei Benutzern, Rollen und Daten – also genau dort, wo der Kunde selbst zuständig bleibt.
Unterstützung bei der Prüfung Ihrer Berechtigungen bietet das SAPify Security Audit; einen monatlichen Überblick über neue SAP Security Notes finden Sie auf unserer Seite SAP Security Notes.
