Data Processing Addendum

This Addendum forms part of the agreement between TableGo Ltd ("TableGo", "we", "us"), 276 Chase Road, Suite 7-0110 Lonsto House, London, N14 6HA, United Kingdom, and the restaurant business using the TableGo Service ("you") under our Business Terms of Service (the "Terms"). It applies whenever we process personal data on your behalf, and meets Article 28 of the UK GDPR.

1.1 You are the controller and we are your processor for the personal data described in Annex 1 ("your personal data").

1.2 We are a controller, not your processor, for our own purposes described in our Privacy Policies: your account, billing, security, fraud prevention and running our websites, and the record of email addresses that cannot receive email described in clause 13.6(k) of the Terms.

2.1 We process your personal data only on your documented instructions, unless the law requires otherwise; in that case we will tell you before processing, unless the law forbids it. Your instructions are: the Terms, this Addendum, your settings in the Service, and the actions of your Authorised Users in the Service, including our support account while it is a member of your Team (clause 13.7 of the Terms).

2.2 We will tell you straight away if we think an instruction breaks the UK GDPR or other data protection law.

Everyone we authorise to process your personal data is bound by a duty of confidentiality.

4.1 We maintain the technical and organisational measures in Annex 2. We may change them, provided the overall level of protection does not fall.

4.2 You are responsible for the measures under your control, including who you invite to your Team, their roles, and the security of their devices and passwords.

5.1 You give us general written authorisation to use the sub-processors listed at https://business.tablego.uk/subprocessors (Annex 3).

5.2 We will tell you of any intended addition or replacement of a sub-processor at least 30 days before it starts processing your personal data, by email to your venue's Owner and on that page. You may object on reasonable data protection grounds within that period by emailing support@tablego.uk. If we cannot resolve your objection, you may stop using the affected feature, or the Service, before the change takes effect.

5.3 Each sub-processor is bound by a written contract with data protection terms that give at least the protection required by Article 28(3) of the UK GDPR. We remain responsible to you for our sub-processors' performance.

6.1 Taking into account the nature of the processing, we will help you respond to requests from individuals to exercise their rights, including access, correction, erasure and objection to direct marketing. You can ask us by email to support@tablego.uk to find, export, correct or delete a guest's data; we do this for you.

6.2 We will pass on to you without undue delay any request, complaint or objection we receive that concerns your processing. An objection to your marketing that reaches us is also recorded as an opt-out for your venue without undue delay, so that it is respected at once in campaigns sent through TableGo (Annex 1A).

6.3 Taking into account the nature of the processing and the information available to us, we will help you meet your obligations on security, personal data breach notification, data protection impact assessments and prior consultation with the Information Commission.

We will tell you without undue delay after becoming aware of a personal data breach affecting your personal data, with the information we have at that time, and update you as we learn more.

8.1 When you stop using the Service, we will delete your personal data or return it to you, at your choice, unless the law requires us to keep it. Ask by email to support@tablego.uk.

8.2 On request we will also give you your guests' newsletter opt-in and opt-out records, so that you can keep respecting their choices.

8.3 A diner's contact record that another venue on TableGo also holds (Annex 2, item 3) is kept for that other venue, without your venue's data.

8.4 Deleted data remains in our database provider's backups until those backups expire, currently after about one week.

We will make available to you the information necessary to demonstrate compliance with Article 28 of the UK GDPR, and allow for and contribute to audits, including inspections, by you or an auditor you appoint. You will give us reasonable notice. Audits take place no more than once in any 12 months unless a regulator requires one or after a personal data breach affecting your personal data. Each party bears its own costs.

We transfer your personal data outside the UK only with the safeguards the UK GDPR requires. Annex 3 shows where each sub-processor processes personal data and the safeguard used.

You are responsible for having a lawful basis for your processing, for giving diners the privacy information the law requires, and for making sure your instructions are lawful. For Marketing, clause 13.6 of the Terms also applies.

12.1 This Addendum applies for as long as we process your personal data.

12.2 Liability under this Addendum is governed by the Terms.

12.3 If this Addendum conflicts with the Terms on a data protection matter, this Addendum prevails.

We may update this Addendum, for example when the law changes or we add a feature. We will give you at least 30 days' notice of a material change by email to your venue's Owner, unless the law requires a change sooner. A change will not reduce the protection of your personal data.

Nature and purpose: hosting and operating the Service for you: taking, storing, changing and displaying the records below, sending emails on your behalf, and producing the reports and exports you request.

Duration: for as long as you use the Service, then section 8.

Frequency: continuous.

1. Hosting and location. Production data is held in a managed PostgreSQL database (Supabase) in Amazon Web Services' London region. Both TableGo applications run on Vercel, with server functions in London; requests reach them through Vercel's global edge network. Our test environment is a separate database project.
2. Encryption. All traffic to the Service uses TLS. Our database provider encrypts stored data (AES-256). Full card numbers and security codes are entered only on Stripe-hosted pages and are never received or stored by TableGo; we store Stripe references.
3. Access control for your users. Access is role-based (Owner, Manager, Staff, Viewer) and denied by default. Roles are enforced in the application and in the database through row-level security. In the database, Viewers cannot change venue data or read guest contact details, payments, vouchers or guest notes, and Staff cannot change opening hours, availability, service periods, tables and floor plans, booking and payment policies or voucher products. Some sensitive columns are hidden from all client access, and email logs, security tokens and bank details are reachable only by our servers. Team invitations are single-use, expire, and can be accepted only by the invited email address.

Diner contact records. A diner's contact details (name, email address and phone number) are held in one record per diner. If the same diner books with more than one venue on TableGo, the Owners, Managers and Staff of each of those venues can see and update that record. Bookings, visit history, notes, tags and newsletter choices are kept separately for each venue.

1. Authentication. Sign-in uses email and password with email verification. Two-factor authentication (authenticator app) is available to every user and, once a user has turned it on, is enforced by both the application and the database. Two-factor authentication is optional. Business sign-up uses bot protection. The sign-up and password-reset forms check new passwords against a public list of breached passwords.
2. TableGo staff access. Internal tools are restricted to named internal administrators. Our support account is added to each new venue's Team as a Manager so that we can help; the venue's Owner can see it in the Team list and its activity log and can remove it at any time. Production database changes follow a test-environment-first process with a migration record, verification scripts and rollback instructions.
3. Logging and monitoring. Team changes are recorded in an audit log the venue Owner can see. Booking changes are recorded in a booking history. Marketing settings and controls are recorded in an append-only audit log. Integration and monitoring logs are deleted after 14 to 30 days. Automated health checks run every two minutes.
4. Integrations and secrets. Payment webhooks are signature-verified; other server-to-server calls are authenticated with secrets; some operational secrets are held in an encrypted secret store.
5. Backups and recovery. The production database is backed up daily by our database provider, and backups are kept for about one week. Point-in-time recovery is not enabled. Application releases can be rolled back.
6. Secure development. Changes are tested on the separate test environment first. Automated tests cover role-based access rules, and database security changes are verified with scripts before release.
7. Data minimisation. Rate-limit counters store keyed hashes, not IP or email addresses. Security tokens are removed from booking activity logs. Marketing suppression and event records store a coded (hashed) form of the email address.
8. Marketing controls. Campaigns are sent only from the venue's own verified domain. Opted-out and suppressed addresses are blocked by the database at send time, and nobody can override the block. Opens and clicks are not tracked. Each guest receives at most one campaign from a venue in any 72 hours. Complaint and bounce rates are monitored per venue and across the platform, and sending pauses automatically when a threshold is crossed. A platform-wide switch can stop all sending at once.
9. Incidents. We assess security incidents and tell you without undue delay of any personal data breach affecting your personal data.

The current list, with what each sub-processor does, the personal data it receives, where it processes it and the transfer safeguard, is published at https://business.tablego.uk/subprocessors and updated under section 5.