# Data Processing Agreement

SAVV8 LIMITED (trading as AtTable) — company number 16906390

Last updated: 24 August 2026

> **Draft for review.** This document has not been reviewed by a qualified solicitor, and the annexes contain items marked [CONFIRM] that must be verified against live infrastructure before publication. See the notes at the end.

## 1. Scope and relationship to other agreements

This Data Processing Agreement (the "**DPA**") applies where **SAVV8 LIMITED**, a company registered in England and Wales under number 16906390, trading as **AtTable** ("**Processor**", "**we**"), processes personal data on behalf of a customer ("**Controller**", "**you**") in the course of providing the AtTable platform.

This DPA forms part of, and is incorporated into, the [Terms of Service](/terms) or any Master Service Agreement between the parties (the "**Principal Agreement**"). Where this DPA conflicts with the Principal Agreement on the processing of personal data, **this DPA prevails**.

No signature is required for this DPA to take effect: it applies automatically from the moment you begin using the platform. A countersigned copy is available on request from legal@attable.io for customers whose procurement process requires one.

## 2. Definitions

Terms used in this DPA have the meanings given in the UK GDPR. In addition:

- **Data Protection Law** — the UK GDPR, the Data Protection Act 2018, the Privacy and Electronic Communications Regulations 2003, and, where applicable to processing under this DPA, the EU GDPR.
- **Customer Personal Data** — personal data contained in Customer Data that AtTable processes on the Controller's behalf.
- **Guest** — an individual who interacts with the Controller's venue through the platform.
- **Sub-processor** — a third party engaged by AtTable to process Customer Personal Data.
- **UK Addendum** — the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses, issued by the ICO under section 119A of the Data Protection Act 2018.

## 3. Roles of the parties

The Controller is the controller of Customer Personal Data. AtTable is the processor.

The Controller is responsible for the lawfulness of the personal data it and its Guests submit, including for providing privacy information to Guests and obtaining any consent required. The Controller warrants that it has a lawful basis for the processing it instructs.

**Where AtTable acts as a controller in its own right.** AtTable is an independent controller — and this DPA does not apply — for: account administration and authentication of the Controller's staff users; billing and collection of fees; security monitoring, fraud prevention and audit logging; support correspondence; and the generation of aggregated, anonymised statistics that cannot be attributed to the Controller, any venue or any individual. That processing is described in our [Privacy Policy](/privacy).

## 4. Processing instructions

AtTable will process Customer Personal Data only:

- on the Controller's documented instructions, which comprise this DPA, the Principal Agreement, and the configuration choices the Controller makes in the platform; and
- as required by law, in which case AtTable will inform the Controller of the legal requirement before processing, unless that law prohibits it on important grounds of public interest.

**AtTable will not** sell Customer Personal Data, use it for its own marketing, or use it to train general-purpose machine learning models.

If AtTable considers an instruction to infringe Data Protection Law, it will inform the Controller without undue delay and may suspend that processing.

## 5. Confidentiality

AtTable ensures that persons authorised to process Customer Personal Data are bound by an obligation of confidentiality, are trained on their data protection responsibilities, and have access only to the data their role requires.

## 6. Security

AtTable implements and maintains the technical and organisational measures described in **Annex II**, having regard to the state of the art, the costs of implementation, and the nature, scope, context and purposes of processing, as required by Article 32 UK GDPR.

AtTable may update those measures, provided the overall level of security is not reduced. The measures in Annex II are those actually deployed; where a control is planned but not yet live, Annex II says so.

## 7. Sub-processors

### 7.1 General authorisation

The Controller gives AtTable **general written authorisation** to engage sub-processors, subject to this clause. The current sub-processors are listed in **Annex III**.

### 7.2 Obligations on AtTable

AtTable will:

- impose on each sub-processor, by written contract, data protection obligations no less protective than those in this DPA;
- carry out due diligence on each sub-processor before engagement; and
- remain **fully liable to the Controller** for the performance of each sub-processor's obligations.

### 7.3 Changes and the right to object

AtTable will give the Controller at least **30 days' notice** before adding or replacing a sub-processor, by email to the Controller's registered administrative contact and by updating the list published at https://attable.io/security.

The Controller may object on reasonable data protection grounds within that 30-day period. The parties will discuss the objection in good faith. If it cannot be resolved, AtTable will use reasonable endeavours to make an alternative available; if it cannot, the Controller may terminate the affected part of the Services without penalty and receive a pro rata refund of fees paid in advance for the unexpired period.

## 8. Assistance with data subject rights

Taking into account the nature of the processing, AtTable will assist the Controller by appropriate technical and organisational measures, insofar as possible, in fulfilling its obligation to respond to requests from data subjects.

**In practice this means:**

- the platform provides self-service export and erasure functions the Controller can operate itself, described in clause 8.1;
- where a data subject contacts AtTable directly about data AtTable processes on the Controller's behalf, AtTable will **not respond substantively**. It will forward the request to the Controller without undue delay, and tell the data subject it has done so;
- AtTable will provide reasonable additional assistance on request. Assistance beyond the self-service functions may be charged at AtTable's then-current professional services rate, save where the need arises from AtTable's own breach.

### 8.1 Self-service functions available to the Controller

- **Guest erasure.** The Controller's owner, admin or manager users can erase an individual Guest's record. Erasure removes the Guest's name, email address, phone number and stored preferences, deletes the identity links and email subscription, and unlinks the Guest from historical orders, leaving an anonymised transaction record the Controller needs for its own accounting and statutory record-keeping.
- **Staff account erasure.** A staff user may request deletion of their own account. Deletion is scheduled **30 days** after the request, during which it can be cancelled, and is then carried out automatically. Authentication credentials are destroyed; the underlying record is scrubbed to a non-identifying tombstone so that audit and financial records required for legal claims remain intact, as permitted by Article 17(3)(e).
- **Staff data export.** A staff user can export their own data in machine-readable form.

> **Known limitation, disclosed deliberately.** The self-service staff export currently returns the most recent **100 sessions and 100 orders** rather than the complete history. Where a data subject access request requires the full record, contact privacy@attable.io and we will produce it manually within the statutory period. There is at present **no self-service export function for Guest records**; Guest access requests are fulfilled by AtTable on the Controller's instruction.

## 9. Assistance with the Controller's wider obligations

AtTable will assist the Controller, taking into account the nature of processing and the information available to it, with:

- security of processing (Article 32);
- notification of a personal data breach to the ICO (Article 33) and to data subjects (Article 34);
- data protection impact assessments (Article 35); and
- prior consultation with the ICO (Article 36).

## 10. Personal data breach

AtTable will notify the Controller **without undue delay, and in any event within 48 hours**, of becoming aware of a personal data breach affecting Customer Personal Data.

The notification will include, to the extent known: the nature of the breach and the categories and approximate number of data subjects and records concerned; the likely consequences; the measures taken or proposed; and a contact point. Where the information is not all available at once, AtTable will provide it in phases without undue further delay.

AtTable will not notify the ICO or data subjects on the Controller's behalf unless the Controller instructs it in writing, since the notification obligation under Articles 33 and 34 rests with the Controller.

To report a suspected breach or vulnerability to AtTable: **security@attable.io**.

## 11. Deletion and return

On termination or expiry of the Principal Agreement, AtTable will, at the Controller's election:

- make Customer Personal Data available for export in a structured, commonly used, machine-readable format for **90 days** after termination; and
- delete Customer Personal Data at the end of that period.

AtTable may retain Customer Personal Data where required by law. Data retained on that basis remains subject to this DPA, is not processed for any other purpose, and is deleted when the retention requirement ends.

Backups are overwritten on a rolling cycle. Personal data present in backups is deleted in the ordinary course of that cycle rather than extracted individually; until then it remains subject to the security measures in Annex II. The current backup retention period is set out in Annex II.

## 12. Audit

AtTable will make available to the Controller the information necessary to demonstrate compliance with Article 28, and will allow for and contribute to audits, including inspections, conducted by the Controller or an auditor it mandates.

The parties agree that:

- AtTable will respond to a reasonable written information request, including a completed security questionnaire, within **30 days**, and this will ordinarily satisfy the Controller's audit right;
- an on-site inspection may be requested no more than **once in any 12-month period**, except following a personal data breach affecting the Controller, on at least **30 days' notice**, during business hours, subject to confidentiality undertakings, and conducted so as not to disrupt AtTable's business or the data of other customers;
- the Controller bears its own costs and AtTable's reasonable costs of an on-site inspection, save where the inspection reveals a material breach by AtTable, in which case AtTable bears its own costs.

## 13. International transfers

AtTable will not transfer Customer Personal Data outside the United Kingdom unless it has taken measures necessary to ensure the transfer is lawful, which may include:

- transferring to a country covered by **UK adequacy regulations**;
- entering into the **UK Addendum** to the EU Standard Contractual Clauses, or the ICO's **International Data Transfer Agreement (IDTA)**; and
- carrying out and documenting a **transfer risk assessment**.

Where the EU GDPR applies to a transfer, the parties will rely on the EU Standard Contractual Clauses, module two (controller to processor), which are incorporated by reference.

The destination and safeguard for each sub-processor are set out in **Annex III**. **AtTable processes Customer Personal Data in the United States as part of ordinary service delivery**, as identified in Annex III; the Controller acknowledges this in agreeing to this DPA.

## 14. Liability

Each party's liability under this DPA is subject to the limitations and exclusions in the Principal Agreement, save that nothing in this DPA or the Principal Agreement limits either party's liability to a data subject or to a supervisory authority.

Where one party pays compensation for damage caused by processing, it is entitled to claim back from the other the part of the compensation corresponding to that other party's share of responsibility, in accordance with Article 82(5) UK GDPR.

## 15. Term, changes and governing law

This DPA takes effect when the Controller begins using the Services and continues until AtTable has ceased all processing of Customer Personal Data and completed deletion under clause 11.

AtTable may update this DPA where necessary to reflect a change in law, a regulator's guidance, or a change in the Services, provided the change does not reduce the protection afforded to data subjects. Material changes will be notified at least **30 days** in advance.

This DPA is governed by the law of England and Wales, and the parties submit to the exclusive jurisdiction of the courts of England and Wales.

---

# Annex I — Details of the processing

**Subject matter.** Provision of the AtTable hospitality platform, comprising QR and online ordering, table service and payments, bookings and reservations, menu management, inventory and supplier management, team and shift management, and analytics.

**Duration.** For the term of the Principal Agreement, plus the export and deletion periods in clause 11.

**Nature of the processing.** Collection, recording, organisation, structuring, storage, retrieval, consultation, use, transmission, restriction, erasure and destruction, by automated means.

**Purpose.** To provide the Services to the Controller and to enable the Controller to serve its Guests.

### Categories of data subject

- Guests of the Controller's venues, including those who order, book, pay, or supply delivery details
- The Controller's staff, including owners, managers, servers, kitchen and crew
- The Controller's supplier contacts
- Individuals named in bookings by a Guest, such as a named celebrant

### Categories of personal data

- **Identity and contact** — name, email address, telephone number, display name
- **Booking data** — booker name, email, telephone, party size, date of birth of a named celebrant where the Guest supplies it, booking notes
- **Order and transaction data** — items ordered, amounts, timestamps, table and session records, receipt codes, payment status, refund records, and the payment provider's transaction reference
- **Delivery data** — delivery address, postcode, geographic coordinates, delivery notes
- **Guest preferences** — stated dietary preferences and excluded allergens, taste preferences, visit and spend history
- **Staff employment data** — role, permissions, shift and attendance records, staff identification code hash
- **Technical data** — device identifier, IP address, browser and device information, session logs, audit records of access to personal data

**No payment card data.** Card numbers, expiry dates and security codes are captured directly by the payment provider in its own hosted fields and **are never transmitted to or stored by AtTable**. AtTable holds only the provider's transaction reference, the amount, and the payment status. See Annex II.

### Special category data

AtTable does not require special category data. However, dietary preferences, allergen exclusions and free-text booking notes supplied by a Guest **may reveal data concerning health or religious belief**. Where they do, that data is treated as special category data, processed solely to fulfil the Guest's order or booking, on the basis established by the Controller with the Guest.

The Controller is responsible for ensuring it has a condition under Article 9 UK GDPR and Schedule 1 of the Data Protection Act 2018 for that processing, and for not soliciting special category data it does not need. Free-text fields are not machine-parsed by AtTable for health information.

### Frequency of processing

Continuous, for the duration of the Principal Agreement.

---

# Annex II — Technical and organisational measures

These are the measures actually in place. Where a control is commonly asked about and **is not** implemented, it is listed as such rather than omitted.

### Access control

- Role-based access control across the platform. Staff see only what their role permits; refunds, payment provider connection and member management are restricted to owner, admin and manager roles.
- Row-level security is enabled on all application database tables as a defence-in-depth backstop behind the application's own authorisation layer.
- Staff and administrator identification codes are stored as **scrypt** hashes with a per-record salt and verified in constant time. Account passwords are handled by our authentication provider and are never stored by AtTable in any form.
- Compromised-password screening is enabled against known breach corpora on all environments.
- Optional IP allowlisting is available to organisations that want to restrict access to their own networks.
- Administrative access to production is limited to named personnel and is logged.
- **Multi-factor authentication is not currently offered** on staff accounts. It is on our roadmap. Controllers for whom MFA is a requirement should raise it before contracting.

### Encryption

- **In transit** — TLS for all connections to the platform and between the platform and its sub-processors, with HTTP Strict Transport Security enforced on the web application.
- **At rest** — database and file storage encryption is provided by our hosting and storage sub-processors.
- **Application-layer encryption** — payment provider access credentials are additionally encrypted at the application layer using **AES-256-GCM** with authenticated encryption and a per-record nonce.
- Sensitive values are excluded from application logs by an enforced redaction denylist covering card numbers, security codes, bank details and national identifiers.

### Segregation and tenancy

- Customer data is logically segregated by organisation and venue, and every data access path is scoped to the requesting organisation. Cross-tenant identifier probing returns "not found" rather than "forbidden", so record identifiers cannot be enumerated across customers.
- Development, staging and production run as separate isolated environments. **Production personal data is not copied into development or staging.**

### Logging and monitoring

- Access to personal data is recorded in an access log capturing the accessor, the category of data, the reason, the IP address and the user agent.
- Administrative actions, billing changes, money movements including refunds, and any administrative impersonation of a customer account are recorded in immutable audit logs.
- Application errors and performance are monitored continuously. Error reporting is configured **not** to transmit personally identifying information by default.
- Consent changes are written to an append-only consent history by database trigger.

### Resilience and availability

- Managed Postgres with automated backups and point-in-time recovery provided by our database sub-processor. Backup retention: **[CONFIRM — set from the Supabase plan in force]**.
- Rate limiting is applied across authentication, payment, refund, booking-code and receipt-lookup paths, backed by a shared store so limits hold across application instances.
- Inbound webhooks from payment and integration providers are cryptographically signature-verified against the raw request body before processing.
- Idempotency keys prevent duplicate processing of payments and refunds on retry.

### Data minimisation and retention

- Guests are not required to create an account to order.
- Session IP addresses are erased **30 days** after the session expires.
- Attendance evidence stores a salted hash of the IP address rather than the address itself.
- Expired sessions holding no order, unaccepted invitations, anonymous device taste profiles, low-confidence guest records with no order history, and outbound message logs are purged automatically on scheduled jobs. The applicable periods are published at https://attable.io/gdpr.
- Access and security logs are purged after 12 months. Contacts who unsubscribed from a venue's marketing are stripped back to a bare suppression record after two years, retaining only the address needed to keep them suppressed.
- Analytics session recording masks all form input by default and is only active where the visitor has consented to analytics cookies.

### Organisational measures

- Confidentiality obligations in all staff and contractor contracts.
- Access on a least-privilege, need-to-know basis, reviewed when a role changes.
- Documented incident response process with a published reporting address.
- A security assessment of the platform was completed in **August 2026**, covering authorisation, tenancy isolation, database privilege and mail authentication. Findings were remediated and re-verified. A summary is available under NDA on request.
- Automated pre-deployment checks for database privilege regressions, row-level-security coverage, cross-tenant access defects and schema drift. **[CONFIRM — these checks are currently not enforcing on every deployment path; do not represent them as gating until that is fixed.]**

### Not claimed

For the avoidance of doubt, as at the date of this document AtTable does **not** hold ISO/IEC 27001 certification, a SOC 2 Type I or Type II report, or Cyber Essentials certification, and does not claim any of them. Nor does AtTable claim a PCI DSS certification; its position on cardholder data is that card data never enters its systems, as described below.

### Payment card data

Card details are entered directly into fields hosted and served by the payment provider — Stripe, Square or Clover in the online flow, or the physical card terminal in the card-present flow. Those fields are not accessible to AtTable's application. AtTable receives only a provider-issued token or transaction reference.

No database column for a card number, expiry date or security code exists anywhere in the platform. Strong customer authentication challenges are handled between the Guest's browser and the payment provider.

The effect is that cardholder data remains within the payment provider's environment and AtTable's systems stay outside cardholder data scope. Controllers requiring a formal scope determination should obtain one from their acquirer.

---

# Annex III — Sub-processors

Current as at **24 August 2026**. The live list is maintained at https://attable.io/security.

Locations marked [CONFIRM] must be verified against the live infrastructure before this annex is published.

### Infrastructure and hosting

- **Supabase** — managed Postgres database, authentication, realtime. Primary store for all Customer Personal Data. Location: European Economic Area (Ireland) [CONFIRM — production project region must be verified; only the development project is evidenced as eu-west-1]. Safeguard: adequacy / IDTA as applicable.
- **Vercel Inc.** — hosting of the web application. **Serverless functions execute in the United States (US East).** Customer Personal Data passes through this environment in the request path. Safeguard: **UK Addendum / IDTA**, supported by a transfer risk assessment.
- **Railway** — hosting of the application programming interface. Location: [CONFIRM]. Safeguard: [CONFIRM].
- **Redis** (managed cache, rate limiting and job queues) — provider and location: [CONFIRM].

### Payments

- **Stripe** — online card payments and platform billing. The Controller is the merchant of record on its own connected account. Stripe acts as an **independent controller** for cardholder data under its own terms, not as AtTable's sub-processor for it.
- **SumUp** — card-present terminal payments, where the Controller uses SumUp.
- **Square** — payments and point-of-sale integration, where the Controller uses Square.
- **Clover** — payments and point-of-sale integration, where the Controller uses Clover. Configured against EU endpoints.

Payment providers are engaged only where the Controller connects them. Each processes cardholder data as a controller in its own right under its own agreement with the Controller.

### Communications

- **Resend** — transactional email, including receipts, invitations and account notifications. Delivery is routed via Amazon Simple Email Service. Processes recipient name and email address.

### Media

- **Cloudinary** — storage and delivery of images uploaded by the Controller, such as dish and venue photographs. Location: [CONFIRM].

### Analytics and monitoring

- **PostHog** — product analytics, feature flags and session replay. Hosted on **PostHog EU Cloud**. Session replay masks all form input; analytics are active only where the visitor has consented.
- **Sentry** — error and performance monitoring. Configured not to send personally identifying information by default; IP addresses and technical context may nonetheless be present in error payloads. Region: [CONFIRM — US or EU Sentry].

### Artificial intelligence

- **OpenAI** — generation of menu descriptions, menu import and parsing, menu translation, and responses in the operator and Guest assistants. Free-text a Guest types into the assistant is transmitted to OpenAI.
- **Anthropic** — the same functions, as an alternative or fallback provider.

Both providers are engaged under terms that exclude the use of submitted content for model training [CONFIRM — verify the API terms in force and that no data-sharing or model-improvement setting is enabled on the account].

### Third-party data sources

- **Google** (Places API) — retrieval of a venue's public rating and reviews at the Controller's request. Processes venue identifiers and returns publicly available review content. Cached for no more than 30 days.
- **Companies House** — verification of a UK company number during onboarding. Processes a company number and business details, not Guest data.

### Under review

- **ip-api.com** — approximate geographic location of an IP address, used to detect anomalous multi-location access to a Controller's account. Receives the IP address of a staff or Guest session.

> **This entry is flagged for removal.** The request is currently made over an unencrypted connection to a provider engaged without a data processing contract, and represents an international transfer without a documented safeguard. It should be replaced with a local geolocation database or an equivalent contracted provider before this DPA is published. It is listed here because omitting a sub-processor that genuinely receives personal data would make this annex inaccurate.

### Not engaged

The following appear in the platform's source code but are **not** active sub-processors, because no credentials are configured and no data is sent to them: Twilio, SendGrid, Cloudflare Turnstile, Toast, Lightspeed and Deliverect. They will be added to this list, with 30 days' notice, if and when they are activated.

---

## Notes for AtTable — remove before publishing

Before this document goes live or is sent to a customer, the following must be resolved. Each is a statement of fact that is currently unverified or known to be inaccurate, and publishing it as-is would be a misrepresentation to customers and to the ICO.

1. **Confirm the production Supabase region.** Only the development project is evidenced as eu-west-1. Do not assert EEA residency for production data until confirmed in the Supabase dashboard.
2. **Confirm Railway's region, the Redis provider and region, Sentry's region, and Cloudinary's region.**
3. **Confirm the backup retention period** from the Supabase plan in force and write it into Annex II.
4. **Resolve ip-api.com.** Sending IP addresses in clear text to an uncontracted third party is a live compliance defect, not a drafting problem. Remove the dependency or contract for it properly, then update Annex III.
5. **Confirm the OpenAI and Anthropic account settings** actually exclude submitted content from training, and record the API terms version relied on.
6. **Fix or soften the pre-deployment checks claim in Annex II.** The checks exist but are not currently enforcing on every deployment path.
7. **Complete the ICO registration** and add the registration number to the GDPR page.
8. **Have a solicitor review this document,** particularly clauses 12 and 14, before it is offered for signature.

Resolved: published retention periods now derive from the same constants the cleanup jobs enforce, so the two cannot diverge. Access and security logs are purged at 12 months, marketing contacts are minimised to a bare suppression record two years after unsubscribing, and dormant accounts are erased at three years after a warning email. Categories that are deliberately never purged on a schedule — consent records above all — are published as exactly that.

Outstanding on this point: dormant-account erasure ships switched off and must be enabled deliberately per environment. While it is off, the published policy states that dormant accounts are not automatically deleted, which is accurate; enabling it flips the published statement too.