Data Processing Agreement
Version 1.0 · Last updated: 18 June 2026
Incorporation and acceptance
In short: This DPA forms part of the ResoFlow Terms of Service. By creating a tenant account on ResoFlow you agree to be bound by this DPA in respect of any personal data you process through the Services.
This Data Processing Agreement (the "DPA") is incorporated by reference into the ResoFlow Terms of Service. By creating a tenant account on ResoFlow, you (the "Customer") and Caleonix LTD (the "Processor") agree to be bound by this DPA in respect of any personal data the Customer processes through the Services.
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 matter | Personal data of the Customer's diners, staff, and any users contacting ResoFlow support. |
| Duration | Term of subscription plus 30 days post-termination. Support correspondence is retained per the schedule in the Privacy Policy. |
| Nature and purpose | Booking 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 |
|
| 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 data | Dietary 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
| Encryption | TLS in transit; AES-256 at rest with Google-managed keys. |
| Perimeter security | A 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 controls | Role-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. |
| Authentication | Firebase Authentication; passwords hashed by Google. |
| Audit logging | Routine 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 monitoring | Sentry error tracking and BetterStack uptime monitoring; periodic manual security review. |
| Backup | Daily backup snapshots retained 31 days, plus 7-day point-in-time recovery (Google Cloud). |
| Incident response | Documented 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.
