Data Processing Terms — Slotina

Last updated: 4 November 2026

These Data Processing Terms ("DPA") form part of the Slotina Terms of Service between the venue and Belavin Limited. They set out the terms required by Article 28(3) of the GDPR and of the UK GDPR.

1. Parties and definitions

1.1 Processor: Belavin Limited (company no. 16735157), 6 Salstar Close, Birmingham, B6 4PP, United Kingdom, trading as Slotina, ICO registration no. 00014129250 ("we", the "Processor"). Privacy contact: hello@slotina.io. Representative in the EU (Article 27 GDPR): Prighter EU Rep GmbH, Schellinggasse 3/10, 1010 Vienna, Austria.

1.2 Controller: the business that has accepted the Slotina Terms of Service and operates a Slotina account (the "venue", the "Controller"), as identified in its account.

1.3 Definitions. "Data Protection Law" means Regulation (EU) 2016/679 (GDPR), the UK GDPR and the Data Protection Act 2018, and any national law supplementing them that applies to a party. "Personal Data", "Processing", "Data Subject", "Personal Data Breach", "Supervisory Authority" and "Sub-processor" have the meanings given in Data Protection Law. "Service" means the Slotina venue console at app.slotina.io, the Slotina app and the guest pages we run for the venue. "Terms" means the Slotina Terms of Service. "Controller Data" means Personal Data that the venue, its team or its guests submit to the Service and that we process on the venue's behalf, as described in Annex I.

1.4 Relationship to the Terms. In case of conflict on a matter of data protection, this DPA prevails over the Terms.

1.5 Two roles. For the venue's account data (logins, billing, the business relationship) we are an independent controller and our Privacy Notice applies. This DPA covers only Controller Data.

2. Subject matter, duration, nature and purpose

2.1 Subject matter: the Processing of Controller Data necessary to provide the Service to the venue.

2.2 Duration: from the venue's acceptance of the Terms until the Controller Data is deleted or returned under clause 5.7.

2.3 Nature: collection through the venue's guest pages, console and app; storage; organisation; retrieval; display to the venue's team; transmission of messages to guests (e-mail; text messages only where the venue switches them on and the Service offers them); transmission to the venue's payment provider; export; anonymisation; erasure.

2.4 Purpose: operating the venue's reservations, waiting list, events and tickets, private dining, pre-orders, pickup and table orders, guest payments, guest book, floor and kitchen screens, team rota, working hours and tips record, sending the messages the venue switches on, and giving the venue its data back on request.

3. Types of data and categories of Data Subjects

The categories of Data Subjects and the types of Personal Data are set out in Annex I. The venue acknowledges that Annex I includes fields — allergies, dietary requirements, accessibility needs, pre-order and order notes, notes on the guest card and free-text answers — that may contain data concerning health, which is special-category data under Article 9 GDPR, and confirms that it has a legal basis under Article 9(2) for collecting such data from its guests before it enters or collects it through the Service.

4. The venue's obligations

4.1 The venue is responsible for the lawfulness of the Controller Data and of its instructions, including an appropriate legal basis, the information it gives its guests and team (it can publish its own privacy notice for guests in the console; the Service links it from every guest form), and honouring Data Subject rights as controller.

4.2 The venue enters only Personal Data that is necessary for the purposes in clause 2.4, and does not use free-text fields for data of a kind the Service is not designed for (identity documents, financial account numbers, data about people who are not its guests or team).

4.3 The venue configures the Service lawfully in its own market: which messages are sent to guests and on what basis, deposit, cancellation and no-show policies, the questions it asks its guests, and the optional features it switches on.

4.4 Where the venue connects a service under its own account and contract — in particular its own Stripe account for guest payments — that provider is engaged by the venue, is not our Sub-processor for the payment it processes for the venue, and the venue is responsible for that relationship. We transmit to it only what the connection requires (Annex I, section 2).

4.5 The venue keeps its logins confidential, assigns roles on a least-privilege basis and removes access for people who leave.

5. Our obligations

5.1 Instructions

5.1.1 We process Controller Data only on the venue's documented instructions, including with regard to transfers to a third country, unless required to do so by law to which we are subject; in that case we inform the venue of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest.

5.1.2 The venue's documented instructions are: (a) the Terms and this DPA; (b) the venue's configuration of the Service in the console and the app; (c) the venue's use of the export, guest-erasure and account-deletion functions; (d) further written instructions agreed by the parties. Instructions that require changes to the Service beyond its documented features are subject to agreement.

5.1.3 We inform the venue immediately if, in our opinion, an instruction infringes Data Protection Law. We are not obliged to carry out a legal review of the venue's processing.

5.1.4 We do not use Controller Data for our own purposes, do not sell it, do not use it for advertising, do not combine one venue's guest data with another's, do not send it to any AI model, and do not use it — or allow any Sub-processor to use it — to train machine-learning models.

5.2 Confidentiality

We ensure that persons authorised to process Controller Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality, and that access is limited to those who need it to provide, support or secure the Service. Access by our staff to a venue's data is logged.

5.3 Security (Article 32)

We implement the technical and organisational measures set out in Annex II and maintain them, or measures giving at least equivalent protection, throughout the term. We may update Annex II provided the level of protection is not reduced.

5.4 Sub-processors

5.4.1 The venue gives general written authorisation to the Sub-processors listed in Annex III, and to the engagement of further Sub-processors under this clause.

5.4.2 We give the venue at least 30 days' prior notice of any intended addition or replacement of a Sub-processor, by e-mail to the owner's login address and by updating the list in our Privacy Notice, stating the Sub-processor's identity, location and function.

5.4.3 The venue may object in writing on reasonable data-protection grounds within that period. The parties will discuss the objection in good faith. If no solution is found, the venue may end the Terms without penalty before the change takes effect; its rights under clause 5.7 apply.

5.4.4 We impose on each Sub-processor, by written contract, data-protection obligations that are substantially the same as those in this DPA. Where a Sub-processor fails to fulfil its data-protection obligations, we remain fully liable to the venue for the performance of that Sub-processor's obligations.

5.5 Assistance with Data Subject rights

5.5.1 Taking into account the nature of the Processing, we assist the venue by appropriate technical and organisational measures, insofar as possible, in responding to requests to exercise Data Subject rights (Articles 15 to 22).

5.5.2 The main means are self-service functions in the Service, free of charge:

• Access and portability (Articles 15 and 20): the venue can export a single guest's data, and its guest book as a CSV file, at any time; on request we provide a complete copy of the venue's data in a machine-readable format.
• Rectification (Article 16): the venue edits guest records directly.
• Erasure (Article 17): the venue can erase a single guest. The guest card is deleted and the guest's details, notes, allergy and dietary notes are removed from the venue's bookings, waiting list, tickets, enquiries and orders; the venue's money records are kept without the guest's name, because the venue has its own legal reasons to keep them.
• Objection (Article 21): every message to a guest contains a link with which the guest stops further messages that are not strictly about a booking; the Service records it.

5.5.3 If a Data Subject contacts us directly about Controller Data, we forward the request to the venue without undue delay, where we can tell which venue it concerns, and do not answer on the merits except as instructed by the venue or required by law.

5.6 Assistance with Articles 32 to 36

We assist the venue in ensuring compliance with its obligations under Articles 32 to 36 (security, breach notification, data-protection impact assessment, prior consultation), taking into account the nature of the Processing and the information available to us.

5.7 Deletion and return of data

5.7.1 At the end of the provision of the Service, we delete or return all Controller Data, at the venue's choice, and delete existing copies, unless Union, Member State or UK law requires storage.

5.7.2 The venue should export its data before the end (clause 5.5.2). When the owner deletes the account in the console or the app (confirmed with the password and a typed confirmation word), all Controller Data is erased at once and irreversibly. Where the Terms end in another way, the venue keeps access to read and export its data for 90 days after the end of its subscription, or for the period stated in clause 15 of the Terms; the data is then erased.

5.7.3 After erasure we keep a deletion record that contains no Controller Data: the venue's name, country, the number of bookings, the account's age, the reason for leaving if one was given, and a shortened hash of the owner's e-mail address. No guest name and no booking survives.

5.7.4 Erased data may persist in the encrypted backups of our database provider for its backup retention period, after which it is overwritten. Backups are not restored to bring back erased data.

5.8 Retention within the Service

The venue decides how long its Controller Data is kept, by erasing guests or deleting its account. In addition, the Service automatically removes the guest's name, contact details and notes from pickup orders 90 days after the pickup time, and deletes entries of the activity log after 2 years.

5.9 Audit

5.9.1 We make available to the venue all information necessary to demonstrate compliance with Article 28 and allow for and contribute to audits, including inspections, by the venue or an auditor it mandates.

5.9.2 Audits proceed in this order: (a) documentation first — this DPA, its Annexes, the sub-processor list and, where available, the Sub-processors' own certifications; (b) written questions, answered within 30 days; (c) an on-site inspection only where required by law or by a Supervisory Authority, or where the documentation demonstrably fails to answer a specific compliance question.

5.9.3 Audits are at the venue's cost, no more than once in any 12-month period (unless a Personal Data Breach affecting the venue has occurred or a Supervisory Authority requires it), on at least 30 days' written notice, during business hours, without unreasonably disrupting the Service, and subject to confidentiality. An audit gives no access to other venues' data.

6. International transfers

6.1 Where the data is. Controller Data is stored in the United Kingdom (database hosting by Neon, London region) and delivered through the application hosting provider's global network. We are established in the United Kingdom.

6.2 Venues in the EU/EEA. Transfers from the venue to us rely on the European Commission's adequacy decision for the United Kingdom (Article 45 GDPR). Should that decision lapse or be invalidated, the parties agree that the Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914, Module Two, controller to processor) apply, incorporated by reference, with the Annexes to this DPA as their Annexes; we will tell the venue of the change.

6.3 Venues in the UK. Processing takes place in the UK; no restricted transfer occurs between the parties.

6.4 Onward transfers. Some Sub-processors in Annex III process data outside the UK and the EEA, in particular in the United States. Each such transfer is protected by the Sub-processor's certification under the EU-U.S. Data Privacy Framework and its UK Extension, or by Standard Contractual Clauses with the UK Addendum, as stated in that Sub-processor's own data-processing terms. We do not add a Sub-processor in a third country that offers no such safeguard.

6.5 We inform the venue if we become unable to comply with this clause 6; the venue may then suspend the affected transfers or end the Terms.

7. Personal Data Breaches

7.1 We notify the venue without undue delay, and in any case within 48 hours, after becoming aware of a Personal Data Breach affecting Controller Data, by e-mail to the owner's login address.

7.2 The notification describes, as far as known at the time and supplemented as information becomes available, the nature of the breach, the categories and approximate number of Data Subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact point.

7.3 We cooperate with the venue and take reasonable steps, as directed by the venue, to investigate, mitigate and remedy the breach. We do not notify Data Subjects or a Supervisory Authority on the venue's behalf unless the venue instructs us to or the law requires it.

7.4 A breach at a Sub-processor is treated as a breach at our end for the 48-hour period, counted from our awareness.

8. Liability

8.1 Each party's liability under or in connection with this DPA is subject to the limitations and exclusions in clause 18 of the Terms, save where liability cannot be limited by law. The parties' liability to Data Subjects under Article 82 GDPR is not limited by this clause.

8.2 The venue indemnifies us against fines, claims and costs arising from its own breach of Data Protection Law, in particular from collecting Personal Data without a legal basis.

9. Term and termination

9.1 This DPA takes effect when the venue accepts the Terms and remains in force for as long as we process Controller Data.

9.2 The end of the Terms ends this DPA, subject to clause 5.7 (deletion and return) and clause 7 (breach notification for events before erasure), which survive.

10. Governing law

This DPA is governed by the law that governs the Terms (clause 20 of the Terms). Nothing in this clause deprives a party of the mandatory protection of the Data Protection Law of its place of establishment, or a Supervisory Authority of its competence.

Annex I — Description of the Processing

1. Categories of Data Subjects

2. Types of Personal Data

Guests

• Identity and contact: name, e-mail address, telephone number, language.
• Guest card: tags, notes written by the team, birthday and anniversary if given, favourite area, number of no-shows and late cancellations, allergies, dietary requirements and accessibility needs (which may be health data, Article 9 GDPR; they are shown to the floor and the kitchen on each visit), whether the guest gave marketing consent or opted out of messages, and when.
• Bookings: date, time, party size, area and table, status, source, occasion and notes, deposit and payment terms.
• Waiting list: name, telephone number, party size, notes; for online entries, when and in which version the guest agreed.
• Pre-orders and orders: dishes, notes and allergy notes for each dish and for the party; for pickup orders also the name, telephone number and e-mail address.
• Events: tickets, add-ons, the names and dietary answers of the people on the tickets, ticket codes and check-in.
• Private dining: the enquiry, the quote and the payment plan.
• Payments: amounts, currency, status, refunds, tips on a bill, and the identifiers of the payment, the customer and the payment method at the venue's Stripe account. We never see or store a card number. We pass Stripe only the guest's e-mail address and the amount.
• Messages: the kind, channel and status of each message sent to a guest and the venue's own text in it; the recipient's address is not stored with the message record.

Team

• Name, e-mail address, role, hashed password, hashed PIN, encrypted two-step sign-in secret and hashed recovery codes, language, push tokens with device platform and language.
• Rota shifts, availability, time off, shift swaps, recorded working hours and breaks, pay rates, tip allocations, section assignments.
• Activity log: which login did what in the venue's account, and when.

3. Special categories

Allergies, dietary requirements, accessibility needs, notes and free-text answers may contain data concerning health. The venue confirms its Article 9(2) basis (normally the guest's explicit consent, Article 9(2)(a)). No other special-category data is intended to be processed.

4. Frequency

Continuous, for the duration of the Terms.

Annex II — Technical and organisational measures (Article 32)

1. Encryption in transit. All traffic is served only over HTTPS.
2. Encryption at rest. The database and its backups are encrypted at rest by our database provider. Two-step sign-in secrets are additionally encrypted in the application before they are stored.
3. Authentication. Passwords and PINs are stored only as one-way hashes; two-step sign-in with an authenticator app is available; sign-in and sensitive functions are rate-limited.
4. Access control and roles. Every request is tied to the venue and the role of the login; each role sees and does only what it needs; only the owner can delete the account.
5. Separation of venues. Every query is limited to the venue's own data. Automated tests try to read and change another venue's data and must fail.
6. Logging. The venue's activity log records which login did what; access by our staff to a venue's data is logged in our own audit log.
7. Data minimisation. No card numbers are held; push notifications carry no guest name or telephone number; the help assistant never receives guest data; guest data is never sent to an AI model.
8. Change management. Every change passes automated checks (type checking, tests) before it is deployed; deployments are made by us, not automatically.
9. Sub-processor governance. Sub-processors are engaged under data-processing terms, and the list in our Privacy Notice is kept up to date.
10. Deletion and export. Self-service export, erasure of single guests, and account deletion by the owner; automatic removal of pickup-order details after 90 days and of activity-log entries after 2 years.
11. Availability. Managed hosting with provider backups; scheduled jobs are monitored.
12. Organisation. Access to production systems is limited to named staff under confidentiality obligations; requests from public authorities are checked for lawfulness and answered with the minimum required.

Annex III — Authorised Sub-processors

Not Sub-processors: the venue's own Stripe account, under the venue's own contract with Stripe, for the payment processing itself (clause 4.4). Google (Gemini API), used for the help chat in the console, receives no Controller Data.

Any addition or replacement is notified under clause 5.4.

Acceptance

The venue accepts this DPA electronically together with the Terms; the acceptance record (time, account, version) stands in place of a signature. A venue that needs a countersigned copy can ask for one at hello@slotina.io.