Data Processing Agreement

1. What this agreement is, and when it applies#

This Data Processing Agreement (“DPA”) applies whenever Gheima processes personal data on your behalf — that is, whenever your application, your managed database or your object storage holds data about people. It forms part of the Terms of Service and is entered into by the same parties.

Two roles are in play at once, and confusing them is the usual source of trouble:

• For the personal data inside your workloads — your users, your customers, your rows and your files — you are the controller and Gheima is the processor. This DPA governs that.
• For the data about your Gheima account — your email, your billing details, your audit trail — Gheima is the controller. The Privacy Policy governs that, not this DPA.

2. Subject matter, duration, nature and purpose#

3. Processing only on your instructions#

We process the personal data in your workloads only to provide the platform, and only as instructed by you. Your configuration — which region you place a resource in, what you deploy, what you store — is your instruction. We will tell you if an instruction appears to breach applicable data-protection law, and we may refuse it.

If a law requires us to process or disclose your data, we will tell you before doing so unless that law forbids the notice. We do not access the contents of your databases, buckets or containers in the ordinary course of running the platform.

4. Confidentiality#

Everyone at Gheima with access to production is bound to confidentiality, and access is granted on the basis of what a role actually needs. Administrative actions, including any staff impersonation of an account for support, are written to the audit log.

5. Security measures#

The technical and organisational measures we apply are, in summary:

• Encryption in transit for all external traffic, with automatically issued and renewed certificates.
• Encryption at rest, AES-256-GCM under a per-account derived key, for environment variables, managed-database credentials, object-storage keys, connected Git tokens and two-factor secrets.
• Tenant isolation enforced as a column on every resource and a scope on every query, with cross-account and cross-region access refused at the boundary.
• Per-tenant network segmentation: managed databases are reachable on a private overlay and publish no ports to the internet.
• Builds executed in an isolated rootless build daemon, separate from cluster management.
• An append-only audit log enforced by a database trigger, with scheduled minimisation of the identifying fields.
• Two-factor authentication available to every user and requirable on team accounts.
• Automated backups, stored encrypted, with a scheduled restore drill that actually restores — a backup nobody has restored is a hypothesis.

We review these measures as the platform changes, and we will not lower them below the level described here for the duration of this DPA.

6. Sub-processors#

You give us general authorisation to use sub-processors. The current list, with each one's purpose and location, is published on our Sub-processors page and forms part of this DPA.

We will publish any addition or replacement on that page and notify account holders by email at least thirty days before the new sub-processor starts processing. If you object on reasonable data-protection grounds within that period, we will work with you to find an alternative; if there is none, you may terminate the affected service and we will refund the unused part of the period. Every sub-processor is bound by terms no less protective than these.

7. Helping you answer data subjects#

Requests from your users come to you, not to us — we have no relationship with them. Where you need our help to answer one, the platform gives you direct access to the data: your managed database is yours to query, your buckets are yours to list, and the account export produces your account-level records as JSON. If a request needs something those do not reach, write to hello@gheima.ma and we will assist at no charge.

8. Personal data breaches#

If we become aware of a breach affecting personal data we process for you, we will notify you without undue delay and in any event within seventy-two hours of becoming aware, with what we know at the time: what happened, which data and roughly how many records are involved, the likely consequences, and what we are doing about it. We will keep updating you as we learn more rather than waiting until the picture is complete. Notifying your supervisory authority and your users, where that is required, is your decision as controller; we will give you what you need to make it.

9. Deletion and return#

Deleting a resource in the dashboard deprovisions the real thing, not just its record: the managed database role and database, the object-storage identity, the container and its volume. Closing an account soft-deletes it and destroys live credentials at once, holds it for a thirty-day restore window, and then hard-purges everything — managed databases, buckets, search and queue instances, volumes and the account record itself.

Export your data before you close the account; after the grace window it is gone. Encrypted backups may retain deleted data for up to fourteen further days before they age out, and we will not claim otherwise. At any point during the relationship you may ask us in writing to delete or return the data we process for you, and we will do so unless a law requires us to keep it.

10. Audits#

On reasonable written notice, and no more than once a year unless a supervisory authority or a breach makes more necessary, we will give you the information you need to demonstrate compliance with this DPA, and we will answer a security questionnaire. Any on-site or hands-on audit is at your cost, scheduled so it does not affect other customers, and conducted by someone bound to confidentiality.

11. International transfers#

Where we transfer personal data out of the country it was collected in, we do so under an appropriate transfer mechanism — standard contractual clauses with the receiving sub-processor, or your own documented instruction, which is what choosing a region is. Section 12 states exactly where data sits for each region we operate.

12. The data-residency add-on: exactly what it covers#

This is the section to read before buying the add-on, and it is written to be checkable rather than impressive.

When a resource is placed in a residency region, these stay inside that region's country, on that region's own hardware:

• the application containers themselves, pinned to nodes in the region;
• managed databases — Postgres and Redis — and everything in them;
• object-storage buckets and their contents;
• snapshots and database dumps;
• build inputs, build logs and deployment logs;
• container logs and metrics, collected by the region's own logging and monitoring stack;
• container images, held in the region's own registry;
• backups, taken in the region and copied to a second location inside the same country.

These do not, today. They live in the control plane, which is central:

• resource metadata — the names of your services, databases, domains and projects, and the repository URLs they build from;
• your environment variables, which are stored as ciphertext in the control database and are decryptable there;
• the audit log of actions taken in the dashboard and API;
• billing records: plans, invoices, usage meters;
• pseudonymised website-analytics rows — visitor hash, path, referring host, country, status, with no raw IP and no user agent;
• the dashboard process itself, which means that when you type a secret into the dashboard, it passes through the control plane in plaintext at that moment before being encrypted and stored.

The control plane runs in the European Union. So the accurate statement of what the add-on gives you is: your customer data at rest stays in the country you chose, while the metadata about it, and the operator interface, do not. We intend to move the control plane into Morocco and will update this section — with a new version number — on the day it happens, not before.

Two further limits, stated plainly. Job payloads for deployment and provisioning pass through the central queue; we have checked that they carry identifiers only — no secrets, no customer data. And a region is claimed as being in a country on the basis of our provider's own statement about where that region is; where we do not yet hold that statement in writing, the region carries no residency claim at all and is offered only as a preview.

13. Order of precedence, and liability#

Where this DPA and the Terms of Service conflict on the processing of personal data, this DPA wins. Everything else in the Terms, including the limitations of liability, applies to this DPA as if set out in it.

14. Signing it#

This DPA applies automatically to every account; you do not need to sign anything for it to be in force. If your procurement process needs a countersigned copy, or your own DPA template reviewed, write to hello@gheima.ma.