Hyperscaler Power, French Jurisdiction

Data residency was the easy part, and most teams solved it years ago by picking an eu-west region. What changed is the realisation that storing data in Europe does nothing if the entity operating the service can still be compelled, under its home country's law, to hand that data over. Sovereignty in 2026 is about who can be served a subpoena, not where the disk spins.

S3NS, the joint venture between Thales and Google Cloud, exists to close exactly that gap: the operational maturity of a hyperscaler, wrapped in a French-controlled legal and operational shell that the US CLOUD Act cannot reach. It is the concrete answer to a question European regulators have been sharpening for years, and the answer has real engineering consequences.

Why sovereignty stopped being optional

The friction is a direct conflict of laws. Under GDPR, personal data of EU residents enjoys strong protection and transfers outside the EEA are tightly constrained. Under the US CLOUD Act of 2018, a US-headquartered provider can be compelled to produce data in its possession, custody or control, regardless of where in the world that data physically sits. A US hyperscaler operating a Frankfurt region is still a US company, and that is the whole problem.

For most workloads this is a theoretical risk you accept. For others, defence, health records, justice, critical infrastructure, public administration, the OIV/OSE operators France classifies as essential, it is disqualifying. The EUCS debate, the schrems rulings invalidating Privacy Shield, and France's own "Cloud au centre" doctrine all push the same conclusion: certain data must live under an operator that is provably immune to foreign extraterritorial reach. SecNumCloud is ANSSI's qualification for exactly that class of provider.

What "sovereign" actually has to mean

The word is abused, so it is worth being precise. A genuinely sovereign cloud has to satisfy four independent properties, and dropping any one of them collapses the guarantee:

• Data residency, the bytes are stored and processed only within the chosen jurisdiction. Necessary, but on its own almost meaningless.
• Operational sovereignty, the people with administrative access, the support staff, and the entity that controls them are local and screened. No remote root from another continent.
• Key custody, encryption keys are generated and held by the customer or a local trustee, so the operator cannot decrypt data even when it holds the ciphertext.
• Immunity to foreign law, the operating entity's capital, governance and chain of command sit outside the reach of any extraterritorial statute. This is the one a region selector can never give you.

SecNumCloud 3.2, the current ANSSI reference, codifies these into auditable requirements, including the now-famous rule that the qualified entity must be immune to non-EU law, capping any non-EU shareholder's influence. A US hyperscaler cannot self-certify against that. It needs a different corporate structure entirely.

How S3NS squares the circle

S3NS is majority-controlled by Thales, with Google Cloud as a minority technology partner. Crucially, the service is operated by S3NS in France, on infrastructure in French regions, by French-screened staff, under French governance. Google contributes the platform technology under licence; it does not run the production environment and has no administrative path into it. That structural separation is what makes the SecNumCloud immunity criterion satisfiable.

Toggle the simulator below between a public US hyperscaler and S3NS, then send a sensitive record. Watch where the data packet, and the encryption keys, actually go relative to the French jurisdiction boundary, and how the compliance panel changes.

The trade-offs nobody puts on the slide

Sovereignty is not free, and pretending otherwise sets teams up to fail their first migration. A trusted-cloud platform is a deliberately constrained subset of the parent hyperscaler, and you plan around the constraints rather than wish them away.

• Smaller service catalogue. S3NS exposes a curated, qualified subset of Google Cloud services. The newest managed product you saw at the last keynote is probably not in scope yet, so architect against what is qualified, not against the public roadmap.
• Region constraints. Fewer regions and zones means you design availability inside France rather than spreading across a global footprint. Multi-region DR looks different, and cross-border replication is by design not an option.
• Key management discipline. Customer-held keys via external key management (EKM/HYOK) mean you now own an HSM-backed key service whose availability gates your data plane. Lose the keys, lose the data, on purpose.
• Migration patterns. Lift-and-shift rarely works cleanly. The realistic path is a sovereignty tier, classify workloads, move only the regulated estate, and keep non-sensitive systems on the broader platform where velocity matters more than immunity.

The encryption story is where the guarantee becomes concrete. With external key management, the keys live in an HSM under your control in France and are referenced, never exported, by the cloud service. The operator processes ciphertext it cannot unilaterally decrypt, so even a lawful order produces nothing usable without a key release the French-controlled entity governs.

# S3NS sovereign workload: external key custody, FR-only placement
project: gov-records-prod
region: eu-fr-paris            # qualified region, no cross-border replication
encryption:
  kms: external                # EKM / HYOK, keys never leave the HSM
  keyUri: ekm://hsm.sovereign.fr/keys/records-aes256
  operatorCanDecrypt: false    # ciphertext-only at the operator
compliance:
  qualification: SecNumCloud-3.2
  immuneToExtraterritorialLaw: true
  operatedBy: S3NS (Thales-controlled, FR)