Sovereignty brief · as of August 2026
What we guarantee, and what we do not.
This document is the first item in our supplier file. Section by section, it states the applicable law, who holds the keys, which flows cross your perimeter, the exit conditions, and the list of things we do not claim.
- Subject
- Sovereignty conditions for Hyperfluid internal-cloud deployments and for the engagements we run
- Scope
- The four deployment targets in §3
- Out of scope
- The security of your own information system, which does not depend on us
- Jurisdiction
- French and European law
- As of
- August 2026
- Citing
- Cite a section by its number: §7 for the NIS2 matrix
- Certifications
- No certification held — see §8
§1 · Definition
What “sovereign” means here
An adjective cannot be verified. Three questions can.
The word “sovereign” means nothing until you say what it makes verifiable. We use it in a narrow, operational sense: a deployment is sovereign when three questions have a written, enforceable answer that can be checked without taking our word for it. (1-perimetre)
- Which law applies to the entity that operates
- Not the building, not the disk: the legal entity that runs the control plane and can be compelled to produce. Of the three questions, this is the only one whose answer cannot be negotiated in a contract.
- Who holds the keys
- Whoever can decrypt without your involvement has access, whatever clause forbids it. A clause gives you a remedy after the fact; a key gives someone a capability right now.
- What crosses the perimeter
- The finite list of outbound flows, their contents, their destination, and whether you can close them without breaking the product. It is published in §4.
Those three criteria are not answered by an adjective, they are answered by a table. §3 publishes that table for the four targets the product deploys into, and every column there has its own address so you can forward exactly one. ▪
§2 · Law
The extraterritorial risk
Where a system is hosted does not decide which law applies. The nationality of the operating entity does.
The CLOUD Act, passed in 2018, allows United States authorities to require a provider subject to US law to produce data it holds, retains or controls, regardless of the country that data sits in. The text is not about where storage is located: it is about who receives the order. §
Section 702 of FISA, for its part, targets electronic communication service providers within US jurisdiction, for foreign intelligence collection concerning non-US persons located outside the United States. The compelled entity is not necessarily in a position to tell its customer. §
The consequence is mechanical and calls for no outrage: a datacentre in France, operated by the European subsidiary of a US-law group, places the provider — and therefore the keys, and therefore the control plane — within the reach of both texts. The Court of Justice struck down the Privacy Shield on exactly this point: the remedies available to the individuals concerned. §
It does not follow that a European provider is beyond the reach of any legal order: French and EU law provide for such orders too. The difference lies in which law applies, which authority issues the order, and what remedies you have. It is a choice of jurisdiction, not a shelter. ▪
§3 · Deployment
The four deployment targets
The amber line is the boundary of the perimeter. In only one of the four figures is that perimeter ours.
The only mode where your data lives with us. Isolated tenant, EU.
One outbound path only: updates, which you open and close.
The contract stays in your name. The provider's law applies.
No connection. Signature verification happens on your side.
| Criterion | Managed tenant | Your datacentre | Your cloud account | Air-gapped |
|---|---|---|---|---|
| Where the platform runs | European platform operated by our teams, isolated tenant | Your datacentre or private cloud | Your own account at a public provider (BYOCloud) | Your sealed enclosure |
| Who holds the infrastructure contract | Us | You | You | You |
| Which law applies | French and European | Yours | Your provider's — choose it knowingly | Yours |
| What leaves your perimeter | Your data lives with us — the only mode where that is true | The updates you open, and close again | What your provider already sees, plus updates | NONE |
| Who holds the keys | Shared | You | You | You |
| Our standing access | Operations | NONE | NONE | NONE |
Every column has its own address: you can forward the exact column to your CISO.
The row that decides is not residency, it is the infrastructure contract. In three of the four targets, the contract, the bill and the quotas for the hardware, the network and the storage stay in your name. We appear nowhere in that chain, so on our side there is nobody to compel in order to reach your data. It is the one row of the six that makes the difference legible, which is why it is there.
We do not run a datacentre. Hyperfluid is software — twenty self-service services in a single console — that you install and your teams consume. The managed tenant is the only target where the infrastructure contract is in our name: that is what you are buying in that mode, and what has to be weighed before choosing it.
Air-gapped mode in detail
What does not change between targets
Why the managed tenant is in this table at all
§4 · Flows
Data residency and data flows
What leaves your perimeter is a finite list, and here it is.
In an internal cloud, residency is not an account setting: the twenty services run where you installed the console, and your data stays in the volumes and buckets of that perimeter. So the useful question is not “where is my data” but “what leaves”. The table below describes the product's default behaviour in the three targets you host: your datacentre, your cloud account, the sealed enclosure. What leaves comes down to a single line — updates, which you open and close again — and air-gapped, even that one disappears. (4-perimetre) ▪
The managed tenant is not in this table, deliberately: your data lives with us there. The question is no longer “what leaves your perimeter” but “what we can see of it”, and §5 handles that. ▪
| Flow | What leaves | Destination | Can you close it |
|---|---|---|---|
| Application updates | Signed artefacts, verified on your side before installation | Our artefact repository, or physical media when air-gapped | Yes — you decide the window, and you close it again |
| Operational logs | NONE | They stay in your own monitoring and are not sent to us | Not applicable |
| Audit trail | NONE | Written to your storage, under your retention policy | Not applicable |
| Product telemetry | NONE | The product emits no usage telemetry | Not applicable |
| Support session | Whatever you open during the session, and nothing else | A named engineer's workstation, at your request | Yes — the session expires and is recorded in your audit trail |
§5 · Access
Encryption, keys and access
Whoever holds the key holds the capability. The rest is contract.
The question a CISO asks is not “do you encrypt”, it is “who can decrypt, and without whom”. The table below answers in two columns, because the answer differs depending on whether you host the platform or we operate it for you. It describes mechanisms, not products: those are named in the deployment contract, because they depend on your estate. (5-perimetre) ▪
| Mechanism | In the three targets you host | In the managed tenant |
|---|---|---|
| In transit | Links between components and to the outside are encrypted. The cipher suites are annexed to the contract: they follow your cryptographic policy, not our catalogue. | Identical. The suites are the platform's, published in the compliance pack. |
| At rest | Encryption is enabled on the volumes and buckets of every service that persists data. The master key is held by you, in your own key manager, named in the contract. | Encrypted, but keys are shared: we hold what is needed to decrypt in order to operate. That is the trade-off of the managed mode. |
| Access control | One IAM for all twenty services, backed by your own directory: fine-grained down to project and object, and down to column and row on the data services. Granting rights remains an act of your organisation. | Identical for your users. Our teams' operations accounts are added on top, named and logged. |
| Audit trail | Every query, access and policy change is logged, timestamped, written to your storage. Retention is whatever you set. | Logged the same way, including our own operations accesses, and the trail is available to you. |
| Standing access | NONE. Our engineers hold no standing account on your environments. Air-gapped, the question does not arise. | Yes, for operations. That is what you are buying in this mode, and what has to be weighed before choosing it. |
| Intervention | Named, opened by you, time-boxed, and it leaves a record in your audit trail — not in ours. | Named and logged, but it does not need to be opened by you: operating the platform is our contractual obligation. |
§6 · Exit
Reversibility
A system you cannot leave is not a choice, it is a dependency.
Reversibility is verified before signature, not at the point of rupture. It is not demonstrated by a return-of-data clause, which only commits to a deadline, but by the interfaces the system has been written in since day one.
An internal cloud does not have one exit, it has twenty. Every service speaks the standard protocol of its category — S3 for object storage, PostgreSQL for databases, Kafka for streams, SQL for queries, OIDC for identity, OCI for containers, Git for source. None of those interfaces was invented by us, and every one of them is implemented elsewhere, by other people, and has been for years.
That changes the nature of the question. Leaving a proprietary system is a programme: everything has to move at once, and it is the cost of that programme, far more than the contract, that keeps you where you are. Leaving an internal cloud is a series of independent moves — you move one service, you measure, you decide on the next. An exit you can start without committing to all of it is the only kind that actually gets used.
The table below gives the protocol of each service family and what it lets you take with you. Tables in particular are written in the Apache Iceberg format in your own object storage, with the query engine decoupled from it: stopping the product does not stop them from being readable. (iceberg)
| Service family | Protocol | What you take with you |
|---|---|---|
| Object storage | S3 | Your objects copy out with any S3 client, to any implementation, without going through us. |
| Relational databases | PostgreSQL | Standard PostgreSQL wire protocol: logical dump, replication into an instance that is not ours, cut-over. |
| Event streams | Kafka | Your producers and consumers repoint to another broker without rewriting a line. |
| Tables and queries | SQL / Iceberg | The engine is decoupled from storage and tables are written in the Apache Iceberg format: another engine reads them where they lie. |
| Identity and entitlements | OIDC | Authentication is delegated to your identity provider. It was never ours, so there is nothing to take back. |
| Containers and registry | OCI | Your images are ordinary OCI artefacts: they push to any registry and run on any Kubernetes. |
| Source and delivery | Git | Your repositories clone, and your deployment manifests are versioned files in those repositories, not settings in our console. |
What does not survive belongs in the same place: the console, the self-service experience, the entitlement policies entered there and the unified monitoring are specific to the product. You get your data and your workloads back through their own protocol; you do not get back the console that served them, and you will have to replace it. ▪
The European Data Act has imposed switching obligations on data processing services since 2025. We draw no marketing argument from it: we simply note that the architecture already answered it. §
§7 · NIS2
NIS2 — shared responsibility matrix
Built to tool the technical requirements of NIS2 — shared responsibility matrix published.
This matrix is not a compliance framework and replaces none. Requirement by requirement, it states what the platform tools and what remains your responsibility. The right-hand column is the important one: it is the column no supplier ever fills in on its customer's behalf.
Compliance belongs to the essential or important entity. It is organisational as much as technical, and it engages your management's liability, not ours. § ▪
Shared responsibility matrix — eight requirements from art. 21
| Requirement | What the platform tools | What remains your responsibility |
|---|---|---|
| art. 21(2)(a) Risk analysis and information system security policies | Map of effective accesses and rights, exportable audit trail, published outbound flow matrix (§4) | The analysis method, its scope, its frequency and its sign-off by management |
| art. 21(2)(b) Incident handling | Timestamped logging of accesses and policy changes, contractual escalation procedure with written response times | Detection across your estate, incident qualification, and notification to the competent authority within the art. 23 deadlines |
| art. 21(2)(c) Business continuity, backup management and recovery | Every service exposed through a standard protocol, so backup and restore use that protocol's own tooling (§6), documented and repeatable reinstall procedure for the console and the services | The continuity plan, recovery objectives, running the backups, and evidence that restores were tested |
| art. 21(2)(d) Supply chain security | Signed artefacts, signature verification performed on your side, dependency inventory and CVE bulletin | Assessing your other suppliers, and assessing us — we answer your assessment in writing, we do not run it |
| art. 21(2)(e) Development security and vulnerability handling | CVE monitoring on delivered components, fixes published per version, coordinated disclosure channel | Your patching policy, its deadlines, and its execution across your estate |
| art. 21(2)(h) Policies and procedures on cryptography and encryption | Encryption in transit and at rest, keys held by you, cipher suites annexed to the contract (§5) | The organisation's cryptographic policy and the key lifecycle: generation, rotation, escrow, destruction |
| art. 21(2)(i) Access control and asset management | One IAM across all twenty services, backed by your directory, per-project resource inventory, no standing access on our side, every elevation recorded | Granting entitlements, reviewing them periodically, and handling leavers |
| art. 21(2)(j) Multi-factor authentication and secured communications | Authentication delegated to your identity provider, which carries the second factor; no local operational passwords | Actually deploying the second factor, its coverage, and any exceptions you grant |
§8 · Certifications
What we do not hold, and what we do instead
We hold none of these three certifications. Here is what a CISO can write instead.
A supplier exception note is written in two columns: what the supplier does not have, and what is put in front of it. We publish both, so the note can be copied rather than investigated. None of the controls in the right-hand column is presented as an equivalent of the certification facing it. (8-perimetre) ▪
| What we do not hold | The compensating control we apply anyway |
|---|---|
| SecNumCloud NOT HELD What the certification attests — ANSSI qualification of a cloud service, including criteria on the provider's own immunity from non-European law. | APPLIED We are not qualified and we present no equivalent. What we offer instead is structural: in your datacentre, in your cloud account or air-gapped, the hosting question disappears, because the infrastructure contract is in your name. In the managed tenant, the applicable law, the identity of the infrastructure operator and who holds the keys are written into the contract and verifiable in §3. |
| HDS NOT HELD What the certification attests — Certification for hosting personal health data, required of the host within the meaning of art. L. 1111-8 of the French public health code. | APPLIED We do not host personal health data and we make no undertaking to do so. Where the use case involves it, deployment happens on premises or at a certified host that you choose and contract with: the obligation then stays where it already sits in your organisation. We supply the software, not the hosting. |
| ISO/IEC 27001 NOT HELD What the certification attests — Certification by an accredited body of an information security management system, with periodic surveillance audits. | APPLIED We hold none. We answer your supplier security questionnaire in full and in writing, we accept a contractual audit clause exercisable by you or by a third party you appoint, and we document per deployment the access matrix, the patch management procedure and the escalation path. These are contractual undertakings, enforceable in court; they are not a certification. |
§9 · Limits
What we do not claim
The list of what this document does not guarantee, written in the same place as everything else.
What follows calls for no softening and no counterweight. An objection a buyer discovers after signature costs more than the same objection read before it.
- We hold neither SecNumCloud, nor HDS, nor ISO 27001, nor SOC 2. No certification process is under way at this date.
- We make no one compliant with NIS2, the GDPR or DORA. Compliance belongs to the entity, never to its supplier.
- We do not make your data immune to the CLOUD Act. No contract can. Only the jurisdiction of the operating entity changes the answer, and §3 states which one applies in each target.
- In the three targets you host, we do not hold your keys: we therefore cannot restore your data if you lose them, and that loss cannot be undone from our side.
- The managed tenant is not a sovereign deployment in the sense of §1: your data lives with us, keys are shared there, and our teams hold standing operations access. We sell it, we do not disguise it.
- We publish no service levels on this site. Availability, response times and penalties are negotiated per deployment and exist only once signed.
- We do not guarantee portability of the console itself: the self-service experience, the entitlement policies entered there and the unified monitoring are specific to the product. Your data and your workloads leave through their own protocol; the console that served them does not.
- We are not answerable for outbound flows created by a connector you configure towards a third-party service.
Get in touch
What you can ask for now
A brief is read, then discussed with someone who wrote it.
The compliance pack restates this document, with the per-deployment flow matrix, our standing answers to supplier security questionnaires, and the administrative documents for a public tender. It is sent by an engineer, not by an autoresponder.