Version v4.0

Privacy Policy

Effective from: 2026-07-01

Privacy Policy — Bitte

Last updated: 2026-07-01 Effective from: 2026-07-01 Version: 4.0 (the §4A behavioural-analytics additions are pending solicitor ratification)

1. Who we are

This Privacy Policy explains how Bitte Limited ("Bitte", "we", "us", "our") collects and uses personal data when you use:

The Bitte website at https://bitte.uk
Restaurant white-label sites built on Bitte (any subdomain or custom domain)
The Bitte mobile app (iOS / Android)
The Bitte merchant dashboard at https://dashboard.bitte.uk

Except for the Customer Profile Data described in Section 2A below — where the restaurant is the controller and Bitte is the processor — we are the data controller for the personal data described in this policy.

Item	Detail
Legal name	Bitte Limited
Companies House number	17140318
Registered office	71-75 Shelton Street, Covent Garden, London, WC2H 9JQ
ICO registration number	ZC193676
Data protection contact	privacy@bitte.uk
General contact	info@bitte.uk

You can reach our data protection contact for any privacy-related question or to exercise your rights (see Section 9).

2. Who decides what happens to your data — Bitte's role, surface by surface

Bitte plays two different roles under UK GDPR depending on which slice of your data is in question. For most processing we are the data controller — we decide why and how the data is processed; for one specific slice (Customer Profile Data at a particular restaurant) we are the processor, acting on the restaurant's instructions. This Section sets out the split in plain English; Section 2A goes deeper on the slice where the restaurant is in charge.

A dual role like this is a normal and recognised pattern under UK GDPR (EDPB Guidelines 07/2020). The decisive question is not which label a contract uses but who actually decides the purposes and means of each specific processing activity. The headline answer for each surface, in one sentence each:

For your orders, payments, account, and platform-wide records, we (Bitte Limited) are the data controller.
For your fraud-prevention data — IP address, device fingerprint, and order-history pattern — we (Bitte Limited) are the data controller.
For your dietary preferences, allergies, VIP records, and other Customer Profile Data at a specific restaurant, the restaurant is the data controller. We process that data only on the restaurant's instructions, under an Article 28 Data Processing Agreement baked into our Restaurant Services Agreement.
For our CRM / Gemini prospect data (business contact details of restaurants we are evaluating), we (Bitte Limited) are the data controller. Customer-facing data does not reach this system.

The longer description of each surface, including the lawful basis, who else sees the data, and how to exercise your rights, follows:

For your orders, payments, account, and platform-wide records, we (Bitte Limited) are the data controller. That covers the order itself (items, delivery address, total), the booking (time, party size, deposit hold), your account (name, email, password, marketing preferences), the payment session, the transactional emails and the platform-wide audit trail. We alone decide how this data is stored, retained, secured and shared with our sub-processors. Restaurants operating storefronts on Bitte are service providers under a contract with us — they are not controllers, joint controllers or processors of this data, and they see only what our merchant dashboard exposes for fulfilment of the meal contract.
For your fraud-prevention data — IP address, device fingerprint, browser characteristics and your order-history pattern, used to score the risk of a particular sign-in, payment or order — we (Bitte Limited) are the data controller. We rely on legitimate interest under Article 6(1)(f) for this processing; the three-part balancing test is documented in our Legitimate Interests Assessment (LIA §3). Restaurants do not see this fraud-scoring data and do not direct its use; the analytics is Bitte's, for Bitte's purpose of keeping the platform safe. We say this here in the open because the no-own-purpose assurance in Section 2A applies only to the Customer Profile Data slice; on this fraud-prevention slice we do analyse your data for our own purpose, candidly disclosed under Article 6(1)(f).
For your dietary preferences, allergies, VIP records, and the other Customer Profile Data a particular restaurant chooses to keep about you at that specific restaurant, the restaurant is the data controller. We process that data only on the restaurant's documented instructions, under an Article 28 Data Processing Agreement baked into our Restaurant Services Agreement (§6). Bitte hosts the data on the restaurant's behalf; we do not aggregate, analyse, benchmark, train models on, or otherwise use this slice for any purpose of our own. Section 2A walks you through the mechanics — lawful basis, consent capture, withdrawal, retention, erasure.
For our CRM / Gemini prospect data — the business contact details of UK hospitality businesses we are evaluating as potential Bitte customers (business name, public business email and phone, public Google Maps / JustEat / Deliveroo listing data, and the free-text replies those businesses send us), we (Bitte Limited) are the data controller. This stream is used only by Bitte's internal sales CRM at crm.bitte.uk. Customer-facing data does not reach this system — your order content, your chat messages and your Customer Profile Data are never sent to the CRM and are never sent to the Gemini API. The legal basis for the prospect stream is documented in the Legitimate Interests Assessment (LIA register §E) and in the processor register at §E (Gemini API scope).

Why we are spelling the dual role out this directly. A reviewer reading our claim in Section 2A that "Bitte does not aggregate / analyse / train on / share" Customer Profile Data, while also reading our Legitimate Interests Assessment for fraud detection (which does aggregate, does analyse, and does score), should not walk away confused. Both claims are true, but they describe different slices of data: the no-own-purpose assurance is specific to Customer Profile Data at a particular restaurant; the fraud- prevention surface is separately disclosed as a Bitte-controller activity in this section, in ROPA Activity #21, and in LIA §3. The same logic applies to our internal sales CRM: Bitte is candidly the controller for prospect data about UK hospitality businesses, but that stream is disjoint at the application layer from any customer-facing data, so the no-own-purpose assurance for Customer Profile Data is not undermined by it. We design the documents to hold up to scrutiny on this point rather than rely on a contract label.

If you are a customer, the rule of thumb is straightforward: anything you do as a diner on Bitte — registering, ordering, paying, booking, chatting with a restaurant — sits on the Bitte-controller side; the specific dietary and preference records a single restaurant has chosen to keep about you at that restaurant sit on the restaurant- controller side.

Restaurants are service providers, not controllers, for the Bitte-controller surfaces

When you book a table or place an order through a restaurant's white-label site or through bitte.uk, the transactional data about that booking or order — your name, contact details, items, delivery address, payment — is processed entirely by Bitte on Bitte-controlled infrastructure. For that processing the restaurant operates the storefront under a service agreement with Bitte but is not a controller, joint controller, or processor of your personal data. Bitte is the sole data controller under UK GDPR Article 4(7) for the platform-wide processing in this Section 2.

A narrow but important exception applies to the dietary, preference and VIP-tier records a particular restaurant chooses to keep about you as one of its known guests. That dataset — the "Customer Profile Data" — sits under the restaurant-controller relationship summarised in the bullets above. The restaurant decides what to record, why, and for whose benefit, so it is the controller for that slice; Bitte hosts the data on the restaurant's behalf as processor under an Article 28 processor agreement signed by every restaurant at on-boarding (Bitte Restaurant Services Agreement §6). Section 2A explains how that works and where to exercise your rights in respect of it.

What the restaurant sees and uses. The restaurant accesses your booking or order details (name, contact, items, delivery address where relevant) only through Bitte's merchant dashboard and only to the extent necessary to fulfil the contract you have entered into — preparing the meal, contacting you about a delay, honouring a refund. The merchant cannot export your data, cannot use it for their own marketing without a separate opt-in collected via Bitte, and cannot share it with any third party outside Bitte's processor list (Section 5).

Where to exercise your rights. For platform-wide processing (your account, your orders and bookings, payments, marketing communications), GDPR rights requests go to Bitte at privacy@bitte.uk. We respond within one calendar month (the statutory time limit under Article 12(3)). You do not need to contact the restaurant for these; they are not in a position to honour them because they are not the controller for that data.

For rights relating to the dietary, preference and VIP-tier records a particular restaurant has chosen to keep about you (Customer Profile Data — see Section 2A), the relevant counterparty is that restaurant, although in practice you may raise the request with either of us and we will route it to whichever party can action it. The right to withdraw consent to dietary recording is available directly from your Bitte account at any time (Section 2A).

2A. Customer Profile Data — where the restaurant is the controller

When a restaurant chooses to record dietary flags ("nut allergy", "vegetarian", "halal", and similar), structured preferences (preferred seating, wine, temperature) and a VIP tier about you as one of its known guests, that record is in the shop_user_profiles table on Bitte's platform but the restaurant is the controller of that data — they decided to record it, decided what to record, and decided why. Bitte hosts the data on the restaurant's behalf under an Article 28 processor agreement signed by every restaurant at on-boarding (Bitte Restaurant Services Agreement §6).

What this means for you in practice.

Lawful basis — per field, not per category. The lawful basis the restaurant relies on is set field by field, with the religion- or health-revealing fields on the explicit-consent side and the genuinely neutral fields on the legitimate-interest side. Bitte's platform enforces the boundary technically:

Religion-revealing dietary fields — explicit consent only. Halal, kosher, vegetarian, and vegan dietary fields can reveal religious or philosophical belief (Article 9(1)). The restaurant processes these under your explicit consent under Article 9(2)(a) for the special-category dimension and under your consent under Article 6(1)(a) for the general "lawful processing" question. A single ticked-box capture covers both.
Health-revealing dietary fields — explicit consent only. All allergy markers (nut allergy, shellfish allergy, dairy, gluten, and the inference-edge values), intolerance markers, the diabetic marker and any other medically-grounded dietary flag are health data (Article 9(1)). The restaurant processes these under your explicit consent under Article 9(2)(a) and under your consent under Article 6(1)(a), in the same single-capture form as the religion-revealing fields.
Neutral preferences — legitimate interest. Genuinely neutral hospitality preferences — preferred seating, wine flavour profile, room temperature, and your preferred communication channel for booking reminders — are processed under the restaurant's legitimate interest under Article 6(1)(f) in delivering personalised service to a known guest. You have the right under Article 21 to object to this processing on grounds related to your situation; the restaurant will then assess whether its legitimate interest is overridden in your case and act accordingly, with the platform supporting deletion of the preferences if the objection is upheld. The supporting balancing test is held by Bitte at docs/compliance/LIA.md §4 on the restaurant-controller's behalf.
VIP tier — legitimate interest, manually set. Your VIP recognition tier (none / silver / gold / platinum) sits on the same Article 6(1)(f) basis as the neutral preferences and the same Article 21 right to object applies. VIP tier is set manually by the restaurant — it is not computed by Bitte from your spend, visit cadence, or any other behavioural attribute. If at any future point VIP-tier allocation becomes derived from your data, the additional profiling balancing test held at docs/compliance/LIA.md §4.4.2 will apply, and any derived tier that produces a legal or similarly significant effect on you will be subject to a review under the Articles 22A–22D safeguards before launch.

Bitte provides the consent capture moment on the restaurant's behalf — when you book, place a first order, or visit a restaurant's privacy settings in your account. The consent applies only to that specific restaurant; consent to Restaurant A is not consent to Restaurant B. Withdrawal of consent triggers immediate deletion of the religion- and health-revealing dietary fields (see "Withdrawal" below).

Granularity. Consent is per-restaurant and covers only the dietary set. You can be a regular at five restaurants and have granted consent to none, some, or all five. The booking and ordering flows are NEVER conditional on this consent — you can always book and dine without granting it.
Withdrawal of dietary consent. You can withdraw your dietary consent at any time from your Bitte account (under Privacy / My Data Sharing). Withdrawal is immediate: Bitte deletes the dietary flags off your profile at that restaurant in the same atomic action. The structured preferences and VIP tier sit on legitimate interest, not consent, and so are not affected by this withdrawal — your lever for those fields is the Article 21 right to object, available from the same privacy page in your account.
Retention. The restaurant's profile of you is retained by default for thirty-six months from your most recent visit, after which it is hard-deleted by an automated nightly job — not just hidden, actually erased. A restaurant may configure a shorter retention but cannot configure a longer one without our written consent.
Erasure on demand. Independent of withdrawal of consent for future processing, you have the right to erasure of an existing profile at any time (UK GDPR Article 17). You can ask either the restaurant or privacy@bitte.uk; either route triggers the same hard-delete and scrub of the audit log.
Cross-restaurant visibility. None. Restaurant A's notes about you are invisible to Restaurant B. This is enforced in the code, not just by policy: every read and write is scoped to a single restaurant identifier, and we maintain an automated regression test that fails the build if the scope is ever broken.
No own-purpose use by Bitte. Bitte does not aggregate, analyse, benchmark, train models on, or otherwise use this data for its own purposes. Bitte hosts it and returns it to the restaurant that wrote it. The moment Bitte ever wanted to do anything else with this data for its own purposes, this Section would have to be revisited; we have committed in the Restaurant Services Agreement to keeping the no-own-purpose condition as a standing rule.
Third-party information you enter. If you enter information about another person on your own profile — for example, a partner's wine preference or a child's nut allergy when booking a family meal — you are responsible for having appropriate authority to share that information. Bitte and the restaurant rely on you to have done so.

A note on inferred special-category data. Five of the eleven dietary values in our system plainly reveal special-category data (allergy / diabetic = health; halal / kosher = religious belief). The other six (vegetarian, vegan, pescatarian, gluten-free, dairy-free, low-sodium) do not, on their face, reveal a special-category attribute, but in context some of them can (gluten-free can correlate with coeliac disease; dairy-free with lactose intolerance; low-sodium with cardiac or renal conditions). We treat the whole list under the same explicit-consent regime rather than draw a line value by value. The practical effect is that you only have to consent (or refuse, or withdraw) once.

Why this structure for platform-wide processing. Bitte chose sole-controller architecture for platform-wide processing — accounts, orders, payments, marketing — rather than joint-controller or processor-for-merchant because:

All personal data is hosted on Bitte's UK AWS infrastructure and never leaves it in raw form.
Bitte makes every meaningful decision about the personal data: retention periods, encryption, sub-processor selection, security controls, breach notification procedures, lawful basis for each processing purpose.
Customers register for an account and consent to processing through Bitte, not the restaurant. The contract for the platform is between the customer and Bitte; the contract for the meal is between the customer and the restaurant.
Sole-controller posture means customers have a single, predictable point of contact for privacy rights, and the friction of having every small restaurant register independently with the ICO is avoided.

A narrow but important exception — Customer Profile Data. The above sole-controller posture does NOT extend to the dietary, preference and VIP-tier records that an individual restaurant chooses to keep about you when you have ordered or booked at that restaurant ("Customer Profile Data"). Section 2A below explains the split.

This decision is reflected in our merchant Terms of Service: every restaurant operating a storefront contractually acknowledges that Bitte is the sole controller for platform-wide processing and agrees to direct any data subject request it receives directly to privacy@bitte.uk rather than acting on it.

3. What data we collect

3.1. When you create an account

Name, email, phone number, password (hashed, never stored in plain text)
Optional: profile photo, language preference, delivery address(es)
Marketing consent flag (users.marketing_consent) — see Section 6

3.2. When you book a table or place an order

The booking time, party size, special requests (allergies, occasions)
The order contents (items, quantities, modifiers)
Delivery address and location coordinates (if delivery)
Payment confirmation (we never see your full card number — see Section 5)
The marketing channel that led you to us (e.g. facebook, google_reserve, direct) — see bitte_booking_source cookie in Section 11

3.3. When you sign in via a third-party identity provider

If you use Sign in with Google, Apple or Facebook, we receive your name, email and a unique provider ID. We never see or store your provider password.

3.4. When you use our apps

Device type, OS version, app version (for crash reporting)
IP address (for security and rate limiting)
Approximate location (delivery zone validation; precise location only with your explicit OS-level permission)
Push notification token (Firebase FCM)

3.5. When you visit a restaurant's white-label site

Same as 3.2 above
Cookie bitte_booking_source (60-minute lifetime) — records which marketing channel led you to the site so the restaurant can attribute bookings. See Section 11.

3.6. We do NOT collect

Special-category data under Article 9 (race, health, sexual orientation, political views, religion, biometrics, genetics) — except where you voluntarily disclose dietary or allergy information in a booking note, in which case we treat it as health data and apply Article 9(2)(a) explicit-consent basis. See Section 6 on the explicit-consent mechanism.
Children's data below the UK age of digital consent. See Section 12 for the detailed age policy.

Order content disclosure: Your order data includes the specific items you ordered. We treat order contents as ordinary commercial data, not special-category data, even where items may carry lifestyle inference (e.g. alcohol availability, vegetarian options). If you have specific concerns about order content visibility, contact privacy@bitte.uk for a redaction discussion.

3.7. Merchant-assisted bookings

Merchant-assisted bookings. Where a booking is taken by the restaurant on your behalf — by phone, or in person as a walk-in — the restaurant provides us with your name, phone number and (optionally) email address so we can record and honour the reservation. We process these details under Article 6(1)(b) (performance of the booking contract). The restaurant is required to inform you that your details are stored by Bitte; you can request access, correction or erasure at any time at privacy@bitte.uk or via the data-subject-rights process in Section 13. We will not use these details for marketing unless you explicitly opt in.

4. Why we use your data — lawful bases

Purpose	Data used	GDPR lawful basis
Create your account, sign you in	Name, email, password, phone	Article 6(1)(b) — performance of contract
Process bookings and orders	Booking/order data, delivery address	Article 6(1)(b) — performance of contract
Record bookings the merchant takes on your behalf (phone, walk-in)	Name, phone, optional email	Article 6(1)(b) — performance of contract
Take payment	Payment session (no card stored on Bitte)	Article 6(1)(b) — performance of contract
Send transactional emails (booking confirmation, order receipt to your inbox)	Email	Article 6(1)(b) — performance of contract
Send a copy of your receipt to the restaurant's accounting system (e.g. Xero)	Name, email	Article 6(1)(a) — your explicit consent (opt-in checkbox at checkout / booking)
Send marketing emails (offers, newsletters)	Email	Article 6(1)(a) — your explicit consent
Detect and prevent fraud	IP address, device info, payment patterns	Article 6(1)(f) — legitimate interest
Crash analytics, app stability	Device info, error stack traces (no PII)	Article 6(1)(f) — legitimate interest
Comply with HMRC tax record-keeping	Order totals, dates, tax breakdown	Article 6(1)(c) — legal obligation
Process customer-initiated refund requests	Order reference, refund-window timestamp, customer message describing the issue, customer-uploaded photos (max 5 per request), the merchant's private response to our ops team, ops decision + reason	Article 6(1)(b) — performance of contract (the refund-request flow is part of the order contract you entered into; the data is necessary to evaluate and effect the refund)
Defend legal claims	Any of the above	Article 6(1)(f) — legitimate interest

You can withdraw consent (rows marked Article 6(1)(a)) at any time — see Section 9.

Refund-process retention — a two-tier split. Refund-process records are not all kept for the same length of time. We split them into a skeleton record and the substantive content:

We keep the basic record of a refund — the order reference, the refund decision (approve in full / approve in part / decline), the decision date, the refund amount, and the clawback line on the merchant's settlement report — for six (6) years alongside the underlying order. We need that long to defend any claim within the standard six-year limitation period under the Limitation Act 1980 and to satisfy HMRC tax record-keeping (Section 8).
We keep your photos and complaint text — the photos you uploaded, the free-text complaint you wrote, the merchant's private written response to our ops team, and the ops decision rationale — for eighteen (18) months after the refund decision. Eighteen months is well over the chargeback and gateway dispute windows operated by Visa, Mastercard, Stripe and PayPal, and well under the six-year limitation period. After eighteen months we hard-delete those items from the active database and from backups on the next rotation; the basic record remains for the balance of the six-year period.

The same split is reflected in Section 8 (the retention table) and in the merchant Terms of Service §6.1.

A note on free-text fields you fill in yourself. The order page, the per-item notes, the booking form's general-purpose note field and similar free-text inputs are there for you to leave practical instructions to the restaurant (which doorbell to press, please cut the pizza into eight, etc.). We've designed the surface to discourage you from typing health information in there: the labels and placeholders are neutral, there's no "Dietary" or "Allergy" box, we don't validate, tag, index or analyse what you write, and the merchant dashboard does not treat the content as health data. The Privacy / Data Sharing page in your account is the proper place to record dietary preferences and allergies — there you can give (and withdraw) explicit consent per restaurant, and the restaurant can actually act on the data safely.

If you do type health information into a free-text note anyway (an allergy, a medical condition, a religious dietary observance), here is what happens to it on our side:

We don't treat it as health data. The note is processed as part of your order — ordinary order content under the contract you've entered into with us to place the order or booking (UK GDPR Article 6(1)(b)). We don't separate, tag, index or surface it as health information, and we don't use it for any purpose that turns on its being health data. It lives alongside the rest of your order at rest on the same UK infrastructure under the same controls.
If you want the data acted on properly, use the Privacy / Data Sharing page. That route gives the restaurant a structured record under the explicit-consent regime described in Section 2A. It is the only route on which Bitte hosts dietary information as such, and the only route where you can withdraw and have the data deleted in one click.
If the restaurant decides to act on what you typed — for example, the kitchen changes the way it prepares your order because you mentioned coeliac disease in the note — that's a decision the restaurant has taken as the controller of its own operations. Bitte has just carried the note from you to them; what they do with it sits under their own privacy notice, not this one.

4A. Behavioural analytics — how we learn from your use of Bitte

When you browse and order on a Bitte property, we collect first-party behavioural events to understand how our sites and apps are used, to improve them, and to give restaurants aggregate insight into their own storefront. This section explains what that means for you.

What we collect. As you move through a Bitte property (bitte.uk ordering, a restaurant's white-label storefront, or the Bitte app), we record a small, fixed list of interaction events — for example, which pages and menu categories you view, which items you see and add to your basket, which steps of checkout or booking you reach, and what you search for. Each event is tagged with a random device identifier and a session identifier we store on your device (see the Cookie Policy for bitte_anon_id / bitte_anon_session_id), the storefront you were on, and your IP address. We record feature-level signals only — we do not capture your keystrokes, mouse movement, dwell time, screen recordings, or any free-text you type, and we do not collect special-category data (health, religion, and the like) through these events.

Why we collect it. To measure and improve the diner journey (where people drop off, what they search for but cannot find), and to show restaurants aggregate analytics about their own storefront so they can improve it.

Lawful basis. The step of storing and reading the identifiers on your device happens only after you accept the relevant cookie/analytics category — it is consent-based under PECR (see the Cookie Policy). The behavioural processing that follows rests on your consent (UK GDPR Article 6(1)(a)), supported for single-site, aggregate product-improvement analytics by our legitimate interest (Article 6(1)(f)) in improving our own service (balancing test at docs/compliance/LIA.md §6). Nothing in these two categories runs until you opt in through the banner, and you can withdraw at any time from Cookie settings.

The marketplace cross-restaurant identity — opt-in only. If you choose to join the Bitte marketplace identity (the consent_marketplace opt-in), we may link your activity across more than one restaurant on Bitte under a single diner identity, so we can recognise you as a returning Bitte diner and compute marketplace-level insights. This cross-restaurant linking happens only if you opt in — it is off by default, and single-restaurant analytics never depends on it. You can withdraw this consent at any time; when you do, we suppress the cross-restaurant links and drop you from cross-restaurant metrics (your Article 7(3) right to withdraw). Restaurants never see this cross-restaurant data — it is used only by Bitte and only in aggregate.

What restaurants see. A restaurant can see aggregate analytics about its own storefront — visitor counts, conversion rate, funnel drop-off, top products, and search terms. Because Bitte is the controller for storefront ordering (see Section 2), providing a restaurant these aggregate insights about its own shop makes the restaurant a recipient of aggregate diner-behaviour analytics for that shop. Restaurants do not see individual-diner rows, do not see other restaurants' data, and do not see the marketplace cross-restaurant identity — those stay with Bitte and are admin-only.

How long we keep it. The raw behavioural event records are pruned at 13 months. Any diner-identifying fields in the analytics data are scrubbed at 24 months. The IP address on an event is scrubbed at 90 days. The aggregate statistics we and restaurants work from carry no direct identifiers.

Full detail of this processing is in our Record of Processing Activities (docs/compliance/ROPA.md #24) and its Data Protection Impact Assessment (docs/compliance/DPIA-behavioural-analytics.md).

Separately — if you are a restaurant/merchant using our dashboard or merchant app: we also collect feature-level product-usage analytics (which features you use) to improve the merchant product. That processing is on a legitimate-interest basis with a fair-processing notice and no opt-out, and is described in your Merchant Terms of Service §4B and the merchant privacy notice, not here — this Section 4A is about diners.

5. Who we share your data with — processors and partners

We share your data with the following categories of third parties. Each acts as a processor on our behalf under written contracts that include GDPR Article 28 clauses. The list mirrors the canonical processor register at docs/compliance/dpa-register.md.

Recipient	Role	What they receive	Region + transfer basis
Amazon Web Services UK Ltd	Hosting, S3 storage, managed MariaDB (Lightsail)	All Bitte data, encrypted in transit and at rest	London (eu-west-2). UK-only — no Chapter V transfer.
Stripe Payments UK Ltd	Payment processor + Connect for restaurant payouts	Payment session metadata; Stripe handles full card details directly on their PCI-DSS Level 1 platform	UK contracting entity → US sub-processing under UK SCC Addendum + UK Extension to the EU-US Data Privacy Framework
PayPal (Europe) S.à r.l. et Cie, S.C.A.	Payment processor + deposit holds	Payment session metadata	LU contracting entity → US sub-processing under UK SCC Addendum + UK Extension to the EU-US Data Privacy Framework
Google Cloud EMEA Ltd (Firebase)	Authentication, Firestore (chat), push notifications (FCM)	Auth email, device tokens, chat messages	IE contracting entity → US sub-processing under UK SCC Addendum + UK Extension to the EU-US Data Privacy Framework
Sendinblue SAS (Brevo)	Transactional + marketing email delivery	Email, name, marketing-consent state, send / open / click events	France — UK adequacy regulations apply
Cloudflare UK Ltd	DNS, CDN, Turnstile bot check, edge security, cookieless storefront web analytics	IP address, user agent, request metadata	UK PoP first; UK adequacy regulations apply
Google (Google Ireland Ltd / Google LLC) — only if you accept analytics cookies	Google Analytics 4 — first-party site statistics on bitte.uk	Cookie ID, IP address, pages viewed, device/browser	UK/EEA contracting entity → US sub-processing under UK SCC Addendum + UK Extension to the EU-US Data Privacy Framework
Meta (Meta Platforms Ireland Ltd / Meta Platforms Inc) — only if you accept marketing cookies	Meta Pixel — advertising measurement and audiences on bitte.uk	Cookie ID, IP address, conversion/page events	UK/EEA contracting entity → US sub-processing under UK SCC Addendum + UK Extension to the EU-US Data Privacy Framework
Xero (UK) Ltd — only if you opt in via Section 6	Restaurant's accounting software	Your name + email on the receipt invoice	UK + New Zealand (UK adequacy decision for NZ)
Google Reserve — only if the restaurant has connected	Google's reservation network	Booking time, party size, your first name (not email)	US under UK SCC Addendum + DPF
TripAdvisor LLC — only if the restaurant has connected	TripAdvisor's bookable inventory	Same as Google Reserve	US under UK SCC Addendum + DPF

What we do NOT share with customer-facing processors

Twilio and Google Cloud (Gemini API) are used only by Bitte's internal sales CRM to identify and reach out to UK hospitality businesses. They do not receive end-customer order or booking data.

Restaurant relationship

Restaurants on Bitte are service providers, not controllers or processors (see Section 2). They view your booking / order data through Bitte's merchant dashboard solely to fulfil the meal contract you have with them. They cannot export, repurpose, or share your data outside Bitte's controlled infrastructure.

We do not sell your data. We do not share it with advertisers.

DPF certification status

For US sub-processing, we rely on the UK Extension to the EU-US Data Privacy Framework where the processor is currently listed on the active DPF participant list. As of the date of this notice, AWS, Google, Meta, Stripe, Cloudflare and PayPal are DPF-certified. If certification lapses for any processor, we fall back to the UK International Data Transfer Addendum to the EU SCCs alone, and update this notice within 30 days.

6. Marketing consent — opt-in only

Restaurant accounting receipt (Xero opt-in)

When you place an order or book a table, you may see an optional checkbox:

☐ Email me a copy of my receipt and order confirmations.

If you tick it, your name and email are written to the restaurant's accounting software (currently Xero, more partners may be added). The restaurant may also send you a transactional receipt by email.

If you leave the box unchecked:

The order or booking still goes through.
The restaurant's accounting record uses an anonymous "Walk-in customer" contact instead of your name.
No email is sent to you (other than the booking/order confirmation required for the contract).

Bitte's own marketing emails

Separately from the receipt opt-in above, Bitte may send you marketing emails about new features, restaurant partner news, and occasional offers — but only if you tick the marketing checkbox during sign-up or in your account settings. The default is unchecked.

Every marketing email carries an unsubscribe link that takes one click to action. Unsubscribing affects only marketing — transactional emails (booking confirmations, order receipts) keep flowing.

Allergy / dietary data (special category)

Dietary information about you is handled through the Customer Profile flow described in Section 2A, not through the booking form. The booking form does NOT capture dietary data — there is no field on it for that purpose. Where a restaurant wants to record your allergens or dietary observance for repeat service, the restaurant invites you (via the consent moment in your Bitte account or at the point of order) to authorise it under your explicit consent (UK GDPR Article 9(2)(a)). The full mechanics of that consent — granularity per restaurant, freely-given guarantee that the booking still works without it, immediate withdrawal-causes-deletion — are set out in Section 2A. The restaurant is the controller for this surface; Bitte hosts the data on the restaurant's behalf as processor.

Consent record-keeping

All consents above are explicit under GDPR Article 7. The default is unchecked. You can withdraw any consent at any time by:

Clicking the unsubscribe link in any marketing email
Emailing privacy@bitte.uk
Updating your account settings

Withdrawal does not affect data already shared with the restaurant or already sent. We record the timestamp of every consent decision (users.marketing_consent_at) so we can prove the date the choice was made if asked.

7. International transfers

Some processors listed in Section 5 carry out sub-processing outside the UK / EEA. For each, we rely on:

Adequacy regulations (UK government has determined the country has adequate data protection) — currently includes the EEA, Switzerland, New Zealand, Japan, South Korea, and others.
UK International Data Transfer Addendum to the EU SCCs for transfers without an adequacy decision.
UK Extension to the EU-US Data Privacy Framework for US sub-processing where the recipient is DPF-certified (see Section 5).

You can request a copy of the SCC Addendum for any specific transfer by emailing privacy@bitte.uk.

8. How long we keep your data

Data	Retention period	Reason
Account profile	Until you delete your account, plus 30 days for backup recovery	Standard SaaS
Bookings and orders	6 years	HMRC tax record-keeping (Schedule 11, VAT Act 1994). After 6 years, customer-identifying fields are pseudonymised; the order shell is retained for any longer period the law requires.
Payment records	6 years	HMRC + Strong Customer Authentication audit
Refund-process skeleton record (order reference, refund decision, decision date, refund amount, clawback line)	6 years	Limitation Act 1980 six-year limitation period; HMRC tax record-keeping
Refund-process substantive content (photos you uploaded, your free-text complaint, the merchant's private written response, the ops decision rationale)	18 months after the refund decision	Sits well over the chargeback / gateway dispute windows operated by Visa, Mastercard, Stripe and PayPal, and well under the six-year limitation period. Hard-deleted from the active database and from backups on the next rotation.
Customer Profile Data (the dietary flags, structured preferences and VIP-tier records a restaurant keeps about you — see Section 2A) — claim-defence slice retained after the restaurant-Bitte relationship ends	For so long as a specific live legal claim Bitte is defending requires it, and in any event no more than the applicable statutory limitation period (typically six years under the Limitation Act 1980)	If a restaurant stops using Bitte and there is a specific legal claim live at that point (for example, a complaint, a billing dispute, or a regulator query that touches your records), we may keep the records that claim depends on for as long as the law allows us to defend it — even after your consent to that restaurant has otherwise been scrubbed off our system. We keep them only to defend that claim, not for any other purpose, and not for any longer than we need to. For ordinary personal data in this slice we rely on Article 6(1)(f) (legitimate interest in establishing, exercising or defending legal claims); for any dietary information in the slice that reveals health or religious belief we rely on Article 9(2)(f) (processing necessary for the establishment, exercise or defence of legal claims). For this claim-defence slice Bitte acts as the independent controller, not as the restaurant's processor.
Delivery addresses	Until you delete them, or 2 years after last order	Convenience, then minimisation
Marketing consent record (`marketing_consent_at`)	Lifetime of account, plus 6 years after deletion	Proof of consent for ICO audit
Webhook event logs (`integration_webhook_inbox`)	90 days	Forensic / dispute resolution
Crash analytics	90 days	Bug investigation
Marketing email engagement	2 years from last open / click	Sender reputation, list hygiene
Cookies (`bitte_booking_source`)	60 minutes	Marketing channel attribution
Public reviews you post	Public until you request removal; moderation history retained 7 years	Performance of contract + legitimate interest in keeping a moderation audit
Cookie consent record (stored in your browser's local storage, not a cookie — see Section 11)	12 months	PECR Reg 6 + UK GDPR Article 7 proof of consent

After the retention period, data is either anonymised or deleted from our active systems and backups (backup retention max 90 days).

9. Your rights (GDPR Articles 15–22)

You have the following rights regarding your personal data:

Right of access (Article 15) — get a copy of the data we hold
Right to rectification (Article 16) — correct inaccurate data
Right to erasure / "right to be forgotten" (Article 17) — except where we must keep data for HMRC (Section 8)
Right to restrict processing (Article 18) — pause processing while a dispute is being resolved
Right to data portability (Article 20) — get your data in a machine-readable format (JSON / CSV)
Right to object (Article 21) — to processing based on legitimate interest, including direct marketing
Right to withdraw consent (Article 7(3)) — for any processing based on consent
Rights in relation to automated decision-making (Articles 22A–22D UK GDPR, as amended by the Data (Use and Access) Act 2025) — Bitte does not currently make solely-automated decisions producing legal or similarly significant effects on you; if that changes we will put the required safeguards in place (information, the ability to make representations, human intervention and a route to contest)

How to exercise your rights

Email privacy@bitte.uk with:

Your full name and email associated with your Bitte account
The right you wish to exercise
Any specific data or time range you're asking about

We will respond within one calendar month (Article 12(3)). For particularly complex or numerous requests we may extend this by a further two calendar months (Article 12(3)), telling you within the first month if we do so.

We do not charge a fee for the first request in any 12-month period. Repeated, manifestly unfounded or excessive requests may incur a reasonable fee or be refused (Article 12(5)).

10. Security

We protect your data with:

TLS 1.2+ encryption for all data in transit
AES-256 encryption at rest for all S3 buckets and database backups
Field-level encryption for high-sensitivity fields (Xero OAuth tokens, payment intent IDs) using Laravel Crypt (AES-256-CBC, key rotation supported)
Bcrypt password hashing (work factor 12)
Sanctum-based API authentication with short-lived tokens
HMAC-SHA256 signature verification on all inbound webhooks (5-minute replay window)
Regular security audits and dependency scanning
Role-based access control on the merchant dashboard

We do not store payment card numbers. Stripe and PayPal handle all card data on their PCI DSS Level 1 environment.

If we discover a personal data breach that is likely to result in a risk to your rights and freedoms, we will notify the ICO within 72 hours and inform affected users without undue delay (Articles 33–34).

11. Cookies and similar technologies

This section summarises the cookies we use. Our full standalone Cookie Policy sets out every cookie, lifetime and third-party recipient in detail and explains how to change your choice; the two documents are kept consistent.

The law. Cookies are governed by the Privacy and Electronic Communications Regulations (PECR), as amended by the Data (Use and Access) Act 2025 (the amended rules took effect 5 February 2026), read together with UK GDPR. We must tell you what each non-exempt cookie does and get your consent before setting it; strictly-necessary cookies are exempt.

Our approach — opt-in, stricter than required. From 5 February 2026 the DUAA exempts first-party analytics cookies from consent (with information + a free opt-out). We have chosen not to rely on that exemption: we ask for your opt-in consent before any analytics or marketing cookie is set, because we also run an advertising pixel and the analytics exemption does not extend to data that can feed advertising. Nothing non-essential loads until you accept it in the banner, the "Reject all" option is as prominent as "Accept all", there are no pre-ticked boxes, and closing the banner counts as reject.

11.1 bitte.uk and the Bitte apps

Cookie / item	Purpose	Lifetime	Category
`XSRF-TOKEN`	Cross-site request forgery protection	Session	Strictly necessary — no consent needed
`bitte_access_token`	Authenticated session — short-lived	15 minutes	Strictly necessary; HttpOnly + Secure + SameSite=Strict
`bitte_refresh_token`	Silent re-authentication when the access cookie expires	30 days	Strictly necessary; HttpOnly + Secure + SameSite=Strict
`bitte_session`	Non-sensitive "you have a session" marker the UI uses to show signed-in state	7 days	Strictly necessary
`__cf_bm`	Cloudflare bot-management / abuse protection	~30 minutes	Strictly necessary
`i18nextLng`	Language preference	Until cleared	Strictly necessary (local storage)
`bitte-gdpr-consent`	Stores your cookie choices + timestamp (how we honour "Reject all")	12 months	Strictly necessary (local storage, not a cookie)
`_ga`, `_ga_<id>`, `_gid`	Google Analytics 4 — first-party site statistics	up to 2 years (`_gid` 24h)	Analytics — set only if you accept analytics cookies
`bitte_booking_source`	Marketing channel attribution (records whether you arrived from Facebook, Google, etc.)	60 minutes	Analytics — set only if you accept analytics cookies
`_fbp`, `_fbc`, `fr`	Meta Pixel (bitte.uk web only — not used in the mobile apps) — advertising measurement and audiences	3 months	Marketing — set only if you accept marketing cookies

11.2 Restaurant white-label storefronts

Storefronts use a smaller set and no advertising cookies: the same strictly-necessary security/session cookies and __cf_bm as above; the consent record in local storage (bitte_store_gdpr_consent_v2) plus a legacy companion cookie (bitte_store_gdpr_consent); and, only if you accept analytics, Cloudflare Web Analytics, which is cookieless (it sets no tracking cookie and does not fingerprint you) but is still gated behind your analytics choice.

Browser local storage is used for: cart contents, theme preference, language, and your cookie-consent record. We do not store authentication tokens in local storage — they live in HttpOnly cookies the browser cannot expose to JavaScript. The full per-cookie detail, third-party recipients and international transfers are in the Cookie Policy and Section 5.

12. Children

Two thresholds, one rule

Bitte applies two layers of age policy:

Statutory threshold — 13. Under the UK Data Protection Act 2018 § 9, processing of children under 13 that relies on consent (Article 8 UK GDPR) requires parental authorisation. We do not knowingly process data of any user under 13 in any circumstance.
Product threshold — 18. For product and licensing reasons (alcohol availability through restaurant partners; binding contracts for orders and bookings; payment / dispute handling), we restrict account creation and ordering to users aged 18 or above. This aligns Bitte with the sector standard set by UK food-delivery platforms including Uber Eats, Deliveroo and Just Eat, which all require account holders to be 18 or older.

How we enforce the 18 threshold

Sign-up form carries a required affirmation — "I confirm I am 18 years of age or older" — that the prospective account holder must tick. The affirmation is captured server-side alongside the registration timestamp; submissions without the ticked box are rejected at validation.
Self-declaration is the only mechanism — we do not verify by ID document at sign-up. If a user falsely affirms 18 or above, we treat the resulting data as adult data until we are notified otherwise.
Notifications path. If anyone (parent, guardian, the user themselves, a regulator, a restaurant) tells us a user is under 18 — or under 13 — we suspend the account immediately and delete the data within one calendar month, retaining only the minimum record of the deletion event itself.
Restaurant age verification at fulfilment. Restaurants on Bitte are responsible for any additional age verification their licensing requires (alcohol, tobacco, other age-restricted items). That verification happens at fulfilment, not at the Bitte account layer.

If you believe a user under either threshold has provided us data, please email privacy@bitte.uk and we will investigate immediately.

13. Changes to this policy

We update this policy from time to time. Material changes will be notified by email at least 14 days in advance, and the updated version will be posted at https://bitte.uk/privacy with the new "Last updated" date.

The current version is 4.0 (DRAFT). The changes from earlier published versions are:

v4.0 (this version, 2026-07-01 — DRAFT, pending solicitor sign-off) — Added a behavioural-analytics disclosure (new §4A). Bitte's first-party behavioural-analytics platform is live in production and was previously undisclosed in the customer notice; §4A closes that gap. It sets out: what first-party interaction events we collect (feature-level only — no keystroke, dwell, screen-recording or free-text, and no special-category data); why (funnel improvement + aggregate storefront analytics for restaurants); the lawful basis (PECR consent for the on-device identifiers, UK GDPR Article 6(1)(a) consent for the processing, with Article 6(1)(f) legitimate interest supporting single-site aggregate product-improvement analytics only); the defined retention schedule (raw events pruned at 13 months, diner-identifying fields scrubbed at 24 months, IP scrubbed at 90 days); the marketplace cross-restaurant identity, which links a diner's activity across more than one restaurant only on the consent_marketplace opt-in (off by default) with Article 7(3) withdrawal suppression; and the disclosure that a restaurant is a recipient of aggregate-only analytics about its own storefront (never individual-diner rows, other shops' data, or the cross-restaurant identity). Ties to ROPA Activity #24, LIA §6, and the new DPIA at docs/compliance/DPIA-behavioural-analytics.md. A pointer notes that merchant/staff product-usage analytics (feature_used) is disclosed in the Merchant Terms of Service §4B, not here. No change to any pre-existing lawful basis or controller/processor posture. Open item honestly recorded in the DPIA: the cross-restaurant identity runs in production ahead of DPIA/LIA sign-off, an owner-accepted residual.
v3.9 (superseded, 2026-07-01) — Cookie disclosure reconciled with the live tracker set, and a standalone Cookie Policy added. The earlier §11 listed Google Analytics but omitted the Meta Pixel marketing cookies (_fbp, _fbc, fr) that the web app fires under the marketing-consent category — a disclosure gap closed here. §5 now lists Google (Google Analytics 4) and Meta (Meta Pixel) as recipients with the US DPF / SCC-Addendum transfer basis, and Meta is added to the DPF-certified list. §11 is rebuilt into a bitte.uk table and a white-label-storefront table (the latter cookieless Cloudflare analytics, no advertising cookies), states the PECR / Data (Use and Access) Act 2025 position (in force 5 February 2026) and records Bitte's deliberate choice not to rely on the new first-party- analytics consent exemption — analytics and marketing both stay opt-in because Bitte also runs an advertising pixel, which takes the analytics data outside the exemption. A new standalone Cookie Policy (docs/COOKIE_POLICY.md → /cookies) carries the full per-cookie detail and is cross-linked from §11 and the banner. No change to lawful bases, controller/processor posture, or any substantive position from v3.8; this is a transparency-and-accuracy pass. Follow-up flagged: the processor register (dpa-register.md) and ROPA need matching GA4 / Meta entries to keep the Article 30 record consistent.
v3.8 (superseded, 2026-05-30) — Dual role made explicit in plain customer English per the friend solicitor's 2026-05-30 review (point 1). Section 2's opening was rewritten so that the four customer-facing surfaces — Bitte-controller for orders / payments / account / platform records, Bitte-controller for fraud-prevention data, restaurant-controller for Customer Profile Data, Bitte-controller for the CRM / Gemini prospect stream — are each named in a single crisp customer-facing sentence at the top of the section before the longer mechanics underneath. A new "Why we are spelling the dual role out this directly" paragraph at the end of Section 2 names the exact reviewer-trap the friend flagged: the "Bitte does not aggregate / analyse / train on / share" assurance in Section 2A must not be read against the LIA-§3 fraud-prevention processing, because the two describe different data slices. The substantive position of v3.6 (dual role identified) and v3.7 (per-field reclassification of dietary preferences) is unchanged; v3.8 is a comprehensibility pass, not a position change. The essential-means defence (EDPB 07/2020 ¶35-40 — Bitte built the field, the restaurant decides whether to use it, the consent flow runs on the restaurant's documented instructions) is articulated in full at ADR 0010 §2 and is reflected in the ROPA header "Essential-means defence" note rather than repeated in the customer-facing notice. Verified in parallel: ROPA Activity #1 (Bitte controller), #3 (Bitte controller — service- provider note in place), #6 (Bitte controller — service-provider note in place), #20 (Bitte processor), #21 (Bitte controller — fraud-prevention scoring, added 2026-05-30), and CRM activities #7-#9 + #15 (Bitte controller — disjoint from customer-facing data). Processor register §G dual-role note added underneath the self-hosted mail clarification.
v3.7 (superseded, 2026-05-30) — Reclassified Customer Profile Data lawful basis per field, not per category, per the friend solicitor's 2026-05-30 review (point 2). The earlier draft characterisation treated the eleven dietary values as a block under Article 6(1)(a) + 9(2)(a), and pushed all preferences (seating, wine, temperature) plus the VIP tier into the legitimate-interest bucket. The friend's reclassification: (i) religion-revealing dietary fields — halal, kosher, vegetarian, vegan — moved onto Article 6(1)(a) + 9(2)(a) explicit consent (religious or philosophical belief is Article 9 data and cannot sit on LI); (ii) health-revealing dietary fields — all allergy markers, intolerance markers, the diabetic marker, and the inference-edge values — moved onto Article 6(1)(a) + 9(2)(a) explicit consent (health data cannot sit on LI either); (iii) genuinely neutral preferences — seating, wine flavour profile, room temperature, communication channel — kept on Article 6(1)(f) legitimate interest, with the supporting balancing test documented at LIA §4; (iv) VIP tier — kept on Article 6(1)(f) on the express basis that it is manually set by the restaurant and not derived from your spend or behaviour. If the VIP tier is ever derived from your data in future, the additional profiling balancing test held at LIA §4.4.2 will apply before launch and a review under the Articles 22A–22D safeguards will engage if the derived tier produces a legal or similarly significant effect. Section 2A's "Lawful basis" sub-section is rewritten from a three-regime structure into a per-field enumeration reflecting the reclassification. ROPA Activity #20 has been updated in parallel.
v3.6 (superseded, 2026-05-30) — Made Bitte's dual role explicit, surface by surface, per the friend solicitor's 2026-05-30 review. Section 2's opening was rewritten under the heading "Who decides what happens to your data — Bitte's role, surface by surface" to set out four customer-facing bullets: (1) Bitte is the data controller for orders, payments, account and platform-wide records; (2) Bitte is the data controller for fraud-prevention data (IP, device fingerprint, order-history pattern) under Article 6(1)(f) per LIA §3; (3) the restaurant is the data controller for the dietary, allergy, VIP and other Customer Profile Data at that specific restaurant — Bitte processes it only on the restaurant's documented instructions under the Article 28 DPA in Restaurant Services Agreement §6 (see §2A for the mechanics); (4) Bitte is the data controller for the CRM / Gemini prospect stream (business contact details of UK hospitality businesses we are evaluating), with the express assurance that customer-facing data does not reach this system. The opening note explains that a dual role is normal under EDPB Guidelines 07/2020 and that the controller / processor split is decided by who actually determines purposes and means for each activity, not by the contract label. Section 2's existing "service providers, not controllers" detail and Section 2A's mechanics for Customer Profile Data are retained underneath the new framing.
v3.5 (superseded, 2026-05-30) — Refined the free-text-note framing per the friend solicitor's 2026-05-30 review. Article 25 is now described as the design-time minimisation obligation Bitte discharges on these surfaces (neutral labels, UI nudges, dedicated consent page, no validation / analytics / tagging, merchant-side workflows do not treat the content as health data) rather than as anything that authorises processing. The typed note itself is processed under Article 6(1)(b) as ordinary order content (no Article 9 condition is relied on because the note is not treated as Article 9 data). The Article 9(2)(a) consented channel on the Privacy / Data Sharing page remains the proper route for any Customer who wants their dietary data acted on as such. If the restaurant decides to act on a typed note (e.g. changing kitchen behaviour because a Customer mentioned coeliac disease), processor / transport characterisation applies and the restaurant decides as controller what to do with the note. Section 4's "note on free-text fields" paragraph is rewritten as a four-bullet stack reflecting these layers in customer-facing English. v3.2 had previously dropped Article 9(2)(e) "manifestly made public" for Article 25 alone; v3.5 corrects the residual misconception that Article 25 could be treated as a lawful basis.
v3.4 (superseded, 2026-05-30) — Post-termination retention exception clause added per the friend solicitor's 2026-05-30 review. Section 8's retention table gains a row for the claim-defence slice of Customer Profile Data: where a restaurant ends its arrangement with Bitte and there is a specific live legal claim that touches a Customer's profile records, Bitte may retain that narrow slice for as long as the applicable limitation period requires (typically six years under the Limitation Act 1980, but no longer than the claim itself needs). For the claim-defence slice Bitte's role flips from processor (acting on the restaurant's instructions) to independent controller (acting for Bitte's own purpose of defending a claim). Bitte's Article 6 basis for that slice is Article 6(1)(f) (legitimate interest in establishing, exercising or defending legal claims); Bitte's Article 9 condition for any special-category data within the slice is Article 9(2)(f) (processing necessary for the establishment, exercise or defence of legal claims), which replaces the Customer's original Article 9(2)(a) consent for that slice on the basis that the consent has been scrubbed on cascade and cannot lawfully be revived. The clause is mirrored in the Restaurant Services Agreement at §6.8.3.
v3.3 (superseded, 2026-05-30) — Retention split: refund skeleton 6y / substantive (photos+text) 18m; CRA perishable exemption + ADR signpost noted (refund policy). Section 4's refund-process retention paragraph is rewritten as a two-tier split — a six-year skeleton record (order reference, decision, date, amount, clawback line) and an eighteen-month substantive content tier (customer photos, customer free-text complaint, merchant private response, ops decision rationale). Section 8's retention table adds matching rows for each tier. The customer Refund Policy gains a note that the Consumer Contracts Regulations 2013 fourteen-day cooling-off right does not apply to perishable food, a clearer distinction between Bitte's decision window and the bank settlement window, and an independent-dispute-resolution signpost to Citizens Advice (0808 223 1133) and the County Court small claims track (Money Claim Online at gov.uk/make-money-claim).
v3.2 (superseded) — reframes the customer-volunteered free-text notes in Section 4. The earlier reliance on Article 9(2)(e) ("data manifestly made public by the data subject") is dropped, on the basis that a private order or booking note sent to a single restaurant is a confidential communication, not a public disclosure. The notes are now described as a non-special-category surface subject to an Article 25 data-minimisation control: we don't solicit health information there, we steer customers away from putting it there via UI nudge and position statement, and where it is included anyway the note is processed under Article 6(1)(b) for the order itself and is not tagged, indexed or used as health data. The Privacy / Data Sharing page in your account remains the proper place to record allergies and dietary observance under the Article 9(2)(a) explicit consent regime described in Section 2A.
v3.1 (superseded) — introduced the purpose-specific controller / processor split for Customer Profile Data: Bitte remains the sole controller for platform-wide processing (accounts, orders, bookings, payments, marketing), but the individual restaurant is the controller for the dietary preferences and VIP-tier records it chooses to keep about its known guests, with Bitte acting as processor for that surface under an Article 28 processor agreement. Section 2A describes the split and how to exercise rights against each party. Section 12's age threshold is aligned with the 18-plus affirmation that the registration form actually enforces, and with the sector standard set by Uber Eats, Deliveroo and Just Eat in the UK.
v3.0 (superseded) — introduced the sole-controller characterisation for the whole platform, retiring the earlier joint-controller framing of v2.0.
v2.0 (superseded) — added the original joint-controller framing for Bitte / restaurant, the Xero accounting integration disclosure, and the unbundled marketing-consent disclosure.

14. How to complain

If you believe we have mishandled your data, please contact us first at privacy@bitte.uk — we'd like a chance to put it right.

You also have a right under the Data (Use and Access) Act 2025 to complain directly to us about how we handle your personal data. You can do so at privacy@bitte.uk. We will acknowledge your complaint within 30 days, investigate it without undue delay, and keep you informed of the outcome. You do not have to complain to us before approaching the ICO, but we would welcome the chance to put things right first.

If you are not satisfied with our response, you have the right to complain to the UK Information Commissioner's Office:

Item	Detail
Address	Information Commissioner's Office, Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF
Helpline	0303 123 1113
Online	https://ico.org.uk/make-a-complaint/

You can also complain to the data protection authority in your EU/EEA country of residence if you are based there.

End of policy.