Data Processing Agreement

Last updated: 5 August 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 guest 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 working 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 deletion or termination of the Customer's account, the Customer has 30 days to request a full export of its Personal Data by emailing [email protected] from the Owner's account email. (Cancelling a paid subscription alone removes what was cancelled at the end of the paid period — a cancelled plan downgrades the account to the free tier, and a cancelled standalone product is removed from the subscription; either way the account stays open and this window does not start.) The Processor will produce the export and provide a secure download link, valid for 24 hours, within 7 working 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 guests, staff, and any users contacting ResoFlow support.
Duration	Life of the Customer's account plus 30 days after account deletion or 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 guest's card and attempting a no-show fee), promotions and offer codes the Customer runs for its guests (server-side validation and per-person usage limits), the Customer's optional loyalty scheme (membership, earning and redemption records, member emails, and optional wallet-pass loyalty cards), the Customer's optional gift cards (sale and delivery — including buyer-scheduled future delivery — balance and redemption records, buyer and recipient emails, optional wallet-pass gift cards, recording the buyer's optional marketing opt-in at the gift purchase page, and creating or updating the Customer's guest profile from a purchase — the buyer only, never the recipient), the Customer's optional pre-ordering for larger bookings (a party's advance dish selections with any choices, quantities, optional per-dish first names, and — where the Customer takes pre-order payment online — Stripe payment references), the Customer's optional Order & Pay table ordering (a guest's at-table food and drink orders — dishes with any choices, quantities and kitchen notes, the table, any tip, the guest's receipt email and optional name, an 18-or-over confirmation for orders containing alcohol, and Stripe payment references — including recording the guest's marketing preference at the order checkout and creating or updating the Customer's guest profile from a paid order, as with bookings), 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	Guests — anyone who, through the Services, books or joins a waitlist at a Customer's venue, buys an event ticket, places an order, joins the Customer's loyalty scheme, or — where the Customer sells gift cards — buys or receives one (a guest need not have made a booking). Tenant staff — the Customer's staff, added by the Customer to their ResoFlow account. Tenant Owners — the natural person who holds the Customer's signup account. External support contacts — non-tenant senders who email ResoFlow's support aliases.
Categories of Personal Data	Guests: 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; where the Customer offers pre-ordering for larger bookings, the party’s advance dish selections (dishes with any choices and quantities, any per-dish first names the organiser adds, the order total, and — where pre-orders are paid online — Stripe payment references only); where the Customer offers Order & Pay table ordering, a guest’s at-table orders (dishes with any choices, quantities and kitchen notes, the table, any tip, the guest’s receipt email and optional name, an 18-or-over confirmation where an order contains alcohol, and Stripe payment references only); a guest’s marketing preference (recorded when they book or order, or when a gift card buyer ticks the optional opt-in box at the gift purchase page, together with consent-evidence records of when and where the choice was made, the wording shown, and the choice); the profile the Customer keeps about a guest (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); where the Customer runs a loyalty scheme, membership records for guests who join it (status and join details including a random member code, stamp / points balances and lifetime totals, a per-event ledger of earns, redemptions and named-staff adjustments, the single bill amount entered by staff for a visit on spend-based schemes, and a device identifier + push token where a member saves their loyalty card to a device wallet, used only to keep the card updated); where the Customer runs promotions, per-guest offer-code usage history and one-way-hashed anti-abuse counters for per-person limits; where the Customer sells gift cards, per-card records involving up to two data subjects — the buyer (name and email; optional for at-venue sales) and the recipient (name, email, and the buyer’s personal message) — together with the card’s value, balance and movement history, expiry, a one-way-hashed spendable code, Stripe payment references for online purchases, and a device identifier + push token where a card is saved to a device wallet, used only to keep the pass’s balance updated (the buyer’s guest profile is created or updated from a purchase where their email is held; no customer profile is created for a recipient); 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 guest’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 guest 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 guest 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 and online gift card sales. A no-show fee is charged when the Customer's staff mark a booking as a no-show, or — where the Customer enables it — automatically when a guest cancels after the free-cancellation deadline. Stripe acts as a Sub-processor (see Annex 3); the Processor does not see, store, or process the guest's card details. The deposit and no-show fee are paid to the Customer; the Processor may deduct a platform fee from the no-show fee (no platform fee is charged on booking deposits), as shown in the Customer's dashboard.

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. Multi-factor authentication is available to all Owner accounts and strongly encouraged; 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 stored for 24 months on every plan (how far back they can be viewed in-app varies by 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 in accordance with section 7 of this DPA.