Enterprise CMS for EU data sovereignty

Why enterprise CMS hosting changes under EU data sovereignty

A self-hosted Drupal or WordPress site on EU infrastructure, or on premises, can keep site content, editor accounts and form submissions in the EU. The transfers usually happen elsewhere: in remote support sessions, offsite backups, CDN edge caches, and third-party add-ons that call servers abroad. The European Data Protection Board's *Guidelines 05/2021* state that remote access from a third country, even only displaying data on a screen for support, is a transfer, and so is storage in a cloud outside the EEA. Under Article 44 of the GDPR, every such transfer, including onward transfers, must meet Chapter V conditions. Treat this as a hosting and vendor decision before it is a platform decision, because the CMS choice matters less than who can touch the data and from where.

Start by mapping every party with a path into the CMS database, file store and logs. For each one, ask where it is located, from where its staff connect, and whether it can copy data elsewhere. Typical candidates are the hosting provider's support desk, the managed backup service, the CDN or web application firewall, the email relay that sends form notifications, and any plugin or module that loads a script, font or API from a foreign domain. Put a written data location commitment into each contract, covering remote access and subprocessors, not only primary storage. Ask your hosting partner to confirm in writing which of these run outside the EU, and whether any provider is subject to third-country law with extraterritorial reach, since the EDPB treats compliance with a third-country authority request as a transfer.

Which GDPR rules make EU data sovereignty a hosting decision

This table maps each GDPR, EDPB, CJEU and EU Data Act requirement to the build decision it forces on a CMS estate. Read it as a checklist: each row names a rule, where it comes from, and what it changes about where Drupal or WordPress runs, who can administer it, and which add-ons may send data abroad.

Requirement	Where it comes from	What it means for the build
Every transfer, including onward transfers, must meet Chapter V	GDPR Article 44; fines up to EUR 20 million or 4% of worldwide annual turnover under Article 83(5)(c)	Map every path where site data, editor accounts or form submissions leave the EEA, including backups, logs, CDN caches and support access. Fines apply to the controller, so the hosting contract and sub-processor list must reflect that map.
Remote access and cloud storage outside the EEA count as transfers	EDPB Guidelines 05/2021 (version 2.0)	A vendor engineer in a third country who can view the CMS admin screen during support is a transfer. Restrict support access by location, log it, and confirm where backup storage and monitoring tools hold data.
An EU processor subject to third-country law still needs an assessment	EDPB Guidelines 05/2021, Example 12	Using an EU hosting provider owned by a non-EU group does not itself create a transfer, but compliance with a foreign authority's request would. Ask the provider for its exposure analysis before signing and record the outcome.
Transfers need a valid transfer tool and a case-by-case check	CJEU Case C-311/18 (Schrems II, 16 July 2020); standard contractual clauses under Decision (EU) 2021/914	Standard contractual clauses survived Schrems II but still require a transfer impact assessment. Keep the signed clauses, the assessment and any module selection with the processing record for each vendor.
US vendors are covered only if on the Data Privacy Framework List	Commission Implementing Decision (EU) 2023/1795; appeal pending as Case C-703/25 P (Official Journal C/2025/6610)	Confirm the current status of any US plugin, SaaS add-on or hosting vendor on the list before relying on it. Because the appeal is pending, keep a fallback transfer tool and an EU-only option ready for each US dependency.
Technical measures may not be enough when the provider reads data in the clear	EDPB Recommendations 01/2020 (version 2.0)	If a provider must access content or form data unencrypted and foreign public authority powers exceed what is necessary, the EDPB does not expect an effective technical fix. For those workloads, choose EU-hosted or on-premises operation with no foreign administrator access.
US providers may have to disclose data they control, wherever it sits	18 U.S.C. 2713 (CLOUD Act), added 23 March 2018	Data stored on EU servers by a US-headquartered provider can still be within reach. Ask vendors whether they can be compelled to preserve or disclose data in their possession, custody or control, and document the answer in the risk assessment.
Foreign court or administrative orders are enforceable only through treaties	GDPR Article 48	Transfers in response to a third-country order are lawful only when an international agreement in force with the Union or a Member State supports them. Build an internal procedure for handling such requests, including legal review and notice to the controller where permitted.
Non-personal data held in the EU must be protected from unlawful foreign access, and customers may switch providers	EU Data Act Article 32 (Regulation (EU) 2023/2854); switching rights in Articles 25, 29 and 50, applicable from 12 September 2025, with switching charges banned from 12 January 2027	Choose hosting and add-ons that can be exported and moved to another provider or on-premises infrastructure. Keep configuration, content exports and deployment code under your control so a switch is possible within the notice and transition periods the Act sets.

Which CMS platforms fit EU-only hosting and why

Each CMS option has a different licensing, update and data-flow profile, and those differences decide whether the estate can stay under EU jurisdiction. The cards below cover the core platforms, the identity modules that keep editor sign-in inside your control, the AI and plugin paths that can send data abroad, and the headless option for a separate front end.

Drupal core for EU hosting

Drupal core is licensed under GPL-2.0-or-later, and there is no paid edition, so the hosting location and the operator are your decisions rather than a licence term. Drupal 11 requires PHP 8.3 or later, and Drupal 10 reaches end of life on December 9, 2026, so sites still on Drupal 10 need a dated move plan. Drupal 12 is scheduled for the week of December 7, 2026. Confirm with your hosting provider which PHP and database versions it supports and where backups and logs are stored.

SAML module for EU identity providers

The samlauth module lets Drupal act as a SAML service provider, so editor sign-in can run against an identity provider you operate or contract within the EU. Its latest stable release 8.x-3.14 supports Drupal 10.3 and later and Drupal 11. Check where your identity provider stores authentication logs and directory attributes, because those records are personal data even when the CMS itself stays in the EU.

OpenID Connect module for account creation

The OpenID Connect module lets an external provider authenticate Drupal users and creates accounts on first sign-in. That behaviour matters for EU sovereignty because account records can be created automatically from a provider's directory, so you must confirm which provider issues the identity and which attributes are copied into the site. Built-in clients cover generic OAuth 2.0, GitHub, Google, LinkedIn, Facebook and Okta, and any of these that is not EU-hosted needs a transfer assessment before use.

WordPress hosting and version controls

WordPress is released under GPLv2 or later, and WordPress.org recommends PHP 8.3 or greater with MariaDB 10.11 or greater or MySQL 8.0 or greater. Only the latest release in the 7.1 series is actively maintained, so your EU host must apply minor updates promptly. Auto-updates for core are on by default for new sites, but plugin and theme updates apply automatically only in special cases chosen by WordPress.org, so the update process must be documented and owned.

Plugin vendor review before EU deployment

Many WordPress plugins call external services for forms, analytics, fonts, maps, chat or embedded video, and each call can move visitor or editor data outside the EU. Build a register of every plugin and its vendor, record where each vendor processes data and which sub-processors it uses, and disable or replace any plugin that cannot document an EU processing path. Your transfer evidence depends on this register, so review it again whenever a plugin is added or updated.

Drupal CMS 2.0 and its AI tools

Drupal CMS 2.0 is the current major release of the distribution for marketers and content teams, and it includes optional AI tools. Those tools may send prompts, page content or editor input to a model provider, and that provider may process data in a third country. Before enabling any AI feature, confirm in writing where model calls are processed, whether prompts are retained, and whether the provider can be contractually bound to EU processing. Disable the AI modules until that evidence exists.

Headless options with a separate front end

Strapi, Payload and Directus suit estates where a separate front end is planned, but each has a different licence model. Strapi's MIT licence covers core, with components under ee directories under a separate Enterprise Edition licence. Payload is MIT licensed. Directus uses the Monospace Sustainable Core License 1.0, which counsel should review against your intended internal and professional-services use before selecting it. Host the API, database and media store in the EU and confirm the front-end host separately.

How EU-only hosting options compare for CMS data

In this model the organization or its implementation partner deploys Drupal or WordPress into a cloud account the organization owns, with the region set to an EU location. The application, database, file storage and backups all live in that account, so the organization controls configuration and access. The jurisdiction question moves to the cloud provider itself, because its staff, support tooling, sub-processors and parent company determine who can reach the data in practice.

Support access: Provider engineers or follow-the-sun support staff outside the EEA may view or troubleshoot resources. Remote viewing from a third country is a transfer under the EDPB's guidance, so confirm support locations and the controls around break-glass access.
Backups and replicas: Snapshots, disaster recovery copies and object storage replication can be configured to cross regions. Lock backups to EU regions and verify that replication settings are enforced.
US-parented providers: A provider with a US parent may still be subject to 18 U.S.C. 2713, which reaches data in its possession, custody or control wherever it sits. Ask for the provider's assessment of this exposure.
Contract terms: Data processing agreements, the sub-processor list with locations, transfer impact assessments and an exit clause under the Data Act.
Evidence produced: Region and resource configuration exports, access logs, key management records and the provider's sub-processor and support location documentation.

Confirm each provider's sub-processors and support locations in writing before signing, not only from the marketing region list.

Why plugins and SaaS add-ons are where data leaves the EU

The CMS core is rarely the transfer problem. Drupal and WordPress run on the servers you choose, and the database holds the content you put there. The data that leaves the EU usually goes out through the components around the core: form builders that store submissions in a vendor's cloud, analytics and tag managers that send visitor data to a third country, chat widgets, transactional email services, AI assistants that process page text or user questions, and embedded video players that load and log viewer activity. Each of these can send personal data to a vendor, and each vendor may store it or allow remote access from outside the EEA. Under the EDPB's reading of remote access and cloud storage (see EDPB Guidelines 05/2021), those flows are transfers even when the CMS itself stays on EU infrastructure.

WordPress plugins deserve particular attention because the update path is not fully automatic. By default, WordPress applies automatic updates to plugins and themes only in special cases chosen through the WordPress.org API, which the WordPress security team controls to patch critical vulnerabilities. Every other plugin update is your decision. That means the organization owns the update and review process: someone must track each plugin's vendor, check whether a new version changes data handling, and approve the change. Confirm which of your plugins call external services, and whether the vendor's terms and hosting location have changed since you installed them.

Drupal contributed modules raise a related question at a different point in the lifecycle. Contributed modules are not vendor SaaS, but many integrations, such as the SAML and OpenID Connect modules, pass identity data to external providers, and modules that call third-party APIs send data the same way. Build a register of every contributed module and custom integration, record the external endpoints each one contacts, and review that register at each core and module update. Before any add-on is installed, map its data flow: what fields it receives, where they are stored or processed, who can access them remotely, and whether a sub-processor sits outside the EEA. That inventory is the basis for any transfer assessment, including the Chapter V analysis and the supplementary measures you may need, so an incomplete inventory produces an incomplete assessment.

How EU data sovereignty work moves from inventory to audit-ready

The sequence turns an unmapped Drupal or WordPress estate into a documented position on where site data, editor accounts and form submissions live, who can reach them, and what evidence supports that position. Each phase closes with a named output that the next phase depends on.

Build the data and transfer inventory
Start by listing every data category the site handles: editor accounts, visitor analytics, form submissions, uploaded documents and backups. For each one, record where it is stored, which plugins, modules, embedded scripts and SaaS add-ons send it onward, and which vendor support paths can see it. Include remote support sessions, because the EDPB guidelines treat viewing data from a third country as a transfer, not only copying it. The output is a register that maps each category to its location, its recipients and its legal basis, reviewed by the data protection lead before design work begins.
Decide hosting and jurisdiction in writing
Choose whether the platform runs with an EU hosting provider or on premises, and record the reasons. For a hosted option, confirm where data is stored and backed up, which legal entities control the provider, and whether any sub-processor sits outside the EEA. Weigh the EDPB point that an EU processor subject to third-country law is not itself a transfer, but a third-country authority request would be, so exposure must be assessed before signing. The output is a signed decision record with contract terms covering data location, sub-processors, notification of government access requests and exit assistance.
Configure EU identity and EU form storage
Build the site so that editor logins and form submissions stay in the chosen location. Connect the Drupal SAML Authentication module or the OpenID Connect module to the organization's own identity provider, and confirm that account creation and role mapping happen there. Point the database, file storage, mail relay and form handlers at infrastructure in the agreed location, and check that caching, search and analytics components do not forward personal data elsewhere. The output is a configuration baseline and a test record showing that a test submission and a test login resolve only to approved endpoints.
Set remote access and support controls
Define the only approved ways that engineers, vendors and agencies may reach production, such as named bastion hosts or a VPN inside the EU, with session recording and individual accounts. Write a rule that prohibits support sessions from third countries, including screen sharing that displays personal data, and make the rule part of every vendor contract. Enable centralized logging of administrative access and review it on a set schedule. The output is an access procedure, a list of approved support paths, and sample logs that demonstrate the rule is enforced.
Assemble the transfer evidence pack
Collect the documents an assessor or supervisory authority will ask for: the transfer assessment for every remaining third-country flow, the standard contractual clauses or other transfer tool in force for each flow, the sub-processor list with locations, and the data inventory from the first phase. Where a US vendor remains in the chain, record whether the recipient appears on the Data Privacy Framework List and how that status is monitored, given the pending appeal in Case C-703/25 P. The output is a versioned evidence pack with a named owner and a statement of what each document proves. DeployOpen prepares this material. Independent auditors and certification bodies assess it.
Cut over and monitor the sovereignty position
Move production to the configured environment only after the inventory, access rules and evidence pack match what is deployed. Confirm that the update process for Drupal or WordPress core, modules and plugins runs inside the approved environment, and that security advisories reach the people who can apply them. Set a vendor review cadence that re-checks sub-processors, transfer tools and add-on data flows, and schedule a formal review date for the whole position. The output is a signed go-live record, an update schedule, and a dated review plan that triggers a fresh assessment whenever a new add-on or provider is introduced.

Transfer evidence to keep and which component produces it

This table maps each transfer evidence item to the component that produces it and the party that owns it. Read it as a working checklist: DeployOpen prepares the records, while auditors, regulators and counsel assess whether the transfer position holds.

Evidence item	What produces it and who owns it	Notes for the reader
Transfer register and data inventory	Controller's record of processing and data map, prepared with DeployOpen from the CMS database, form tables and media storage. Owned by the controller's privacy office.	List every form, editor account field and log store that holds personal data, including backups.
Add-on and module inventory with data flow notes	Installed plugin and module list with the outbound endpoints each one calls. Owned by the platform team, reviewed by the privacy office.	Plugins for analytics, chat, embeds and form builders are the most common source of unplanned transfers.
Provider and sub-processor list with support locations	Vendor register covering hosting, CDN, email, backup and support staff, including where each one accesses data. Owned by procurement and the privacy office.	Record remote support access from outside the EEA as a transfer, not only storage.
Signed standard contractual clauses under Decision 2021/914	Executed clause sets for each non-EEA recipient or onward recipient, stored with the contract file. Owned by legal counsel.	Confirm the module chosen fits the role of each party before signature.
Transfer assessment file citing EDPB Recommendations 01/2020	Documented assessment of third-country law and supplementary measures for each transfer. Prepared by the controller with counsel, supported by DeployOpen technical notes.	Where provider access to data in the clear is possible, the assessment must address whether an effective technical measure exists.
Hosting location configuration and backup location records	Infrastructure-as-code outputs, cloud region settings, storage bucket locations and backup target configuration. Produced by DeployOpen and the client platform team.	Capture the region and any replicas or snapshots kept in other regions.
Remote access logs	Bastion, VPN and support session logs showing who accessed the environment, from where and when. Produced by the infrastructure layer, owned by the client security team.	Retain logs under the client's own retention rule and confirm they cover vendor support sessions.
Data Privacy Framework list check for any US vendor	Dated screenshot or record of the vendor's entry on the Data Privacy Framework List at the time of review. Owned by the privacy office. Confirm current status with the vendor and the list before relying on it.	Adequacy covers only organizations on the list. The General Court judgment is under appeal (Case C-703/25 P), so keep the position under review.
Update and vendor review log	Dated record of CMS core, module and theme updates, security release application and periodic vendor reviews. Produced by DeployOpen and the client change board.	A current log shows the transfer position is reviewed when the stack, providers or law changes.

Questions to put to an EU hosting partner before scoping

Start with access, because access is where transfers happen. Ask the partner which legal entities can reach production systems, under which national law each entity operates, and whether any parent company outside the EU can compel staff or give them instructions. Under the EDPB's Guidelines 05/2021, remote access from a third country counts as a transfer even when the engineer only views data on a screen, so ask where support engineers connect from, whether sessions originating outside the EEA are blocked at the bastion or VPN layer, and how that block is logged. Request the written list of every access path, including emergency access and vendor remote tools, and confirm that the list is reviewed on a set schedule.

Then trace the copies. Ask where backups, log archives, monitoring data, search indexes and CDN caches are stored and processed, and which sub-processors touch each one. A CDN that caches form pages or editor previews can move personal data abroad even when the origin server sits in Frankfurt, so ask for the edge location policy in writing. Also ask how the partner reviews plugin and module vendors, which for WordPress and Drupal includes any SaaS add-on that receives form submissions or visitor data. The answer should name who approves a new add-on, what data it receives, how it is replaced if its vendor moves data abroad, and how long a swap takes on the site.

Finally, test the contract against reality. Ask how switching rights under the Data Act would work in practice: which export formats the partner supports for content, users, media and form submissions, who runs the export, and what happens to the data after a switch. Confirm that the partner will update the transfer impact assessment, the sub-processor list and the data flow map whenever a sub-processor changes, and ask how much notice the buyer gets before that change takes effect. Ask who keeps those records, where they are stored, and how the buyer receives them. Each answer should be checked against the signed contract, not a slide deck.

What EU data sovereignty for a CMS costs and requires

Does hosting a CMS in an EU data center make it GDPR compliant?

No. An EU data center removes one element of the problem, but it does not make a site compliant on its own. GDPR Article 44 applies to every transfer of personal data to a third country, including onward transfers, so remote access from outside the EEA can still count as a transfer even when the servers sit in Frankfurt or Paris. The EDPB Guidelines 05/2021 also say that displaying data on a screen for support is a transfer. Compliance depends on the full assessment: where data is stored and accessed, which subprocessors and plugins touch it, the legal exposure of each provider, and the documented safeguards. Treat data location as one input to that assessment, not the conclusion.

What drives the cost of an EU sovereign CMS setup?

Cost follows scope, and Drupal and WordPress carry no license fee, so the spend is in work and running services. The main drivers are:

Scope: number of sites, languages, forms and integrations that handle personal data.
Add-ons: each plugin, module or SaaS form tool that sends data abroad needs a review, a replacement or a contract.
Hosting model: EU cloud, EU managed provider or on-premises, each with different recurring costs.
Migration: moving Drupal 7 or older WordPress sites to a supported version, where themes may need rebuilding.
Evidence work: the transfer inventory, assessments and records you keep for an auditor.

One-time costs cover inventory, configuration and migration. Recurring costs cover hosting, security updates and support. Ask any partner for a quote that separates these lines and names who pays the hosting provider, the license holders and the legal reviewers.

How long does an EU data sovereignty CMS project take?

The duration depends on the written scope, and no fixed timeline applies across projects. The number of sites, the count of third-party add-ons, whether a migration is required, and how quickly your legal and procurement teams can review contracts will set the schedule more than the technical build. Migrations from Drupal 7 or older WordPress versions usually take longer than configuring a new hosting environment because content, redirects and themes must be handled. DeployOpen works on fixed-scope engagements agreed in writing before work starts. Ask for a schedule that lists each phase, the client dependencies in each phase and the review points where legal sign-off is needed, so you can see where delays would arise.

What does the client team need to provide for this work?

The work needs decisions and access from several internal owners, not only from IT. Expect to provide:

System owners who can confirm which sites, forms and editor accounts hold personal data and who uses them.
Legal review of the transfer inventory, contracts with hosts and vendors, and any supplementary measures.
Procurement involvement to approve EU hosting providers, support contracts and add-on subscriptions.
Identity provider access so editor single sign-on can be tested, including the account data that leaves your environment.

Without these owners, the inventory stays incomplete, and the technical changes can't be signed off. Confirm the named person for each area before the project starts.

Can our internal team run EU data sovereignty for the CMS alone?

Your team can handle some tasks alone, such as reviewing editor accounts, checking which site features load external scripts, and tightening access controls. Other tasks need specialist input. Building the data inventory, mapping every transfer, reviewing vendor and plugin terms, and deciding which supplementary measures apply all require legal input, because the answers affect contracts and liability. Technical steps such as hosting configuration, SSO setup and moving sites to supported versions require engineering skills and time. Many teams split the work: internal staff own the inventory and approvals, and an implementation partner handles the platform configuration and evidence preparation. Decide which parts you will keep in-house before you request a quote.

Is using a US-based CMS vendor or plugin provider prohibited under EU rules?

No rule bans using a US vendor, but the transfer and access rules still apply. The EU-US Data Privacy Framework adequacy decision, Commission Implementing Decision (EU) 2023/1795, covers only US organizations on the Data Privacy Framework List, and an appeal in Case C-703/25 P is pending. Before using a US provider, confirm whether it is on that list, what contract terms and standard contractual clauses it accepts, and whether it can be compelled by US authorities to disclose data held in the EU. The EDPB Recommendations 01/2020 say that where access to clear-text data goes beyond what is necessary and proportionate, no effective technical supplementary measure may be possible. Confirm the vendor's status and the measures with your legal counsel before use.

Which parts of the EU data sovereignty evidence must we keep?

Keep records that show where personal data is stored and accessed, who can reach it, and what legal basis or safeguard covers each transfer. Core items include the data inventory for each site and form, a list of subprocessors and plugins with their locations, signed contracts and the standard contractual clauses in use under Commission Implementing Decision (EU) 2021/914, transfer impact assessments, access logs, and records of each supplementary measure. Also keep the update history, since security patches on Drupal and WordPress arrive on a fixed cadence. These records are inputs for your assessors and auditors. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue the actual reports and attestations.

How DeployOpen scopes an EU-sovereign CMS engagement

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including EU cloud accounts, EU data centers and on-premises networks. For EU data sovereignty, the work starts with a written map of where site data, editor accounts and form submissions flow, and every component is configured to keep that flow under EU control.

How we scope

Map every system that touches site data, editor accounts and form submissions, including plugins and SaaS add-ons
Record which hosting location, administrators and support staff have remote or logical access to the data
Agree in writing which third-country transfers are excluded, which are accepted and which need transfer evidence
Confirm the Drupal or WordPress version, PHP level and update policy before any build work is quoted

How we build

Deploy Drupal or WordPress on EU infrastructure or on premises, with the database, media storage and backups kept in the agreed jurisdiction
Configure SSO through the SAML or OpenID Connect modules against the client's own identity provider, with no external login relays
Replace or disable form, analytics and embed components that send submissions or visitor data to non-EU endpoints
Test data flows, remote access paths and outbound requests before the site goes live

How we hand over

Deliver a data flow register listing each processor, hosting location, access path and transfer mechanism in use
Document the update, backup, restore and access review procedures so the client's own team can run them
Provide the configuration baseline and evidence set that the client's legal and compliance teams can review with their auditors
Confirm handover acceptance against the written scope, with deliverables listed by name

How we support

Offer ongoing support, upgrades and security patching as a retainer after the fixed-scope build ends
Review new plugins, modules and SaaS add-ons against the data flow register before they are enabled
Run continuous security testing of the site, its APIs and its integrations under a separate agreement
Revisit the transfer assessment when the hosting provider, vendor terms or the law changes