GDPR-ready on Dibbla

This is the companion to secure-app.md for the other question a customer asks: not “is it secure?” but “what do you do with my data?” Same shape — seven situations in one sentence each, what Dibbla already handles, one sentence to paste to your agent, and how you check afterwards that it was really done.

You do not need to read the GDPR. You need to know which parts are Dibbla’s, which parts are yours, and what the answer looks like when someone asks for it in writing.

Your role, and Dibbla’s

Two sentences carry everything below.

For the data in your app, you are the controller and Dibbla is your processor. You decided to collect it, you decided what it is for; Dibbla only stores and runs it because you told it to. Dibbla never uses your application’s data for its own purposes and never trains AI models on it.

Towards your own customers, Dibbla is a sub-processor. When a customer asks you to sign a data processing agreement, they are asking you to name everyone who can touch their data underneath you. Dibbla is on that list, and so is every service you added — your mail sender, your error tracker, your analytics.

There is a third case worth separating out so you do not mix it up: for your account data — your e-mail address, your organisation, your billing details — Dibbla is the controller, and that is covered by Dibbla’s own privacy policy at dibbla.com/privacy. That one is not your responsibility.

What Dibbla takes care of

Facts you can quote to a customer today. Nothing here is aspirational.

Two things that are honest to know. Managed databases and buckets are not deleted with an app — they belong to the organisation, because people share them between apps and redeploy. dibbla apps delete names them and gives you the command that removes them; if you skip that step the data is still there. And the logs of a deleted app are not erased on the spot today; they age out with the 180-day retention like every other log line.

One thing that is not ready yet, stated plainly so you do not promise it. Dibbla’s written data processing agreement and its published sub-processor list at dibbla.com/subprocessors are being prepared and are not published at the time of writing. The table above is what is factually true and what you can put in your own sub-processor list in the meantime. Do not tell a customer that Dibbla has signed a DPA with you until the document exists — check dibbla.com/terms for the current state before you answer a procurement question in writing.

How to use this file

Paste the Ask your agent sentence for one point into whatever agent you build with. Do them one at a time; each answer is short.

Several points end with what REVIEW.md should show. REVIEW.md is the security review your agent writes at the root of your project before deploying — dibbla deploy refuses to upload without it, and it is committed with your code. Its Personal data (GDPR) section is the one part of that report written to be read outside your team: it is what you hand a customer who asks how you handle their data.

One file, added to — never replaced. Everything here goes into the existing REVIEW.md. Its --- header block (Review-status:, One-Sentence-Summary:) is what the deployments dashboard reads; an agent that rewrites the file from scratch and drops the header leaves the deploy working and the status blank. If you are unsure, tell your agent: “add this to REVIEW.md, keep the header and the sections that are already there.”

Two points ask for documents, not code — your privacy policy (point 2) and your data processing agreement (point 3). An agent can draft both from what your code actually does, which is the only way they end up true. Neither is legal advice, and for a real procurement you will want a lawyer to read the result once.

1. You cannot say what personal data your app holds

The risk. A customer, or their lawyer, asks what you store about their users. You answer from memory, miss the avatar bucket and the analytics table, and the answer you gave in writing is wrong.

Dibbla does. Makes your agent write the inventory before every deploy: the pre-deploy checklist’s Personal data (GDPR) check is mandatory, and a deploy whose report does not list the stores holding personal data is blocked. Dibbla cannot know which of your fields are personal — only your code knows that — so the platform’s part is forcing the question, not answering it.

Ask your agent.

“Add to REVIEW.md — keeping the header and the sections already there — the Personal data (GDPR) section of the guardrails report, with an inventory under four headings. Stored: every table, file and bucket that holds data about a person, named as store.field. Deletion: how one person is deleted and which stores that delete does not reach. Logs: whether any personal data is written to the logs. Third parties: who receives personal data and which fields they get. Then add, for each field, what it is used for and how long it is kept — say ‘kept indefinitely’ where that is the truth.”

How you know it’s done. REVIEW.md has the Personal data (GDPR) section with those four headings filled in, plus a purpose and a retention for each store. You can read it aloud to a customer without checking anything else. If the app holds no personal data, one line saying so is the correct answer.

2. Your privacy policy does not match what your code does

The risk. The policy on your site was written before the feature that collects phone numbers, or it was copied from a template and lists a cookie banner you never installed. The gap between the two is the part a regulator reads first.

Dibbla does. Nothing here — this is your text about your users, and Dibbla cannot write it for you. What Dibbla gives you is the ingredients for the part about hosting: where the data is (Germany and Finland), who the sub-processors are, and the retention figures in the table above.

Ask your agent.

“Read the personal-data inventory in REVIEW.md and my current privacy policy, and list every difference: data the code collects that the policy does not mention, claims in the policy the code does not support, and missing items — purpose and legal basis per category, retention, the rights people have, and who the data is shared with. Then draft the corrected policy. Say that hosting is on Dibbla, in the EU (Hetzner, Germany and Finland), and list my other sub-processors by name.”

How you know it’s done. Every store in the inventory appears somewhere in the policy, and every claim in the policy is one you could point at code for. The sub-processor list in the policy matches the Third parties line in REVIEW.md — if those two disagree, one of them is wrong.

3. A customer asks for a data processing agreement and you have nothing to send

The risk. Your first serious B2B customer sends a procurement questionnaire and a DPA to sign. It asks you to list your sub-processors, state where data is stored and confirm that you can delete on request. A week of improvising follows, and the deal slows down.

Dibbla does. Keeps your data in the EU and is the sub-processor you name for hosting. Dibbla’s own DPA and published sub-processor list are in preparation (see above) — until they exist, name Dibbla in your list with the facts from the table above, which are true today and verifiable.

Ask your agent.

“Draft a data processing agreement I can give my own customers, as an annex to my terms. Take the categories of data and data subjects from the personal-data inventory in REVIEW.md, state that hosting is in the EU with Dibbla (Hetzner, Germany and Finland) as sub-processor, list every other sub-processor I use with what it sees and where it is, and include deletion on termination, breach notification and assistance with data-subject requests. Flag anything you had to guess so I can check it with a lawyer.”

How you know it’s done. You have one document you can send the same day it is asked for, its sub-processor list matches the Third parties line in REVIEW.md, and nothing in it promises a control you do not have. The last part matters most: a DPA that promises what your code cannot do is worse than no DPA.

4. Someone asks for a copy of everything you hold about them

The risk. A user exercises their right of access. You have thirty days, the data sits in four tables and a bucket, and there is no way to assemble it except by hand — so it is done badly, or late, or not at all.

Dibbla does. Nothing at this layer: only your code knows which rows are that person’s. What Dibbla does give you is the shape to build it in — a route in your app, or a dibbla.yaml job you run on demand.

Ask your agent.

“Add a way to export everything the app holds about one person, as JSON plus any files, covering every store in the REVIEW.md inventory — including uploads and anything in object storage. Make it reachable only by that person or by an admin, log that it ran, and note the route and the stores it covers in REVIEW.md.”

How you know it’s done. You can run it once for a real account and read the result: it contains what the inventory says it should, and nothing belonging to anyone else. REVIEW.md names the export route under the Personal data section.

5. Someone asks to be forgotten and you can only delete half

The risk. You delete the user row. Their name stays on old orders, in the search index, in a cached profile and in last month’s CSV export in a bucket — and you tell them in writing that they were erased.

Dibbla does. Removes everything on its side when you remove the app or the organisation, and gives you the outer bound in writing: a deleted database row is unrecoverable from production backups after 30 days, and log lines age out with the 180-day retention. Inside your own database, deletion is yours — the pre-deploy checklist blocks a deploy that stores personal data with no way to delete a person, and warns when the delete path leaves copies behind.

Ask your agent.

“Trace what happens when one person is deleted. Go through every store in the REVIEW.md inventory and tell me which ones the delete reaches and which it does not — child tables, search indexes, caches, queued jobs, exports and files in object storage. Fix the ones it misses, or say why they must stay, and record the result under Deletion in REVIEW.md.”

How you know it’s done. The Deletion line in REVIEW.md names the delete path and every store it deliberately does not reach, with a reason for each. There is no BLOCKER: no way to delete a person and no unexplained “incomplete deletion” warning. When you tell a customer someone was erased, that line is what makes it true.

6. You collect more than you need, and keep it forever

The risk. The signup form asks for a phone number nobody ever calls, sessions from two years ago are still in the table, and every CSV export ever generated sits in a bucket. None of it is used, all of it is yours to lose.

Dibbla does. Applies its own retention to everything it holds on your behalf — logs 180 days, AI prompts and responses 30 days, backups 30 days — and gives you a scheduled job (dibbla.yaml cron) to run your own cleanup. What you keep in your own database is your decision; nobody will prompt you about it.

Ask your agent.

“Go through the personal-data inventory in REVIEW.md. For each field, tell me what it is actually used for in the code, and flag anything collected but never read. Then propose a retention period for each store and a scheduled job that enforces it — sessions, tokens, uploads, exports and soft-deleted rows first. Record the periods under the Personal data section in REVIEW.md.”

How you know it’s done. Every store in the inventory has a retention next to it, and a job that enforces it or an explicit “kept while the account exists”. Anything collected and never read is either removed from the form or justified in one line.

7. Personal data ends up in your logs and in services you added yourself

The risk. A debug line prints the whole request body, so e-mail addresses are in the logs for months. An error tracker you added in an afternoon receives the same payloads, on servers you never checked — and it is not in your privacy policy or your sub-processor list.

Dibbla does. Keeps platform log lines pseudonymous — user_id and org_id, not e-mail addresses — and retains logs for 180 days in production. But what your app prints, your app owns: every line it writes to stdout is stored on the same terms, for the same 180 days, and is readable by everyone in your organisation. Anything you send to a third party from your own code leaves Dibbla entirely and is outside all of the above.

Ask your agent.

“Find every place this app writes personal data to the logs — request bodies, error payloads, user objects in log lines — and replace it with an id. Then list every third party the app sends personal data to: mail, SMS, analytics, error tracking, payment, AI. For each, name the fields that leave and where the service is hosted. Update the Logs and Third parties lines in REVIEW.md.”

How you know it’s done. The Logs line in REVIEW.md says ids only, and the Third parties line names every recipient with the fields it gets — and matches the sub-processor list in your privacy policy and your DPA. Three lists, one set of names. When they agree, you can answer a procurement questionnaire from memory.

What this file does not cover

Said out loud so you do not assume it is handled.

• Cookies and tracking consent. If you load analytics, ad pixels or third-party fonts, consent rules apply before they load. The pre-deploy checklist warns about trackers that fire without a consent gate; the banner itself is yours to build.
• A personal-data breach. If data leaks, you have 72 hours to notify your supervisory authority, and possibly the people affected. Knowing who was affected depends entirely on the inventory in point 1 — which is the practical reason to write it before you need it.
• Transfers outside the EU/EEA. Everything Dibbla stores stays in the EU. If you add a US service, that transfer is yours to justify.
• Legal advice. This file, and anything an agent drafts from it, is a starting point written from what your code actually does. Have a lawyer read the finished policy and DPA once.

Where the words come from