Data Processing Agreement

Parties

This Data Processing Agreement (“DPA” or “Agreement”) is entered into between:

Data Controller: The restaurant business or individual who has entered into a subscription agreement with Seatly Software Ltd for use of the Seatly booking platform (“Controller”, “you”, or “Restaurant Client”).

Data Processor: Seatly Software Ltd, a company incorporated in England and Wales (“Processor”, “Seatly”, “we”, or “us”).

Together referred to as the “Parties.”

This DPA forms part of and supplements the Seatly Terms of Service (“Principal Agreement”) between the Parties. In the event of any conflict between this DPA and the Principal Agreement, this DPA shall prevail in respect of data protection matters.

Section 1 — Definitions

In this Agreement, the following terms have the meanings set out below. Terms not defined here shall have the meanings given to them under UK GDPR and the Data Protection Act 2018.

“Applicable Data Protection Law” means the UK General Data Protection Regulation (UK GDPR) as retained in UK law by the European Union (Withdrawal) Act 2018, as amended by the Data Protection, Privacy and Electronic Communications (Amendments etc) (EU Exit) Regulations 2019; the Data Protection Act 2018 (DPA 2018); and any successor legislation or guidance issued by the Information Commissioner’s Office (ICO).

“Controller” means the natural or legal person, public authority, agency, or other body which, alone or jointly with others, determines the purposes and means of the processing of Personal Data — in this Agreement, the restaurant client.

“Data Breach” means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Personal Data transmitted, stored, or otherwise processed by the Processor on behalf of the Controller.

“Data Subject” means an identified or identifiable natural person to whom Personal Data relates.

“DSAR” means a Data Subject Access Request made under Article 15 UK GDPR, or any other Data Subject rights request made under UK GDPR Articles 16–22.

“ICO” means the Information Commissioner’s Office, the UK supervisory authority for data protection.

“Personal Data” means any information relating to an identified or identifiable natural person, as defined in Article 4(1) UK GDPR. The categories of Personal Data processed under this Agreement are described in Annex A.

“Processing” means any operation or set of operations performed on Personal Data or on sets of Personal Data, whether or not by automated means — including collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure, or destruction.

“Processor” means a natural or legal person, public authority, agency, or other body which processes Personal Data on behalf of the Controller — in this Agreement, Seatly Software Ltd.

“Special Category Data” means Personal Data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership; genetic data; biometric data processed for the purpose of uniquely identifying a natural person; data concerning health; or data concerning a natural person’s sex life or sexual orientation, as defined in Article 9 UK GDPR.

“Sub-Processor” means any third party engaged by the Processor to carry out processing activities in respect of the Personal Data on behalf of the Controller.

“UK GDPR” means the General Data Protection Regulation as it forms part of retained EU law by virtue of the European Union (Withdrawal) Act 2018, as amended.

Section 2 — Scope and Purpose

2.1 Subject Matter

The Processor provides the Controller with a white-label, multi-tenant restaurant booking SaaS platform (“Seatly Platform”) comprising:

• A customer-facing booking widget embedded in the Controller’s website
• A staff-facing administration widget for managing bookings and availability
• Automated transactional email notifications (booking confirmations, reminders, cancellation notices)
• Automated text (SMS) reminders and walk-in “table ready” notifications, where the Controller enables them
• Deposit and pre-payment collection via Stripe Checkout, where the Controller enables it

Seatly’s billing of the Controller for its subscription is not processing on the Controller’s behalf. Seatly handles that data as a controller in its own right, as described in its Privacy Policy.

2.2 Purpose of Processing

The Processor processes Personal Data solely for the following purposes:

• Booking management — collecting, storing, and retrieving diner booking records on behalf of the Controller
• Communication — sending transactional emails and text messages to diners regarding their bookings and walk-in visits (confirmations, reminders, cancellations, table-ready notifications)
• Administration — enabling restaurant staff to manage bookings, availability, and table configurations
• Platform operation — maintaining availability, security, and integrity of the Seatly Platform
• Compliance — fulfilling obligations under Applicable Data Protection Law, including DSAR responses and Data Breach notification

2.3 Duration

Processing shall commence on the Effective Date of the Principal Agreement and shall continue until the Agreement is terminated, subject to the survival provisions in Section 10.

2.4 Nature of Processing

Processing activities are described in full in Annex A (Description of Processing).

Section 3 — Obligations of the Processor

The Processor shall:

3.1 Process Only on Instructions

Process Personal Data only on documented instructions from the Controller, including with regard to transfers of Personal Data to a third country or international organisation, unless required to do so by applicable law. In such a case, the Processor shall inform the Controller of that legal requirement before processing, unless prohibited from doing so on grounds of public interest. The instructions in this DPA and the Principal Agreement constitute the Controller’s documented instructions.

3.2 Confidentiality

Ensure that persons authorised to process Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality. The Processor shall ensure that access to Personal Data is limited to personnel who require access for the purposes described in Section 2.

3.3 Security Measures

Implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, in accordance with Article 32 UK GDPR. The Processor’s current security measures are described in Annex B (Technical and Organisational Measures).

3.4 Sub-Processors

Not engage a new Sub-Processor or make a material change to an existing Sub-Processor arrangement without:

(a) providing the Controller with at least 30 days’ prior written notice of the intended change; and

(b) giving the Controller the opportunity to object within that 30-day period. If the Controller objects on reasonable data protection grounds and the Parties cannot reach agreement, the Controller may terminate the relevant service on written notice.

The current list of approved Sub-Processors and their roles are set out in Annex C (Approved Sub-Processors).

3.5 Imposing Equivalent Obligations on Sub-Processors

Ensure that any Sub-Processor engaged under this Agreement is subject to data protection obligations at least equivalent to those imposed on the Processor under this DPA, by way of a written contract. The Processor remains fully liable to the Controller for the performance of any Sub-Processor’s obligations.

3.6 Assistance with DSARs

Taking into account the nature of the processing, assist the Controller by appropriate technical and organisational measures, insofar as possible, for the fulfilment of the Controller’s obligations to respond to Data Subject rights requests under Chapter III UK GDPR. The Processor shall provide the following tools:

• Export function — generate a complete JSON export of all Personal Data held for a named Data Subject, delivered within 5 working days of a written request from the Controller
• Deletion function — permanently anonymise or delete all Personal Data relating to a named Data Subject, with written confirmation of completion within 5 working days of a written request from the Controller

3.7 Assistance with Breach Notification

Assist the Controller in ensuring compliance with the Controller’s obligations under Articles 33 and 34 UK GDPR (notification to supervisory authority and communication to Data Subjects), taking into account the nature of processing and the information available to the Processor. See Section 8 for detailed breach notification obligations.

3.8 Data Return and Deletion on Termination

At the choice of the Controller, delete or return all Personal Data to the Controller after the end of the provision of services relating to processing, and delete existing copies unless applicable law requires storage. See Section 9 for full terms.

3.9 Compliance Information

Make available to the Controller all information necessary to demonstrate compliance with the obligations laid down in this DPA and allow for and contribute to audits, including inspections, conducted by the Controller or an auditor mandated by the Controller, subject to reasonable notice (no less than 30 days) and at the Controller’s cost. The Processor may object to any audit that would, in its reasonable opinion, breach obligations of confidentiality owed to other clients, or compromise platform security.

Section 4 — Obligations of the Controller

The Controller shall:

4.1 Lawful Basis

Ensure that there is a valid lawful basis under Article 6 UK GDPR (and Article 9 for any Special Category Data) for each processing activity described in Annex A before instructing the Processor to process Personal Data.

4.2 Documented Instructions

Ensure that all instructions provided to the Processor are documented, lawful, and consistent with Applicable Data Protection Law. The Controller shall not instruct the Processor to process Personal Data in a manner that would infringe Applicable Data Protection Law.

4.3 Inform Data Subjects

Provide Data Subjects with all required privacy notices under Articles 13 and 14 UK GDPR before their Personal Data is collected through the Seatly Platform. Seatly provides template privacy notice language upon request, but the Controller is responsible for its accuracy and completeness.

4.4 Respond to DSARs

Handle all communications from Data Subjects regarding their rights under UK GDPR, and notify the Processor promptly if the Processor’s assistance is required under Section 3.6.

4.5 Notify Processor of Relevant Requests

Notify the Processor promptly (and in any event within 3 working days) upon receiving any request, inquiry, or complaint from a Data Subject or regulatory authority that concerns or may concern Personal Data processed by the Processor on the Controller’s behalf.

Section 5 — Sub-Processors

5.1 General Authorisation

The Controller hereby grants the Processor general authorisation to engage the Sub-Processors listed in Annex C for the purposes described therein. The Processor shall ensure that each Sub-Processor is bound by written obligations at least equivalent to those imposed on the Processor under this DPA.

5.2 Changes to Sub-Processors

The Processor shall notify the Controller of any intended addition or replacement of Sub-Processors at least 30 days in advance, per Section 3.4. Notice shall be provided by email to the Controller’s registered account address.

5.3 Processor Liability

The Processor remains liable to the Controller for the performance of a Sub-Processor’s data protection obligations as if it were performing those obligations itself. This does not limit any contractual limitation of liability in the Principal Agreement.

5.4 Updated Sub-Processor List

The current approved Sub-Processor list is maintained on the Sub-Processor List page and is updated upon any material change.

Section 6 — International Transfers

6.1 General Restriction

The Processor shall not transfer Personal Data outside the United Kingdom without ensuring that an appropriate safeguard is in place under Chapter V UK GDPR.

6.2 Permitted Transfer Mechanisms

Where Personal Data is transferred to a third country, the Processor shall rely on one of the following mechanisms:

(a) Adequacy regulations — regulations made by the UK Secretary of State specifying that the recipient country, or a territory or sector within it, ensures an adequate level of protection;

(b) UK International Data Transfer Agreement (IDTA) — the standard contractual clauses issued by the Information Commissioner under section 119A of the Data Protection Act 2018, a safeguard under Article 46(2)(d) UK GDPR; or

(c) Standard Contractual Clauses (SCCs) — the European Commission standard data protection clauses as incorporated and adapted for UK purposes by the ICO’s International Data Transfer Addendum to the EU SCCs (the UK Addendum), which the Information Commissioner also issued under section 119A of the Data Protection Act 2018, so they too are a safeguard under Article 46(2)(d) UK GDPR.

6.3 Current Transfer Mechanisms

The transfer mechanisms in use for each Sub-Processor are set out in Annex C. Seatly’s primary database is hosted within the United Kingdom (AWS eu-west-2 London region via Supabase), so storing core booking data involves no international transfer. Supabase’s Edge Functions, which handle requests to the Platform, run in the Supabase region nearest the request, which may be outside the United Kingdom. Some Sub-Processors, including those that deliver email, text messages and payments, do process Personal Data outside the United Kingdom. The mechanism for each is set out in Annex C.

Section 7 — Data Subject Rights

7.1 Controller’s Primary Responsibility

The Controller is the primary point of contact for Data Subjects exercising their rights under UK GDPR Articles 15–22. The Processor assists the Controller in fulfilling those obligations as set out in Section 3.6.

7.2 Export (Subject Access)

Upon written request from the Controller, the Processor shall provide a complete export of all Personal Data held for the identified Data Subject in JSON format within 5 working days. The export shall include all fields described in Annex A that contain data relating to that Data Subject.

7.3 Erasure (Right to Be Forgotten)

Upon written request from the Controller, the Processor shall:

(a) Permanently anonymise or delete all Personal Data fields relating to the identified Data Subject across all systems (including backups within the next scheduled backup cycle); and

(b) Provide written confirmation of completion within 5 working days of the request.

Where data must be retained to comply with a legal obligation (e.g. financial records), the Processor shall inform the Controller of the specific obligation and the minimum retention period.

7.4 Restriction and Portability

Where the Controller instructs the Processor to restrict processing for a specific Data Subject, or to provide data in a portable format, the Processor shall comply within 5 working days and confirm in writing.

Section 8 — Data Breach Notification

8.1 Initial Notification

The Processor shall notify the Controller without undue delay, and in any event within 24 hours of becoming aware of a Data Breach affecting Personal Data processed under this Agreement.

8.2 Content of Notification

The initial notification shall include, to the extent available at the time:

(a) A description of the nature of the Data Breach, including the categories and approximate number of Data Subjects and Personal Data records concerned;

(b) The name and contact details of the Processor’s data protection contact;

(c) A description of the likely consequences of the Data Breach;

(d) A description of the measures taken or proposed to be taken by the Processor to address the Data Breach, including measures to mitigate its possible adverse effects.

Where all information cannot be provided simultaneously, the Processor shall provide it in phases without further undue delay.

8.3 Cooperation

The Processor shall cooperate fully with the Controller to enable the Controller to meet its own notification obligations to the ICO (within 72 hours of becoming aware, where feasible) and to affected Data Subjects where required.

8.4 Breach Register

The Processor shall maintain an internal register of all Data Breaches (whether or not notifiable to the ICO), including the facts, effects, and remedial action taken, and make this available to the Controller on request.

8.5 Controller’s Responsibilities

The Controller remains responsible for determining whether a Data Breach requires notification to the ICO or to affected Data Subjects under Articles 33 and 34 UK GDPR. The Processor’s notification to the Controller under Section 8.1 does not constitute an admission of fault or liability.

Section 9 — Data Return and Deletion

9.1 On Termination

Upon expiry or termination of the Principal Agreement, the Processor shall:

(a) Make available to the Controller a complete export of all Personal Data processed under this Agreement in JSON format within 30 days of the termination date; and

(b) Permanently delete all Personal Data (including copies held in backups, after the next scheduled backup cycle) within 60 days of the termination date, except where applicable law requires continued retention.

9.2 Written Confirmation

The Processor shall provide the Controller with written confirmation of deletion within 5 working days of completing the deletion process described in Section 9.1(b).

9.3 Legal Retention Obligations

Where applicable law requires the Processor to retain certain Personal Data beyond the 60-day period, the Processor shall:

(a) Notify the Controller in writing of the specific legal obligation and the data concerned; and

(b) Ensure that such data is retained securely and not processed for any other purpose.

9.4 Controller’s Own Deletion Obligations

The Controller remains responsible for deleting or anonymising any Personal Data it has exported or holds independently. The Processor’s deletion of its own copies does not relieve the Controller of its own obligations.

Section 10 — Term and Survival

10.1 Term

This DPA shall come into force on the Effective Date of the Principal Agreement and shall remain in force for so long as the Processor processes Personal Data on behalf of the Controller.

10.2 Co-Terminous

This DPA is co-terminous with the Principal Agreement. Termination of the Principal Agreement for any reason shall also terminate this DPA, subject to the survival provisions below.

10.3 Survival

The following sections shall survive termination or expiry of this DPA for a period of 6 years (or such longer period as required by applicable law):

• Section 8 (Data Breach Notification) — in respect of any Data Breach that occurred during the term
• Section 9 (Data Return and Deletion) — until the Processor has confirmed deletion and the deletion period has elapsed
• Section 10 (Term) — this survival clause itself

10.4 Effect of Termination

On termination, all licences and permissions granted under this DPA shall cease. The Controller shall lose access to the Seatly Platform and its administrative tools for export and deletion; it is therefore the Controller’s responsibility to exercise its export rights under Section 9.1 before or promptly after termination.

Annex A — Description of Processing

A.1 Data Subjects

The following categories of Data Subjects are processed under this Agreement:

A.2 Categories of Personal Data

A.3 Special Category Data

The special_requirements field is a free-text field provided to diners to communicate dietary needs, accessibility requirements, or other relevant information to the restaurant. This field may incidentally contain Special Category Data, in particular:

• Health data — e.g. allergy information, mobility requirements
• Religious or philosophical beliefs — e.g. dietary restrictions based on religious practice

The Controller is responsible for:

• Establishing a valid legal basis under Article 9 UK GDPR (typically explicit consent) before collecting this data
• Providing appropriate notice to Data Subjects about the nature of this field
• Ensuring that only relevant information is collected

The Processor shall treat all data in the special_requirements field as Special Category Data for the purposes of security and access controls.

A.4 Processing Operations

A.5 Retention Periods

Retention settings may be adjusted by the Controller via the administration widget or by written request to privacy@seatly.uk.

Annex B — Technical and Organisational Measures

The Processor implements the following technical and organisational measures in accordance with Article 32 UK GDPR to ensure a level of security appropriate to the risk:

B.1 Encryption in Transit

All data transmitted between client browsers and the Seatly Platform is encrypted using TLS 1.2 or higher. Unencrypted HTTP connections are redirected to HTTPS. All API calls between platform components use encrypted connections.

B.2 Encryption at Rest

All Personal Data stored in the Seatly database is encrypted at rest using AES-256 encryption, provided natively by Supabase (Amazon RDS encryption). Backup snapshots are encrypted using the same standard.

B.3 Access Control and Authentication

• Supabase Auth — all user authentication (restaurant staff login) uses Supabase’s managed authentication service, supporting secure password hashing (bcrypt), JWT-based session tokens, and optional multi-factor authentication
• Role-based access control — staff roles limit access to booking data for the Controller’s own restaurant only
• Row Level Security (RLS) — Supabase RLS policies are applied at the database level to enforce per-tenant data isolation; no query can return data belonging to a different restaurant client

B.4 Multi-Tenant Isolation

The Seatly Platform is a multi-tenant system. Personal Data belonging to each Controller is logically isolated from all other Controllers via:

• Database-level RLS policies on every table containing Personal Data
• Tenant-scoped API queries enforced at the application layer
• Regular automated testing of RLS boundaries to verify isolation

No Controller can access, view, or modify another Controller’s data.

B.5 Audit Logging

Material actions affecting Personal Data (creation, modification, deletion, export, status change) are recorded in an audit log. Logs are retained for 36 months — except DSAR accountability records (counts and timestamps only), retained indefinitely under Article 5(2) — and are available to the Controller on request.

B.6 Data Minimisation

The Processor collects only the Personal Data fields necessary for the purposes described in Annex A. The special_requirements field is optional. Phone number collection is optional and configurable by the Controller.

B.7 Backup and Recovery

Supabase performs daily automated backups of the Seatly database. Backups are retained for a minimum of 7 days (standard tier) or 30 days (pro tier). Backups are stored encrypted in the same AWS eu-west-2 region as the primary database.

B.8 Incident Response

The Processor maintains an internal incident response process that includes:

• Platform-level monitoring and alerting provided by our infrastructure provider
• Application audit logging of material actions affecting Personal Data (see B.5)
• Documented escalation procedures for suspected Data Breaches
• Obligation to notify the Controller within 24 hours of becoming aware of a confirmed or suspected Data Breach (see Section 8)
• Post-incident review and remediation

B.9 Personnel Confidentiality

All Seatly personnel and contractors with access to Personal Data are bound by:

• Contractual confidentiality obligations
• Data protection training appropriate to their role
• Access restricted to the minimum necessary for their function (principle of least privilege)

B.10 Vulnerability Management

The Processor maintains a process for identifying, assessing, and remediating security vulnerabilities in the Seatly Platform, including:

• Dependency vulnerability scanning via automated tooling
• Timely application of security patches to platform components
• Security review of material code changes before deployment

Annex C — Approved Sub-Processors

The Controller hereby authorises the Processor to engage the Sub-Processors listed in the Seatly Sub-Processor List, which is maintained as a separate document and incorporated into this DPA by reference:

Sub-Processor List

The Sub-Processor List sets out, for each approved Sub-Processor:

• Name and registered address
• Purpose and scope of processing
• Categories of Personal Data processed
• Data location
• Transfer mechanism (where applicable)
• Link to Sub-Processor’s own DPA

Changes to Approved Sub-Processors

The Processor shall provide the Controller with at least 30 days’ written notice before adding a new Sub-Processor or making a material change to an existing Sub-Processor arrangement. Notice shall be sent to the Controller’s registered account email address. The current version of the Sub-Processor List is dated and versioned; the Controller may request the latest version at any time by contacting privacy@seatly.uk.

Transfer Mechanisms Summary

Current international transfers and their mechanisms are detailed in the Sub-Processor List. In summary:

Contact and Execution

Data Processor contact for data protection matters:

Seatly Software Ltd Email: privacy@seatly.uk

Execution:

This DPA is incorporated into and forms part of the Principal Agreement between the Parties. By accepting the Seatly Terms of Service, the Controller agrees to the terms of this DPA on behalf of their organisation.

Change Log