EU data sovereignty for project management | DeployOpen

Why project management for EU data sovereignty needs its own design

Moving project data off a US SaaS tool starts with where personal data is stored, who can reach it and which law governs that access, and the hosting choice is only part of the answer. A project tool that holds tasks, time entries and staff identities processes personal data, so the GDPR applies whether the tool runs in an EU data center or a US cloud. Names, roles, assignments and time records about employees are all personal data. Under Article 44, every transfer of personal data to a third country, including onward transfers, must meet the Chapter V conditions, and EDPB guidance treats remote access from a third country as a transfer, even when the person only views data on a screen for support. An EU region is a starting point, but the legal team also needs to know who administers the platform, who supports it and from which countries.

On platforms, OpenProject is the most direct fit for self-hosting by an EU vendor. It is licensed under GPL-3.0, developed by OpenProject GmbH, and runs in your own infrastructure through Docker, packages or Kubernetes. The Community edition is free, but single sign-on through SAML or OIDC, LDAP group synchronization and custom branding are Enterprise features, so a regulated deployment that depends on directory-based access will usually need a paid edition. Plane is a credible alternative with edition limits to check first: its Community edition is AGPL-3.0, while the Commercial and Airgapped editions are proprietary, and a paid plan means moving a self-hosted install to the Commercial edition. Redmine is the long-running option you may already know. Confirm its current maintenance model, plugin dependencies and support provider before you build on it.

Which EU requirements shape the project tool build

This table maps each EU requirement to what it means for where project data is hosted, who can reach it from outside the EU, and how you leave the platform later. Read each row as a design question you must answer before choosing a hosting model, and treat the right-hand column as the evidence to request from a partner or auditor. The main takeaway is that a self-hosted tool inside the EU still needs access controls for administrators and support staff, because remote access from a third country can itself be a transfer.

Requirement	What it means for the project tool	What to confirm or evidence
GDPR Article 44 and transfer definition (EDPB Guidelines 05/2021)	Any transfer of personal data to a third country, including onward transfers, must meet Chapter V. Remote access from outside the EEA, even only displaying data on screen for support, counts as a transfer.	Map every location and every person who can view task, comment or timesheet data, including vendor support engineers abroad.
Fine ceiling (GDPR Article 83(5)(c))	Infringements of Articles 44 to 49 can carry fines of up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher.	Board-level risk statement that names transfers in the project tool and the controls that limit them.
Schrems II and the Data Privacy Framework	The 2020 ruling invalidated Privacy Shield but kept standard contractual clauses valid. The DPF adequacy decision covers only US organizations on the DPF List, and an appeal (Case C-703/25 P) is pending.	Written record of the transfer mechanism for each US provider, plus a plan if the DPF adequacy finding changes.
CLOUD Act reach (18 U.S.C. 2713)	US providers must preserve or disclose data in their possession, custody or control, wherever it is stored. An EU data center run by a US parent company can still be reachable.	Ask vendors whether they hold keys, administrative credentials or logs that could be compelled, and where those sit.
Foreign disclosure orders (GDPR Article 48)	A third-country court order to disclose personal data is recognized only if based on an international agreement such as a mutual legal assistance treaty.	Contract clause stating how the provider handles foreign requests and notifies you, and whether it challenges overbroad demands.
Data Act Article 32 and switching rights	Providers must take measures against third-country governmental access to non-personal data held in the EU. Customers may switch to another provider or to on-premises infrastructure, with switching charges banned from 12 January 2027.	Written exit plan: export formats for projects, work packages, attachments and time entries, plus a tested restore on your own infrastructure.
Administrator access	Platform admins and database operators who sit outside the EEA create transfers. Hosting in the EU does not remove this exposure.	Named admin list with locations, role-based access, and logged privileged sessions.
Support access	Vendor support that views live data in a ticket or screen share is a transfer. Support should use redacted data or time-limited access from inside the EEA.	Support procedure with access approval, session recording and data minimization rules.
Exit planning	Keeping project history portable depends on importers and export paths. Jira Cloud and Asana history may not map cleanly to a self-hosted target, so test the import before cutover.	Migration test report showing which fields, attachments and user mappings survive, and a documented rollback path.

What the US provider's access exposure means for project data

Hosting project data in an EU region does not settle the sovereignty question on its own. The test that matters is whether a non-EU parent company, a foreign support engineer or a third-country authority can reach the data in the clear. A vendor can store every work package in Frankfurt and still expose it if its US parent can be compelled to produce it or if remote staff in a third country can open it during a support session. The EDPB's Guidelines 05/2021 treat remote access from a third country as a transfer, even when the person only views data on a screen for support or administration, and they treat storage in a cloud outside the EEA as a transfer too. Under GDPR Article 44, that means Chapter V conditions apply, and the fines for infringing Articles 44 to 49 reach EUR 20 million or 4% of worldwide annual turnover, whichever is higher.

The practical consequence is for vendor support on SaaS project tools. Ask the vendor, in writing, where its support engineers sit, whether they can open tenant data in the clear, which sub-processors have access, and how it handles government access requests. Then compare those answers with the EDPB's position in Recommendations 01/2020: where a provider needs access to data in the clear and the destination's public authority powers go beyond what is necessary and proportionate, the EDPB cannot envision an effective technical supplementary measure such as encryption. Relevant US law includes 18 U.S.C. 2713, which applies to providers regardless of where the data is stored, and the EU has noted in Article 48 of the GDPR that third-country court orders are enforceable only where an international agreement such as a mutual legal assistance treaty is in force. A self-hosted deployment on infrastructure you control removes most of this exposure, because no third-party provider holds the data or its keys.

Assess this exposure before you choose a processor, not after the contract is signed. Map every place project data, user records and time entries can be read, including backups, logs, email notifications and support tickets, and record which of those locations sit under non-EU control. Confirm which Chapter V mechanism applies to each transfer you cannot avoid, and whether a standard contractual clauses decision is in place. The position on the EU-US Data Privacy Framework is still in litigation, so do not rely on it as a settled basis without checking its current status with counsel. Treat this section as a risk assessment input, not a legal opinion: the final position on whether a given vendor or hosting arrangement is lawful for your data needs advice from qualified data protection counsel.

Which self-hosted project platforms fit an EU sovereignty brief

An EU sovereignty brief narrows the field before features do. Each candidate differs in license, edition model and the paid tier needed for single sign-on and directory sync, and those differences change the budget and the hosting design.

OpenProject on premises

OpenProject is GPL-3.0 software developed by OpenProject GmbH, and it can run on your own servers with Docker, packaged installs or Kubernetes with Helm. For a sovereignty brief, the Enterprise on-premises tier is needed for SAML, OIDC and LDAP group synchronization, so the Community edition alone does not meet a directory-based access requirement. Confirm the supported operating systems (Debian 12 and RHEL 9.x are listed for packaged installs) and the PostgreSQL 16 or later requirement with your platform team before sizing.

Plane Community and Commercial

Plane Community Edition is AGPL-3.0 and matches the feature set of the Plane Cloud Free tier. Paid features, including SAML and OIDC on Pro and above, and LDAP on Enterprise, require moving from Community to the proprietary Commercial Edition with a license key. Plane's Airgapped edition is a separate proprietary codebase with its own release cycle, so an isolated deployment is a different procurement, not an add-on. Ask the vendor which edition covers your identity and directory requirements before you commit.

Redmine as the long-standing option

Redmine has been used for many years by public bodies and engineering teams that want a mature, self-hosted tracker with a large plugin ecosystem. Its fit for a sovereignty brief depends on how identity is wired, since native LDAP and plugin-based single sign-on are handled differently from the commercial tiers of OpenProject and Plane. Confirm with your Redmine vendor or plugin maintainers which authentication features are native, which need a plugin, and how each is maintained across upgrades.

Hosting and data location checks

Whichever platform you shortlist, self-hosting only changes the data picture if the database, object storage and backups stay in your chosen jurisdiction. Plane's Kubernetes deployment relies on PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible storage, and each can point to an external managed service. Each external service can introduce a transfer or third-country access question, so map every component and its location before you accept a managed option.

How hosting location changes the design

Running an open-source project tool in your own EU data center, using a vendor-supported edition from an EU company, keeps the data inside your control boundary. Where the data is stored in the EEA and no support staff outside the EEA can view it, there is generally no restricted transfer to assess for the hosting itself. The remaining questions are about remote access and support: any vendor engineer who views data on screen from a third country, even during troubleshooting, can trigger the transfer rules under EDPB Guidelines 05/2021.

Transfer analysis: Map every support path, including vendor screen-sharing, log exports and backup replication, and confirm each one stays in the EEA or is covered by a documented transfer mechanism.
Key custody: Your team holds the database, object storage and application secrets, so you decide who has administrator access and how keys are rotated.
Exit path: Under the Data Act, the right to switch to on-premises infrastructure or another provider applies to cloud services, so a self-hosted tool mainly needs documented export formats and a tested restore.
Operating burden: Patching, backups, high availability and upgrades remain with your team or your implementation partner.
Edition fit: Confirm which features needed for identity and audit sit in the paid edition, since the community edition may not include them.

Confirm with counsel whether your support contracts create any third-country access before you finalize the design.

How a sovereign migration from Jira or Asana runs in phases

The sequence moves project history out of a US SaaS tool into an EU-hosted platform in controlled stages, with each phase producing a record that the data protection, security and project owners can sign off before the next one starts.

Map data and assess the transfer
Inventory every Jira or Asana project, board, custom field, attachment, comment, user record and time entry, and note where each category is stored today. Your data protection lead records the processing activities and the lawful basis for each, and checks whether any copy, support session or administrator access from outside the EEA counts as a transfer under the GDPR. The step closes with a record of processing and a data inventory that names the source system, the data categories and the retention need for each. Ask your legal team to confirm the SaaS vendor's current transfer terms before you rely on them.
Design EU-only hosting and identity
Choose the EU region for the self-hosted platform, the database, object storage and backups, and confirm that no component (monitoring, email relay, logging or support tooling) sends project data to a third country. Decide how single sign-on and directory sync will connect to your identity provider and which edition supports the protocols you need. Your platform engineering team and DeployOpen design the architecture together, and the step closes with an EU-only architecture diagram and an SSO plan signed off by security. Confirm edition-specific SSO and LDAP features with the vendor before purchase.
Run a pilot import on limited projects
Select a few representative projects that cover your common workflows, custom fields and attachment types, then import them into a non-production instance. Confirm the importer's coverage before you start: the OpenProject Jira Migrator supports Jira Data Center 10.x and 11.x, not Jira Cloud, and is in beta with documentation advising use only in test setups. Plane's Jira importer covers Jira Cloud as well as Jira Server and Data Center, and Asana usually needs a separate conversion route, so confirm that path with the partner. The step closes with a documented list of what transferred, what was dropped or changed, and the fixes agreed with the project owners.
Migrate full history and map users
Run the full import against the agreed scope, mapping SaaS accounts to directory identities and carrying over roles, permissions and time entries under the retention rules set in the first phase. Compare record counts, sample issues and attachments against the source, and check that comments and history appear in the right order. The step closes with a validation report, a completed user mapping and the retention settings applied to each project, all approved by the data owners. Plan the freeze window for active projects with your delivery leads.
Cut over access and train users
Switch users to the self-hosted instance, disable new edits in the SaaS workspace, and confirm that single sign-on, notifications and integrations with Git, chat and file storage work from EU-hosted services. Run short role-based training so project managers, time approvers and administrators know where work now lives. The step closes when the access list is reviewed, the cutover checklist is signed by the project sponsor and the support path is documented.
Decommission the SaaS tool with deletion confirmation
Export a final copy of each project from the SaaS tool for your archive, keeping only what your retention schedule requires, then request deletion of your workspace and confirm in writing with the vendor that the data, backups and sub-processor copies are removed. Revoke API tokens, integrations and service accounts that still point at the old tool. The step closes with a deletion confirmation from the vendor, a record of revoked credentials and an updated record of processing that no longer lists the SaaS tool.

What evidence a data protection review asks for

What records of processing activities should cover a self-hosted project tool?

The record of processing activities, kept by the controller under GDPR Article 30, should list the project platform as a processing activity, with its purposes, the categories of personal data (account identities, assignments, comments, time entries), the data subjects, the recipients, retention periods and any transfers. For a self-hosted OpenProject, Plane or Redmine instance, the entry should name the hosting location and the operator who administers it. DeployOpen can prepare the draft entry from the deployed architecture and the agreed data inventory, and it can flag fields that hold more personal data than the purpose needs. Your data protection officer or legal team approves the entry and decides whether it is complete and lawful.

Is a transfer impact assessment needed if the project tool is hosted in the EU?

A transfer impact assessment is needed only where personal data leaves the EEA or can be reached from a third country, which includes remote administration from outside the EEA and vendor support sessions that display data on a screen. EDPB Guidelines 05/2021 treat those access paths as transfers, so the assessment should cover support access, backups, mail notifications and any SaaS add-ons such as hosted email or identity providers. Using an EU processor subject to third-country law is not itself a transfer, but the controller should assess whether a third-country authority could compel disclosure, as the EDPB Recommendations 01/2020 describe. DeployOpen can document the data paths and access routes it sees in the engagement and prepare the assessment inputs. The controller and its legal advisers conclude on the risk.

What data flow and hosting location records do auditors expect?

Reviewers expect a current data flow diagram and a hosting location register that show where project data is stored, processed, backed up and administered, and which systems exchange data with it. For a typical self-hosted stack, the register covers the application server, PostgreSQL, object storage for attachments, the reverse proxy, the identity provider, SMTP relays, backup targets and any integration with a file store such as Nextcloud. Each item should list the country, the cloud account or data center, the operator and the access path. DeployOpen can produce the diagrams and register from the as-built environment and keep them current through change control. The organization confirms that the records match its real infrastructure and its contracts.

Which access logs and admin activity logs prove who saw project data?

Access evidence comes from three places: the application audit trail, the web server and reverse proxy access logs, and the operating system and database logs for administrative actions. Before a review, confirm what each edition records. Plane lists API-enabled audit logs as an Enterprise feature on self-hosted deployments, so a Community or Pro install may not give you a complete application audit trail and you may need to rely on proxy and database logs. OpenProject and other platforms have their own logging options that you should verify against the installed version. DeployOpen can configure log collection, retention and a central log store inside your environment and document the gaps. Your security team decides whether the logs are sufficient for the access questions you must answer.

What retention and deletion procedures should a project platform have?

A retention schedule should set how long tasks, comments, attachments, time entries and user accounts are kept, and what triggers deletion, such as project closure or an employee leaving. Deletion has to reach the application database, object storage, search indexes, caches, and backups within the stated backup cycle. Time-tracking data may carry a separate statutory retention period, so the schedule should be checked against your labor and tax rules. DeployOpen can implement the configured deletion jobs, backup rotation and a documented offboarding runbook, and test that deletion behaves as written. Legal and records management set the periods, and the controller confirms them.

What exit and switching plan does a data protection review ask for?

A reviewer will want a documented exit plan that explains how project data can be exported, moved to another platform or to on-premises infrastructure, and deleted from the original provider. The EU Data Act, applicable since 12 September 2025, gives customers a switching right with a maximum two-month notice period and a 30-day transition, and it bans switching charges from 12 January 2027 (Articles 25, 29 and 50). For a self-hosted tool, the plan should cover database and attachment export formats, the Jira or Asana history you still need to keep, and a tested restore. DeployOpen can prepare the export procedure and run a restore test as part of the scope. Your procurement and legal teams confirm how the plan fits your contracts and regulatory obligations.

Who decides whether the evidence is sufficient for a data protection review?

The controller decides, usually through its data protection officer, and a supervisory authority or external auditor can test the evidence later. DeployOpen prepares the systems, configurations, records and test results that support the review, including the record of processing activities inputs, data flow diagrams, logging setup and the exit procedure. DeployOpen does not issue audit reports, attestations or certifications, and it does not decide whether a transfer is lawful. Before engagement, ask your reviewer which evidence formats they accept and which controls they consider mandatory, so the scope is written against those expectations.

Questions to ask an implementation partner before migration

Start with where the data will physically sit and who can reach it. Ask the partner which EU data center or customer-owned facility is proposed, which cloud account or hardware it runs on, and whether any administrator, support engineer or subcontractor outside the EEA can open the running system, view a session or read a database during support. The EDPB guidance treats remote access from a third country, even only viewing data on a screen, as a transfer, so the answer should name roles, access paths and the approval step for each. Ask also who on the vendor side can see data in the clear, including backup operators and anyone who handles logs, and request that the access model be written into the proposal rather than described verbally.

Then ask how the history will move and what will not. For Jira, confirm whether the source is Jira Cloud or Jira Data Center, because the OpenProject Jira Migrator documentation covers Data Center 10.x and 11.x only and marks the tool as beta, while Plane's importer also covers Jira Cloud. Ask for a field-by-field mapping of issues, comments, attachments, workflows, custom fields, sprints, user accounts and permissions, and for a written list of what will be lost or flattened. For Asana, ask the same questions, since the mapping rules differ. Time-tracking entries deserve their own line: ask whether they are migrated at all, which personal fields they contain, the retention period the client will set, and who deletes them at the end of it. Under GDPR, that retention decision belongs to the controller, so the partner should implement it, not invent it.

Finally, ask for the edition and the exit. Confirm in writing which edition delivers the SSO and directory sync you need: OpenProject lists SAML, OIDC, CAS, Kerberos, Okta and LDAP group synchronization under Enterprise, and Plane lists SAML and OIDC from Pro and LDAP under Enterprise. Ask how the exit under the Data Act is documented, including the export format, the notice and transition steps the client can use, and the cost of switching. Then request a fixed-scope written proposal that lists the systems, environments, migration waves, test and cutover activities, training, documentation, handover and what is excluded. Check that the proposal names the people doing the work, states acceptance criteria, and sets out how support and upgrades are handled after go-live.

How much does EU-sovereign project management cost and how long does it take?

What drives the total cost of EU-sovereign project management software?

Total cost is driven by four components: the software edition and its per-user fees, the hosting you run in your own EU infrastructure, the volume and complexity of migrated history, and the legal review of your data flows. Software fees may be zero for a community edition, but hosting, operations, upgrades, backups and support are recurring costs you carry. Migration and legal review are usually one-time costs. Ask any partner for a written quote that separates these components, names who performs each task, and states which items recur each year.

How much does OpenProject Enterprise cost per user?

OpenProject Enterprise on-premises is priced per named user per month, according to the OpenProject pricing page: Basic at 5.95 euros and Professional at 10.95 euros, with a 25-user minimum, Premium at 15.95 euros with a 100-user minimum, and Corporate on request for 250 or more users. Single sign-on, LDAP group synchronization and custom branding sit in these Enterprise tiers, so check which features you need before choosing a tier. Confirm current prices and minimums directly with OpenProject, since list prices change.

How much does Plane cost per user for self-hosted teams?

Plane's pricing page lists Pro at 6 to 8 US dollars and Business at 13 to 15 US dollars per user per month, with Enterprise Grid priced on request. These figures describe Plane's published plans, and self-hosted deployments are priced through the Commercial Edition with a license key, so confirm which plan and seat count applies to your installation. On self-hosted Plane, SAML and OIDC are available from Pro upward, while LDAP and API-enabled audit logs are listed as Enterprise features. Ask Plane to confirm current pricing for your seat count and edition.

Can the community edition of a project tool meet EU data sovereignty needs?

A community edition can host your data in EU infrastructure, which addresses where data is stored, but it does not by itself settle sovereignty. Plane Community Edition is licensed under AGPL-3.0 and matches the feature set of the Plane Cloud Free tier, so features such as SSO and LDAP are not included. OpenProject Community includes work packages, Gantt charts, agile boards, time tracking and dashboards, with community support only. Decide which identity, audit and support requirements are mandatory first, then check whether the community feature set meets them. Your legal team should confirm the result.

How long does a migration from Jira or Asana take?

Migration duration depends on scope: the number of projects, the volume of issues, attachments and history, the custom workflows and fields that must be mapped, and how many users must be mapped to new accounts. Importer coverage also matters. The OpenProject Jira Migrator supports Jira Data Center 10.x and 11.x, not Jira Cloud, and is in beta, so Jira Cloud data may need a different route. Plane's Jira importer supports Jira Cloud as well as Jira Server and Data Center. Ask for a written plan with phases, and confirm importer support for your exact Jira version.

What must our team provide before an implementation partner starts?

Your team typically needs to provide a complete inventory of projects, workflows, custom fields, users and permissions, plus access to the source system and a named decision-maker for mapping choices. You also need the target infrastructure, including the EU region, operating system support, PostgreSQL version, storage and backup requirements, and the identity provider for single sign-on. Legal or compliance staff should document where personal data, including time-tracking records, will be processed and which transfers, if any, occur. Confirm these inputs in the written scope before work begins.

Can we run an EU-sovereign project management migration in-house?

Yes, many teams do, provided they have staff who can operate the chosen platform, maintain the database and object storage, apply security updates and test restores. The work that most often needs outside help is migration mapping, importer troubleshooting, hardening, and documenting controls for an assessment. Plan for the recurring operations work as well as the one-time setup. If you engage a partner, DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted platforms in your own infrastructure, under a fixed-scope written agreement.

Does DeployOpen issue GDPR or ISO certificates for our project tool?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments and issue any certificates. Ask a partner to show how it will document configuration, access controls, backup and transfer records so your auditor can review them. Your data protection officer or legal counsel should decide whether an EU processor or a third-country transfer creates obligations under GDPR Chapter V.

How the Data Act protects an exit from a cloud project tool

The Data Act gives customers of a cloud project tool a statutory right to leave. Under Articles 25, 29 and 50 of Regulation (EU) 2023/2854, you may switch from a data processing service to another provider or to on-premises ICT infrastructure. The regulation sets a maximum two-month notice period and a 30-day transition, and it bans switching charges from 12 January 2027. For a team that wants to move work items, projects and time entries off a US SaaS tool, this is a planning input: the exit path no longer depends only on what the vendor chooses to offer. Read the regulation text alongside the Data Act on EUR-Lex before you rely on it.

Use these dates to build the exit plan. Work backward from the go-live date for a self-hosted instance, and count the notice period and the transition window against the renewal or termination date in your current contract. Check whether the vendor's contract terms already match the statutory periods, or whether they add conditions such as early termination fees, minimum commitments or data export formats that limit what you can take with you. Ask the vendor to confirm in writing which data is exportable (projects, work packages, comments, attachments, time entries, audit logs and user records) and in what format. Confirm before the notice date whether the export includes history and attachments, because the Jira or Asana history you need for the migration depends on it.

The switching right supports planning an exit from a current SaaS contract, but it does not replace legal review. Whether a specific contract, a specific service tier or a specific fee structure falls within the regulation's scope is a question for your counsel and, where relevant, your data protection officer. Also confirm how the Data Act interacts with any data processing terms you already hold under the GDPR, including who bears the cost of the export and how deletion of residual data is documented after the switch. Treat the two-month notice and 30-day transition as the outer limits to test against, not as a guaranteed timetable for your migration, since the import, user mapping and validation work in your own environment will take longer.

How DeployOpen scopes and delivers a sovereign project management build

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source project management platforms inside your own cloud accounts, data centers or air-gapped networks. Engagements start with a written scope that fixes what data stays in the EU, which platform and edition fit, and how history is migrated.

How we scope

Map where project, time and user data is stored today and every third-country access path, including vendor support and remote administration.
Confirm the platform and edition: OpenProject Community or Enterprise, Plane Community or Commercial, and the SSO and LDAP features each requires.
Agree in writing the import scope for Jira Cloud, Jira Data Center or Asana, including what history will and will not carry over.

How we build

Deploy the chosen platform in your EU hosting environment with PostgreSQL, object storage and backups located where your transfer assessment requires.
Configure single sign-on, directory group sync, roles and project templates to match your permission model before any migration runs.
Test the migrated data, access controls and audit logging against the scope, then document the results for your compliance and records team.

How we hand over

Deliver runbooks for installation, upgrades, backups and restores, written for your own platform and operations teams.
Provide the configuration record, network diagram and data location map that your data protection officer and auditors will ask for.
Run a handover session with administrators and project leads, and agree in writing what remains with your internal team.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, so security patches reach production on a planned schedule.
Retest after each platform upgrade and after changes to identity, hosting or integrations that could affect data location or access.
Review new third-country access exposure whenever a vendor, support path or hosting provider changes, and update the documentation to match.

Project management for EU data sovereignty