Skip to main content

Data Processing Agreement

Version 1.0 · Last updated: 18 June 2026

1. Definitions

Terms used in this DPA take their meaning from the UK GDPR and the Data Protection Act 2018, including but not limited to:

  • Controller — the entity that determines the purposes and means of processing.
  • Processor — the entity that processes personal data on behalf of the Controller.
  • Personal Data — any information relating to an identified or identifiable natural person.
  • Personal Data Breach — a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Personal Data.
  • Sub-processor — any third party engaged by the Processor to process Personal Data on behalf of the Customer.
  • Data Subject — the identifiable natural person to whom Personal Data relates.

2. Roles

  • The Customer (the tenant) is the Controller in respect of Personal Data processed through the Services.
  • Caleonix LTD is the Processor.
  • The third parties listed at /policies/subprocessors are Sub-processors.

3. Scope and purpose

The Processor will process Personal Data only as reasonably necessary to deliver the Services to the Customer in accordance with the Terms of Service.

4. Customer obligations

The Customer warrants and undertakes that it:

  • Has a lawful basis under the UK GDPR for any processing it instructs the Processor to perform.
  • Provides accurate, lawfully obtained Personal Data.
  • Handles its own Data Subject rights requests, with reasonable assistance from the Processor under section 9.
  • Notifies the Processor promptly of any material change in its processing instructions.

5. Caleonix obligations

The Processor will:

  • Process Personal Data only on the Customer's documented instructions. Signing up to use the Services constitutes the Customer's documented instruction to operate the Services as marketed.
  • Ensure that persons authorised to process Personal Data are bound by appropriate confidentiality obligations.
  • Implement and maintain the technical and organisational measures required by Article 32 of the UK GDPR (see Annex 2).
  • Comply with the rules on engaging Sub-processors set out in section 7.
  • Assist the Customer with its obligations under Articles 32 to 36 of the UK GDPR.
  • Make available to the Customer all information reasonably necessary to demonstrate compliance with this DPA.

6. Technical and organisational measures

The Processor maintains the technical and organisational measures described in Annex 2.

7. Sub-processors

The Customer grants the Processor general written authorisation to engage Sub-processors, on the conditions that:

  • The current list of Sub-processors is published at /policies/subprocessors.
  • The Processor will give at least 30 days advance notice before engaging a new Sub-processor that will process Personal Data as part of the Customer’s existing use of the Services. Where a new Sub-processor only supports an optional feature the Customer chooses to enable, it is disclosed on the sub-processors list and the Customer’s decision to enable that feature constitutes its authorisation to engage that Sub-processor for that feature; the Customer remains free not to enable the feature.
  • The Customer may object on reasonable grounds and terminate without penalty if its objection cannot be resolved.
  • The Processor engages each Sub-processor under a written contract imposing data-protection obligations substantially equivalent to those in this DPA.
  • The Processor remains liable to the Customer for the acts and omissions of its Sub-processors.

8. International transfers

Some Sub-processors are based outside the UK. International transfers are governed by:

  • The UK International Data Transfer Agreement (IDTA), or
  • The EU Standard Contractual Clauses with the UK Addendum where applicable.
  • Where a US Sub-processor is certified under the EU-US Data Privacy Framework and its UK Extension, that framework may additionally apply alongside the mechanisms above.

Each Sub-processor’s data-processing terms incorporate one of these mechanisms.

This description of our transfer mechanisms is provided on a best-effort basis and is not legal advice.

9. Data subject rights

The Processor will assist the Customer in responding to Data Subject rights requests as follows:

  • Self-serve tooling: tenants can export and delete individual diner data through Customers → Export / Delete in the dashboard.
  • Manual escalation: for complex cases, the Customer may email [email protected].
  • The Processor will respond within 7 business days of any such request.

10. Personal data breaches

The Processor will notify the Customer without undue delay (and in any event within 72 hours of becoming aware) of any Personal Data Breach affecting the Customer's data. The notification will include, to the extent known:

  • The nature of the breach.
  • The categories and approximate number of Data Subjects concerned.
  • The categories and approximate number of records concerned.
  • The likely consequences.
  • The measures taken or proposed to address the breach.

The Customer is responsible for any onward notification to the ICO under Article 33 of the UK GDPR or to affected Data Subjects under Article 34.

The Processor maintains an internal incident-response process covering breach detection, containment, assessment, notification, and recovery, which it reviews periodically and after any material incident. A high-level summary is available on request to Controllers by emailing [email protected].

11. Audit rights

The Customer may audit the Processor's compliance with this DPA once per 12-month period on 30 days written notice. Audits are conducted at the Customer's expense, with the Processor's reasonable cooperation, and under a mutual non-disclosure agreement.

12. Termination and data return

On termination of the subscription, the Customer has 30 days to request a full export of its Personal Data by emailing [email protected] from the Owner's account email. The Processor will produce the export and provide a secure download link within 7 business days of the request. After the 30-day window the Processor will permanently delete the data, subject to any legal retention obligations (see the retention table in the Privacy Policy).

13. Liability

Liability under this DPA is governed by section 15 (Limitations of liability) of the Terms of Service.

14. Order of precedence

In the event of a conflict between documents, the order of precedence is: UK GDPR > this DPA > the Terms of Service.

15. Governing law

This DPA is governed by the laws of England and Wales, matching the Terms of Service.

Annex 1 — Subject matter and details of processing

Subject matterPersonal data of the Customer's diners, staff, and any users contacting ResoFlow support.
DurationTerm of subscription plus 30 days post-termination. Support correspondence is retained per the schedule in the Privacy Policy.
Nature and purposeBooking management, customer communications (email and SMS), analytics, deposit handling, no-show protection (saving a diner's card and attempting a no-show fee), and customer support communication via the in-app chat, the support@/billing@/policies@ email aliases, an AI first-line responder, and an internal staff-messaging bridge.
Categories of Data Subjects
  1. Diners — anyone who books a table or joins a waitlist at a Customer's restaurant.
  2. Tenant staff — restaurant employees the Customer adds to their ResoFlow account.
  3. Tenant Owners — the natural person who holds the Customer's signup account.
  4. External support contacts — non-tenant senders who email ResoFlow's support aliases.
Categories of Personal Data

Diners: contact details (name, email, phone); booking details (date, time, party size, table, optional notes, booking history, and optional date of birth for birthday messages); dietary and allergy information; the profile the Customer keeps about a diner (VIP flag, tags, free-text notes, seating preference, and family details such as number of children and highchair / children’s-menu needs); event-ticket details (buyer name, email and phone, any additional attendee names, and a device identifier + push token where a ticket is saved to a device wallet, used only for pass updates); activity the Processor derives for the Customer (attendance history, lifetime spend on deposits and tickets, average party size, previous names / phone numbers seen on the profile, and — for marketing emails the Customer sends — email-engagement events such as whether a message was delivered, opened or clicked); and — where the Customer enables deposits or no-show protection — Stripe payment references only (a saved-card / mandate reference and any deposit or no-show fee charge or refund reference). The diner’s card details themselves are held by Stripe on the Customer’s connected Stripe account and are not stored by the Processor. The full, itemised list is in the Privacy Policy.

Tenant staff: name, username, assigned role and permissions, optional work contact details and job title, a one-way hash of the staff PIN (plaintext is never stored or visible to us), device identifiers for enrolled devices, sign-in IP addresses and session metadata (retained for security and the tenant’s audit log), and basic preferences.

Tenant Owners: name, email address, billing contact details, multi-factor authentication factors, and audit-log records of the Owner's administrative actions.

External support contacts: sender email address, message content, and the sender’s IP address and browser user-agent captured at message time, plus AI assistant interaction logs (excluding internal model diagnostics). Attachments from an external sender are only processed once we have replied and opened a support thread.

Derived: administrative-action audit records (actor identity, action type, timestamp, target reference) and aggregated daily and monthly analytics snapshots produced from the above.

Special category dataDietary and allergy information, processed under Article 9(2)(a) (explicit consent — the diner provides it voluntarily so it can be catered for).
Payment processing (deposits and no-show fees)Where the Customer enables deposits or no-show protection, Stripe processes the deposit charge, the saved-card mandate (created when the diner saves a card at booking time; no funds are taken or held at that point), and any no-show fee charge or refund directly on the Customer's own connected Stripe account (the Customer is the merchant of record), on the same direct-charge basis as event-ticket sales. A no-show fee is charged only when the Customer's staff deliberately mark a booking as a no-show (or, where the Customer enables it, a late cancellation), never automatically. Stripe acts as a Sub-processor (see Annex 3); the Processor does not see, store, or process the diner's card details. The deposit or no-show fee is paid to the Customer; the Processor may deduct a platform fee from it.

Annex 2 — Technical and organisational measures

EncryptionTLS in transit; AES-256 at rest with Google-managed keys.
Perimeter securityA CDN with DDoS protection, a managed web-application firewall and bot-protection ruleset, and a challenge step on public submission paths (per-submission on the public booking page and app-wide as the attestation provider for our app-integrity checks); custom rate limits on public submission paths.
Access controlsRole-based access control with least-privilege defaults, using built-in and Customer-defined roles with per-user permission overrides. Owners use multi-factor authentication; tenant staff sign in via PIN on owner-paired devices only. High-stakes actions (deletions, refunds, role changes, staff PIN resets, GDPR exports) require step-up re-authentication.
AuthenticationFirebase Authentication; passwords hashed by Google.
Audit loggingRoutine administrative and data-access actions are logged for 12 months (24 months on the Chef’s Table plan); billing-related entries (refunds, plan changes, subscription cancels) are mirrored at write time into a tamper-resistant retained billing log and held for 7 years per UK HMRC requirements.
Security monitoringSentry error tracking and BetterStack uptime monitoring; periodic manual security review.
BackupDaily backup snapshots retained 31 days, plus 7-day point-in-time recovery (Google Cloud).
Incident responseDocumented incident-response process; material incidents are reported on the Customer-facing status page.

Annex 3 — Sub-processors

The current list of Sub-processors is published at /policies/subprocessors. The list is updated with 30 days advance notice as required by section 7 of this DPA.