Trust center # What we commit to, per regulation Dibbla AB is a Swedish company in Stockholm. The managed platform runs in the EU, on Hetzner in Germany and Finland. Below, per regulation: what the rule requires, what Dibbla does about it, and what it means for the customers you answer to. Every claim on this page is one a published, binding document already makes — the Terms, the Data Processing Agreement, the Sub-processor List or the Privacy Policy. Each point links to the one it comes from. Nothing here is aspirational: if it is not in production, it is not on this page, and the things we deliberately do not do are[named below](#not-covered). Last updated: September 22, 2026 - In the EUCompute, databases, storage and backups in Germany and Finland. - A Swedish companyDibbla AB, Stockholm. Swedish law, with IMY as supervisory authority. - Processor under Art. 28The DPA is part of the Terms and binds us the moment you accept them. - Never used to train AINot your code, not your data, not your customers' data. - Leave wheneverExport in open formats, no switching charges, assistance within 30 days. [GDPR](#gdpr)[Data Act](#data-act)[Security](#security)[ISO 27001](#iso-27001)[Your own application](#your-app)[Text you can paste](#paste)[Documents](#documents) ## GDPR Regulation (EU) 2016/679 You are the controller for the data in the applications you deploy; Dibbla is your processor. Everything below follows from that one split. 1. ### Who is responsible for what Art. 4(7)–(8), Art. 28(1) The requirement Whoever decides why and how personal data is processed is the controller. Anyone who processes it on their behalf is a processor, and may only be engaged if they offer sufficient guarantees. What Dibbla does For the data inside the applications you deploy — your databases, buckets, files and application logs — you are the controller and Dibbla is your processor. For your own account, organisation membership and billing details, Dibbla is the controller. Dibbla never uses your application's data for its own purposes, does not sell it, and does not use it to train general-purpose AI models. [DPA §2](/dpa) What this means for your customers Your customers deal with you, not with Dibbla. If one of their users asks for access or erasure, the request is yours to answer; a request that reaches Dibbla is forwarded to you and not acted on except on your instruction. 2. ### A data processing agreement that is already in force Art. 28(3) The requirement Processing by a processor must be governed by a contract setting out the subject matter, duration, nature and purpose of the processing, the types of personal data and categories of data subjects, and the processor's obligations. What Dibbla does The DPA forms part of the Terms and binds both parties the moment you accept them — no signature, no negotiation round. Annex 1 states the subject matter, duration, nature and purpose, the data types and the categories of data subjects; Annex 2 lists the technical and organisational measures. A Swedish version is published alongside it. [DPA (and the Swedish version)](/dpa) What this means for your customers When a customer asks which agreement governs your hosting, you send a public URL that is the agreement actually in force — not a template you would have to negotiate first. 3. ### Sub-processors, each with the condition that makes it apply Art. 28(2), Art. 28(4) The requirement A processor may engage another processor only with the controller's authorisation, must inform the controller of intended changes and give it the chance to object, and must impose the same obligations further down the chain. What Dibbla does The Sub-processor List is published and incorporated into the DPA by reference. It is arranged in tiers with an “applies when” column, so you can see which ones touch your data and which ones never will. Dibbla gives at least 30 days' notice before a new sub-processor starts processing, by updating the page and e-mailing the organisation's contact and everyone subscribed; you may object on reasonable data protection grounds. AI model providers process nothing until an organisation admin enables an AI feature, and then only the provider you chose. [Sub-processor List](/subprocessors) What this means for your customers Their agreement with you asks for your sub-processor list. Ours is a public page with a subscribable change notice, so the list you hand them does not go stale the month after you send it. 4. ### The data stays in the EU Chapter V, Art. 44–46 The requirement Personal data may be transferred outside the EU/EEA only under an adequacy decision, Standard Contractual Clauses, or another mechanism recognised by Chapter V. What Dibbla does Compute, databases, object storage and backups run on Hetzner in Nuremberg, Germany and Helsinki, Finland. Dibbla does not transfer customer personal data out of the EU/EEA and does not permit a sub-processor to do so, unless the transfer is covered by adequacy or by the EU Standard Contractual Clauses (Decision (EU) 2021/914). Cloudflare terminates TLS at the edge, so traffic passes through it in transit; Google or Microsoft, as sign-in providers, see the e-mail address and display name of whoever signs in. Each location and each transfer mechanism is named in the Sub-processor List. [DPA §12](/dpa) What this means for your customers “Where is our data?” has one answer, and it has two city names in it. 5. ### Deletion, and how long everything lives Art. 5(1)(e), Art. 17, Art. 28(3)(g) The requirement Personal data may be kept no longer than necessary, must be erased on request where the conditions are met, and must be deleted or returned at the end of the service. What Dibbla does The Privacy Policy publishes the retention schedule the DPA refers to — one row per kind of data, with what ends it. Platform logs live 180 days and carry pseudonymous identifiers, not e-mail addresses. Prompts and responses through the AI gateway live 30 days and are erased by an automatic hourly sweep. A deleted database row is gone from every backup after 30 days. When the agreement ends, your data stays exportable for at least 30 days, after which all customer personal data is deleted within 30 days and the deletion confirmed on request. Deleting an application removes its workload, volumes, secrets, images, records and the repository it deploys from; managed databases and buckets belong to the organisation and are deliberately not removed with it — the command that deletes them is named in the output. [Privacy Policy §11](/privacy) What this means for your customers “How long do you keep it, and what happens when we leave?” can be answered with figures instead of adjectives. 6. ### An incident reaches you in time to report it Art. 33(1), Art. 33(2) The requirement The controller notifies the supervisory authority within 72 hours of becoming aware of a personal data breach. The processor notifies the controller without undue delay. What Dibbla does Dibbla notifies you without undue delay and no later than 48 hours after becoming aware of a breach affecting your data, describing the nature of the breach, the categories and approximate numbers of data subjects and records concerned, the likely consequences, the measures taken and a point of contact — in phases if that is how the facts arrive. Notifying the supervisory authority and the people affected stays yours as controller, which is exactly why the notice is set inside your 72 hours. [DPA §9](/dpa) What this means for your customers 48 hours to you, plus your own assessment, still fits inside the 72 hours the law gives you. The deadline is not something you inherit from your host. 7. ### Rights requests, and the record that makes them answerable Art. 12–23, Art. 28(3)(e)–(f), Art. 30 The requirement Data subjects have rights of access, rectification, erasure, restriction and portability. The processor assists the controller in meeting them, and each party keeps records of its processing. What Dibbla does Dibbla assists with requests and forwards any it receives directly to you. The part only your code knows — which rows belong to one person — is what the pre-deploy checklist makes your agent write down: REVIEW.md carries a Personal data section listing what is stored and where, how one person is deleted and which stores that delete does not reach, whether personal data is written to the logs, and which third parties receive it. It lives in your repository and is versioned with the code it describes. [GDPR-ready on Dibbla](/trust/gdpr-checklist) What this means for your customers An access or erasure request is answered from a document that changes when the code changes, rather than from memory. ## Data Act Regulation (EU) 2023/2854, Chapter VI Chapter VI is about being able to leave. It applies to Dibbla as a data processing service, and Section 12 of the Terms was written against it. 1. ### You can leave, and the contract says how Art. 25(2) The requirement The contract must set out the switching rights: a notice period of no more than two months, a transitional period of up to 30 days for completing the switch, and a retrieval period of at least 30 days afterwards. What Dibbla does You terminate by deleting your organisation or by writing to support. The notice period is never longer than two months from the day we receive your notice, and you may choose any earlier date. If you are switching, we assist and complete the switch within 30 days of the notice period ending, and the service keeps running at the same level of security and business continuity throughout. If 30 days is technically unfeasible in a specific case, we tell you within 14 working days, explain why and propose an alternative of at most seven months. Your data stays available for export for at least 30 days after that. [Terms of Service §12](/terms) What this means for your customers Continuity of your service does not depend on your relationship with your host staying good. 2. ### Everything is exportable, in formats that work without Dibbla Art. 23, Art. 30(1) The requirement Providers must remove the obstacles to switching and make exportable data available in a structured, commonly used, machine-readable format. What Dibbla does Application source as a git repository with its full deployment history. Databases as PostgreSQL dump archives that restore into any PostgreSQL server. Buckets as the files they contain, with their object keys as paths. Environment and configuration as dotenv files and your dibbla.yaml manifest, together with a compose file and a README describing how the exported parts run together. Workflows as YAML. The dibbla export command produces all of it in one step, at any time, without our involvement. Container images rebuild from the Dockerfile in that source with any container runtime — there is nothing Dibbla-specific inside them. [Terms of Service §12](/terms) What this means for your customers Your exit plan is a command, not a project, and you can prove it by running it. 3. ### Nothing to pay for leaving Art. 29 The requirement Switching charges are being withdrawn, and from 12 January 2027 a provider may not charge for switching at all. What Dibbla does Dibbla charges nothing for terminating the agreement, for switching, for exporting your data, or for transferring data out of the service. Only the ordinary fees for your plan apply, and only for the period you actually use it. This is already the case, ahead of the date the regulation sets. [Terms of Service §12](/terms) What this means for your customers There is no exit fee in the chain underneath you to disclose or to negotiate away. 4. ### What you would be moving is your own code Art. 30(2)–(3) The requirement Infrastructure providers must ensure functional equivalence after switching; other providers must make open interfaces available. What Dibbla does What runs on Dibbla is your own container, built from your own Dockerfile. Around it the platform adds a URL with TLS, sign-in, managed PostgreSQL, object storage, secrets and logs — each with a standard counterpart at any other provider. Dibbla's own platform software is not part of the export, and you do not need it to run your applications elsewhere. [Terms of Service §12](/terms) What this means for your customers Moving provider does not imply a rewrite, which is the part of lock-in that actually costs money. ## Security GDPR Art. 32 · ISO/IEC 27001:2022 Annex A The measures below are the ones Annex 2 of the DPA commits us to, stated in more detail and mapped to the Annex A controls they correspond to. 1. ### One organisation cannot reach another's Art. 32(1)(b) · A.8.22 The requirement The controller and processor must ensure the ongoing confidentiality and integrity of processing systems and services. What Dibbla does Each customer organisation is logically separated, with organisation-level isolation of data, network and secrets, and role-based access control on top. Only the services you mark as public are published; everything else is reachable only from inside your own deployment. Authorisation is org-scoped in the data layer and fails closed. [DPA Annex 2](/dpa) What this means for your customers Their data is not sitting in a shared table behind a tenant column that one query could forget to filter on. 2. ### Encrypted in transit, and the sensitive parts at rest Art. 32(1)(a) · A.8.24 The requirement Appropriate measures including, as appropriate, pseudonymisation and encryption of personal data. What Dibbla does All data in transit is protected with TLS, at the edge and in the cluster, including on custom domains. Sensitive data at rest is encrypted. Secrets are stored outside your source code and injected as environment variables when the application runs; there is no permission anywhere that reads a secret value back out, and an upload is stripped of its .env files — only .env.example, the names without the values, travels with your code. [DPA Annex 2](/dpa) What this means for your customers “Is it encrypted in transit?” is yes, everywhere, and a leaked repository does not leak your keys with it. 3. ### Access is role-based and least-privilege, including ours Art. 32(4) · A.5.15, A.5.18, A.8.2 The requirement Anyone acting under the controller's or processor's authority may process personal data only on instruction, and access must be restricted to what is necessary. What Dibbla does Roles are granted per organisation. Access to production systems is restricted to authorised Dibbla personnel, granted on a least-privilege basis and reviewed regularly, and personnel with access are bound by confidentiality. Sign-in is federated — Dibbla stores no passwords at all. Sessions use secure, HTTP-only cookies with CSRF protection and short-lived tokens, and any change of role or organisation invalidates every cookie already issued to you. [DPA Annex 2](/dpa) What this means for your customers Removing someone's access removes it now, not at the next session expiry. 4. ### Every change has a name on it — including an AI agent's Art. 5(2) · A.8.15 The requirement The controller must be able to demonstrate compliance, and logs of activities must be produced, kept and protected. What Dibbla does Deployments and administrative actions are logged with the acting user. A connected AI agent acts as the person who authorised it, inside one organisation, and never holds a standing account of its own: every change it makes is an audit entry naming the client, the user and the outcome, kept for 180 days. Consent defaults to read-only — write permissions are unticked on the consent screen — and destructive actions need a separate, bound confirmation at the moment they are taken, so the permission alone is never enough. [Privacy Policy §5, §11](/privacy) What this means for your customers “Who did this?” has an answer even when the answer is an agent, and the answer names a person. 5. ### Backed up, and recoverable Art. 32(1)(c) · A.8.13 The requirement The ability to restore availability and access to personal data in a timely manner in the event of an incident. What Dibbla does Databases are backed up with a seven-day point-in-time recovery window plus 30 nightly copies. An application's source and deployed files keep the last 30 nightly backups; object storage keeps 30 dated backup generations of deleted or overwritten objects. The platform runs on redundant infrastructure inside the EU. Backups are never edited to remove individual records — they age out, which is the same 30 days the deletion promise above is measured in. [Privacy Policy §11](/privacy) What this means for your customers A deletion by mistake is recoverable, and a deletion on request is final within 30 days. One mechanism, stated honestly in both directions. 6. ### Every deployment passes a written security review Art. 32(1)(d) · A.8.25, A.8.28 The requirement A process for regularly testing, assessing and evaluating the effectiveness of the measures, and rules for secure development and secure coding. What Dibbla does Every deployment goes through a code review gate covering common web application security risks. In practice your agent runs the pre-deploy checklist and writes REVIEW.md at the root of your project; dibbla deploy refuses to upload without one, and the file is committed with your code, so it can be read, diffed and shown to a customer. Said plainly, because it is the sentence that matters: REVIEW.md is an agent's judgement of source code, recorded in writing and versioned with it. It is not a scan, not a penetration test and not a certification. [Make your app more secure on Dibbla](/trust/app-security) What this means for your customers Every release was looked at against a named list of risks, and the record of that is in the repository rather than in somebody's memory. 7. ### Every build is scanned, and the findings stay with the deployment Art. 32(1)(d) · A.8.8, A.5.21 The requirement Information about technical vulnerabilities must be obtained in time to act on it and the exposure evaluated, and the risks in the ICT supply chain must be managed. What Dibbla does Once a rollout is live, the platform scans that revision inside the cluster and stores the result on it: a bill of materials for every image, that inventory matched against the known-vulnerability database with a severity, a fix version and an advisory link per finding, and a scan of the built source for leaked secrets — the matched secret itself is never stored. Services running a pulled image are scanned too, so the list covers the whole revision, and nothing of yours leaves the platform to make it happen: the image is read from our own registry and the source from our own disk. The scan runs after the deploy and does not block it, and the overnight maintenance agent reads it when it decides what to propose. This is the deterministic half, and it is worth keeping apart from the one above: the scan is a tool's list of what is in your build, the review is an agent's judgement of what your code does. Neither replaces the other. [Make your app more secure on Dibbla](/trust/app-security) What this means for your customers Known holes in the libraries you ship are found by a tool, on every release, with a date on the finding — not the next time somebody remembers to look. 8. ### Incidents have a process, and vulnerabilities have an owner Art. 32(1)(d) · A.5.24–A.5.26, A.8.8 The requirement Technical vulnerabilities must be managed, and incidents must be planned for, assessed and responded to. What Dibbla does Platform components are kept up to date, and Dibbla maintains an incident process with classified response times, containment levers and the breach notification above. For the applications you deploy, scheduled checks and an overnight maintenance agent are available once you switch them on: the agent reads logs, source and check history and files a proposal with a diff. It never deploys on its own — you approve or deny, and the person whose agent wrote a proposal cannot be the one who approves it. [DPA Annex 2](/dpa) What this means for your customers Changes to a running application are proposed, reviewed by a second person and recorded, rather than applied quietly overnight. ### Two things Dibbla deliberately does not do They belong to the application, and guessing on your behalf would break working apps. They are yours, and the checklist below tells your agent how to take them. - **Filter your application's outbound network traffic.** Restrict the URLs your own code fetches — point 8 of the checklist. - **Apply request-size or rate limits in front of your application.** Rate-limit your own login, signup, reset and verification endpoints — point 6 of the checklist. ## ISO 27001 ISO/IEC 27001:2022 Annex A Controls aligned with ISO/IEC 27001:2022 Annex A. Dibbla AB is not certified. “Aligned with” means the measures on this page were written against the Annex A controls and are assessed against them: each theme has a named owner, a written policy and a documented gap analysis that is reviewed twice a year and whenever a control changes. Where a control is only partly in place, it is recorded as partly in place. It does not mean an accredited certification body has audited anything. Dibbla AB holds no ISO 27001 certificate, is not currently pursuing one, and nothing on this page should be presented as one. If you need a certificate in your supply chain, this is the point at which to tell us — we would rather you heard it here than discovered it in an audit. The data centres Dibbla's infrastructure runs in are themselves ISO 27001-certified, as Hetzner's facilities in Germany and Finland. That is a certification of the buildings and the operator, not of Dibbla, and this page does not borrow it as one. Under Article 28(3)(h) of the GDPR, Dibbla makes available the information necessary to demonstrate compliance and allows for and contributes to audits by you or an auditor you mandate: once per twelve months, on 30 days' written notice, and sooner if a supervisory authority requires it or a breach has occurred. - A.5OrganizationalPolicies, roles, supplier management, incident management, legal and regulatory requirements. - A.6PeopleConfidentiality undertakings and security guidance for everyone with access to customer data. - A.7PhysicalDischarged by Hetzner, whose data centres in Germany and Finland are ISO 27001-certified. - A.8TechnologicalIsolation, cryptography, access restriction, deletion, logging, backup, network segregation and secure development — the controls this page describes in detail. ## Your own application The half of this that is yours Everything above is the platform. What the platform cannot know is which of your rows belong to which of your customers, or which of your fields are personal data. These two checklists are the source your agent reads — the same files installed into a project by`dibbla skills install dibbla`, published here so you can read them before you install anything. Each point carries a sentence to paste to your agent and a way to check afterwards that it was really done. - [Make your app more secure on DibblaTen risks in one sentence each, what Dibbla handles, a sentence to paste to your agent, and how you check afterwards that it was done.Read it →](/trust/app-security) - [GDPR-ready on DibblaSeven situations a customer will put you in — the inventory, the privacy policy, the DPA they ask you to sign, access, erasure, retention and logs.Read it →](/trust/gdpr-checklist) ## Text you can paste GDPR Art. 13–14, Art. 28(2) and Art. 28(4) Your customers ask you where their data is and who you use. These are the answers about Dibbla, written so you can paste them into your own privacy policy and your own sub-processor list. Every fact in them is one the documents below already state. - ### For your privacy policy: who hosts the service One line for the “where is the data processed” paragraph most privacy policies already have. Nothing to fill in. Our service is hosted by Dibbla AB, Stockholm, on servers within the EU. Dibbla acts as our data processor under a data processing agreement. Copy - ### The same thing, at the length procurement asks for When a customer's questionnaire asks for hosting, location and transfers in the policy itself rather than in an annex. Our service is hosted by Dibbla AB (Stockholm, Sweden) on infrastructure located in Germany and Finland. Dibbla acts as our data processor and processes personal data only on our documented instructions, under a data processing agreement meeting the requirements of Article 28 of the GDPR. Dibbla does not use the data in our application for its own purposes, does not sell it and does not use it to train general-purpose AI models. Dibbla engages sub-processors of its own; the current list, with each one's purpose, location and safeguard, is published at https://dibbla.com/subprocessors. Personal data is not transferred outside the EU/EEA except where the transfer is covered by an adequacy decision or by the EU Standard Contractual Clauses. Copy - ### For your sub-processor list: the Dibbla row The four columns a sub-processor list has. Paste it as a row in yours. - **Dibbla AB** — Purpose: Application hosting: running our application and its managed databases, object storage, backups and logs. Location: Sweden (company); servers in Germany and Finland (EU). Safeguard: Data processing agreement under Art. 28 GDPR; data stays in the EU/EEA Copy - ### And Dibbla's own sub-processors, which you pass on Article 28(4): Dibbla's sub-processors carry the same obligations, and your customer's agreement usually asks to see the whole chain. Keep the rows whose condition applies to you and delete the rest. Sub-processors engaged by our hosting provider, Dibbla AB (current list: https://dibbla.com/subprocessors): - **Hetzner Online GmbH** — Purpose: Servers, block storage and backup storage the application runs on. Location: Germany and Finland (EU). Safeguard: Data stays in the EU; Art. 28 processor agreement; ISO 27001-certified data centres. Applies when: Always - **Cloudflare, Inc.** — Purpose: DNS, TLS termination, DDoS protection and edge network in front of the application. Location: Global edge network; United States company. Safeguard: Encrypted in transit and not stored at the edge; EU Standard Contractual Clauses; EU-US Data Privacy Framework. Applies when: Always - **Brevo (Sendinblue SAS)** — Purpose: Delivery of transactional e-mail sent by the platform: notifications, invitations and alerts. Location: France (EU). Safeguard: Data stays in the EU; Art. 28 processor agreement. Applies when: Always - **Google LLC** — Purpose: “Continue with Google” sign-in: verifying identity and returning e-mail address and display name. Location: United States and EU. Safeguard: EU Standard Contractual Clauses; EU-US Data Privacy Framework; only identity data is exchanged. Applies when: We sign in to Dibbla with Google - **Microsoft Corporation** — Purpose: “Continue with Microsoft” sign-in: verifying identity and returning e-mail address and display name. Location: United States and EU. Safeguard: EU Standard Contractual Clauses; EU-US Data Privacy Framework; only identity data is exchanged. Applies when: We sign in to Dibbla with Microsoft - **Stripe Payments Europe, Ltd.** — Purpose: Subscription billing and invoicing for our Dibbla plan. Location: Ireland (EU), with Stripe, Inc. (United States) as its own sub-processor. Safeguard: EU Standard Contractual Clauses; EU-US Data Privacy Framework; card numbers never reach Dibbla. Applies when: We are on a paid Dibbla plan - **Anthropic, PBC** — Purpose: Language models behind the optional AI features we have enabled in Dibbla. Location: United States. Safeguard: EU Standard Contractual Clauses; commercial API terms: inputs and outputs are not used to train models. Applies when: We have enabled an AI feature and chosen Anthropic - **OpenAI, L.L.C.** — Purpose: Language models behind the optional AI features we have enabled in Dibbla. Location: United States. Safeguard: EU Standard Contractual Clauses; commercial API terms: inputs and outputs are not used to train models. Applies when: We have enabled an AI feature and chosen OpenAI Copy These blocks describe Dibbla, and we keep them true. What your own policy has to say is still yours to decide — they are drafted for you to adapt, not legal advice. ## The documents What actually binds us - [Terms of Service](/terms)Including Section 12, switching and termination - [Data Processing Agreement](/dpa)Article 28 terms, in force on acceptance - [Data Processing Agreement (svenska)](/dpa/sv)Swedish translation; English prevails - [Sub-processor List](/subprocessors)In tiers, with 30 days' notice of changes - [Privacy Policy](/privacy)Including the retention schedule in Section 11 - [Cookie Policy](/cookies)Cookies on this website Questions, a procurement questionnaire, or an audit request:[privacy@dibbla.com](mailto:privacy@dibbla.com). Anything else, including a security report:[support@dibbla.com](mailto:support@dibbla.com).