Hosting and data

What this domain covers#

The fourth domain asks the declarant to make precise the effective location of the servers and data, the jurisdiction under which these servers are operated, the trajectory of client data (does it transit through, or is it stored, outside the European Union, in which cases, for which purposes), the contractual guarantees on this location, and the procedure for informing the client in the event of an extra-European requisition.

The domain does not stop at the physical location of the data centres. It interrogates the effective jurisdiction: a data centre located in France but operated by a subsidiary of an American group remains subject to the American CLOUD Act, as confirmed by the United States Supreme Court and by the public analyses of ANSSI. Physical location is necessary but not sufficient. The jurisdiction of the operational decision-maker and the capital chain that controls it are determining.

Why this domain matters#

Thesis 7 of the manifesto founds the requirement: “distributing free software through registries and networks subject to a foreign jurisdiction is to grant that jurisdiction a right of oversight and cut-off over what we believe we own.” Client data, which often constitutes the most precious asset that an organisation entrusts to a provider, deserves a particularly precise analysis of this jurisdictional dimension.

The French regulatory context of “Cloud at the centre”, the requirements of the NIS 2 directive, and the SecNumCloud qualification issued by ANSSI for sensitive workloads converge towards a clear expectation: for sensitive data (health, defence, personal data with stakes), American jurisdiction via the CLOUD Act is a structural risk that must be declared and ideally avoided. In spring 2026, nine providers are SecNumCloud 3.2 qualified (Outscale, OVHcloud, Cloud Temple, Worldline, Orange Business, Cegedim, Oodrive, Tenexa, and S3NS since 17 December 2025), which constitutes a credible offer for the most sensitive workloads — even if the functional breadth remains lower than that of the American hyperscalers, a gap that the manifesto documents in its inventory.

At an aggregate scale, the publication of hosting information by European providers reveals the actual concentration of the field: how many European publishers ultimately host with AWS, Azure or GCP despite a “French” presentation? This transparency is a leverage point to shift default choices.

What is asked, by category of declarant#

For a SaaS publisher, or for the hosting recommendations of an on-premise solution. Location of the servers (country, hosting provider, effective jurisdiction), trajectory of client data (storage, processing, backups — including any transfers outside the EU and their purpose), contractual guarantees on the location, procedure for informing the client in the event of an extra-European requisition, options offered to the client for hosting (hyperscaler, European hosting provider, on-premise hosting at the client’s site).

For a hosting or cloud provider. Precise location of the data centres (city and country), capital ownership hierarchy of the operating companies, applicable certifications (HDS, SecNumCloud, ISO 27001, ISO 27017, ISO 27018), resistance to extraterritorial laws with reasoned analysis, contractual commitment on the country of effective execution of client data, public procedure in the event of an extra-European requisition.

For a distributor or integrator. Where are the distributed solutions actually hosted? Can the distributor guarantee a European location through its own contract, or only pass on the conditions of the original publisher? In the case of a managed service resold under a white label, who actually controls the servers, and is the chain of control communicable to the end client?

An example of an honest, well-done answer#

A French SaaS publisher of 22 staff declares its domain 4 as follows. Production hosting on OVHcloud Public Cloud, Gravelines data centre (France). Encrypted backups hosted with Scaleway, Paris data centre. For clients with reinforced requirements (premium offer), a deployment option on Outscale qualified SecNumCloud 3.2 (data centre in the Paris region) at a higher tariff. No client data transits through, or is stored, outside the EU in the standard deployment; for the transactional mailing service currently operated by an American provider (declared as a blind spot in domain 7), outgoing emails transit through the provider’s American SMTP servers, which is being migrated to Mailjet (France) by 2026. The client contracts include a clause for information within 5 working days in the event of foreign requisition, insofar as the law allows. No extra-European requisition has been received to date.

An anti-pattern to avoid#

A domain 4 that contents itself with mentioning “hosting in Europe, GDPR-compliant” without making precise the effective jurisdiction of the cloud operator misses the CLOUD Act stake. GDPR compliance says nothing about resistance to extraterritorial laws. A triumphant mention along the lines of “our data is safe in our data centres” without making precise which data centres and who operates them does not constitute a usable declaration. Conversely, an alarmist declaration that exaggerates the risks loses credibility. The tone to aim for: precise, factual, traceable.

Articulation with the other domains and commitments#

Domain 4 is articulated directly with the provider commitment pub-008-european-host-default: a provider that has taken on this commitment has concrete arguments for its domain 4. It is also articulated with domain 6 (governance and capital): a host’s jurisdiction depends largely on its capital structure. The client that reads a provider’s domain 4 can extend its analysis by reading the domain 4 of the host cited, in a logic of complete chain consistent with thesis 6 of the manifesto.

How to fill in the form#

Domain 4 is the densest of the Profile. It distinguishes two radically different situations: consuming hosting (the case of a SaaS publisher, of an integrator, of an MSP) and producing hosting (the case of OVH, Scaleway, AWS…). The form is broken up into 4 steps presented in a horizontal stepper, and adapts automatically to the categories ticked at the Profile step:

• Publisher: steps 01 (consumed hosting), 02 (consumed bricks), 04 (variants and frame).
• Hosting or cloud provider: steps 01 (my infrastructure), 04 (variants and frame).
• Managed service provider / MSP: all 4 steps (01 consumed hosting + 02 bricks + 03 MSP tools + 04 variants and frame).
• Distributor or integrator: steps 01, 02, 04 (as for the publisher, plus the hosting of the distributed solutions in 04).
• If several categories are ticked (e.g. publisher and hosting provider), all the relevant blocks appear in the corresponding steps.

Step 01 — Hosting#

This step gathers everything that pertains to the servers and the trajectory of the data: if you are yourself a hosting provider, your own infrastructure; if you consume hosting, the list of providers; and in all cases, the cross-provider narrative of the data and the requisition procedure.

My infrastructure (reserved for hosting and cloud providers)#

For providers that operate the infrastructure themselves — you are the host, not a consumer. The full capital detail goes to domain 6; here we document what directly concerns the data centres and the contractual client commitments.

• Operated data centres: for each site, Location (city, country), Jurisdiction, Mode of occupation (Owned / Leased / Colocation), Comment (SecNumCloud qualification of the site, redundancy, etc.).
• Contractual guarantee of the country of execution: contractual commitment given to the client on the country of effective execution of its data. Example: “framework contract guaranteeing that the data does not leave France”. Distinct from the marketing discourse.
• Summary of the capital chain: one or two sentences on who controls the entity in fine. The line-by-line detail goes to domain 6.

Hosting and cloud providers#

List all the hosting and cloud providers that you consume. Several entries are the norm: multi-cloud, hybrid (public cloud + colocation), production + disaster recovery in another region, segmentation by application workload…

A library proposes the main providers (OVHcloud, Scaleway, 3DS Outscale, Cloud Temple, Bleu, S3NS, Hetzner, Infomaniak, AWS, Azure, GCP…). Select those that match; each entry pre-fills its name, its jurisdiction and — for operators that run an outsourced stack such as Bleu or S3NS — the jurisdiction of the underlying stack.

For each host, you fill in:

• Name: commercial name.
• Jurisdiction of the host: country under whose law the hosting company operates.
• Jurisdiction of the underlying technical stack: to be filled in only if the host operates the technical stack of another publisher. Example: Bleu operates Microsoft Azure → operator jurisdiction France, underlying stack jurisdiction United States. For OVH or AWS, this field remains empty.
• Location of the data centres used: data centres actually used with this provider (city, region). E.g.: “Roubaix (RBX1) + Strasbourg (SBG3)”. Per provider because a multi-cloud deployment uses different sites with each one.
• Exposure to extraterritorial laws (CLOUD Act, etc.): ternary (Yes / No / Partial / Not applicable / Not communicated) with comment and source, for THIS host. An honest declaration may combine Yes (AWS) and No (OVH) depending on the providers; this is precisely what the per-provider separation allows to be expressed.
• Qualifications of this host: public certifications attached to this provider (SecNumCloud, HDS, ISO 27001, EUCS…). Entered per host so that we always know to whom each qualification applies.

Trajectory of the data and requisition procedure#

Fields at the level of the domain (below the list, independent of any particular provider):

• Trajectory of the data: overall flow of client data, including the passages between providers. E.g.: “primary storage OVH, backups Scaleway, transfers outside the EU for transactional mailing”. This is a cross-provider narrative, not a fact sheet per host.
• Procedure for informing in the event of extra-European requisition: process of the declarant when a foreign authority addresses a requisition to any of its providers. Independent of the provider that receives the request.

Step 02 — Consumed bricks#

Beyond hosting, your solution depends on third-party bricks: SaaS services for runtime functions (payment, email, CRM…) and platforms (PaaS) for application code. These two categories have a sovereignty exposure distinct from the principal host and deserve their own declaration.

Platforms (PaaS) and reversibility strategy#

Distinct from the principal host: a PaaS imposes a lock-in at the level of the API and the runtime. Migrating elsewhere is not a configuration change but a rewriting project, the scale of which depends on the platform features used.

A dedicated library (Vercel, Heroku, Cloud Run, Clever Cloud PaaS…). Each entry pre-fills the estimated complexity of exit and displays, on selection, a “Key points” panel that details the typical proprietary components.

• Name, Jurisdiction of the platform: pre-filled from the library, editable.
• Purpose (what is this PaaS for): Next.js frontend hosting, cron jobs, serverless API, etc.
• Complexity of exit: Low (standard redeployment on another runtime), Medium (adaptation needed), High (substantial rewriting), Not assessed. Pre-filled from the library, to be adjusted to your actual usage.
• Proprietary components used: list the specific platform features used (Edge Functions, KV, Blob, managed identity, image transforms, proprietary queues…). If you use none, say so — it is good news for portability.
• Portability strategy: what is portable in your application code and what is not. Honesty preferable. “Application code 100% portable, data in external Postgres” is a more useful answer than “open technology”.
• Reversibility strategy: how do you redeploy elsewhere if the PaaS becomes unavailable? Identified target platform, estimated lead time, blocking dependencies.
• Concrete portability test: Status (fully / partially / not tested) + Date of the last test. Without a concrete test, portability is only a hypothesis.
• Qualifications of the platform: public certifications attached to this PaaS (SOC 2, ISO 27001, EUCS, HDS…). Same fields as for the principal host. Entered per PaaS so that we know to which provider each qualification applies.

Secondary services#

Beyond hosting, your solution depends at runtime on a set of third-party services: payment (Stripe, Mollie, PayPlug), transactional email (SendGrid, Brevo, Mailjet), CRM (HubSpot, Pipedrive), client support (Intercom, Zendesk, Crisp), SMS (Twilio). These services see a portion of the client data pass through and often fall under a jurisdiction different from the host’s.

GDPR compliance says nothing about the CLOUD Act: a declarant that hosts in France but ships its emails via an American service must declare it honestly.

A dedicated library proposes the most common services. For each service used: Name, Purpose (payment, transactional email, CRM, client support…), Jurisdiction (US, FR, IE…).

Step 03 — Operations tools (reserved for MSPs)#

Specific to managed service providers. These tools — RMM (ConnectWise, NinjaOne, Datto, Kaseya, Atera, N-able…), PSA, monitoring, backup, remote access — access your clients’ systems continuously through persistent agents installed on each endpoint. This is a major sovereignty blind spot: most major publishers are American, hence subject to the CLOUD Act and FISA 702. The Linux servers you operate at your French client’s site inherit it.

A library proposes the main tools. For each one, indicate:

• Name, Type (RMM / PSA / Monitoring / Backup / Endpoint security / Remote access / Ticketing / Other), Publisher, Jurisdiction of the publisher: pre-filled from the library, editable.
• Deployment perimeter: where is the agent or collector installed? E.g.: “all client servers”, “dedicated bastion”, “workstations only”. Determines the actual scope of exposure.
• Access perimeter: what can the tool read or modify? E.g.: “full root access”, “system telemetry only”, “reading of application logs”. A root agent on every client server does not expose the same thing as a read-only SNMP collector.
• Comment: open source alternative considered, migration plan, mitigation measures.

Step 04 — Variants and frame#

This last step covers contextual divergences (variants by mode of delivery, hosting operated on behalf of clients) and the general frame of the domain (comment, “not applicable” mention).

Variants by mode of delivery#

To be filled in only if you offer your solution in several forms — for example a publisher that sells both a SaaS version hosted by itself and an on-premise version deployed at the client’s site. If your solution exists in only one form, leave empty.

The idea is not to repeat the entire form for each mode, but to note what changes in relation to the principal declaration above.

• Mode concerned: short name of the variant (on-premise at the client’s site, premium SecNumCloud offer, government edition…).
• What changes for this mode: differences in relation to the answers above. E.g.: “hosting at the client’s site, not at ours”, “Outscale data centres SecNumCloud-qualified instead of OVH”, “no requisition possible on the publisher’s side (the client is the sole data controller)”. No need to repeat what is identical.

Hosting of distributed solutions#

For distributors, integrators and MSPs: describes where the solutions operated on behalf of the client are actually hosted. Distinct from the “Principal host” above, which covers the infrastructure that you consume for your own services.

• Name of the solution: product or platform delivered to the client (managed WordPress, dedicated GitLab, Magento e-commerce site…).
• Effective hosting jurisdiction: country under which the hosting actually operates, taking the capital chain into account (a French cloud subsidiary of a US group remains subject to the CLOUD Act).
• Transmissible guarantees: contractual clauses that you can pass on to the end client (commitment on the country, requisition procedure, certifications). If you can only pass on the conditions of the original publisher, say so honestly.

General frame#

At the bottom of the step, two transverse fields:

• My case is not covered (checkbox + comment): if the entire domain does not apply to your situation, declare it honestly. A complete but short declaration is worth more than a partially filled one.
• General comment: free clarifications that fall into none of the structured fields above.