Where Your Data Actually Lives: Cloud Sovereignty as an Infrastructure Decision, Not a Legal Checkbox

You have signed Standard Contractual Clauses with your hosting provider. Your privacy policy is in order. Your Data Processing Agreement is signed. Legally, you are covered. But if the server running your database is operated by a US company, regardless of where the data center is physically located, that company can be legally compelled under the CLOUD Act to grant access to US authorities. Paperwork does not change that technical fact.

1. The problem paperwork does not solve

Most companies in Moldova and Romania run on AWS, Azure, or Google Cloud. The reasons are straightforward: scalability, competitive pricing, ready-made integrations. But all three are US companies, and the CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) requires US providers to respond to US authority requests for data, even when that data physically sits on servers in Frankfurt or Dublin. Signing SCCs does not cancel a provider's legal obligation to its own government. SCCs are a useful tool for GDPR compliance around data transfers, but they do not change who can technically and legally request access to the physical infrastructure.

2. Why this matters right now

Three factors are converging in 2026: The EU Data Act is being enforced more firmly, pushing toward data portability and control within the EU. Geopolitical tension is rising, and more European companies, particularly in regulated sectors like fintech, healthcare, and the public sector, are asking what happens to their data if the relationship between the EU and a non-EU provider deteriorates suddenly. Reputational and business risk is growing: enterprise customers increasingly ask, during due diligence, where data is stored and who can access it.

3. What is cloud sovereignty? Four checkable criteria

Cloud sovereignty means real, technically verifiable control over the jurisdiction, location, and access to your data, not just compliance with contractual clauses. The term is often used commercially with little real substance behind it. Four checkable criteria make the difference:

1. Operator jurisdiction: under which law does the company that owns the infrastructure operate? A European subsidiary of a US company is ultimately still subject to US law for certain types of requests.
2. Physical location: where are the disks and backups physically located, including replicas and snapshots?
3. Real technical access: who holds infrastructure-level access credentials, not just application-level ones? Is this access logged? Can it be audited?
4. Real portability: how much time and effort would a full migration take, without vendor lock-in to proprietary formats or closed APIs?

4. A technical checklist, not a legal one, for your current infrastructure

Unlike a GDPR compliance checklist (documents, DPO, registers), this one is about infrastructure:

• Who, besides your own team, has SSH or admin console access to your servers?
• Is two-factor authentication enforced on all administrative accounts, including the provider's own?
• Are access logs centralized and protected against tampering?
• Are backups encrypted, with encryption keys under your control rather than the provider's?
• Could you fully export your infrastructure (configuration, data, code) in under a week if you needed to?
• Do you know exactly which country and jurisdiction each copy of your data sits under, including disaster recovery replicas?

If you cannot confidently answer most of these questions, your data sovereignty is, at this point, theoretical.

5. The practical first step: not migration, access control

The most realistic starting point for most companies is not a complex migration to fully sovereign infrastructure, but checking and locking down what you already have. SSH hardening, disabling the provider's default access, tamper-protected audit logging, and strict access policies are concrete measures, deployable in a matter of days, that directly answer the question of who can reach your data today.

SECURITY · SERVER HARDENING

Who has access to your servers today?

We lock down access to your existing infrastructure: SSH hardening, CIS-benchmark firewall configuration, automated security patching, and tamper-protected audit logging. Verifiable technical control over who can reach your data, regardless of where the servers are hosted.

5 DAYS

FULL DELIVERY

Harden your servers →

How the WebDirect team helps

The WebDirect team helps companies in Moldova, Romania, and the EU move from cloud sovereignty as a slogan to verifiable technical control, from server hardening and audit logging to full migrations to EU-native infrastructure when that makes sense for the business. If you want to know exactly who has access to your infrastructure today, get in touch.

Sources

• Clarifying Lawful Overseas Use of Data Act (CLOUD Act), United States, 2018.
• Regulation (EU) 2023/2854 (EU Data Act).
• Regulation (EU) 2016/679 (GDPR), on international data transfers.

This material is for informational purposes only and does not constitute legal advice.

Frequently asked questions

What is cloud data sovereignty?
Cloud data sovereignty means a company's data is subject to the laws and control of its own jurisdiction, not the laws of the country where its cloud provider is registered. It is verified through four technical criteria: operator jurisdiction, physical location, who has real access, and how easily data can be exported.What is the CLOUD Act, and why does it matter for companies in Moldova or Romania?
The CLOUD Act is a 2018 US law that requires cloud providers with a legal presence in the US, such as AWS, Azure, and Google Cloud, to respond to US authority requests for data, even when that data is physically stored in the EU.Aren't SCCs enough to protect data from foreign access?
SCCs address legal compliance around data transfers under GDPR, but they do not remove a US provider's legal obligation to respond to US authority requests under the CLOUD Act, regardless of contractual clauses.Do we need to fully migrate away from AWS or Azure?
Not necessarily. For many companies, the effective first step is securing technical access to existing infrastructure. A full migration is a separate decision based on risk profile and industry.How much does a basic server security check cost?
Linux server hardening (SSH hardening, firewall, audit logging) starts at €600, delivered within 5 business days.