UK GDPR & Data Protection

1. Our commitment

AtTable is operated by SAVV8 LIMITED, a company registered in England and Wales (company number 16906390). We process personal data in accordance with the UK General Data Protection Regulation (UK GDPR) and the Data Protection Act 2018, and — where we process the data of individuals in the European Economic Area — the EU GDPR.

This page explains our role, what we have built to support data subject rights, and how to exercise them. It sits alongside our Privacy Policy, which describes what data we collect and why, and our Data Processing Agreement, which is the contractual instrument for restaurant customers.

2. Controller or processor — it depends what data

This distinction matters, because it determines who you contact.

2.1 Where AtTable is a processor

For guest data generated at a venue — orders, bookings, dietary preferences, table sessions, delivery addresses, anything a guest submits by scanning a QR code — the restaurant is the controller and AtTable is the processor. We handle that data on the restaurant's documented instructions and for no other purpose.

If you are a guest and you want your data from a particular restaurant erased or exported, the restaurant decides. You can send the request to us and we will route it to them, and we will act on their instruction.

2.2 Where AtTable is a controller

For our own business data we are the controller. That covers:

• restaurant account holders and staff users — names, work emails, roles, login records;
• billing and subscription records;
• security and audit logs, including IP addresses, used to detect and investigate abuse;
• support correspondence; and
• website visitors and marketing contacts.

For anything in this list, contact us directly and we will handle it ourselves.

2.3 Where a restaurant is the controller and we are not involved

A restaurant may hold guest data outside AtTable — a paper diary, a separate loyalty scheme, its own email list. That is nothing to do with us and we cannot act on it.

3. Lawful bases we rely on

• Performance of a contract — providing the platform to a restaurant, and taking and fulfilling a guest's order.
• Legitimate interests — securing the platform, preventing fraud and abuse, product analytics on aggregated data, and business communications with existing customers. We have carried out balancing assessments and will share the relevant one on request.
• Consent — non-essential cookies, marketing email to prospects, and any optional guest personalisation. Consent can be withdrawn at any time without affecting processing already carried out.
• Legal obligation — retaining financial records under the Companies Act 2006 and tax law, and responding to lawful requests from authorities.

We do not rely on consent for anything the platform needs in order to function, and we do not use special category data. Dietary preferences and allergen information a guest chooses to give may reveal health or religious belief; where they do, we treat them as special category data processed on the basis of the guest's explicit consent, given at the point they enter it, and used only to fulfil that guest's order.

4. Your rights

Under UK GDPR you have the right to:

• Be informed — know what is collected and why. That is what the Privacy Policy is for.
• Access — get a copy of your personal data and information about how it is processed.
• Rectification — have inaccurate data corrected and incomplete data completed.
• Erasure — have data deleted where there is no overriding reason to keep it.
• Restrict processing — have processing paused while a dispute over accuracy or legitimate interests is resolved.
• Data portability — receive data you provided in a structured, commonly used, machine-readable format, and have it transmitted to another provider where technically feasible.
• Object — object to processing based on legitimate interests, and object absolutely to direct marketing.
• Not be subject to solely automated decision-making that produces legal or similarly significant effects. We do not carry out such decision-making.

Exercising these rights is free. We may charge a reasonable fee, or refuse, only where a request is manifestly unfounded or excessive, and we will explain why if we do.

5. How to make a request

Email privacy@attable.io with:

• your name and the email address or phone number associated with your data;
• which right you are exercising;
• if your data sits with a restaurant, which venue and roughly when you visited — without that we often cannot find you, because we deliberately do not require guests to create accounts.

Restaurant account holders can also export and delete data directly from account settings, without asking us.

5.1 What happens next

• We acknowledge the request and, where necessary, verify your identity. We ask for the minimum needed to be confident, and we do not use identity documents for anything else.
• We respond within one calendar month. We may extend by up to two further months for complex or numerous requests, and we will tell you within the first month if we do.
• If we are the processor rather than the controller, we forward the request to the relevant restaurant without undue delay and tell you we have done so.
• If we refuse, we tell you why and explain your right to complain.

6. What we have actually built

Data subject rights are implemented in the product, not handled purely by hand:

• Export. A staff or account user can download their own data as a machine-readable file from account settings, immediately and without asking us. It contains the profile, consent record, restaurant memberships, and session and order history.
• Erasure — staff accounts. A user can request deletion from account settings. Deletion is scheduled 30 days ahead and can be cancelled at any point in that window; after it, an automated job carries it out. Login credentials are destroyed, and the underlying record is scrubbed to a non-identifying placeholder so that audit and financial records required for the establishment or defence of legal claims survive, as Article 17(3)(e) permits. Where a user is the sole owner of a restaurant, we ask what should happen to that restaurant before we proceed.
• Erasure — guests. A venue's owner, admin or manager can erase a guest record. This removes name, email, phone number and stored preferences, deletes the identity links and any email subscription, and unlinks the guest from historical orders — leaving an anonymised transaction the venue still needs for its accounts.
• Consent history. Every consent change is appended to an immutable log with the timestamp, IP address and policy version, so what you agreed to and when can always be established.
• Access control and audit logging. Access is role-based, and access to personal data is logged with the accessor, the reason and the context.

6.1 Two limitations we would rather state than hide

• The self-service export is capped at the most recent 100 sessions and 100 orders. For a high-volume account that is not the complete record. If you need everything, email privacy@attable.io and we will produce the full export manually within the statutory period.
• Guests have no self-service export or erasure. Because we deliberately do not make guests create accounts, there is no guest login to attach those functions to. Guest requests are fulfilled by the venue, or by us on the venue's instruction. Send them to privacy@attable.io and we will route them.

Anonymised and aggregated data is not personal data and is not returned or deleted in response to a request, because it can no longer be linked to you.

7. How long we keep data

We keep data for as long as we need it for the purpose we collected it, plus any period the law requires. The periods we actually enforce, by automated purge jobs:

• Session IP addresses — erased 30 days after the session expires.
• Expired table sessions with no order attached — deleted after 30 days. Sessions that anchor an order are kept, with the IP address stripped, because deleting them would destroy the order.
• Anonymous device taste profiles — deleted after 12 months.
• Guest records with no order history and no contact details — deleted after 30 days.
• Outbound message logs — deleted after 90 days.
• Unaccepted invitations — deleted after 7 days.
• Raw analytics events — deleted after 12 months. Aggregated figures, which are not personal data, are kept longer.
• Billing, invoice and plan-change records — kept for seven years, as UK tax and company law require.

Guest records held on behalf of a restaurant are kept for as long as that restaurant instructs, and are deleted or anonymised when the restaurant's account closes and its 90-day export window has passed.

Also deleted on a schedule:

• Access and security logs — deleted after 12 months. Financial and administrative audit trails are separate and kept for seven years, and the record that a data subject request was made and answered is kept separately too, so this does not remove the evidence that we complied.
• Marketing contacts — unsubscribing stops the processing immediately. Two years after unsubscribing, the record is stripped back to the email address alone: name, phone number and engagement history are erased. We keep the address deliberately, so that a later import cannot resubscribe someone who asked us to stop.
• Dormant accounts — where enabled, an account with no sign-in for three years is erased. We email a warning 30 days beforehand, and a single sign-in stops the process and resets the clock. Accounts that are the only administrator of a venue, and accounts attached to a paying subscription, are never swept up this way.

7.1 Where we deliberately do not delete on a schedule

Publishing a retention period that nothing actually applies would be worse than publishing none, so these are stated as they are:

• Consent records — the record of what you consented to, when, and when you withdrew it. Deliberately kept, because Article 7(1) requires us to be able to demonstrate that consent was given: deleting it would destroy the evidence that we were entitled to send what we sent. Consent records are erased when the person they belong to is erased.
• Guest records — kept for as long as the venue instructs, and erased on request.
• Order and payment history — kept for at least seven years as a legal obligation. That is a minimum we must keep, not a date at which records are deleted. Where a guest is erased, the identifying details are removed and the anonymised transaction remains.

The periods on this page are read from the same source as the automated jobs that enforce them, so what we publish here and what the platform actually does are the same thing by construction. The live machine-readable list is served from our API at /api/users/gdpr/retention-policies.

8. International transfers

Our primary database sits in the European Economic Area. However, parts of our web application run on infrastructure in the United States, so requests carrying personal data pass through a US region on their way to the EEA database. We say so plainly because it is the question a data protection adviser will ask, and because burying it would make our transfer disclosures inaccurate.

Where personal data is processed outside the UK, we rely on:

• the UK adequacy regulations, where the destination country has been found adequate; or
• the International Data Transfer Agreement (IDTA) or the UK Addendum to the EU Standard Contractual Clauses, supported by a transfer risk assessment.

The current sub-processor list, with the location of each and the safeguard relied on, is published on our Trust & Security page.

9. Personal data breaches

We maintain an incident response process. Where a breach is likely to result in a risk to people's rights and freedoms:

• if we are the controller, we notify the ICO within 72 hours of becoming aware, and notify affected individuals without undue delay where the risk is high;
• if we are the processor, we notify the affected restaurant customer without undue delay after becoming aware, with the information they need to make their own notification. Contractual timings are in the Data Processing Agreement.

To report a suspected vulnerability or breach, email security@attable.io.

10. Data protection contact

We are not required to appoint a statutory Data Protection Officer, because our core activities do not consist of large-scale systematic monitoring or large-scale processing of special category data. We have nonetheless assigned responsibility for data protection.

• Data protection contact: privacy@attable.io
• Security: security@attable.io
• Post: Data Protection, SAVV8 LIMITED, 71-75 Shelton Street, Covent Garden, London, WC2H 9JQ, United Kingdom
• ICO registration number: [TO BE CONFIRMED]

11. Complaints

If you are unhappy with how we have handled your data, tell us first — privacy@attable.io — and we will try to put it right.

You also have the right to complain to the Information Commissioner's Office, the UK supervisory authority:

• Website: ico.org.uk/make-a-complaint
• Helpline: 0303 123 1113
• Post: Information Commissioner's Office, Wycliffe House, Water Lane, Wilmslow, Cheshire, SK9 5AF

If you are in the EEA, you may complain to your local supervisory authority instead.