Introduction

The EU is putting more pressure on organizations to rethink how they choose, deploy, and govern digital technology.

For teams evaluating a digital experience platform in Europe, data sovereignty can no longer be treated as a simple question of where data is stored. Data sovereignty now raises bigger questions about cloud dependency, platform ownership, vendor control, legal jurisdiction, software transparency, and long-term portability.

That matters for any organization building digital experiences in Europe, especially in regulated industries, public sector environments, and other settings where control and auditability are essential.

What Is Data Sovereignty?

Data sovereignty refers to the principle that data is subject to the laws, governance requirements, and access controls of the jurisdiction in which it is collected, stored, processed, or accessed.

For European organizations, this often means ensuring that sensitive data, personal data, customer data, financial records, and other business-critical information are handled in ways that align with EU data protection regulations, local regulations, internal governance policies, and customer expectations regarding privacy and control.

But data sovereignty is not only a compliance concern. It is also an architectural concern.

Why Data Sovereignty Depends on More than Location

A platform can store data in Europe while still depending on:

• A non-European cloud provider
• A proprietary SaaS architecture
• Foreign vendor ownership
• Vendor-controlled infrastructure
• Closed software that cannot be fully inspected or adapted
• Service-level agreements that limit visibility into how data is stored and processed

Each of these factors can create sovereignty concerns, even when basic data residency requirements appear to be covered.

That is why data sovereignty matters for more than legal teams. Data sovereignty is a critical consideration for IT, security, procurement, digital experience, and business operations teams that need to protect sensitive data while maintaining control over their platforms.

Data Sovereignty vs. Data Residency

Data residency and data sovereignty are closely related, but they are not the same thing.

Data Residency Focuses on Where Data Is Stored

Data residency refers to the physical location where data is stored. For example, an organization may require customer information to remain in an EU-based data center.

That can be an important part of a compliance strategy, but it does not answer every question of sovereignty.

Data localization goes a step further by requiring certain data to remain within a particular country or region. These requirements are often driven by data sovereignty laws, data protection laws, or other relevant laws that affect how organizations collect, process, transfer, and store data.

Data Sovereignty Focuses on Who Controls the Data and Platform

Data sovereignty goes further, asking questions like:

• Who controls the platform?
• Who can access the data?
• Which country’s laws apply to the vendor and infrastructure provider?
• Can the system be audited?
• Can the organization move or operate the platform independently if requirements change?
• Are encryption keys controlled by the organization or by the vendor?
• Does the cloud strategy account for legal obligations in every particular jurisdiction where the organization operates?

This distinction is becoming more important. EU-hosted infrastructure may help address data location and data storage requirements, but it does not automatically solve broader sovereignty concerns.

If a platform is cloud-only, proprietary, or dependent on a vendor’s infrastructure roadmap, the organization may still have limited control over how its digital experience environment is governed over time.

How Data Sovereignty Is Determined

Data sovereignty is determined by more than the physical location where data is stored. Data sovereignty can also depend on where data resides, where teams process data, who owns the platform, which cloud providers are involved, how legal access is handled, and which applicable laws govern the vendor relationship.

In other words, knowing the data location is only the starting point. Organizations also need to understand how the platform works across multiple regions, cloud environments, data centers, and operational processes.

Why EU Technology Sovereignty Is Changing DXP Decisions

On June 3, 2026, the European Commission proposed a European Technological Sovereignty Package designed to strengthen Europe’s digital autonomy and reduce strategic dependency on external technology providers.

The package includes several major initiatives that point to a larger shift in how Europe evaluates digital infrastructure across cloud computing, AI, hardware, software, data, and applications.

These initiatives include:

• The Cloud and AI Development Act, which focuses on strengthening Europe’s cloud and AI infrastructure, expanding data center capacity, and reducing dependency on non-European cloud providers.
• Chips Act 2.0, which focuses on strengthening Europe’s semiconductor ecosystem and reducing supply chain dependencies in the hardware that digital services rely on.
• The EU Open Source Strategy, which promotes open-source software as a way to improve transparency, auditability, portability, and independence from closed vendor-controlled platforms.

Sovereignty Is Becoming a Design Principle

For digital experience platform decisions, sovereignty is becoming more than a contractual requirement. It is becoming a design principle.

Organizations now need to look beyond vendor assurances and ask whether their technology stack gives them enough control over:

• Infrastructure
• Deployment
• Software transparency
• Data access
• Auditability
• Long-term portability
• Data governance
• Data protection
• Cybersecurity risks

That creates new pressure for platforms built primarily around hyperscaler-dependent or cloud-only delivery models.

In regulated industries and public sector procurement, the question is no longer just whether a platform can host data in Europe. The bigger question is whether the organization can truly govern the platform on its own terms.

Why Cloud-Only DXP Models Can Create Sovereignty Risk

Cloud-based software has real advantages. Cloud tech can simplify operations, speed up deployment, and reduce the burden on internal IT teams.

But when a digital experience platform is only available through a vendor-controlled cloud environment, organizations may have less control over the infrastructure, legal exposure, and operating model behind their digital experiences.

Common Sovereignty Challenges with Cloud-Only Platforms

A cloud-only DXP can create several key challenges for organizations with strict data sovereignty needs:

• The organization may be tied to a specific hyperscaler or hosting model.
• The vendor’s ownership structure may introduce legal or jurisdictional dependencies.
• The platform may be difficult to audit beyond contractual commitments.
• Portability may be limited if the organization needs to change infrastructure providers.
• Long-term control may depend on the vendor’s product roadmap, pricing model, and deployment strategy.
• Teams may have limited visibility into where data resides, how data is stored, or which storage locations are used across multiple regions.

These risks become more important when organizations are subject to strict procurement rules, security requirements, public accountability standards, or sector-specific regulations.

A vendor can offer EU data residency and still leave customers with limited control over the deeper layers of the stack.

Cloud Provider Choice is Part of Sovereignty

For many global businesses, cloud storage and cloud computing are necessary parts of modern operations. The issue is not whether organizations should use the cloud. The issue is whether they can select cloud providers and cloud environments that match their sovereignty, compliance, and operational requirements.

For example, an AWS data sovereignty strategy may include region selection, data encryption, access controls, encryption keys, and contractual commitments. Those measures can be useful, but they should still be evaluated within a broader sovereignty model that encompasses vendor ownership, legal jurisdiction, portability, and data control.

A sovereign cloud approach can help organizations address some of these requirements, but it should not be treated as a substitute for platform-level control.

Why Vendor Ownership Matters for Data Sovereignty

Vendor ownership is also part of the sovereignty conversation.

For example, Contentful has long been associated with the European technology market. But Salesforce has just announced a definitive agreement to acquire Contentful, which shows why organizations should be careful about relying on vendor identity, headquarters, or brand history as a sovereignty strategy.

Why? As Drupal founder and Acquia co-founder Dries Buytaert explains, Salesforce is a US corporation and falls under US laws like the CLOUD Act. This means that once the acquisition goes through, Contentful becomes subject to US law as well. “For governments, public institutions, and regulated industries,” Buytaert says, “it exposes a harder truth: a vendor being European today is no guarantee it stays European tomorrow.”

Vendor Identity Can Change Over Time

Ownership can change. Commercial strategy can change. Deployment options can change.

A vendor that seems to be aligned with European sovereignty priorities today may not remain structurally aligned in the future.

For organizations making long-term platform decisions, this matters because legal jurisdiction does not depend only on where data is stored. It can also depend on the provider, parent company, operating model, and the platform's infrastructure relationships.

That does not mean every cloud vendor or acquisition creates the same level of risk. But it does mean organizations should evaluate sovereignty based on structural control, not just brand positioning.

The CLOUD Act Is Part of the Evaluation

For European organizations, the CLOUD Act is often part of the broader data sovereignty conversation because it can affect providers subject to U.S. jurisdiction, even when data is stored outside the United States.

That does not mean every U.S.-connected vendor creates the same risk. But organizations need to understand which laws apply, how legal access requests are handled, and whether their platform architecture provides sufficient control to meet internal policies, data protection requirements, and customer trust expectations.

Why Open Source Matters for Data Sovereignty

Open source does not automatically guarantee data sovereignty. Organizations still need the right governance, infrastructure, security, and operational maturity.

But open source can give organizations a stronger foundation for sovereignty by reducing dependence on a closed, vendor-controlled platform.

Open Source Gives Organizations More Visibility and Control

With open-source software, organizations have more ability to:

• Inspect how the platform works
• Audit the code
• Adapt the software to specific requirements
• Operate the platform in the environment that best fits their governance model
• Reduce dependency on a single vendor’s closed architecture or roadmap
• Maintain control if cloud strategy, data sovereignty compliance, or business requirements change

That transparency matters when sovereignty depends on more than contractual promises.

This is why open source is increasingly being treated as a strategic control layer, helping organizations avoid unnecessary dependency on a single vendor’s closed architecture, roadmap, or commercial model.

For European organizations, that flexibility can be especially valuable as data laws, procurement rules, and infrastructure requirements continue to evolve.

Why Self-Hosted Deployment Matters

Open source is only part of the answer. Deployment flexibility matters just as much.

A platform may be open, but if it can only run in a vendor-controlled cloud environment, the organization still has limited control over where and how that platform operates.

Self-Hosting Gives Organizations More Control Over the Full Environment

Self-hosted deployment gives organizations more direct control over the infrastructure behind their digital experiences.

Instead of being locked into a vendor-controlled cloud model, teams can choose where the platform runs, which infrastructure providers are involved, how access is governed, and how the environment aligns with internal security and compliance requirements.

For organizations with data sovereignty requirements, this can make a meaningful difference.

A self-hosted model can help organizations:

• Choose EU-based infrastructure or data centers that align with their requirements
• Reduce dependency on a single hyperscaler or SaaS vendor
• Apply their own security, monitoring, and access control policies
• Maintain more control over upgrades, integrations, and operational timelines
• Preserve portability if legal, regulatory, or business requirements change
• Decide how to encrypt data and manage encryption keys
• Limit unnecessary transfer of data across regions or vendors

The ability to self-host is not just a technical detail. It is a strategic option that gives organizations more room to adapt as requirements change.

Data Sovereignty Best Practices for DXP Evaluation

Data sovereignty compliance depends on a mix of legal, technical, and operational decisions. The right approach will vary based on the organization’s industry, countries of operation, risk profile, and data sovereignty needs.

Still, several data sovereignty best practices can help organizations evaluate DXP options more effectively.

Map Where Data Is Stored, Processed, and Accessed

Organizations should understand where data is stored, where it is processed, where it may be transferred, and who can access it.

This includes customer data, personal data, financial records, sensitive data, operational content, and other information that may fall under data protection regulations or local laws.

Align the Cloud Strategy with Sovereignty Requirements

A sovereignty-ready cloud strategy should account for more than performance and cost. Your strategy should also address data location, storage locations, data centers, cloud providers, service level agreements, legal obligations, encryption, and portability.

This is especially important for global organizations operating across multiple regions or working under different local regulations.

Use Security Controls that Support Data Protection

Data security is a key component of sovereignty. Organizations should evaluate how each platform supports access control, data encryption, monitoring, audit trails, and, where appropriate, the ability to encrypt data using organization-controlled keys.

These controls can help protect sensitive data and reduce cybersecurity risks, but they should work alongside governance and deployment controls rather than replace them.

Maintain Flexibility as Requirements Change

Data sovereignty is becoming more important as laws and regulations continue to evolve. A platform that provides organizations with greater deployment flexibility, auditability, and control over data can make it easier to adapt as data sovereignty laws, data protection laws, or procurement requirements change.

This is where operational sovereignty matters. Organizations need the practical ability to run, govern, and adjust their digital experience infrastructure without being locked into a single vendor-controlled model.

How Liferay DXP Helps Organizations Stay in Control

Liferay DXP is open-source software built for organizations that need flexible, secure, and scalable digital experiences. That open-source foundation gives businesses and public-sector teams more transparency and control than they would typically have with a closed, proprietary platform.

Liferay DXP also gives organizations deployment flexibility, which is especially important for teams that need to align digital experience infrastructure with sovereignty, security, and compliance requirements.

Self-Hosted Deployment

With self-hosted deployment, teams can run Liferay DXP on their own infrastructure or in a cloud environment of their choosing.

That gives organizations more control over where their platform runs, how it is governed, and how it aligns with internal security, compliance, and data sovereignty requirements.

Liferay Cloud Native Experience

With Liferay Cloud Native Experience, organizations can run and scale Liferay DXP on their own cloud and take advantage of existing cloud infrastructure.

This gives teams a way to modernize deployment and operations without sacrificing control over the environment behind their digital experience platform.

A Flexible Foundation for Enterprise Digital Experiences

With Liferay DXP, organizations can build and manage:

• Websites
• Customer portals
• Partner portals
• Intranets
• Commerce experiences
• Self-service environments
• Content-rich digital experiences
• Workflow-driven applications

You can do this without being forced into a cloud-only operating model.

That combination is especially relevant for European organizations evaluating digital experience platforms through the lens of data sovereignty. Liferay DXP gives them the flexibility to choose the deployment approach that best fits their security, compliance, infrastructure, data governance, and operational needs.

Questions to Ask When Evaluating a DXP for Data Sovereignty

As data sovereignty becomes a bigger part of technology procurement, organizations need to ask more than, “Where will our data be stored?”

They should also look at how much control they will have over the platform, infrastructure, vendor relationships, and long-term roadmap.

Platform Control

• Can the platform be self-hosted?
• Is the platform open-source or closed-source?
• Can our teams inspect, audit, and adapt the platform if needed?
• Are deployment options structurally committed or likely to be phased out?
• Does the platform help us maintain control if data sovereignty needs change?

Infrastructure and Hosting

• Can we choose the infrastructure provider and region where the platform runs?
• Are we dependent on a specific hyperscaler or vendor-controlled cloud environment?
• Can we select cloud providers based on our compliance, performance, and sovereignty requirements?
• Can we migrate the platform if our sovereignty requirements change?
• Can the platform run across multiple regions without creating unnecessary data sovereignty risk?

Legal and Governance Considerations

• What legal jurisdiction applies to the vendor and its parent company?
• What legal jurisdiction applies to the cloud or infrastructure provider?
• Which relevant laws apply in each particular country where we operate?
• How does the vendor respond to legal access requests?
• Does the vendor provide real architectural control, or only data residency commitments?
• How will the platform help us ensure data sovereignty as laws, regulations, and customer trust expectations evolve?

These questions help separate genuine sovereignty capabilities from surface-level promises.

Build Digital Experiences on Infrastructure You Control

The EU’s technology sovereignty agenda reflects a growing reality: organizations need more control over the technology stacks that power critical digital services.

For digital experience platforms, that means data residency is no longer enough. Organizations also need to evaluate vendor dependency, cloud architecture, software transparency, deployment flexibility, and long-term portability.

Liferay DXP was built around principles that align with this shift:

• Open source transparency
• Deployment flexibility
• Enterprise-grade security and scalability
• Extensibility
• Infrastructure control
• Long-term portability
• Stronger control over data and deployment decisions

For European organizations that need to deliver modern digital experiences without giving up control of their infrastructure, Liferay DXP offers a practical path forward.

Explore how Liferay DXP’s deployment can help your organization build digital experiences on infrastructure you control.

Frequently-Asked Questions

Does the U.S. have data sovereignty laws?

The U.S. does not have one single federal data sovereignty law that works like a national data localization framework. Instead, data control and privacy requirements are spread across federal laws, state privacy laws, sector-specific regulations, and rules that can affect cross-border data access.

For European organizations, the key concern is often whether a technology provider is subject to U.S. jurisdiction. In some cases, that can affect how data may be accessed through valid legal processes, even if the data is stored outside the United States.

What is an example of data sovereignty?

A common example of data sovereignty is a European public-sector organization requiring that citizen data be stored, processed, and governed within the EU.

But true data sovereignty would go beyond choosing an EU data center. The organization would also evaluate who owns the platform, which cloud provider runs the infrastructure, which laws apply to the vendor, who can access the data, and whether the organization can audit the platform or move it if requirements change.

What is the principle of data sovereignty?

The principle of data sovereignty is that data should remain under the legal, operational, and governance control of the organization or jurisdiction responsible for it.

In practice, that means organizations need to understand not only where data is stored but also who controls the platform, which laws apply, how access is managed, and whether the underlying technology provides sufficient transparency and portability to maintain control over time.