You’ve read the legal sources about the Data Act switching procedures coming in September 2025. They tell you what you need to do—data portability, functional equivalence testing, exit clauses. What they don’t tell you is how to actually do any of it.
This guide is part of our comprehensive Understanding European Digital Sovereignty and the Movement Toward Independent Cloud Infrastructure resource, where we explore the strategic, regulatory, and technical dimensions of European independence from US platforms. Whilst that overview provides the migration context, this article delivers the step-by-step implementation blueprint you need to execute it.
We’re covering data export procedures that meet Data Act specs, deploying NextCloud and Mattermost on European infrastructure, negotiating contracts with measurable exit clauses, and build-vs-buy frameworks for sovereignty migration. The goal: keep your business running whilst avoiding vendor lock-in and hitting compliance requirements you can actually measure.
What are the Data Act switching procedures taking effect September 2025?
The Data Act switching procedures are mandatory processes that let you move between cloud providers without the usual barriers and costs. They kick in September 12, 2025 across the EU.
Here’s what you need to provide: data portability in standardised formats, functional equivalence testing protocols, exit clauses that spell out switching timelines and costs, and interoperability specs that prevent vendor lock-in. All your digital assets—structured and unstructured data, metadata, configurations—must be exportable. Target providers must support equivalent functionality. Switching costs get capped at reasonable levels.
The regulatory context matters within the broader European independence landscape. The European Commission saw vendor lock-in killing cloud competition, and the Data Act is their response. Contracts must specify every category of data and digital asset available during switching, and providers have to eliminate commercial, technical, and contractual obstacles. For detailed guidance on these compliance procedure requirements, see our comprehensive regulatory framework guide.
The timelines are specific. You get a maximum notice period of two months, a transitional period of typically 30 days (extendable to seven months in exceptional cases), and a minimum 30-day data retrieval period. Cost-covering switching charges are allowed until January 2027, after which switching charges are completely prohibited.
Model contract terms from Latham & Watkins and BCLP give you negotiation templates. The European Commission is publishing non-mandatory standard contractual clauses by September 2025.
The connection to functional equivalence testing is direct. IaaS providers must take all reasonable measures to ensure you achieve functional equivalence when you transition to alternative services. That’s not aspirational language—it’s a compliance requirement with teeth.
How do I execute data export procedures under Data Act requirements?
Start with a comprehensive audit of digital assets across your source platform. That means structured databases, unstructured files, metadata repositories, system configurations, API integration state, and user permission mappings. Article 2(38) defines exportable data as all input and output data including metadata generated by your use of the service—primary files you uploaded, configuration settings, logs, analytics, and any derived data created during operations.
Use provider-specific export tools combined with third-party ETL pipelines for format standardisation. AWS Data Export, Google Cloud Transfer Service, and Azure Data Box each have capabilities worth comparing. Google Cloud’s BigQuery exports support CSV, JSONL, Avro, and Parquet formats. Cloud Spanner uses a Dataflow template for consistent point-in-time snapshots in Avro files. Cloud SQL exports work with SQL dump files or CSV saved to Cloud Storage buckets.
The Data Act requires structured, commonly used, machine-readable formats. That means CSV or JSON for databases, XML for configuration files, and standardised formats like Dublin Core or ISO 19115 for metadata. If an industry standard format exists for your data type, use it.
Validate exports against Data Act interoperability specs. You’re checking for machine-readable formats, complete metadata preservation, referential integrity maintenance, and no proprietary encoding. Document everything with checksums, row counts, and schema validation. This documentation proves reproducibility for compliance audits.
Common pitfalls? Incomplete metadata export, broken referential integrity, and proprietary format lock-in. The main skills you’ll need centre on ETL pipelines, data validation, and format conversion scripting—these inform your build-vs-buy decision later.
What is functional equivalence testing in cloud migration?
Functional equivalence testing validates that your target infrastructure provides comparable capabilities and performance to your source system. This prevents service degradation during sovereignty transitions and establishes measurable quality gates that determine whether your migration succeeds or fails.
The testing protocol has four phases: capability mapping, performance benchmarking, integration validation, and user acceptance testing. Each phase needs defined acceptance criteria—measurable metrics like latency thresholds, throughput minimums, and uptime SLAs.
Capability mapping verifies feature parity. You’re documenting every feature your current system provides and confirming the target system can replicate it. This isn’t aspirational—you need explicit verification that functionality exists and works. Document gaps immediately because they inform rollback decisions. This capability verification is a critical component of the broader migration methodology we cover in our strategic planning framework.
Performance benchmarking establishes baseline metrics. Measure latency, throughput, and concurrency on your source system under typical and peak loads. Then replicate those conditions on the target system and compare results. Your acceptance criteria define acceptable performance deltas. A 10% latency increase might be fine, but a 50% increase probably isn’t.
Integration validation tests API compatibility and third-party service connections. All of those connections need verification on the target system. Document integration endpoints, test authentication flows, and validate data exchange formats.
User acceptance testing puts real users on the target system with production-like workloads. This surfaces issues that technical testing misses—UI differences, workflow disruptions, performance problems under specific usage patterns. Define acceptance criteria with your users before testing starts, not after.
The French Ministry of Education provides a reference implementation worth studying. Their NextCloud deployment serves 330,000 daily active users with verified performance equivalence to Microsoft 365. That’s not proof-of-concept scale—it’s production deployment with measurable validation.
Your rollback decision framework ties directly to acceptance criteria failures. If performance benchmarks fail, you don’t proceed to user acceptance testing. If integration validation reveals incompatibilities, you address them before moving forward. The testing protocol establishes quality gates, and those gates determine whether migration continues or rolls back.
How do I deploy NextCloud for file sharing sovereignty?
NextCloud deployment centres on a five-layer architecture: front-end application (PHP-FPM with Apache or Nginx), database (PostgreSQL or MySQL), object storage (S3-compatible backends), caching (Redis or Memcached), and load balancing for 50,000+ user scale. Understanding this architecture helps you work out whether you’ve got the capability to run it yourself or whether managed services make more sense.
European infrastructure provider selection matters because data residency compliance depends on actual infrastructure location, not marketing claims about “EU regions.” OVHcloud is French jurisdiction and a Gaia-X participant. Scaleway is French and cost-competitive. Hetzner is German and performance-optimised. Exoscale is Swiss with strict data residency guarantees. For detailed platform deployment guides comparing these providers across performance, feature completeness, and compliance capabilities, see our comprehensive European alternatives evaluation.
Your deployment approach depends on scale and in-house capability. Containerised approaches using Docker or Kubernetes simplify scaling and maintenance. The multi-tier architecture isolates concerns—application servers handle web requests, database servers manage persistence, object storage handles file data, caching layers reduce database load, and load balancers distribute traffic.
The configuration work involves LDAP or Active Directory integration for authentication, office document editing through Collabora Online or OnlyOffice, mobile client deployment, and backup/disaster recovery procedures. These aren’t optional features—they’re functional equivalence requirements if you’re migrating from Microsoft 365 or Google Workspace.
Integration with existing authentication infrastructure matters for user acceptance. LDAP and Active Directory integration provides single sign-on, but configuration requires understanding directory services and attribute mapping.
Office document editing determines whether users can actually work in NextCloud. Collabora Online and OnlyOffice both provide browser-based editing with reasonable compatibility for Word, Excel, and PowerPoint formats. Test compatibility with your organisation’s most complex documents before committing.
The operational burden for self-hosted NextCloud includes security patch management, database maintenance and backups, monitoring and alerting, user support, capacity planning, and disaster recovery testing. That operational load informs your DIY-vs-managed-services decision, which we’ll cover in the build-vs-buy section.
Migration from Microsoft 365 or Google Drive requires export of existing file structures, preservation of sharing permissions, mapping of user identities, validation of file integrity, and user training on interface differences. Parallel operation during transition lets users validate functionality before full cutover, with rollback capability if acceptance criteria fail.
How do I deploy Mattermost for team collaboration sovereignty?
Mattermost deployment follows a similar multi-tier approach to NextCloud: application servers running the Mattermost platform, PostgreSQL database for persistence, S3-compatible storage for file attachments, Elasticsearch for search functionality at scale, and load balancing for high availability.
European infrastructure deployment uses the same provider options as NextCloud—OVHcloud, Scaleway, Hetzner, or Exoscale—with the same data residency compliance requirements. Verify actual data centre locations and operational control by EU-based entities, not just marketing claims.
High-availability configuration requires multiple application servers behind load balancers, PostgreSQL replication for database redundancy, and S3 storage with geographic redundancy. These aren’t enterprise-only features—they’re functional equivalence requirements if you’re migrating from Microsoft Teams or Slack at any meaningful scale.
Authentication integration with your existing SSO infrastructure (SAML, OAuth, LDAP) provides the single sign-on experience users expect. This integration maintains security policies and reduces password fatigue, but configuration requires understanding identity protocols and claim mapping.
Migration from Microsoft Teams presents specific challenges. You need to inventory channel structures and replicate them in Mattermost, export message history from Teams (limited by API access constraints), re-implement bots and integrations via Mattermost API, develop user training and adoption plans, run parallel operation with both platforms, and plan gradual cutover with rollback capability.
The bot and integration re-implementation is often underestimated. Teams bots use Microsoft Bot Framework, whilst Mattermost uses its own API. You’re not migrating configurations—you’re rebuilding integrations. Budget engineering time accordingly and prioritise integrations by user impact.
User training matters more than technical features. Teams and Mattermost have different interfaces, keyboard shortcuts, and workflows. Users need hands-on training, documentation for common tasks, and clear communication about timeline and rollback plans. Poor user adoption kills technically sound migrations.
The operational considerations parallel NextCloud: security patches, database backups, search index maintenance, monitoring, user support, and bot/integration maintenance as APIs evolve.
The parallel operation period reduces risk by letting users validate functionality before Teams decommissioning. Run both platforms for at least 30 days, longer if your organisation is risk-averse or regulatory constraints demand extended validation. Monitor usage patterns, collect user feedback, and define acceptance criteria before cutover.
What is a five-layer AI sovereignty stack and how do I implement it?
The five-layer AI sovereignty stack separates concerns across data, infrastructure, models, applications, and governance. This lets you achieve sovereignty where it matters most whilst accepting dependencies where risk is manageable.
Layer one is data sovereignty—keeping training data, fine-tuning datasets, and user-generated content under your jurisdiction and control. This matters most if your business handles regulated data or competitive intelligence. Implementation means European infrastructure providers, encryption key management under your control, and data residency compliance with documented location guarantees.
Layer two is infrastructure sovereignty—compute, storage, and networking under European jurisdiction. This doesn’t mean avoiding hyperscalers entirely. It means understanding where workloads run and evaluating the geopolitical risks accordingly. Regulated industries may require complete European infrastructure. Others may accept hybrid approaches with documented risk mitigation.
Layer three is model sovereignty—controlling the AI models your applications depend on. Open-source models (Llama, Mistral, BLOOM) provide sovereignty at the cost of operational complexity. Proprietary model APIs from OpenAI or Anthropic reduce operational burden at the cost of dependency. The trade-off depends on your risk tolerance and technical capability.
Layer four is application sovereignty—the software that orchestrates models, manages prompts, and delivers functionality to users. Building custom applications maximises control but requires engineering investment. Using platforms like LangChain or LlamaIndex reduces development time but introduces dependencies. Evaluate based on your organisation’s engineering capacity and strategic importance of AI functionality.
Layer five is governance sovereignty—policies, auditing, and compliance frameworks that ensure your AI stack operates within acceptable boundaries. This layer is always under your control regardless of underlying dependencies. Semantic layers and access controls enforce data governance whilst enabling AI functionality.
Implementation starts with mapping current dependencies across all five layers. Document where data resides, which infrastructure hosts it, which models you use, what applications consume those models, and what governance policies apply. This audit reveals where your sovereignty gaps are and which ones matter.
Build-vs-buy decisions differ by layer. Data sovereignty almost always means building—you can’t outsource control of regulated data. Infrastructure sovereignty might accept managed services from European providers who meet compliance requirements. Model sovereignty might use open-source models with managed hosting. Application sovereignty depends on strategic importance and engineering capacity.
How do I negotiate cloud contracts with Data Act exit clauses?
Your contract negotiation needs to start before September 2025 if your current agreements lack compliant exit terms. You’re negotiating maximum notice periods, transitional timelines, data retrieval procedures, switching cost caps, and functional equivalence commitments.
The maximum notice period is two months under Data Act requirements. If your current contract specifies longer periods, renegotiate. The provider’s obligation to cooperate in good faith begins when you trigger the exit clause.
Transitional period specs need clear timelines and deliverables. Thirty days is typical, with extension to seven months for exceptional circumstances. Define what constitutes “exceptional circumstances” explicitly—infrastructure complexity, data volume, integration dependencies. Vague terms create negotiation deadlines when you need predictable timelines.
Data retrieval procedures must specify formats, delivery mechanisms, validation procedures, and timeline guarantees. Contracts should enumerate specific formats for your data types—CSV, JSON, XML, Parquet, or industry-standard formats—rather than relying on generic language about “machine-readable formats.”
The cost question matters. Cost-covering charges are permitted until January 2027, then completely prohibited. Negotiate explicit cost caps now rather than accepting “reasonable costs” language that invites disputes. Data egress fees from providers like AWS can add up when you’re transferring terabytes, so address these specifically in exit clauses.
Functional equivalence commitments bind the provider to support your migration testing. IaaS providers must take all reasonable measures to ensure you achieve functional equivalence on alternative services. That obligation should extend to documentation, technical support, and validation assistance.
Model contract terms from law firms provide negotiation starting points. Latham & Watkins and BCLP published templates aligning with Data Act requirements. Use these to identify gaps in your current contracts and prioritise renegotiation discussions.
The European Commission’s non-mandatory standard contractual clauses arrive by September 2025, providing additional reference material. These clauses aren’t binding, but they represent regulatory guidance on compliant contract terms. Providers who deviate substantially may face scrutiny during enforcement.
Negotiation leverage depends on contract renewal timing and competitive alternatives. If you’re mid-contract with years remaining, renegotiation may require concessions elsewhere. If you’re approaching renewal, Data Act compliance becomes a competitive factor in RFP evaluation. If you’re starting fresh, compliant exit terms should be table stakes.
What are build-vs-buy decision frameworks for sovereignty migration?
Build-vs-buy decisions affect every layer of sovereignty migration—infrastructure, platforms, applications, and operational support. The framework evaluates technical requirements, skills availability, operational burden, cost structures, and risk tolerance.
Technical requirements start with functional equivalence. If you need capabilities that only proprietary platforms provide, building from open-source alternatives may not meet acceptance criteria. If open-source platforms provide equivalent functionality with acceptable performance, building becomes viable.
Skills availability determines implementation feasibility. NextCloud deployment requires container orchestration, PostgreSQL administration, and LDAP integration expertise. If you have these skills in-house, DIY deployment is realistic. If you’re hiring for all technical capabilities, managed services might be more pragmatic.
Operational burden extends beyond initial deployment. Self-hosted platforms require security patch management, database backups, monitoring, user support, capacity planning, and disaster recovery testing. Managed services shift these responsibilities to vendors but introduce dependency and cost.
Cost structures differ significantly between DIY and managed approaches. DIY means infrastructure costs, engineering salaries, and operational overhead. Managed services mean monthly fees with fewer hidden costs but higher total expenditure. Model both scenarios with realistic assumptions about engineering time and infrastructure requirements. For comprehensive frameworks on implementation cost tracking and ROI modelling, our economic analysis guide provides detailed cost comparison methodologies.
The five-to-seven-year TCO comparison often favours DIY approaches for organisations with engineering capacity. The upfront investment in deployment and automation pays off through reduced ongoing costs. Smaller organisations or those with limited technical staff may find managed services more economical.
Risk tolerance determines acceptable dependency levels. Regulated industries with strict data residency requirements may require DIY deployment with complete control. Less regulated organisations might accept managed services from European providers who meet compliance requirements. Map your risk profile before evaluating options.
The DIY-vs-managed-services decision isn’t binary. Hybrid approaches use managed infrastructure (Kubernetes clusters from OVHcloud) with DIY application deployment (NextCloud and Mattermost). This balances control with operational burden, letting you own application sovereignty whilst outsourcing infrastructure operations.
Consulting services from Adfinis or Code Enigma provide middle ground options. They offer deployment services, training for your team, and ongoing support that reduces operational burden without full managed service dependency. Evaluate based on your team’s capability development goals and timeline constraints.
Assessment criteria for any approach include European infrastructure deployment experience, successful NextCloud or Mattermost track record, open-source platform expertise, ongoing support models, and client references from similar-scale deployments.
What skills requirements should I plan for during sovereignty migration?
Skills requirements span technical, operational, and strategic domains. The specific skills you need depend on build-vs-buy decisions, but understanding the full scope helps inform those decisions.
Technical skills for DIY infrastructure deployment include container orchestration (Docker, Kubernetes), database administration (PostgreSQL, MySQL), object storage configuration, web server configuration, and SSL/TLS certificate management. These infrastructure skills apply across NextCloud, Mattermost, and custom deployments.
Platform-specific skills for NextCloud include PHP-FPM configuration, NextCloud-specific modules and extensions, Collabora Online or OnlyOffice integration, LDAP/Active Directory integration, and mobile client configuration and distribution. For Mattermost, you need Go application management (Mattermost is written in Go), Elasticsearch configuration for search, SAML/OAuth integration for SSO, and bot/integration API development.
Data engineering skills for export procedures include ETL pipeline development, data validation frameworks, format conversion scripting (Python, SQL), schema mapping and transformation, and checksum verification and integrity validation. These skills ensure data export procedures meet Data Act compliance requirements.
Testing and validation skills include test automation framework development, performance benchmarking methodology, load testing tool configuration (JMeter, Gatling, K6), metrics collection and analysis, and acceptance criteria definition and measurement. These skills support functional equivalence testing protocols.
Operational skills for ongoing management include security patch management processes, backup and disaster recovery procedures, monitoring and alerting system configuration (Prometheus, Grafana, Datadog), capacity planning and scaling procedures, and incident response and troubleshooting. These skills determine whether DIY deployment is operationally sustainable.
Strategic skills for migration planning include vendor contract negotiation, risk assessment and mitigation planning, technical due diligence for vendor evaluation, project management for complex migrations, and stakeholder communication for change management. These skills apply regardless of build-vs-buy decisions.
The skills gap analysis determines training requirements, hiring needs, and consulting engagement scopes. Map current team capabilities against required skills, identify gaps, and evaluate whether training, hiring, or external services fill those gaps most effectively.
Training investment for DIY approaches should start before migration begins. Budget time for experimentation and learning rather than expecting production-ready expertise immediately.
Hiring for sovereignty migration should target candidates with open-source platform experience and European infrastructure deployment backgrounds. These specialists accelerate migration timelines and reduce risk.
Consulting engagement scopes vary from full managed services to time-boxed knowledge transfer. If you want to build internal expertise, structure consulting engagements around training and knowledge transfer.
Which consulting service providers support European sovereignty migrations?
Consulting service provider evaluation should focus on European infrastructure deployment experience, successful NextCloud and Mattermost track records, open-source platform expertise, ongoing support models, and client references from similar-scale deployments.
Adfinis is a Swiss consulting firm with documented sovereignty migration expertise, particularly in NextCloud and Mattermost deployments. Their client base includes European public sector organisations with strict data residency requirements.
Code Enigma is a European consultancy focusing on open-source platforms and digital sovereignty. Their expertise spans infrastructure deployment, platform configuration, and ongoing operational support.
Assessment criteria for any consulting provider should include documented European infrastructure deployments (not just European clients using US infrastructure), NextCloud deployments at your user scale (don’t assume skills transfer from 50-user to 50,000-user scale), Mattermost deployments with high-availability configurations, functional equivalence testing experience with defined acceptance criteria, and client references willing to discuss deployment challenges and outcomes.
The engagement model matters as much as technical capability. Some consultancies offer turnkey deployments then hand off operations to your team. Others provide ongoing managed services with operational responsibility. Some focus on time-boxed knowledge transfer engagements that build your team’s capabilities. Match the engagement model to your organisation’s capability development goals.
Service level agreements should specify deployment timelines, acceptance criteria for handoff, response time commitments for support requests, and escalation procedures for incidents. Vague commitments create disputes during stressful migration periods. Explicit SLAs align expectations and provide recourse when delivery falls short.
Reference calls with existing clients reveal more than marketing materials. Ask about deployment challenges, how the consultancy handled unexpected issues, whether timelines were met, and whether they’d engage the same provider again.
Avoiding common consulting pitfalls requires explicit documentation of scope, deliverables, acceptance criteria, and handoff procedures. Consultancies may shortcut these for efficiency. Insist on them as part of engagement scope.
What are common pitfalls in Data Act switching implementations?
Common pitfalls span technical, operational, and strategic domains. Understanding these risks lets you build mitigation into project planning rather than discovering them during execution.
Incomplete data export procedures often miss metadata, configurations, or derived data that aren’t obvious in primary data stores. The Data Act requires all input and output data including metadata, but audit procedures sometimes focus on primary data only. Document data dependencies comprehensively before beginning export.
Broken referential integrity during data export corrupts relationships between database tables, user permissions, and file associations. Validate integrity after export with automated checking rather than discovering problems after target deployment. Export procedures should preserve foreign key relationships and validate them before declaring export complete.
Underestimated migration timelines create compression when implementation takes longer than planned. Functional equivalence testing, in particular, requires more time than technical leaders typically budget. Plan conservatively and build buffer into timelines rather than optimistic scenarios that assume perfect execution.
User training and change management determine whether technically sound migrations actually work in practice. NextCloud and Mattermost work differently than Microsoft 365 and Teams, and interface familiarity matters more than technical feature parity. Budget time for training and adoption support, not just technical deployment.
Rollback planning provides insurance against acceptance criteria failures. Parallel operation periods, backup retention, and defined rollback procedures let you recover from failed migrations without business disruption. Plan rollback procedures before migration begins, not after discovering problems.
Missing functional equivalence acceptance criteria create disputes about whether migration succeeded. Define measurable criteria before testing begins—latency thresholds, throughput minimums, feature parity checklists, uptime SLAs. Document criteria in writing and get stakeholder agreement.
Vendor lock-in can recur when sovereignty migration simply changes vendors without addressing underlying architectural dependencies. Moving from AWS to OVHcloud doesn’t prevent lock-in if your application architecture remains tightly coupled to provider-specific services. Design for portability across European providers, not just exit from US providers.
Operational burden gets underestimated when organisations plan successful deployments but don’t account for ongoing patch management, backup procedures, monitoring responsibilities, and user support requirements. Model operational requirements realistically before choosing DIY deployment, and budget headcount or managed services accordingly.
Compliance gaps discovered late in migration happen when legal and technical teams don’t align on Data Act interpretation until implementation reveals gaps. Engage legal counsel early to review export procedures, contract exit clauses, and functional equivalence testing protocols before finalising technical approaches.
Cost overruns from data egress fees surprise organisations that don’t model AWS transfer costs accurately. Data egress fees are eliminated by January 2027, but until then, expect charges that scale with data volume for transferring terabytes out of AWS. Budget these costs explicitly in migration planning.
Most of these pitfalls are preventable with proper planning. They’re execution risks, not inherent migration challenges. Comprehensive planning, conservative timeline estimates, explicit acceptance criteria, realistic operational burden modelling, and coordination between technical and legal teams address most of them upfront.
Where do I start?
You’ll want to start with a contract audit. Review current cloud service agreements for exit clause language, notice period specifications, data export procedures, and switching cost terms. Identify gaps relative to Data Act requirements and prioritise renegotiation discussions with providers.
Next, conduct digital asset inventory. Document all data, configurations, integrations, and customisations in your current environment. This inventory informs data export procedures, functional equivalence testing scope, and migration timeline estimates. Incomplete inventory creates surprises during implementation.
Define functional equivalence acceptance criteria with stakeholders before technical work begins. Measure current system performance, document required features, specify acceptable performance deltas, and get explicit agreement from technical and business stakeholders. Written acceptance criteria prevent scope creep and provide clear quality gates.
Evaluate skills gaps honestly. Map your team’s current capabilities against DIY deployment requirements, identify gaps, and decide whether training, hiring, or consulting services fill those gaps. Optimistic self-assessment creates operational problems after deployment completes.
Pilot deployments reduce risk before full migration. Deploy NextCloud or Mattermost for limited user populations, test functionality with real usage patterns, measure performance against acceptance criteria, and iterate based on feedback. Pilot deployments reveal issues before they affect your entire organisation.
Build comprehensive timelines with conservative estimates. Include time for learning, testing, rollback procedures, user training, and buffer for unexpected issues. Compressed timelines create pressure that leads to shortcuts and mistakes. Plan for realistic execution, not optimistic scenarios.
The September 2025 deadline is approaching. You’ve got contracts to renegotiate, infrastructure to deploy, data to export, testing to validate, and users to train. Start now, plan comprehensively, and build in rollback capability. The Data Act gives you rights—implementation gives you sovereignty.
For a complete overview of the strategic rationale, regulatory landscape, and economic considerations that inform these implementation procedures, see our sovereignty implementation overview.
