Why LMS data sovereignty is a hosting and vendor-chain question
For a DPO or CIO who must show that learner records stay under EU jurisdiction, the platform licence is not the constraint. The hosting provider, remote administrative access, third-party plugins and any AI or video services decide whether personal data is transferred to a third country. Moodle and Open edX are both open source with no licence fee attached to the core, so the question to answer is who can reach the data, from where, and under which law. GDPR Article 44 applies to every transfer, including onward transfers, and the EDPB's Guidelines 05/2021 treat even remote access from outside the EEA, including support staff only viewing a screen, as a transfer. A hosting contract with an EU data centre does not settle the question if a US-based vendor can log in to administer the site.
On the Moodle versus Open edX question for this context, the supplied facts favor neither on licence grounds. Both are self-hostable: Moodle is GPL-3.0 and Moodle 5.3.0 carries security fixes until October 1, 2029, while Open edX is AGPL-3.0 and only its latest named release, Verawood, is supported at a given time, with Willow planned for December 2026. Moodle's longer security window fits a sovereignty plan that must run for years without a forced upgrade. Open edX, by contrast, is recommended for production through a service provider or Tutor, which means the deployment and operations chain is wider and must be mapped contractually. Confirm with each candidate hosting partner which staff hold administrative access, where they sit, and whether backups and logs leave the EEA.
Map the vendor chain before choosing a host. List every component that touches learner data: the LMS core, authentication (for example, an external identity provider reached over SAML 2.0 or LDAP), each plugin, any AI provider plugin, video hosting and analytics. Ask which of these send data to a non-EEA service, and whether a provider is subject to third-country law with extraterritorial reach. The EDPB's Example 12 notes that using such an EU processor is not itself a transfer, but complying with a third-country authority request would be, so this exposure must be assessed before the engagement. Schrems II and the pending appeal in Case C-703/25 P also mean that US adequacy cannot be assumed to last, so the register should record the legal basis for each flow and a fallback plan.
Which GDPR and Data Act requirements shape the LMS build
This table maps each GDPR and Data Act requirement that touches learner records to what it means for hosting, support access and backups. Read each row as a design question: where could learner data leave the EU, who could reach it from outside, and what evidence would show the answer. The main takeaway is that a self-hosted Moodle or Open edX placed in the EU still needs controls over support access, third-party services and backups.
| Requirement | Hosting | Support access and backups |
|---|---|---|
| GDPR Article 44 and onward transfers (fines up to EUR 20 million or 4% of worldwide turnover under Article 83(5)(c)) | Every transfer to a third country, including onward transfers, must meet Chapter V. Confirm the physical location of every host, CDN and managed service. | Map each subprocessor and its onward transfers. Confirm backup copies are not stored outside the EEA unless a Chapter V mechanism covers them. |
| EDPB Guidelines 05/2021: remote access and cloud storage as transfers | Storing learner data in a cloud region outside the EEA is a transfer. Hosting in a third-country region is not compliant by default. | Remote support from a third country counts as a transfer, even if staff only view data on screen. Restrict and log support sessions originating outside the EEA. |
| EDPB Guidelines 05/2021, Example 12: EU processors subject to third-country law | Using an EU-based processor is not itself a transfer, but that processor's exposure to third-country law must be assessed before engagement. | Ask hosting and support partners whether they could be compelled to disclose data under foreign law, and document the assessment. |
| Schrems II (Case C-311/18) and standard contractual clauses | Standard contractual clauses remained valid after the 2020 ruling, but a transfer impact assessment is still needed for each third-country destination. | Where support staff must see data in the clear from outside the EEA, confirm the transfer tool and supplementary measures cover that access. |
| Data Privacy Framework (Decision 2023/1795) and pending Case C-703/25 P | Adequacy applies only to US organizations on the Data Privacy Framework List. Check the list entry before relying on it, and track the pending appeal. | A DPF listing does not cover every US-linked support or plugin vendor. Verify each vendor separately and plan a fallback transfer mechanism. |
| GDPR Article 48: third-country disclosure orders | A foreign court or authority order is enforceable in the EU only under an international agreement such as a mutual legal assistance treaty. | Ask providers how they handle foreign disclosure requests, whether they notify the controller, and which legal basis they would rely on. |
| US CLOUD Act, 18 U.S.C. 2713 (added March 23, 2018) | US-headquartered providers may have to preserve or disclose data they control, wherever it is stored. EU hosting alone does not remove this exposure. | Backups, logs and support tickets held by a US-controlled provider are within reach of this provision. Confirm control and key ownership. |
| EU Data Act Article 32 (Regulation (EU) 2023/2854): protection against third-country governmental access to non-personal data | Processing service providers must take measures against conflicting third-country access to non-personal data held in the Union, such as course analytics and system logs. | Ask providers which technical, organizational and legal measures they apply to non-personal operational data, including backups and telemetry. |
| Data Act switching rights (Articles 25, 29 and 50) | Customers may switch to another provider or to on-premises infrastructure. Switching charges are banned from January 12, 2027, and the Data Act has applied since September 12, 2025. | Require export of learner records, course content and backups in documented formats, so the platform can move to another host or on-premises without fees. |
EU provider hosting or on-premises: which keeps learner records in the EU
A provider runs Moodle or Open edX for you, either through a managed offering such as MoodleCloud or a Moodle Partner, or through a hosting firm that operates the platform in its own or a leased data centre. Headquarters location is a starting point, not proof of where data is stored or who can compel access to it. Subsidiaries, sub-processors, support tooling and cloud regions can all sit outside the EU, and the EDPB treats remote access from a third country as a transfer.
- Access: Ask which staff roles can open tenant databases and file stores, whether any of them work outside the EU, and how access is logged and reviewed.
- Backups and logs: Confirm the region for primary storage, replicas, backups and log pipelines, including any monitoring or error-tracking service the provider uses.
- Remote support: Support sessions that display learner data on a screen from outside the EU are transfers in their own right, so ask where support engineers sit and how screen sharing is controlled.
- Third-country legal exposure: Ask whether the provider or its parent is subject to laws with extraterritorial reach, such as the US CLOUD Act, and what it commits to do when a foreign authority requests data.
- Sub-processors: Request the current list, with locations, and the notice period before changes.
The jurisdiction of any specific provider must be confirmed directly with that provider and in its contract, because the facts available here do not establish it.
Your organization or its implementation partner installs and runs Moodle or Open edX on servers or cloud accounts in an EU data centre that you select. You keep control of the operating system, database, backups and access policy, and the legal exposure depends on the data centre operator and any cloud provider underneath. Using a cloud provider headquartered outside the EU still needs a review of its access powers and its contractual commitments.
- Access: Your administrators and any named partner engineers hold the access, so you decide who gets database, shell and application administrator rights.
- Backups and logs: You choose the storage location and retention for database dumps,
moodledatafile stores, web and PHP logs, and replicas, and you can keep them in the same EU region. - Remote support: Support from a partner outside the EU is still a transfer if it views data, so limit it to named EU personnel or use controlled, logged sessions.
- Upgrades and patches: Plan your own upgrade path, for example Moodle's documented requirement that the web root point to
/publicfrom Moodle 5.1 onward. - Operator and provider terms: Confirm the data centre operator's location, certifications you can ask to see, and whether any underlying cloud service has an EU region that keeps keys and logs in the EU.
Ask the operator and cloud provider which entity controls the infrastructure and whether any third-country law can reach the environment.
On-premises places Moodle or Open edX on hardware you own or lease in your own facilities. Data stays in buildings you control, which removes most provider-side transfers, but it moves the burden of physical security, staffing, patching and disaster recovery onto your team. This model suits organizations that already run data centre capacity and have staff who can operate the database, web and cache tiers.
- Access: Access is limited to your staff and contractors, and you can apply your own identity and privileged access controls.
- Backups and logs: Backups go to media you control, including an off-site location inside the EU, and you own retention and destruction.
- Remote support: If a vendor or partner must reach the system, use a controlled jump host, time-limited accounts and session recording so that no third-country viewing happens unnoticed.
- Capacity and resilience: Peak enrolment, exam periods and failover all depend on hardware you have provisioned, so size them before go-live.
- Software updates: Moodle's minor releases and LTS windows still apply, so set a schedule that keeps you within supported versions.
Confirm that the staff and partners who will operate the system are cleared for the data you hold and that the physical and logical controls match your data protection impact assessment.
Moodle or Open edX: which platform fits EU residency needs
Both Moodle and Open edX can be hosted entirely inside EU infrastructure, so the choice rarely turns on licence fees. It turns on which data flows you can keep in the EU, how much operations capacity you have, and how often you can absorb upgrades. The cards below set out the decisions that connect those points.
Moodle 5.3 as the next LTS
Moodle 5.3 is the next long-term support release, with security fixes until 1 October 2029. For EU residency, the longer window lets you keep learner records on a stable, EU-hosted version without a major upgrade every cycle. Core authentication covers manual accounts, LDAP, OAuth 2, Shibboleth and external database, so you can keep identity inside your jurisdiction. Confirm which of these your identity provider and directory support, and whether the directory itself sits in the EU.
Moodle 5.1 support and upgrade path
Moodle 5.1 has general support until 5 October 2026 and security support until 19 April 2027, so an installation still on it needs a planned move. Upgrades to 5.1 require sites on Moodle 4.2.3 or later, and the web root must point to the new public directory. Older sites on a previous branch should plan the path step by step. Any migration that moves learner data between hosts is a transfer you must document and assess.
Open edX Verawood on Tutor
Open edX is licensed under AGPL-3.0 and Verawood is the current named release. Tutor, the official Docker-based distribution, supports Kubernetes deployments, which lets you run the stack in an EU cluster you control. Open edX supports only the latest release, so you must budget for each named release to be applied. Operations capacity matters more than licence terms: the maintainers recommend a service provider or Tutor rather than bare-metal installation.
Canvas LMS hosting questions
Canvas LMS is licensed under AGPL-3.0, so self-hosting the open source code is possible under the same copyleft family as Open edX. Confirm which Canvas distribution, documentation and support terms apply to a self-hosted deployment before you commit, because the open source code and vendor-hosted offerings are not the same thing. Ask where any supporting services, telemetry and update channels send data, and whether they sit within the EU.
Plugin and integration data flows
Every plugin, LTI tool, AI provider or video service can send learner data to a third country, and a plugin can make that transfer without anyone noticing. Moodle 5.3 adds an AI provider plugin for Anthropic's Claude, so an AI feature enabled by an administrator can send prompts outside the EU. Inventory each plugin's external calls, pin versions, and block third-country endpoints at the network layer before go-live.
How plugins, AI and video services create transfers without moving the server
A Moodle or Open edX instance can keep its database and file store in the EU and still send learner data abroad, because the transfer happens in a component, not the server. A plugin, AI provider connection, external video host or xAPI analytics stack can each receive personal data from the LMS and forward it to a provider outside the EEA. Under EDPB Guidelines 05/2021, storage in a cloud outside the EEA is a transfer, and so is remote access from a third country, even when someone only views data on a screen for support. The database location therefore tells a data protection officer only part of the story.
The Anthropic provider plugin that Moodle 5.3 adds is the clearest example of a connection a site may enable without a formal review. Once an AI provider is configured, prompts and any learner content included in them leave the instance for that provider's endpoint, so the decision is about which data fields are sent, under which contract, and whether the provider's processing location is acceptable. On Open edX, the AI Extensions Framework in Verawood and any external video or LTI tool follow the same logic. Confirm each provider's processing and sub-processor locations in writing before enabling it, and record the decision with the purpose and data categories involved.
Open edX Aspects is the component most often missed in a review. Its event-routing-backends plugin converts tracking logs into xAPI statements, which are stored in a ClickHouse database through Ralph or Vector and shown in Superset dashboards. Each of these three parts can run on different hosts, and a managed or hosted option may sit outside the EU. Build an inventory of every plugin, theme, AI connection, video embed and analytics service, and for each one run a data-flow check: what fields leave the platform, which host receives them, where that host and its support staff are located, and whether a third-country authority could compel access. Record the result beside the plugin's version, since an update can add a new endpoint.
How an EU sovereign LMS rollout moves from data mapping to cutover
The sequence turns a loose sovereignty goal into a documented, tested platform where every learner record, provider, plugin and upgrade path can be shown to stay under EU control before any live learners move across.
Map learner data flows and transfers
Start by listing every category of learner record the LMS holds, such as profiles, enrollments, grades, completion certificates, activity logs and uploaded files, then trace where each one is created, stored, backed up, viewed and accessed for support. Include remote administration sessions, analytics pipelines and any AI or video service a course or plugin calls. Mark each flow that could reach a location outside the EEA or a provider subject to third-country law. The output is a transfer register signed by the controller's data protection lead, with each flow tagged as stays in the EU, remote access from a third country, or external transfer requiring a Chapter V basis.
Decide hosting and review provider contracts
Using the transfer register, choose between on-premises hosting, an EU-based hosting provider, or a support partner working inside your own cloud tenancy, and document why each option meets the findings. Review the hosting, support and subprocessor contracts for data location commitments, restrictions on remote access from outside the EEA, notification duties when a third-country authority requests data, and exit terms under the Data Act. Confirm with each provider where backups and logs are kept. The output is a signed hosting decision record and a contract review checklist with every open clause resolved or escalated to legal counsel.
Configure identity and approve plugins
Connect the LMS to your own directory through the authentication methods the platform supports, such as LDAP, SAML 2.0, OAuth 2 or Shibboleth for Moodle, or the third-party providers configured for Open edX, so credentials never leave your control. Inventory every third-party plugin, theme and LTI tool, then check each one for outbound calls, bundled scripts, external fonts and storage of learner data. Disable or replace anything that sends data to unapproved destinations. The output is a configuration baseline and an approved plugin list, each entry recording its data flows and the person who accepted them.
Write the upgrade and patch runbook
Set the upgrade path against the support windows for your chosen platform. For Moodle, this means matching the release line to its security support dates and the PHP and database versions it requires; for Open edX, it means planning around named releases, since only the latest is supported. Document how plugins are retested, how the web server document root and other configuration changes are applied, how backups are verified before each change, and who approves a patch that is needed out of cycle. The output is a runbook with a rollback procedure and a calendar of support dates that the DPO and IT owner have both signed.
Migrate records and verify integrity
Move courses, users, enrollments, grades and completion records in a controlled migration, with each batch logged and reconciled against the source. Compare record counts, timestamps, grade totals and file checksums between the old and new systems, and sample individual learner histories by hand. Confirm that migrated audit and activity logs keep their original timestamps and that no record was altered in transit. The output is a reconciliation report listing every discrepancy found, how it was resolved, and the sign-off of the person who owns the source data.
Test access, logs and deletion
Before cutover, run test cases for role-based access, administrator access to learner records, disclosure logging, backup restoration and the deletion or retention rules in your policy. Include a test of remote support sessions to confirm they follow the approved access method and are recorded. Check that restored backups contain only data inside the approved location. The output is a test report with each case marked pass or fail, and any failure must be fixed and retested before the next step.
Obtain DPO sign-off before cutover
Assemble the evidence pack: the transfer register, hosting decision, signed contract review, plugin approvals, runbook, reconciliation report and test results. The data protection officer reviews the pack against the transfer and processor duties in the GDPR and documents any residual risk, including exposure to third-country legal requests that technical measures cannot fully remove. Cutover proceeds only once the DPO has signed the decision and any open risk has an owner and a review date. The output is a dated sign-off record that becomes the reference for later audits.
Evidence data protection officers ask for and which component produces it
This table maps each piece of evidence a data protection officer typically requests to the platform component or process that produces it. Read it as a checklist for the build: if a row has no owner in your design, the evidence will be hard to produce when the DPO asks. DeployOpen prepares this evidence for your assessors but does not issue audit reports or certifications.
| Evidence | Produced by | What to confirm before go-live |
|---|---|---|
| Records of processing and transfer map | Data flow diagram covering Moodle or Open edX, plugins, backups, support access and any AI or video services | Every location where learner records are stored, processed or viewed remotely is named, including support staff outside the EEA |
| Transfer impact assessment inputs | Hosting location record, provider jurisdiction analysis and a list of third-country public authority powers that could reach the data | Your legal team confirms the assessment method and the outcome for each provider with access to data in the clear |
| Processor contract and sub-processor list | Signed contract with the hosting or support provider and a current register of sub-processors | The contract names sub-processors, notification duties for changes and the EEA location commitments you need |
| Standard contractual clause documentation | Executed clauses from the relevant Commission decision, kept with the transfer records, where any transfer still occurs | Module selection and annexes match the actual transfer, and you know which vendors rely on them |
| Access logs and admin access records | Moodle or Open edX authentication and event logs, plus infrastructure logs for privileged and remote administrator sessions | Logs record who accessed learner data, from which country and why, and are retained for the period your policy sets |
| Backup location records | Backup inventory listing storage region, encryption status, retention and restore test dates | Backup copies stay inside the EEA, including off-site and disaster recovery targets |
| Plugin inventory with versions | Software bill of materials for Moodle core, third-party plugins, themes and Open edX components with their licenses | Each plugin has a documented data flow, and any that call external services appear in the transfer map |
| Upgrade and patch records | Change log of Moodle minor releases and security updates, or Open edX release upgrades, with test and rollback notes | Supported versions are current, since Moodle and Open edX only support specific releases, and dates are confirmed against the vendor's release pages |
| Data Act switching documentation | Exit plan covering export formats, data return, and the migration path to another provider or on-premises infrastructure | The plan states the notice period, transition window and switching terms in your provider contract, and is tested on a sample export |
What EU data sovereignty for an LMS costs and needs from your team
Does Moodle or Open edX have a licence fee?
Neither platform has a licence fee to pay for the software itself. Moodle is licensed under GPL-3.0 and the Open edX platform under AGPL-3.0, so the cost sits in hosting, setup, integrations, content migration, upgrades and support. Your spend is what you pay providers to run it, not the code. Compare that with a hosted LMS subscription, which bundles hosting and support into a recurring fee. Ask any vendor to show which of these items sit inside their quote and which are billed separately, including any plugin licences for AI, video or payment services that your data protection officer may need to review.
What drives the hosting and migration cost of an EU-hosted LMS?
The main drivers are where the servers run, how many learners sit online at peak, how much content and history you migrate, and how many systems need integrating. Hosting is recurring: it covers compute, storage, backups, monitoring and the database. Migration and setup are usually one-time. Ask each provider for a quote that separates hosting by environment (production, staging, backup), states the EU data centre regions, names the sub-processors that touch learner data, and itemises content migration by course count and record format. Ask how backups stay in the EU, because a backup copy outside the EEA is also a transfer.
How long does an EU data sovereignty LMS rollout take?
The duration depends on the scope you agree in writing, not on a fixed template. The biggest variables are the number of identity and HR or student information system integrations, the volume of records to migrate, how many third-party tools you must review before go-live, and how quickly your internal reviewers answer. Most engagements are fixed-scope, so ask for a timeline tied to named milestones: hosting decision, data flow mapping, integration build, migration rehearsal, data protection review and cutover. Also ask how the rollout accounts for the Moodle release calendar, because a go-live near an upgrade window needs its own plan.
What must our DPO, identity owner and procurement team provide?
Your data protection officer owns the transfer assessment, the record of processing and the review of each processor and sub-processor. Your identity owner provides the directory, single sign-on design and the rules for account lifecycle. Procurement owns the contract terms, including data processing agreements, standard contractual clauses where they apply, audit rights, breach notice and exit provisions. Your LMS or learning lead defines the course and record requirements. Agree these responsibilities at the start, because a missing sign-off from the DPO is the most common cause of delay in a data sovereignty project.
Can our internal team run an EU-hosted Moodle or Open edX alone?
A small internal team can run a Moodle site with stable hosting, but the work includes regular minor releases, the major upgrade every six months, plugin reviews, backups and security patching. Moodle 5.3 requires PHP 8.3 or later and PostgreSQL 17, and the web root must point to the /public directory from Moodle 5.1 onward. Open edX is harder: the maintainers recommend a service provider or Tutor for production, and bare-metal installation has limited community support. Decide early which tasks your team keeps and which you contract, and ask any partner to confirm support hours, response routes and who applies security fixes.
Does a non-EU support vendor create transfer risk for our LMS?
It can. Under the EDPB guidance, remote access from a third country is a transfer even when the person only views data on screen for support. So a vendor outside the EEA that logs in to troubleshoot learner records triggers Chapter V obligations. Using an EU processor that is subject to third-country law is not itself a transfer, but complying with a third-country authority request would be, so assess that exposure before you sign. Ask each vendor where support staff sit, whether they can access data in the clear, how access is logged and whether they hold any EU-based access controls you can audit.
What do Data Act switching rights mean for an LMS contract?
The EU Data Act, applicable since 12 September 2025, gives customers of data processing services the right to switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition under Articles 25, 29 and 50. From 12 January 2027, switching charges are banned. Write these rights into the contract: export formats for courses, records and logs, a documented exit plan, and a named transition window. Also ask the provider how Article 32 safeguards against third-country access to non-personal data are implemented in their setup. Confirm applicability with your legal counsel, since the rules depend on the service model.
What should we request in a quote for an EU data sovereignty LMS?
Request a written scope that lists each deliverable, the hosting location and provider for each environment, every integration with its authentication method, the migration volume and format, the upgrade approach and the support hours. Ask for a separate line for each third-party plugin and each AI or video service, with a statement of what data it receives and where that processing happens. Also request the evidence package you will need for your data protection officer, including data flow diagrams, sub-processor list, transfer assessments and the exit plan. Compare quotes on the same written scope, not on the headline figure.
Questions to put to an implementation partner before signing
Start with the people and the screens. Ask the partner where its engineers, support staff and on-call administrators sit, and whether any of them can view learner records from outside the EU or EEA. The EDPB Guidelines 05/2021 treat remote access from a third country, even only displaying data on a screen for support, as a transfer, so a support desk in another time zone can make an EU-hosted system a transfer under Article 44 of the GDPR. Ask for the list of locations and access paths in writing, how privileged sessions are logged, and whether the contract restricts support access to EU-based staff. Confirm the answer with the partner's own access procedures, not only the marketing description.
Next, ask for the full chain of sub-processors and plugins that touch learner data. For a Moodle site, that includes the hosting provider, backup vendor, email relay, video host, AI provider plugin and any LTI tools, and each one can move personal data outside the EU. Ask where each component stores data and logs, which of them can be reached by a third-country authority, and how new plugins are assessed before they are installed. Ask where backups and log aggregation run, who holds the encryption keys, and how long copies persist after a learner leaves. Request a current data flow diagram that matches the production configuration, and check it against your records of processing.
Then test the partner's position on government requests and upgrades. Ask how it would respond to a demand from a third-country authority under the US CLOUD Act (18 U.S.C. 2713) and how that demand would be handled under Article 48 of the GDPR, which generally requires an international agreement before a foreign judgment can be enforced in the EU. Ask how upgrades are scheduled against the Moodle LTS windows, such as Moodle 5.3 with security fixes until October 1, 2029, and how an Open edX deployment would move between named releases, since Open edX supports only the latest release. Finally, ask what exit support exists under the Data Act, which gives customers a right to switch providers or move to on-premises infrastructure, and whether the partner will commit in writing to a migration plan and a data return format.
