Sovereignty becomes a more complicated question when core ERP systems move to the cloud. Knowing where data is stored no longer tells an organization enough about how much control it retains over the environment.
Gabriele Fiata, Head of Market Strategy for SAP Cloud ERP Operations and Support, recently laid out SAP’s view in “What Sovereign Cloud Should Actually Mean for ERP,” describing sovereignty across four interdependent dimensions: data, operational, technical, and legal. The framework gives ERP customers a broader way to judge whether a cloud environment provides the level of control their business requires.
Sovereignty Extends Beyond the Location of ERP Data
Fiata’s four-part framework starts with data sovereignty, but his broader point is that location alone does not establish control. The other dimensions determine who can operate the environment, how independently the technology functions, and which legal authorities can ultimately reach it. Together, they show why meeting a data-location requirement does not necessarily establish sovereignty over an ERP environment, especially when those systems hold some of an organization’s most sensitive and operationally important information.
Data Sovereignty
In its “What Is Digital Sovereignty?” guide, SAP defines data sovereignty around how information is governed and processed under the laws of the country or region where it originates. That control extends beyond the primary system to secondary data flows such as logs and telemetry. SAP says its SAP Sovereign Cloud keeps customer data in local data centers or approved countries to prevent unauthorized cross-border transfers.
Operational Sovereignty
Operational sovereignty shifts the focus from where information sits to who can work with the environment. Fiata points specifically to the people responsible for administration and maintenance, particularly where regulated workloads require approved personnel and security clearances. SAP’s digital sovereignty guide extends that control to incident response and escalation, which it says should also remain within trusted jurisdictions.
Technical Sovereignty
Technical sovereignty goes deeper into the architecture. Fiata focuses on whether environments are genuinely isolated and whether the control plane has dependencies outside the country. SAP’s digital sovereignty guide adds that customers should be able to verify those controls through measures such as tenant isolation, encryption, and independent auditability rather than relying on assumptions about how the cloud environment operates.
Legal Sovereignty
Legal sovereignty addresses who can ultimately exercise authority over the environment. Fiata raises the risk that extraterritorial legislation can give foreign authorities legal reach even when systems are operated locally. SAP’s digital sovereignty guidance frames the issue around whether operations remain subject to the appropriate local legal authority and whether contractual and ownership arrangements limit unwanted foreign access.
Why Sovereignty Needs Differ Across SAP Customers and Workloads
Not every SAP workload requires the same sovereignty posture. In its digital sovereignty guidance, SAP explains that sovereignty does not require organizations to abandon hyperscalers or isolate their technology. Instead, the infrastructure and managed services supporting a workload need the appropriate legal, operational, and technical controls to remain governable regardless of the provider’s nationality.
Organizations may use global hyperscalers for some workloads and sovereign environments for others, depending on their sensitivity and regulatory requirements. That can leave companies with a mix of conventional cloud services and infrastructure subject to tighter local control rather than a single sovereignty model applied across the entire SAP landscape.
SAP’s own portfolio reflects that range. SAP Sovereign Cloud On-Site, for example, places SAP-operated infrastructure in a data center selected or owned by the customer. The model gives customers local physical control while SAP remains responsible for operating the infrastructure, providing another option for workloads that require a higher degree of sovereignty.
Regulatory requirements are one reason sovereignty needs differ across organizations and workloads. SAPinsider’s Cloud and AI Security for SAP research found that 85% of security leaders cited GDPR as the requirement demanding the most effort across SAP cloud landscapes, ahead of ISO 27001, SOX, and NIST. SAP makes the distinction particularly clear for regulated sectors in its digital sovereignty guide: “For the public sector and highly regulated industries, the question is no longer whether to use the cloud. It’s how to move to the cloud while staying compliant, secure, and in control so that modernization of ERP and HR systems can deliver innovation without introducing governance gaps.”
AI Adds a New Layer to the Sovereignty Equation
AI extends the sovereignty question beyond the ERP application and its underlying data. SAP describes sovereign AI as keeping models, data, and decision-making processes under the required legal authority and operational oversight. Those principles apply across the AI lifecycle.
That includes knowing where training and inference take place and preventing data from moving outside approved regions. SAP also connects sovereignty to the ability to trace and audit how AI operates through model provenance, logging, explainability, and independent verification. How those controls are applied depends in part on local regulatory and risk-management requirements.
Fiata brings the issue directly into the ERP environment by focusing on where AI workloads run, which jurisdiction governs inference, and who can access prompts, outputs, and underlying data. Because processing can now move through AI services as well as the ERP system itself, customers need to assess whether models, data, and inference remain within the same controlled boundary as the rest of the environment.
The Questions SAP Customers Should Be Asking
SAP customers evaluating sovereign cloud need to look past the label and establish what they actually need to control. That starts with the workload itself. A financial system subject to local regulation may require tighter restrictions than a less sensitive application, while public-sector, defense, or critical-infrastructure environments may need stronger operational and technical separation. Fiata’s guidance is to match the control model to those requirements rather than assume that every offering described as sovereign provides the same level of protection.
Customers then need to understand what sits behind that control model:
- Where is the data processed as well as stored?
- Who can administer the environment?
- Can foreign laws reach the provider or the data?
- Does the control plane depend on infrastructure outside the required jurisdiction?
Those questions also extend beyond transactional data to logs, telemetry, backups, and other secondary flows that may leave the primary ERP environment. SAP’s digital sovereignty guidance makes clear that these operational and technical details are part of determining whether control can actually be verified and enforced.
Sovereignty requirements can continue to change after an ERP environment is deployed. Regulations change, workloads become more sensitive, and AI can introduce new infrastructure and processing dependencies. SAP customers therefore need to know what level of sovereignty each workload requires today and whether the architecture can support tighter controls later if those requirements change. The practical goal is to retain enough control over each environment to satisfy the business, regulatory, and security requirements attached to it.
What This Means for ERP Insiders
Sovereignty decisions now happen per workload. SAP teams should map sovereignty requirements against individual modules and data types instead of applying one policy across the entire landscape. This shift asks procurement and architecture teams to justify each deployment choice against specific regulatory and sensitivity criteria.
AI features expand the sovereignty perimeter. Embedding copilots or generative AI into ERP introduces new jurisdictional questions about where inference, prompts, and outputs are processed. Teams evaluating AI-enabled ERP features need to extend existing data governance reviews to cover model behavior, not just stored data.
Sovereignty is a continuous governance discipline. Maintaining verifiable control requires continuous identity management, incident response, and audit processes. Organizations may need dedicated governance staff to keep sovereignty commitments current as regulations and AI capabilities evolve.
A version of this article was first published by SAPinsider.
