SAP souverän in der Cloud betreiben: Was wirklich zählt

Definition

SAP souverän in der Cloud betreiben bedeutet, SAP-Systeme so zu betreiben, dass Datenresidenz, Zugriffskontrolle, Governance und Compliance nachweisbar eingehalten werden. Es ist eine Kombination aus Architektur, organisatorischen Regeln und technischen Kontrollen, nicht nur „SAP in einem EU-Rechenzentrum“.

Es ist nicht gleichbedeutend mit „maximal abgeschottet“ oder „immer On-Prem“, sondern beschreibt einen Anforderungen-Rahmen für Betrieb, Verwaltung und Audit.

Einleitung

Wenn du SAP in die Cloud bringst, kommen zwei Welten zusammen: mehr Flexibilität und Skalierung auf der einen Seite, strengere Anforderungen an Datenschutz, Sicherheit und Kontrolle auf der anderen. Genau hier setzt der Begriff „souverän“ an.

Dieser Artikel ordnet ein, was SAP Sovereign Cloud im europäischen Kontext bedeutet und wie du daraus eine umsetzbare Entscheidung ableitest.

Was „Sovereign Cloud“ in Europa praktisch heißt

Im Kern geht es um digitale Souveränität: Daten sollen in Europa bleiben, Zugriffe sollen nachvollziehbar und kontrollierbar sein, und die Organisation muss gegenüber Prüfern erklären können, wie Betrieb und Verwaltung abgesichert sind. Dazu gehören DSGVO, regulatorische Anforderungen (je nach Branche) und ein Modell, das mit EU- und Deutschland-spezifischen Vorgaben kompatibel ist.

Wichtige Unterscheidung: „EU-Datenresidenz“ beantwortet nur die Standortfrage. Souveränität umfasst zusätzlich die Kontrollfrage: Wer kann administrativ zugreifen, nach welchen Regeln, mit welchen Protokollen, und wie wird das im Audit belegt?

SAP Sovereign Cloud, SAP Cloud Infrastructure und Delos Cloud einordnen

Bei SAP tauchen mehrere Begriffe auf, die in Projekten oft vermischt werden: SAP Sovereign Cloud als Konzept/Angebotswelt, SAP Cloud Infrastructure als Infrastruktur-Basis für SAP Cloud-Angebote und Delos Cloud als deutscher Ansatz speziell für den öffentlichen Sektor. Für Entscheider zählt weniger das Label, sondern ob das Zielbild eure Anforderungen an Datenschutz, Kontrolle, Betrieb und Audit erfüllt.

Praktische Leitfrage: Deckt das Modell eure Provider- und Admin-Zugriffsregeln ab (zum Beispiel Vier-Augen-Prinzip, getrennte Rollen, nachvollziehbare Wartungsfenster) und passt es zu eurem Compliance-Rahmen wie ISO/IEC 27001, BSI C5 Typ II oder C3A (Criteria Enabling Cloud Computing Autonomy)?

Welche Betriebsmodelle passen zu welchen Anforderungen?

Die meisten Organisationen landen nicht bei „alles Cloud“ oder „alles On-Prem“, sondern bei einem bewussten Mix. Drei Modelle sind entscheidungsrelevant:

• Hybrid: Kernprozesse bleiben strikt kontrolliert, Erweiterungen (z. B. Integration, Analytics, KI) laufen flexibel auf einer Cloud-Plattform.
• Private Cloud: sinnvoll, wenn Mandantentrennung, feste Betriebsprozesse und definierte Kontrollpunkte für Verwaltung und Support zentral sind.
• On-Prem in eigener Infrastruktur: relevant bei sehr hohen Schutzanforderungen oder festen Standortvorgaben, wenn maximale Kontrolle Vorrang vor Skalierung hat.

Der Nutzen für Anwender entsteht dann, wenn Governance nicht bremst, sondern Klarheit schafft: schnellere Freigaben, weniger Schatten-IT und stabile Betriebsprozesse, die Fachbereiche nicht bei jedem Audit ausbremsen.

Architektur: S/4HANA, SAP BTP und KI-Cloud zusammen denken

Viele Cloud-Entscheidungen scheitern später an Integrationen. Deshalb sollte das Zielbild drei Ebenen sauber trennen: das SAP S/4HANA-Kernsystem, Erweiterungen/Integrationen über die SAP Business Technology Platform (BTP) und KI-Cloud-Szenarien (z. B. SAP EU AI Cloud oder KI-Workloads entlang EU AI Act).

Typische Architekturfrage: Wo liegen welche Datenklassen, wie werden sie in BTP-Prozessen verarbeitet, und welche Kontrollen gelten für KI (z. B. Protokollierung, Datenminimierung, Berechtigungskonzepte)? So verhindert ihr, dass sensible Daten „nebenbei“ in nicht freigegebenen Flows oder Services landen.

Compliance, Audit und Zugriffskontrollen: die echten Knackpunkte

Sicherheit in souveränen SAP-Setups ist weniger eine Tool-Frage als eine Kontroll- und Nachweisfrage. Prüfer wollen verstehen, wie ihr Datenschutz und Sicherheit im Betrieb zuverlässig umsetzt: von Rollenmodellen bis Logging, von Schlüsselmanagement bis Drittanbieter-Zugriffen.

Drei Themen entscheiden fast immer über den Projekterfolg:

• Administrative Kontrolle: klare Regeln für Provider- und Partner-Zugriffe, inklusive Protokollierung und Genehmigungsprozessen.
• Daten- und Workload-Klassifizierung: welche Systeme/Daten dürfen wohin, was bleibt zwingend in eigenen oder europäischen Infrastrukturen?
• Audit-Fähigkeit: Reports, Prozesse und Verantwortlichkeiten, die ISO/BSI-Anforderungen nicht nur erfüllen, sondern belegbar machen.

Implementierungsfahrplan: von der Einordnung zum Rollout

Ein pragmatischer Fahrplan reduziert Risiko und Diskussionen. Er beginnt nicht mit der Migration, sondern mit Klarheit über Anforderungen und Zielarchitektur.

1) Anforderungen und Rahmen klären

DSGVO, Branchenregeln, interne Vorgaben, EU AI Act (falls KI geplant ist), Schutzklassen und Audit-Erwartungen definieren. Ergebnis ist ein verbindlicher Rahmen für Betrieb, Verwaltung und Anbietersteuerung.

2) Zielarchitektur und Betriebsmodell festlegen

Festlegen, welche SAP-Systeme in welches Modell gehören (Hybrid/Private/On-Prem), inklusive BTP-Integrationen und Schnittstellen.

3) Migration in Wellen

Pilot-Umfang definieren, dann stufenweise Rollout-Strategie mit Testkonzept, Cutover-Plan, Coexistence (wenn nötig) und klarer Abnahme durch Fachbereiche und Compliance.

Use Case (Mini-Story): öffentlicher Sektor

Eine Behörde möchte SAP-Prozesse modernisieren, darf aber bestimmte Daten nur in europäischen Infrastrukturen verarbeiten und muss Admin-Zugriffe streng steuern. Statt „alles neu“ wird ein Hybrid-Setup gewählt: das Kernsystem bleibt in einem streng kontrollierten Betriebsmodell, während Integration und digitale Services über BTP standardisiert werden. Ergebnis für die Anwender: stabilere Prozesse, schnellere Änderungen im Fachverfahren und weniger Abstimmungsaufwand bei Prüfungen, weil Audit-Nachweise von Anfang an geplant sind.

Kosten, Lizenzierung und ROI: wie man sinnvoll rechnet (ohne Preislisten)

Die häufigste Kostenfalle ist die Verwechslung von „verlagern“ und „modernisieren“. Souveräne Anforderungen erhöhen oft den Aufwand bei Betrieb, Kontrollen und Nachweisen, können aber gleichzeitig Risiken, Audit-Aufwand und Stillstandszeiten senken. ROI entsteht typischerweise durch planbaren Betrieb, weniger Compliance-Reibung und eine Architektur, die Erweiterungen (z. B. digitale Services oder KI) ohne Schattenlösungen ermöglicht.

Zur Lizenzierung: Hybride Lizenzmodelle und Vertragsrahmen sollten früh geprüft werden, damit Architektur und Beschaffung zusammenpassen. Sonst wird ein gutes Zielbild später durch „geht lizenztechnisch nicht“ ausgebremst.

Wann externe Unterstützung sinnvoll wird

Externe Unterstützung lohnt sich, wenn Datenschutz, Governance, Architektur und Migration gleichzeitig entschieden werden müssen oder wenn öffentliche/ regulierte Anforderungen (z. B. BSI, VS-NfD-Kontext, strenge Audit-Pflichten) den Spielraum stark begrenzen. Sinnvoll ist auch ein neutraler Blick, wenn mehrere Anbieter-Optionen im Raum stehen und ihr eine belastbare Entscheidungsgrundlage braucht, statt Meinungen.