LakehouseBox — Data Processing Agreement (Art. 28 GDPR)

Version: 30 October 2026
Effective: 16 October 2026
Processor: Lakehousebox, S.L., calle Bárbara de Braganza, 2, 2ª planta, 28004 Madrid, Spain, NIF B05742093
Controller: the Customer identified by the account that accepted the Terms of Service

1. Scope and roles

1.1 This Agreement applies whenever the Customer stores personal data in the Service (in Iceberg tables, in the blob bucket that accompanies a catalog, or in table metadata). For that data, the Customer is the controller (or a processor acting for its own controller) and LakehouseBox is the processor.

1.2 It does not apply to the account data LakehouseBox processes as controller (email addresses of account holders, organisation membership, API key records, logs). That is covered by the Privacy Policy.

1.3 It forms part of the Terms of Service and is accepted with them. In case of conflict about personal data, this Agreement prevails. "GDPR" means Regulation (EU) 2016/679; Spanish Organic Law 3/2018 (LOPDGDD) applies where relevant.

2. Details of the processing

The subject-matter, duration, nature and purpose of the processing, the types of personal data and the categories of data subjects are set out in Annex I.

3. LakehouseBox's obligations as processor

LakehouseBox will:

a. Instructions. Process personal data only on the Customer's documented instructions, including on transfers to a third country, unless EU or Spanish law requires otherwise, in which case LakehouseBox informs the Customer before processing unless the law forbids it. The Customer's instructions are: the Terms of Service, this Agreement, and the API calls and storage operations the Customer makes with its credentials. LakehouseBox tells the Customer if it believes an instruction infringes data protection law.

b. Confidentiality. Ensure that the people it authorises to process personal data are bound by confidentiality. Today this is the founder(s) of Lakehousebox, S.L.; there are no other staff. Access to Customer content is never needed to operate the Service and is not made in the ordinary course.

c. Security. Implement the technical and organisational measures in Annex II, which reflect the state of the art, the cost of implementation and the risk of the processing, as Art. 32 requires. Annex II also names the measures that are not yet in place, so the Customer can make its own risk assessment honestly.

d. Sub-processors. Engage only the sub-processors listed in Annex III, under a written contract imposing the same data-protection obligations as this Agreement. The Customer gives a general authorisation for them. LakehouseBox gives the Customer 30 days' notice by email before adding or replacing a sub-processor; the Customer may object on reasonable data-protection grounds within that period, and if the objection cannot be resolved, either party may terminate the affected Service with the Customer entitled to export its data first. LakehouseBox remains fully liable to the Customer for its sub-processors.

e. Data-subject rights. Assist the Customer, by appropriate technical and organisational measures and as far as possible, in answering requests from data subjects (access, rectification, erasure, restriction, portability, objection). Because LakehouseBox never reads Customer content and the Customer holds full read, write and delete access to its own tables and files through standard Iceberg and S3 tooling, the Customer can satisfy most requests itself. LakehouseBox forwards any request it receives directly to the Customer without answering it, unless the Customer instructs otherwise.

f. Assistance with Arts. 32–36. Assist the Customer with security, breach notification, data protection impact assessments and prior consultation, taking into account the nature of the processing and the information available to LakehouseBox. Personal data breach: LakehouseBox notifies the Customer without undue delay, and in any case within 48 hours of becoming aware of a breach affecting Customer content, with the information Art. 33(3) requires as far as it is known, supplemented as it becomes known.

g. Deletion or return. At the end of the Service, at the Customer's choice, delete or return all Customer content and delete existing copies, unless EU or Spanish law requires storage. Return is self-service: the Customer exports its data in open formats (Iceberg, Parquet, ORC, Avro, plain objects) with its own credentials at any time before deletion. Deletion is complete within 30 days of the request or of termination; copies in backups expire within a further 14 days (backup retention, Annex II).

h. Audit. Make available to the Customer all information necessary to demonstrate compliance with Art. 28, and allow for and contribute to audits, including inspections, conducted by the Customer or an auditor it mandates. Procedure: the Customer first relies on the documentation LakehouseBox publishes (the Security overview, this Annex II, the deployment record in the repository on request); if that is insufficient, an on-site or remote audit may take place once a year on 30 days' notice, during business hours, without access to other customers' data, at the Customer's cost unless it reveals a material breach. LakehouseBox holds no third-party certification (ISO 27001, SOC 2) today and does not claim one.

4. The Customer's obligations as controller

The Customer: (a) has a lawful basis for the personal data it stores and for instructing LakehouseBox; (b) gives the information required by Arts. 13/14 to its data subjects; (c) does not store special-category data (Art. 9) or data about criminal convictions (Art. 10) without having assessed that the measures in Annex II are adequate for it and, where needed, agreeing additional measures with LakehouseBox in writing; (d) keeps its credentials secret and uses the scoped, short-lived credentials the Service provides rather than sharing long-lived API keys; (e) is responsible for the personal data it puts in table names, namespace names, schemas and file paths, which are not encrypted differently from data and appear in metadata and logs.

5. Transfers outside the EU/EEA

5.1 None, except on the Customer's own instruction. Customer content is stored and processed in the European Union: in Frankfurt, Germany, with a second copy of the stored data in Stockholm, Sweden kept by the storage's replication (Annex I, Annex III). Two settings that the Customer controls are the Customer's documented instruction (Article 28(3)(a) GDPR) for copies of Customer content to be cached by BunnyWay d.o.o. (bunny.net, Slovenia; Annex III) on edge locations worldwide, outside the EU/EEA too: (a) making a catalog public: copies of its files are cached on edge locations worldwide, so that anyone can download them; (b) turning on edge caching for a private catalog: copies of the files its authorised readers read through the edge (its table files, and the files of its files folder read with the command-line tool or in its DuckDB sessions) are cached on the edge locations that serve those readers, worldwide, until the end of the day (UTC) at most. Turning either setting off withdraws the instruction, and the copies are removed from the edge by a purge (Annex III says how soon). LakehouseBox does not otherwise transfer Customer content to any third country and does not use any sub-processor established in, or controlled from, a third country for Customer content.

5.2 The one non-EU/EEA sub-processor, Infomaniak Network SA (Switzerland), hosts LakehouseBox's own company mailboxes and never receives Customer content. Should a Customer send personal data to a LakehouseBox mailbox (for example in a support request), that data is processed in Switzerland, which is covered by the European Commission's adequacy decision for Switzerland (Decision 2000/518/EC, confirmed by the Commission's report of 15 January 2024). No Standard Contractual Clauses are therefore required.

5.3 If LakehouseBox ever proposes a sub-processor outside the EU/EEA and outside an adequacy decision, it will do so only through the sub-processor notice in clause 3(d), with the 2021/914 Standard Contractual Clauses (Module 3, processor to processor) and a transfer impact assessment, and the Customer may object. LakehouseBox's product rule is that no US-controlled entity operates its infrastructure or holds Customer content (see the Security overview); this Agreement will be amended, with notice, before that rule changes.

6. Liability and term

6.1 Liability between the parties under this Agreement follows the Terms of Service, clause 11, subject to Art. 82 GDPR, which is not limited by anything here.

6.2 This Agreement lasts as long as LakehouseBox holds Customer content, including the deletion period in clause 3(g).

7. Governing law and courts

Spanish law; courts of Madrid, Spain, as in the Terms of Service. The supervisory authority is the Agencia Española de Protección de Datos (AEPD).

Annex I — Description of the processing

Annex II — Technical and organisational measures

Every measure below is implemented in the deployment described in platform/deploy/README.md and audited in platform/docs/security.md on 2026-09-19. Measures that are planned but not in place are listed separately at the end, on purpose.

II.1 Confidentiality and access control

1. Tenant isolation at the catalog. Each catalog is its own table bucket, its own IAM identity and its own catalog namespace inside the storage system. A bucket policy naming that identity is the only grant; a credential for one catalog is refused by the catalog service and by the object store for any other catalog. Isolation is tested with positive and negative controls in the automated test suites (platform/scripts/test.sh, Phase 1 "isolation" checks) on every deployment.
2. Short-lived, scoped storage credentials. Engines reading or writing a table receive credentials vended by the catalog for that table (or catalog) only, valid 60 minutes, signed with a key the operator can rotate to revoke every outstanding session at once (measured: 11 s).
3. API authentication. Callers hold an API key with a 256-bit random secret; the Service stores only its SHA-256 hash and compares in constant time. Tokens for the API are RS256 JWTs valid 15 minutes. Failed attempts are rate-limited per key and per network address; a correct key is never locked out.
4. Human sign-in. Email one-time code (6 digits, hashed, 10-minute validity, 5 attempts) for signup and key recovery; an email + password login served by the control plane itself at lakehousebox.com/app/ (passwords stored only as argon2 hashes; set-password and reset links single-use and hashed), with an optional TOTP second factor (secret encrypted at rest, single-use backup codes stored as keyed hashes) and optional passkeys (WebAuthn with user verification; only the public key is stored); a device-approval flow for the command-line tool. No third-party identity provider.
5. Administrative access. SSH to the host is key-only (PasswordAuthentication no), from a single allow-listed IP address, enforced by the cloud firewall; root login by key only. No web administration panel for the storage system is exposed. Internal control-plane endpoints (/internal/*) are not reachable from the internet (verified with path-normalisation variants).
6. Network exposure. Only ports 80 and 443 are open to the internet (plus 22 to one address). Every storage, catalog, IAM and administration port is bound to the container network or loopback. Verified by port sweep.
7. Least privilege in the control plane. The control plane holds the storage administrator key pair read-only from the data volume, to create tenants; tenant operations use the tenant's own identity, never the administrator's.
8. Staff. The only people with access are the founder(s), bound by confidentiality; no third party has administrative access. Sub-processors have physical/infrastructure access only (Annex III).

II.2 Integrity and transport security

9. TLS everywhere. All public hostnames (api., catalog., s3., mcp.lakehousebox.com) serve TLS 1.2 and 1.3 only, with Let's Encrypt certificates renewed automatically; HTTP redirects to HTTPS; HSTS (1 year, includeSubDomains), X-Content-Type-Options: nosniff, Referrer-Policy: no-referrer; server version strings are stripped. Signed S3 requests (SigV4) provide request integrity end to end.
10. Request limits. JSON API bodies capped at 1 MB at the gateway; signup and recovery limited to 5 per hour per address.
11. Secrets never in transit to us in clear beyond TLS, never logged. API key secrets, one-time codes and storage secrets do not appear in logs; only key identifiers do. Deployment scripts print hashes, not secrets.

II.3 Availability, backup and recovery

12. Daily backups, at least, of the complete state (storage volumes, storage metadata, catalog configuration, keys, control-plane database): a recovery point of at most 24 hours.

    Since 28 October 2026 the stored data files (tables and files) are kept in storage in Frankfurt, Germany, which keeps a full second copy in Stockholm, Sweden (replication); that copy is not a backup: a deletion or an overwrite reaches both. Every 5 minutes, once every write has reached the storage, the state needed to rebuild the Service (the control-plane database, the storage metadata and catalog configuration, and keys) is backed up, encrypted, to separate storage replicated the same way, and read back after upload; the newest 144 copies (about 12 hours) are kept. Protection against a mistaken deletion or overwrite of a table is its recent versions (time travel). The backups made before 28 October 2026 are deleted.

13. Restore rehearsed, not assumed: a backup of one host was restored onto a freshly provisioned second host on 2026-09-19 and a customer's existing API key worked against the restored copy (platform/STATE.md, Phase 5). The procedure is scripted (deploy/restore.sh) and re-runnable.

14. Operating-system security updates installed automatically (unattended-upgrades).

II.4 Key management and rotation

15. Every long-lived key has a rehearsed rotation procedure with measured revocation: the storage administrator key pair (old pair refused everywhere within 17 s), the credential-vending signing key (every vended session revoked in 11 s), and each catalog's key pair (self-service POST /v1/warehouses/{id}/rotate: old key refused immediately; sessions already vended expire within 60 minutes). Details in platform/deploy/README.md, "Rotation procedures".
16. File permissions. Backup archives 0600 in a 0700 directory; key files 0600; certificate store 0700.

II.5 Organisational

17. Documented security audit with findings, severities and status (platform/docs/security.md), re-run after each deployment.
18. Change control. All infrastructure and code is versioned; deployments are scripted and reproducible from the repository; a secret scanner runs before publication.
19. Dependency monitoring. Published advisories for every component (storage system, gateway, Python libraries) were reviewed against deployed versions on 2026-09-19 and the upgrades scheduled.
20. Data minimisation by design. The website sets no cookies; its request log holds visitors' IP addresses only shortened at the edge before they are written (IPv4 /24, IPv6 /64) and is kept 30 days; rate-limit state is held in memory and in the database for about an hour; the Service never reads customer content.

II.6 Not yet in place (disclosed)

• High availability. There is no standby: the storage system, the catalog, the API and the control plane run as one container in Frankfurt, Germany (since 28 October 2026). A container that stops is started again; one that loses its disk is rebuilt from the latest backup (measure 12) and the storage, which was rehearsed before the move. Planned (platform/PLAN.md §8).

• Encryption at rest of tenant secrets with a separate key. Tenant storage key pairs are stored in plaintext in the control plane's database; its backups are encrypted before they leave our servers (platform/docs/recovery.md §2c). Envelope encryption with a separate key is designed (docs/security.md, "Tenant keys at rest") but not implemented.

• Encryption at rest of customer content in the storage. Since 28 October 2026 the stored data files are kept in storage as they were written, reached only with that storage's own access keys; we do not add our own encryption to that copy. (Our store's own encryption, since 2026-09-22, applies to the local disk of the server that runs it.)

• Encryption of backup indexes. The backups are encrypted before they leave our servers, except the index of each backup, which names its files (Annex III).

• Container hardening of the storage system. Our own services run with every capability dropped, no privilege escalation and a read-only root filesystem; the storage system still runs with the container runtime's default capabilities. Container logs are bounded in size.

• Third-party certification. None (no ISO 27001, no SOC 2).

• Individual revocation of a vended storage credential. Only wholesale rotation (measure 15) exists; the 60-minute lifetime is the bound.

Annex III — Sub-processors

General authorisation under clause 3(d). Complete list as of the version date.

No sub-processor in the United States. No US-controlled entity processes Customer content or account data. The open-source software LakehouseBox runs (Apache Iceberg, the object store, Caddy, DuckDB, PyIceberg) is operated by LakehouseBox itself on the infrastructure above; its authors are not processors.

Change log

• 2026-09-19-draft — first draft. Annex II drawn from platform/docs/security.md, platform/deploy/README.md and platform/STATE.md Phase 5; the "not yet in place" list is the residual-risk section of the audit restated for customers. Not published.
• 2026-09-21 (factual corrections, still draft) — Rauthy retired 2026-09-20 and removed from Annex II measure 4, measure 19 and the Annex III software list; the control plane's own login takes its place. Public hostnames are api., catalog., s3., mcp.lakehousebox.com. "warehouse" → "catalog" in prose (API paths unchanged). notes at the backup measure and on Let's Encrypt.
• 2026-09-23-draft (factual corrections) — the website's request log is kept (anonymised at the edge, 30 days, bunny.net storage in Germany; infrastructure/tofu/bunny/web_logs.tf, platform/deploy/obs/bunny_logs.py): measure 20 and the bunny.net row of Annex III no longer say "no access log" / "logging off". The website itself is served from bunny.net storage since the same day.
• 2026-09-24 (factual correction, still draft) — Annex II measure 4 names the optional TOTP second factor (live since 2026-09-23): secret encrypted at rest, backup codes stored as keyed hashes.
• 2026-09-25 (factual correction, still draft) — Annex II measure 4 names the optional passkeys (WebAuthn, user verification required, only the public key stored), live with this change.
• 2026-09-30-draft — the processor is named: LakehouseBox SL, C. de la Basílica, 19, 28020 Madrid (still in formation, CIF pending). No change to the sub-processors: the newsletter sender handles account holders' addresses under the privacy policy, never customer content.
• 2026-10-01-draft — company name and registered office: Lakehousebox, S.L., calle Bárbara de Braganza, 2, 2ª planta, 28004 Madrid (still in formation, CIF pending).
• 2026-10-02 (presentation only; the version above is unchanged) — notes for the lawyer and placeholders no longer appear on the published page, which carries a banner saying the document is a draft and the company is in formation. Where a placeholder stood, the page shows what is known: the CIF is "to be published on incorporation", the effective date reads "not yet in force", the breach-notification time is marked "(proposed)", and the courts are those of Madrid, as assumed throughout the drafts. No term changed.
• 2026-10-02 (factual corrections, still draft) — the review note at Annex II measure 12 records the backups as they run since 2026-09-24 (platform/docs/recovery.md §1: hourly store metadata and data files, a weekly full archive) instead of "data nightly"; the measure's own text is unchanged and is for the founder and the lawyer.
• 2026-10-02-draft, founder decisions — the 48-hour breach notification (clause 3(f)) and the courts of Madrid (clause 7) are confirmed; Customer content is processed exclusively in the European Union, in Germany with a second copy of the backups in Finland (clause 5.1, Annex I, Annex III); Annex II measure 12 keeps the commitment to daily backups (recovery point at most 24 hours), says we currently copy hourly, states the 14-day retention and drops the superseded 03:17 UTC / 7 on-host / 14 off-host detail; II.6 and Annex I say the same.
• 2026-10-02b-draft (factual correction, still draft) — Annex II measure 20: rate-limit state is held in memory and in the database for about an hour (it said "in memory for at most one hour"; platform/docs/audit-and-quota.md, auth_rate).
• 2026-10-09-draft — a third, locked copy of the recent backups at Scaleway in Paris, France (security review 2026-10-08, H2): clause 5.1 and Annex I name France; Annex II measure 12 says what the copy holds (the last 2 days), that it is written with a credential that cannot delete and locked for 6 days, and that it is removed within 14 days of each backup's time; Annex III gives Scaleway its second service and the data concerned. The 14-day backup retention of clause 3(g) is unchanged (platform/deploy/backup_vault.py, platform/docs/recovery.md §2d).
• 2026-10-11-draft — the off-site copies are in France only (founder, 2026-10-11: "One copy outside Hetzner is enough"): the second copy of the backups in Helsinki, Finland, is no longer made, and the copy of the cold storage tier (data not written for 7 days) moved from Helsinki to Paris the same day. Clause 5.1, Annex I and Annex III name Germany and France only (Hetzner's row loses Finland, Scaleway's gains the cold-tier copy); Annex II measure 12 describes two copies of the backups, not three. The 14-day backup retention is unchanged (platform/docs/recovery.md §1, §2d).
• 2026-10-13-draft (factual corrections) — Annex II.6 brought in line with measures 2 and 12 and Annex III, which it contradicted since 2026-09-22: customer content is encrypted at rest since that day (older content until maintenance rewrites it) and the backups are encrypted before they leave our servers (their indexes are not); the control plane's database is PostgreSQL on its own host since 2026-10-07, not a file; a failed host is recreated automatically; our own containers are hardened, the storage system's not yet; vended storage sessions live 60 minutes, not 15 (measure 15 and II.6). No term changed.
• 2026-10-14-draft — clause 5.1, Annex I and Annex III: bunny.net is also the content delivery network for the files of catalogs the Customer chooses to publish openly, served from edge locations worldwide (outside the EU/EEA too) on the Customer's instruction to publish; no request log of those downloads is kept; copies are removed when the catalog is made private or deleted (a purge, which can take a few hours), while a file removed from a catalog that stays public can stay cached for up to a year (PLAN 24.3, infrastructure/tofu/bunny/public_data.tf). Content the Customer has not published never passes through it. (Corrected 2026-10-14, measured: the edge purge after a catalog is made private or deleted is sent by a scheduled job that ran hours apart, so it can take a few hours, not minutes.) (Corrected again 2026-10-14, measured after PLAN 24.6: the purge is now sent within about a minute of falling due, from a runner nothing else uses; three unpublished catalogs were gone from the edge after 42, 84 and 136 s, so "usually within a few minutes", not "a few hours".)
• 2026-10-14b-draft — the company is incorporated (public deed of 2026-10-09): Lakehousebox, S.L., NIF B05742093 (provisional NIF), registered office unchanged; "in formation" removed.
• 2026-10-16 — in force from 16 October 2026 (founder, 2026-10-16); the draft label is removed from the published page. No term changes.
• 2026-10-19 — Annex III, bunny.net's row: the files of a folder the Customer publishes next to a public catalog's tables are cached for at most an hour when changed or removed, and purged when the folder stops being published (PLAN 29, infrastructure/tofu/bunny/public_files.tf). No term changes.
• 2026-10-19b — Annex III, bunny.net's row: a file of a published folder that is changed or removed in place is purged from the edge as well (PLAN 29 step 3; measured 37 to 72 s), usually within two minutes; the edge keeps such copies for at most seven days if that purge cannot run (it was an hour). No term changes.
• 2026-10-25 — Annex I and Annex III, bunny.net's row: on the Customer's own instruction, a per-catalog setting ("edge caching for private catalogs", off by default), bunny.net also caches the table files of that private catalog read by its authorised readers, on EU edge locations only (no transfer outside the EU/EEA: clause 5.1 unchanged), until the end of the day (UTC) at most, purged when the setting is turned off, the catalog deleted or a person's access removed (infrastructure/tofu/bunny/edge_reads.tf, platform/docs/edge-reads.md). bunny.net is already a listed sub-processor: no sub-processor is added or replaced (clause 3(d)). No term changes.
• 2026-10-25b — Annex I and Annex III, bunny.net's row: a private catalog's edge caching also covers the files of its files folder (photos, documents) read by its authorised readers, downloaded with the command-line tool, cached on EU edge locations only until the end of the day (UTC) at most and purged with the catalog's table files (infrastructure/tofu/bunny/edge_reads_lib.js, platform/docs/edge-reads.md). No sub-processor is added or replaced; no term changes.
• 2026-10-26 — Annex III, bunny.net's row: a file of a published folder that is changed or removed in place is now removed from the edge usually within a few seconds (research/100: the purge is sent to bunny.net the moment the storage reports the change, and repeated a few seconds later; measured 0.4 to 1.4 s on production), not two minutes; the seven-day bound if that removal cannot run is unchanged. No sub-processor is added or replaced; no term changes.
• 2026-10-26b — Annex III, bunny.net's row: a private catalog's files-folder files with edge caching turned on are read through the edge by all its authorised readers' supported tools (the command-line tool's downloads and its DuckDB sessions), and a file changed or removed in place is removed from the edge usually within a few seconds (research/100; platform/docs/edge-reads.md). Still EU edge locations only, until the end of the day (UTC) at most. No sub-processor is added or replaced; no term changes.
• 2026-10-26c — Clause 5.1, Annex I and Annex III, bunny.net's row: turning on edge caching for a private catalog is now, like making a catalog public, the Customer's documented instruction (Article 28(3)(a) GDPR) for copies of the files its authorised readers read to be cached on edge locations worldwide, outside the EU/EEA too (clause 5.1(b); the founder's decision, 2026-10-26; infrastructure/tofu/bunny/edge_reads.tf). Correction: the earlier "EU edge locations only" was bunny.net's European routing zone, whose 35 locations include eight outside the EU/EEA (London, Zurich, Belgrade, Tirana, Novi Travnik, Chisinau, Kyiv, Moscow; bunny.net's region list, read 2026-10-26); bunny.net's traffic statistics for that zone showed only Frankfurt, Madrid and Milan serving it. No sub-processor is added or replaced (clause 3(d)); the transfer mechanism bunny.net uses for its locations outside the EU/EEA has been asked of bunny.net (legal/DECISIONS-FOR-THE-FOUNDER.md). No other term changes.
• 2026-10-28 — the move to bunny.net (research/106; research/results/t106_swap.txt: writes paused 04:47 UTC, the service names on bunny.net from 07:07 UTC): clause 5.1, Annex I (processing location), Annex II (measure 12, the "not yet in place" list) and Annex III (Hetzner, Scaleway and bunny.net's rows). The Service now runs on bunny.net in Germany, its storage replicated to Stockholm, Sweden (infrastructure/tofu/bunny-cells/cell/main.tf, variables.tf: region DE, replication SE; platform/cell/migrate/PROD-CELL.md); the backups are metadata-only, every 5 minutes, the newest 144 kept (platform/cell/migrate/prod_cell_env.py, platform/deploy/backup_meta.py); no new copy to Scaleway (prod_cell_env.py: the Paris vault and the cold tier dropped). Hetzner keeps the services that have not moved yet (platform/cell/migrate/PROD-CELL.md, research/104 §7) and the read-only copy kept as the way back (platform/cell/migrate/SWITCH.md step 9). Scaleway's row names the language models hosted agents use (platform/docs/user/hosted-agents.md), a role it already had and this list left out. The 30-day notice of clause 3(d) and the commitments of measure 12 and clause 3(g) are flagged for the founder, not changed.
• 2026-10-30 (factual correction) — clause 5.1, Annex I (processing location), Annex II (measure 12, the "not yet in place" list) and Annex III: the hosting used before the move of 28 October 2026 is deleted (the founder, 2026-10-30: the Hetzner project is deleted, with every server, volume, object-storage bucket and backup in it, and the Paris copies made before the move are gone; production runs in Frankfurt, Germany, its data replicated to Stockholm, Sweden: research/106, platform/cell/). Hetzner Online GmbH is removed from Annex III (a sub-processor removed, none added: no notice under clause 3(d)); Scaleway's row loses the backup and cold-tier copies; bunny.net's row (kept: Annex III must name every sub-processor) adds the containers of the query service, scheduled SQL, hosted agents and the file drop box, in Germany. Narrative clauses give the location instead of the provider. No term changes; the measure-12 and clause-3(g) commitments flagged on 2026-10-28 remain the founder's call.