DRAFT — for review by a solicitor. This text has not yet been approved; it is governed by the law of England and Wales. Divvent will publish a final version and ask you to accept it.
Data processing agreement
Version 1, in effect from 2026-09-28
1. Roles and scope
This agreement forms part of the Terms of service between Divvent and the Customer. For personal data in the Customer’s Applications, and in the requests and models the Customer gives Divvent, the Customer is the controller and Divvent is the processor, under the UK GDPR, the Data Protection Act 2018 and, where it applies, the EU GDPR.
Subject matter and duration: building, deploying, operating, backing up and supporting the Customer’s Applications, for as long as the Terms are in force and until deletion under section 10.
Nature and purpose: hosting in the hosting account Divvent holds for the Customer (section 1a), deployment, backup and restore, rehearsal of platform updates, AI-assisted proposal of changes, and support.
Personal data and data subjects: whatever the Customer’s Applications are designed to hold about the Customer’s staff, customers and contacts, as the Application’s model declares it; including, where the model declares it, special-category data and children’s data.
1a. The hosting account
Hosting account. Divvent hosts each of the Customer's applications in a Cloudflare account that Divvent creates, holds and pays for, used for the Customer alone (the "hosting account"). The Customer is not a member of it and is not billed by Cloudflare for it; Cloudflare's charges are included in the Customer's Divvent plan price.
Sub-processor. Cloudflare, Inc. is Divvent's sub-processor for the hosting account: it stores and processes the Customer's application data (databases, files) and runs the application. Divvent is the Cloudflare customer and the Customer has no contract with Cloudflare.
Location. Every database and file bucket in the hosting account is created with Cloudflare's Western Europe location hint, so that the Customer's data is stored in the UK/EU region. Cloudflare's network may serve requests from other locations; stored data stays where it was created.
Access. Divvent reaches the hosting account with a credential scoped to that account alone and to the four capabilities a deploy needs, sealed in Divvent's control plane and opened only by Divvent's deploy program. No credential that Divvent holds for one customer's hosting account can reach another's.
End of contract. When the Customer leaves, the hosting account and everything in it is deleted after the export window in which the Customer may take its data out, and not before.
2. Instructions
Divvent processes the personal data only on the Customer’s documented instructions — these terms, the Application’s model, and the changes the Customer approves — unless the law requires otherwise, in which case Divvent tells the Customer first where the law allows it.
3. The platform does not read Application data
Divvent’s platform is built so that it never reads the records in a Customer’s Application: a restore is by a bookmark, a health check reads whether the Application answers, and no part of the platform imports a client that reads Application data. The exceptions are the ones this agreement names: a rehearsal copy (section 11), and a support session the Customer’s owner is told about, which is recorded.
No Application data is sent to the AI provider. The model receives the words of a change request and the Application’s structure.
4. Confidentiality
Everyone at Divvent who can reach personal data is bound by confidentiality. Operator access to production is behind Cloudflare Access with a second factor, and emergency access to a Customer’s Application (break-glass) is granted per person and per Application, time-limited, notified to the Customer’s owner and recorded.
5. Security
Divvent maintains the measures described in its security documentation, including: encryption in transit and at rest (by Cloudflare); every customer credential sealed at rest with a key the web-facing services cannot open; secrets that are write-only and never logged; every change to the platform or to an Application recorded in an append-only audit trail with who, what and from where; a second factor for every person with access; least privilege for every service; key rotation on a published schedule; and a daily backup of each Application’s database into the Customer’s own storage.
6. Sub-processors
The Customer gives general authorisation for Divvent to engage the sub-processors listed on the published sub-processor list. Divvent imposes data protection terms on each that are no less protective than these, and remains liable for them.
Divvent tells the Customer of an intended addition or replacement at least thirty days before it takes effect, by publishing a new version of the list and notifying the Customer’s owners. The Customer may object on reasonable data-protection grounds within that period; if the parties cannot resolve the objection, the Customer may end the Terms without penalty.
7. Data residency
When a company is created its owner chooses where its Applications’ data is stored. The choices are: European Union — guaranteed; Western Europe — preferred; Eastern Europe — preferred; Eastern North America — preferred; Western North America — preferred; Asia-Pacific — preferred; Oceania — preferred. A guaranteed choice is a Cloudflare jurisdiction, within which Cloudflare stores and processes the data; the others are location hints Cloudflare follows when it creates the database and bucket.
The choice applies to every database, bucket, nightly backup and rehearsal copy made for the company’s Applications, because all of them are created through one deploy target that carries it. It is shown to the Customer in the portal and cannot be changed by a setting; moving a company’s data is a procedure the Customer asks for.
8. International transfers
Where a sub-processor processes personal data outside the UK, the transfer is made under UK adequacy regulations or under the International Data Transfer Addendum to the EU Standard Contractual Clauses, as the sub-processor list states for each.
9. Assistance, breaches and audits
Divvent helps the Customer answer requests from data subjects — each Application has an export and an erasure for a person — and with impact assessments, for which each Application publishes a data inventory.
Divvent notifies the Customer without undue delay, and in any case within 48 hours of becoming aware, of a personal data breach affecting the Customer’s data, with what is known and what is being done.
Divvent makes available the information needed to demonstrate compliance with this agreement, including an evidence export drawn from its audit trail, and allows audits by the Customer or its auditor on reasonable notice, no more than once a year unless a breach or a regulator requires it.
10. Deletion and return
The Customer’s Applications and data are in the hosting account Divvent holds for the Customer; when the Terms end, the Customer may export them during the export window, after which the hosting account and everything in it is deleted. What Divvent holds about an Application — its models, builds and records — is deleted within ninety days of the end, except what the law requires Divvent to keep; audit records hold identifiers, never Application data.
11. Rehearsing a platform update on a copy of production
11.1 Purpose. Before an update to the Divvent platform (as distinct from a change the Customer makes to its own application) is applied to the Customer's production application, Divvent rehearses it. A rehearsal deploys the same built application, identified by its hash, to a separate deployment in the Customer's hosting account (clause H1) that has no address and that no person can sign in to, running on deterministic synthetic data; runs the application's generated tests and health checks against it; and removes it when it has answered. Only a rehearsal that passes allows the update to proceed to production.
11.2 Processing of a copy of production data. As part of the rehearsal, and only once the rehearsal on synthetic data has passed, Divvent may process a copy of the Customer's production database solely to test that the update's database changes apply to it correctly. To make the copy, Divvent's deploy program reads the rows of the production database over Cloudflare's API and writes them into a new database in the Customer's hosting account. That program runs on infrastructure provided by GitHub, Inc., which is Divvent's sub-processor for it; the rows pass through the program's memory only and are not written to its disk, to any log, or to any system of Divvent's. Sign-in sessions, verification codes and account credentials are not copied. The copy is read from the production database a few seconds after Divvent marks the point the production database can be restored to before the update; it is not restored from that point, and writes made in those seconds may be in it. While it exists, the copy is connected to no application and has no network address of its own, and nothing of Divvent's opens it other than the program that applies database changes; it remains reachable, however, by Divvent's deploy credential for the Customer's hosting account and by the Divvent staff who administer that account. Where the production database is larger than Divvent's stated limit for a copy, no copy is made and the rehearsal uses synthetic data only.
11.3 Deletion. The copy exists for minutes. It is deleted when the rehearsal has answered, whether it passed or failed, and its deletion is confirmed by looking it up by name; a copy that a failed run left behind is found by name and deleted by Divvent's next check of the Customer's account, and each deletion is recorded.
11.4 Records. Every step of the rehearsal is recorded in Divvent's audit log by the deployment it concerns and the step's name. Divvent's records of a rehearsal contain whether each step passed, the names of the checks and tests that failed, counts of rows affected where the change's plan already reports them, and the class and code of any error — and never the contents of the Customer's data, including in error messages.
11.5 Consent for regulated applications. Where the Customer has an application whose declared risk profile is `children`, `health` or `highly_regulated`, or which holds data classified as children's personal data or health data, Divvent processes a copy of production data under this clause only with the consent of the Customer's account owner, given in the Divvent portal and changeable there at any time. Without that consent, or until it is given, the rehearsal uses synthetic data only. For every other application the copy is used by default, unless the account owner has said no, which is honoured for every application of the account. The answer is read once, immediately before the copy is made.
12. Law
This agreement is governed by the law of England and Wales.