Data protection
Where your data is processed, who can reach it, which sub-processors are involved, and how long it is kept.
Where your data is processed, who can reach it, and what briq does and does not do with it. Every statement here is specific enough to check against the security model and the data processing agreement.
What you get
| Guarantee | Where it comes from |
|---|---|
| Briqs, volumes and logs are processed in the team's region; Paris by default | The region is a team setting; EU regions keep the data in the EU |
| One Firecracker microVM per briq, one private network per team | Security model |
| Secrets are write-only, masked in status, logs and audit | Security model |
| A processing agreement you can rely on without signing anything | DPA |
| 30 days' notice before a sub-processor changes | DPA, Annex III |
briq holds no GDPR certification. Nor, in the general sense, does anyone: the GDPR is a regulation rather than a standard you pass, and the schemes Article 42 provides for certify one named processing operation through an accredited body, not a company as a whole. What you can rely on instead is specific and checkable: this page, the DPA, and the security model.
Where your data is
| Thing | Where | Retention |
|---|---|---|
| Briqs (the microVM, its memory and rootfs) | The team's region (paris by default) | Destroyed with the briq |
| Volumes | Same region as the briq | Destroyed with the volume |
Logs readable through briq_logs | Same region as the briq | While the briq exists, not after destroy |
| briq's own database (accounts, teams, keys, audit) | Paris, cdg | See personal data |
| briq's API and web app | Paris, cdg | — |
A team chooses its region: Paris by default, Frankfurt, London, two US sites, Montréal, Singapore,
Tokyo or Sydney. Briqs, their volumes and their logs are processed in the region of their team at
the time they were created, and nowhere else. The paris and frankfurt regions keep that data
inside the EU; the others do not, and the dashboard says so next to the setting. briq's own
database, API and web app run in Paris whichever region a team picks. See regions.
Jurisdiction
Residency and jurisdiction are two different questions, and briq answers them differently.
briq runs on infrastructure operated by a third-party provider. That provider runs the Paris region we use, participates in the EU-U.S. Data Privacy Framework, and has a data processing agreement in place with us. Its corporate parent is incorporated in the United States.
That means:
- Your data at rest is in Paris. This is true and verifiable.
- The provider is subject to US jurisdiction. A US legal instrument such as a CLOUD Act order can in principle be served on a US-incorporated provider regardless of which region holds the bytes. Choosing an EU region reduces exposure; it does not place data beyond the reach of US process.
If your threat model requires an EU-incorporated provider, briq v0 does not meet it today. Two mitigations are on the roadmap and neither is shipped: a second adapter on an EU-incorporated provider, and briq's own Firecracker fleet in French data centres. The architecture is built around a provider adapter, so that this is a migration rather than a rewrite.
Roles
briq sits on both sides of the GDPR's controller/processor split, and the split matters for who owes whom what.
| Data | briq is | You are |
|---|---|---|
| Your account: name, email, sessions, team, billing | Controller | The data subject |
| Whatever your agent puts inside a briq | Processor | Controller |
briq does not read what is inside your briqs, index it, or use it to train anything. But if your agent writes personal data into a Postgres briq, you are the controller for it, you decide the lawful basis, and you need a processing agreement from us. That agreement is the DPA, and it needs no signature.
What personal data briq processes
From the actual schema, not from a template:
| Field | Purpose | Source |
|---|---|---|
| Name, email | Identify the account, send service email | You, at sign-up |
| Password hash | Authenticate you | You, at sign-up |
| Session token, IP address, user agent | Keep you signed in, spot session abuse | Your browser |
| Team name, slug, membership role | Tenancy and access control | You |
| API key name, prefix, SHA-256 hash | Authenticate agents; the key itself is never stored | Generated |
| Audit rows: key id, action, target, duration, cost delta | Show you what your agent did, bill correctly | Your API calls |
Not processed: the contents of your images, the values of env vars marked { secret }, stdout
and stderr beyond the response handed back to you, or anything in a volume after it is
destroyed. The security page has the full stored/not-stored table.
GitHub OAuth and magic-link email are not enabled yet; when they are, this table gains the OAuth tokens and the email provider joins the sub-processor list below.
Sub-processors
| Sub-processor | Role | Where | Status |
|---|---|---|---|
| Infrastructure provider | Compute, volumes, logs, and hosting for briq itself | The team's region (Paris by default); corporate parent US-incorporated | In use |
| Stripe | Payments | EU + US | Planned, not wired |
| Sentry | Error tracking | EU region available | Planned, not wired |
| Email provider | Magic links, service email | To be chosen, EU preferred | Planned, not wired |
Today the list is one entry long. That is a property of being early, and it is the easiest it will ever be to audit. We will publish changes to this list before they take effect.
What is in place, and what is not
As of 21 September 2026:
| Artifact | Status |
|---|---|
| Privacy notice (Arts. 13-14) | Published |
| Data processing agreement (Art. 28(3)) | Published, incorporated into the terms, no signature needed |
| Terms of service | Published |
| Record of processing (Art. 30) | Written, internal |
| Data subject request procedure (Arts. 15-22) | Written; executed by hand, not automated |
| Breach procedure (Arts. 33-34), 72 h | Written |
| Sub-processor list with 30 days' notice | Published in the DPA, Annex III |
Still open:
- Automated retention and erasure. The periods above are policy; the jobs that enforce them are not written, so deletion at the end of a period is done by hand on request.
- A countersigned DPA with our infrastructure provider. They publish a pre-signed one; executing and filing it is an administrative step we have not completed.
- Legal review. These documents were drafted from how the system actually works, which makes them accurate, not authoritative. They are reviewed by a lawyer before launch.
- An Article 42 certification. Not planned, and as explained above, not a thing you can hold in general anyway.
Your rights and how to reach us
If you have an account, you can ask for access, correction, export, deletion or restriction of your personal data, and you can object to processing. Email privacy@briq.cloud. We aim to answer well inside the one-month window in Article 12(3).
Security reports go to security@briq.cloud instead; see responsible disclosure.
You also have the right to lodge a complaint with a supervisory authority. For a French establishment that is the CNIL.
This page is a factual description of how briq is built and operated. It is not legal advice, and it is not a contract. Before relying on it for a procurement decision, read it alongside the agreement you sign with us.