Order now

One page with the answers procurement teams and data protection officers ask for. No marketing: everything here is backed by the terms of service, the data processing agreement and the subprocessor list, all linked at the bottom. Where we do not have something, we say so.

In short

  • Every customer gets a separate application instance and a separate database. Nothing is shared.
  • A human reads your request. The AI tools receive neither its text nor any data from your application.
  • Daily backups, verified by restoring them. A full export with one click, at any time.
  • We hold neither SOC 2 nor ISO 27001, and we say so plainly rather than working around it.

Isolation and architecture

We are not a multi-tenant platform. Every customer gets their own application instance with their own database, running separately. There is no shared table where your records sit next to someone else's and are kept apart by a tenant id - and that difference decides what the worst possible bug looks like.

Application
A separate instance for every customer
Database
A separate PostgreSQL instance for every customer
Region
One region agreed before the start, the European Union by default. Application, database and backups sit in the same region

Backups and restores

We back up your database daily and verify it by restoring it, because a backup nobody has restored is only an assumption.

Frequency
Daily, with backups in the same region as the application
Maximum data loss (RPO)
Up to 24 hours - the interval between backups
Restore time (RTO)
We state no numeric commitment. We do test restores, but we do not measure them in a way that could be settled against - and we would rather not promise a number we cannot settle

Regardless of our backups, you can export all of your data with one click at any time. We encourage you to do it - a copy held by you is a safeguard we cannot replace.

Who sees your data

Only people who need it to run the service are given access to a customer database, and they are bound by confidentiality obligations. Every such access is logged. Inside the application, roles and permissions apply, and every content change stays in the log - you can see what changed, who approved it and when.

It is worth describing separately how work on an ordered change happens, because that is the question we get most often. A human on our side reads your request. That person writes down, in their own words, what needs to be built, and only that description reaches the AI tools we write code with. The AI tools receive neither the text of your request nor any data from your application.

Where a change needs test data, we use anonymised or invented data - never your production records. Customer data and content is also never used to train AI models, ours or anyone else's.

Encryption and access

Technical and organisational measures match Article 32 GDPR. The main ones:

  • Encryption in transit and at rest.
  • Role and permission based access, with a change log inside the application.
  • Separate environments: work on changes does not happen on your production instance.

Incidents

If a personal data breach occurs, we inform you without undue delay after becoming aware of it - so that you can notify your supervisory authority within the 72 hours GDPR gives you. Our notice carries what we know at the time of sending; it does not wait for the full picture.

Security fixes go out immediately, without notice, and we tell you about them afterwards. Planned work is announced by e-mail in advance.

Subprocessors

The list of parties processing data from your application is public and forms part of the data processing agreement. Today it holds one party: the infrastructure provider in the eu-central-1 region. We give at least 30 days' notice by e-mail before adding or changing a subprocessor, and you may object during that period.

A change you order may require an external service - a payment gateway, SMS delivery, a bank integration. That provider then becomes a subprocessor of your data, and we add it to the list applying to your instance before the change goes live. We tell you at the quoting stage, not after delivery.

Certifications

We do not hold SOC 2 or ISO 27001 certification today. We write that plainly, because procurement will check anyway, and finding silence here costs more than finding an answer.

Instead of a certificate we can show what we actually do: a separate instance and database per customer, encryption in transit and at rest, daily backups verified by restoring them, logged access to databases, a public subprocessor list, a data processing agreement available before you sign anything, and work on changes carried out away from production data.

If certification is a condition of purchase for you, write to us - we will tell you plainly where we stand rather than promise a date we do not have.