Tablemere — Data Processing Agreement (Art. 28 GDPR)

Version: 2026-09-19-draft
Effective: [effective date]
Processor: Tablemere SL (in formation), [registered address], Spain, CIF [CIF/NIF] Controller: the Customer identified by the account that accepted the Terms of Service

DRAFT for lawyer review. Not yet in force. See legal/README.md.

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 warehouse, or in table metadata). For that data, the Customer is the controller (or a processor acting for its own controller) and Tablemere is the processor.

1.2 It does not apply to the account data Tablemere 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. Tablemere's obligations as processor

Tablemere 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 Tablemere 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. Tablemere 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 Tablemere SL; 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. Tablemere 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. Tablemere 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 Tablemere 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. Tablemere 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 Tablemere. Personal data breach: Tablemere notifies the Customer without undue delay, and in any case within 48 hours of becoming aware of a breach affecting Customer content [founder to confirm the hour figure], 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 Tablemere publishes (security-overview.md, 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. Tablemere 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 Tablemere; (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 Tablemere 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. Customer content is stored and processed exclusively in Germany (Annex III). Tablemere does not 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 Tablemere's own company mailboxes and never receives Customer content. Should a Customer send personal data to a Tablemere 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 Tablemere 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. Tablemere's product rule is that no US-controlled entity operates its infrastructure or holds Customer content (see security-overview.md); 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 Tablemere holds Customer content, including the deletion period in clause 3(g).

7. Governing law and courts

Spanish law; courts of [city of the courts — 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 warehouse 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 warehouse is refused by the catalog and by the object store for any other warehouse. 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 warehouse) 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; optionally an OpenID Connect identity provider we run ourselves (Rauthy, with passkeys, MFA enforced for its administrators). No passwords are stored by the control plane.
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., auth.) 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 of the complete state (storage volumes, filer store, catalog configuration, keys, control-plane database) taken by a systemd timer at 03:17 UTC, with a checksum; 7 copies kept on the host, 14 copies off-host in Hetzner Object Storage (Falkenstein, Germany), each off-host copy downloaded again and its checksum compared after upload.
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 tenant's key pair (self-service POST /v1/warehouses/{id}/rotate: old key refused immediately; sessions already vended expire within 15 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, identity provider, Python libraries) were reviewed against deployed versions on 2026-09-19 and the upgrades scheduled.
20. Data minimisation by design. The website keeps no access log and sets no cookies; rate-limit state lives in memory for at most one hour; the Service never reads customer content.

II.6 Not yet in place (disclosed)

• High availability. One host runs everything. A host failure means downtime until restore from backup (recovery point: up to 24 hours; recovery time: the rehearsed restore took minutes plus provisioning). Planned (platform/PLAN.md §8).
• Encryption at rest of tenant secrets. Tenant storage key pairs are stored in plaintext in the control plane's database file (root-only, 0600). Envelope encryption with a separate key is designed (docs/security.md, "Tenant keys at rest") but not implemented.
• Encryption at rest of customer content. The storage system has server-side-encryption key material generated, but per-bucket encryption of customer objects has not been verified as enabled; Hetzner block storage is not represented as encrypted by us. Treat customer content as unencrypted at rest until this line changes.
• Encrypted backup archives. Off-host backup archives are protected by the object-storage credentials and by transport TLS, not by their own encryption. Encrypting the archive before upload is the next backup iteration.
• Container hardening (dropping capabilities, read-only root filesystems) and log rotation with a defined retention are scheduled, not deployed. Until then, host logs are not automatically pruned.
• Third-party certification. None (no ISO 27001, no SOC 2).
• Individual revocation of a vended storage credential. Only wholesale rotation (measure 15) exists; the 15-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 Tablemere runs (Apache Iceberg, SeaweedFS, Caddy, Rauthy, DuckDB, PyIceberg) is operated by Tablemere 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.