Data Processing Agreement
This agreement forms part of the Terms of Service between Datatreehaus, a sole trader business established in England and Wales ("Processor", "we") and the business that accepts these documents through the Thezi dashboard ("Controller", "you"). It is made under Article 28 of the UK GDPR.
Effective date: 11 September 2026
Processor contact for data protection matters: hello@thezi.app. The name of the sole trader behind Datatreehaus and the Processor's full postal address are available on request from that address.
Controller contact for data protection matters: the contact email on your account, and the person named in your acceptance record.
1. Roles
1.1 The Controller determines the purposes and means of processing personal data through the Services. The Processor processes that data only on the Controller's documented instructions.
1.2 The Terms of Service, this agreement, the settings the Controller configures in the dashboard and the Controller's use of the Services constitute the Controller's documented instructions.
1.3 The Processor will inform the Controller if, in its opinion, an instruction infringes data protection law, and may refuse to act on it.
1.4 If the Processor determines the purposes and means of any processing, it acts as a controller for that processing and this agreement does not apply to it. Clause 2 identifies the processing where that is the case.
2. Processing details (Annex 1)
Subject matter: provision of a table booking platform to the Controller for its Venue.
Duration: the term of the Terms of Service, plus any retention period under clause 8.
Nature and purpose: collection, storage, retrieval, display, amendment and deletion of booking records; computation of availability; transmission of booking confirmations and cancellations; recording of marketing agreement and its withdrawal, and export of the resulting list to the Controller; recording of parties waiting for a table; and, where the Controller has connected a payment provider, facilitation of card holds and cancellation charges through the Controller's own account with that provider.
Categories of data subject
| Category | Description |
|---|---|
| Diners | Individuals who make or attempt a booking at the Venue, and individuals a member of the Controller's staff adds to the waitlist |
| Controller staff | Named individuals with their own dashboard sign-in |
| Controller agents | Automated software acting under an API key the Controller issued |
Categories of personal data
| Data subject | Fields |
|---|---|
| Diners | Name, email address, phone number, booking date, time, party size, table assigned, booking status, free-text notes, marketing agreement state and the wording agreed to, and payment provider customer and payment method references where a card is taken |
| Diners on the waitlist | Name, party size, the day waited for, optional phone number and email address, free-text notes, and whether the party was seated or left |
| Controller staff | Name, email address, password hash, session and sign-in records, and the audit trail of actions taken |
| Controller agents | API key identity and the audit trail of actions taken |
Special category data. The booking form includes a free-text notes field, offered to Diners for allergies, dietary requirements and similar. It is therefore capable of containing health data within Article 9 UK GDPR. The Controller is responsible for establishing an Article 9 condition. The Service supports this by seeking the Diner's explicit consent at the point of entry and by stating the purpose in the Diner Privacy Notice. The Processor treats that field as containing special category data for the purposes of clauses 6 and 8. No other field in the Services is intended to hold health data, and the Controller must not record it elsewhere.
Marketing agreement. Whether the booking form asks at all is the Controller's setting, and it is off until the Controller turns it on; a Controller that has not turned it on has nothing recorded, whatever a caller sends. Where it is on, the Controller also chooses the style — an unticked box (consent, PECR reg 22(2)) or a pre-ticked box the Diner may clear (the soft opt-in at reg 22(3)) — and the Processor records the Diner's email address, the fact and time of the agreement, the version of the exact wording they were shown, and any withdrawal and its time. An ABSENT answer is recorded as "not asked", never as a refusal, so a booking taken by phone cannot unsubscribe anyone. Agreement is held against the Controller's Venue only. There is no cross-venue marketing table in the Services and the Processor does not create one.
Export. The Controller may export its opted-in Diners from the dashboard. Once exported, that copy is outside the Services and outside this agreement's security measures; the Controller is the controller of it in every sense, and is responsible for protecting it and for keeping it in step with withdrawals.
Acceptance records. The Processor records the name, timestamp, IP address and document bundle version of the individual accepting these documents. The Processor acts as a controller in respect of that record, not as a processor, and retains it as evidence of the agreement between the parties.
Account records. The Processor acts as a controller in respect of the Controller's own staff account records — name, email address, credentials and sign-in history — to the extent it uses them to operate, secure and bill for the Services. It acts as a processor in respect of the same records where they appear in the audit trail of actions taken on the Controller's data.
Data not processed: the Processor does not receive, process or store full payment card numbers at any point. Card data passes directly to the Controller's own payment provider.
3. Processor obligations
The Processor will:
3.1 process personal data only on the Controller's documented instructions, unless required otherwise by law, in which case it will inform the Controller unless the law prohibits it;
3.2 ensure that any person authorised to process the data is subject to a duty of confidence;
3.3 implement the technical and organisational measures in clause 6;
3.4 respect the conditions in clause 4 for engaging sub-processors;
3.5 assist the Controller as set out in clauses 5 and 7;
3.6 delete or return personal data as set out in clause 8; and
3.7 make available the information necessary to demonstrate compliance with Article 28, and allow audits as set out in clause 9.
4. Sub-processors
4.1 The Controller gives general authorisation for the Processor to engage the following sub-processors:
| Sub-processor | Purpose | Location |
|---|---|---|
| Cloudflare, Inc. | Application hosting, database storage, and sending of booking emails | Western Europe (London) |
The Controller's payment provider processes card data under the Controller's own direct arrangement with it and is not a sub-processor of the Processor. Where the Controller connects Stripe, it does so from its own Stripe account and may disconnect it at any time; the Processor holds delegated access solely to operate the Services for that Venue.
4.2 The Processor will give the Controller at least 30 days' written notice before adding or replacing a sub-processor. If the Controller reasonably objects on data protection grounds within that period, the parties will discuss in good faith, and if no resolution is reached the Controller may terminate the Terms of Service without penalty.
4.3 The Processor remains fully liable to the Controller for the acts and omissions of its sub-processors.
5. Data subject requests
5.1 Data subject requests are the Controller's responsibility. The Diner Privacy Notice directs Diners to the Controller.
5.2 If the Processor receives a request directly from a data subject, it will not respond substantively. It will forward the request to the Controller without undue delay and confirm to the data subject that it has done so.
5.3 The Processor will assist the Controller in responding, taking into account the nature of the processing, by providing access to the relevant records through the dashboard, and by carrying out deletion, correction or export where the Controller instructs it and the dashboard cannot do so.
5.4 Assistance under clause 5.3 is provided at no charge for a reasonable volume of requests. The Processor may charge at its standard rates for volumes that are materially disproportionate.
6. Security
6.1 The Processor implements the following measures:
- All database queries use parameterised statements with bound values, and the query plans of the hot booking queries are asserted in the test suite so that a query missing its venue filter fails the build.
- Staff sign in with individual accounts. Passwords are stored as PBKDF2-SHA-256 hashes and sign-in is rate limited.
- Sessions are server-side records and can be revoked; a password change invalidates the sessions the old password minted.
- Every change to data is written with an audit record identifying the actor and whether that actor was a person or an automated agent, and that record commits in the same transaction as the change.
- Public booking writes are gated by a bot check that refuses rather than passes when it is unavailable.
- A booking's own identifier is an unguessable UUID, and cancelling a booking requires the booker's email address as well as that identifier.
- All traffic is served over TLS.
- Card data is handled directly by the payment provider; the Processor never receives a full card number.
- Booking pages load no third-party content, no advertising and no tracking.
- Application logs are configured not to capture personal data.
- Database backups are encrypted before storage and the restore procedure is tested rather than assumed.
6.2 Individual accountability. Each member of the Controller's staff signs in with their own account, and each automated agent acts under its own API key. The audit record for every change names the account or key that made it and states whether it was a person or software. The Controller is responsible for who it grants access to, for revoking access when someone leaves, and for every action taken under a key it has issued.
6.3 Data isolation. The Services are multi-tenant. Every venue's data is held in one shared database, separated by a venue identifier on every row and enforced by the application, rather than by a separate database per venue. This is a deliberate design decision, disclosed so the Controller can assess it. The measures in clause 6.1 addressing query plans and audit records exist principally to defend that boundary.
6.4 The Processor will not materially reduce the overall level of security during the term.
7. Personal data breaches and assistance
7.1 The Processor will notify the Controller without undue delay, and in any event within 24 hours, of becoming aware of a personal data breach affecting the Controller's data.
7.2 The notification will describe, so far as known, the nature of the breach, the categories and approximate number of data subjects and records affected, the likely consequences, and the measures taken or proposed.
7.3 The Processor will not notify the Information Commissioner's Office or any data subject on the Controller's behalf unless instructed to.
7.4 The Processor will provide reasonable assistance with data protection impact assessments and prior consultations, to the extent the Controller cannot reasonably obtain the information itself.
8. Retention, deletion and return
8.1 Retention periods are configured per venue and are enforced on instruction, not yet automatically. The dashboard records the Controller's chosen retention periods for the free-text notes field and for booking records as a whole. The Processor does not currently run an automatic sweep that applies them. Until it does, the Processor will delete or minimise data in line with those periods on the Controller's instruction, without undue delay and at no charge. The Processor will tell the Controller when automatic enforcement is in place, and this clause will be reissued accordingly.
8.2 The default periods, which the Controller may change, are: the contents of the free-text notes field minimised 12 months after the booking date, and the booking record deleted 24 months after the booking date. Marketing agreement records are kept until the agreement is withdrawn, and the record of a withdrawal is kept afterwards as evidence of it — a deleted record cannot show that someone was taken off a list. Waitlist entries are closed but not deleted: an entry still waiting at the end of its day is marked expired automatically, and the entry itself is retained so that "how many parties did we turn away" remains answerable. It carries no separate retention period today; deletion is on the Controller's instruction under clause 8.1.
8.3 Data held with the Controller's payment provider is outside this clause. That account is the Controller's own, the Controller contracts with the provider directly, and the data held there is the Controller's payment and accounting record. The Processor does not delete, detach or otherwise alter data in that account, and is not responsible for its retention. The Controller is responsible for retaining that data in line with its own accounting obligations and for erasing it where a data subject request requires it.
8.4 On termination the Processor will, at the Controller's election made within 30 days, return the personal data in a common machine-readable format or delete it. Absent an election, the Processor will delete it after 30 days.
8.5 The Processor may retain personal data to the extent required by law, and this agreement continues to apply to it.
8.6 Backups and point-in-time recovery data are overwritten on the infrastructure provider's own cycle and are deleted on that cycle rather than on demand.
9. Audit
9.1 The Processor will make available the information reasonably necessary to demonstrate compliance with this agreement, on written request and no more than once in any 12 month period.
9.2 The Controller may audit compliance on 30 days' written notice, during business hours, at the Controller's cost, subject to reasonable confidentiality undertakings. Audits must not disrupt the Processor's business or compromise other customers' data.
9.3 The Processor is a sole trader business. Audit rights will be exercised proportionately having regard to that.
10. International transfers
10.1 The Processor does not transfer the Controller's personal data outside the UK. The database used for the Services is located in Cloudflare's Western Europe region.
10.2 The Controller's payment provider may transfer payment data internationally under its own safeguards. The Controller's own arrangement with that provider governs that transfer.
10.3 The Processor will not introduce a new international transfer without the Controller's prior written consent.
11. Liability
11.1 Liability under this agreement is subject to the limitations and exclusions in clause 11 of the Terms of Service, save to the extent applicable law does not permit that.
11.2 Nothing in this agreement limits either party's direct liability to a data subject or to a supervisory authority under data protection law.
12. Duration and precedence
12.1 This agreement takes effect on 10 September 2026 and continues for as long as the Processor processes personal data on the Controller's behalf.
12.2 In the event of conflict, this agreement prevails over the Terms of Service in respect of the processing of personal data.
12.3 This agreement is governed by the law of England and Wales.
Acceptance
No printed signature is required. This agreement is entered into by electronic confirmation in the dashboard, in accordance with clause 15.1 of the Terms of Service. The Processor records the name entered, the timestamp, the originating IP address and the document bundle version accepted, and will provide the Controller with a copy of that record on request.
Issued by Datatreehaus.