Legal disclaimer: This article is general information for restaurant operators about Regulation (EU) 2016/679 (GDPR) and is not legal advice. For specific situations, work with a qualified data-protection lawyer or DPO. The regulation, supervisory-authority guidance, and case law continue to evolve. The most authoritative sources are the European Data Protection Board (edpb.europa.eu), your national DPA (CNIL, ICO, AEPD, Garante, BfDI, etc.), and the consolidated text of the regulation on EUR-Lex.

TL;DR — A restaurant owner’s 5 GDPR priorities

What counts as “personal data” under GDPR?

GDPR Article 4(1) defines personal data as “any information relating to an identified or identifiable natural person”1. In a restaurant context this is broader than most operators assume:

  • Customer data: first and last name, phone number, email address, date of birth, order history, payment information (including last 4 digits of card), IP address, loyalty points, table feedback.
  • Employee data: HR file, national ID number, social security reference, medical certificates, bank IBAN, shift records.
  • Supplier contacts: name, phone, email of supplier representatives.
  • CCTV recordings: since they capture employee and customer images, CCTV is personal data.

Data you consider “anonymous” or “statistical” — for example, “an 18:00 visit by a male customer aged 25-34 who ordered menu X” — can become personal data when combined with other information that makes the individual identifiable.

Who is the data controller? The restaurant owner.

GDPR defines two roles: the controller (who determines the purposes and means of processing) and the processor (who processes on the controller’s behalf). In a typical restaurant:

  • Controller = the business owner. You decide why customer and employee data are collected, where they are stored, and to whom they are transferred.
  • Processor = your POS, CRM, or loyalty provider. They store, process, and report on the data on your servers (or theirs) on your behalf.

This split matters because legal accountability sits with the controller — you. Even if your POS provider says “we’re compliant”, you are the one who answers to the regulator and to affected individuals in the event of a breach. That is why GDPR Article 28 requires a written Data Processing Agreement (DPA) between controller and processor.

What lawful basis applies? GDPR Article 6

GDPR Article 6 lists six lawful bases for processing personal data. At least one must apply for every processing activity:

Lawful basisRestaurant example
Consent (Art. 6(1)(a))Phone number for loyalty programme, birthday campaign sign-up, SMS/email marketing
Performance of a contract (Art. 6(1)(b))Address and payment for online order delivery
Legal obligation (Art. 6(1)(c))Tax records, invoice retention, payroll for employees
Vital interests (Art. 6(1)(d))Rare in restaurants — emergency medical situations
Public task (Art. 6(1)(e))Generally not applicable to private restaurants
Legitimate interests (Art. 6(1)(f))CCTV for site security (limited duration, clearly signposted), fraud prevention

A critical point for marketing: SMS or email marketing almost always requires consent. The “they were our customer, we had their phone, we sent a campaign” approach is a GDPR violation. EU member states also impose ePrivacy Directive (“PECR” in the UK) requirements on top of GDPR for direct electronic marketing, generally requiring opt-in consent for cold contacts.

DPA registration and DPO appointment

Unlike GDPR’s pre-2018 predecessors, registration with a DPA is not universally required under GDPR itself — but several member states maintain national-level requirements, and certain triggers under Article 37 require appointment of a Data Protection Officer (DPO).

DPO appointment is required when:

  • Processing is carried out by a public authority, or
  • The core activities consist of regular and systematic monitoring of data subjects on a large scale, or
  • The core activities consist of large-scale processing of special categories of data (health, biometrics, etc.).

For most independent restaurants and small chains, DPO appointment is not mandatory, but a designated point of contact for data-protection matters is good practice.

Confirm thresholds with your national supervisory authority:

  • France: CNIL (cnil.fr)
  • United Kingdom: ICO (ico.org.uk) — note UK GDPR diverges slightly from EU GDPR post-Brexit
  • Germany: Federal BfDI plus state-level authorities
  • Spain: AEPD (aepd.es)
  • Italy: Garante per la protezione dei dati personali

The EDPB (edpb.europa.eu) publishes cross-EU guidance.

How should the consent text be drafted?

Under GDPR Articles 7 and 13 (transparency and conditions for consent), the consent text generally needs to present the following five elements in clear and distinguishable language:

  1. What categories of data are processed (name, phone, date of birth, etc.)
  2. Purposes of processing (loyalty points, campaign notifications, etc.)
  3. Recipients of the data (POS provider, SMS gateway, cloud provider)
  4. Retention period (membership term + reasonable additional time, or legally mandated retention)
  5. Data subject’s rights (Articles 15-22 — access, rectification, erasure, restriction, portability, objection) and how to exercise them

For UK businesses subject to UK GDPR, ICO has published a detailed lawful basis checker and consent guidance that can help narrow down the right basis for each processing activity.

Retention period: how long?

Article 5(1)(e) requires personal data to be kept “for no longer than is necessary for the purposes for which the personal data are processed.” In a restaurant context this typically translates into parallel retention periods:

Data categoryTypical retentionBasis
Tax / accounting records5-10 years (varies)National tax law
Electronic invoice records5-10 yearsNational e-invoicing rules
Employee HR fileEmployment relationship + statute of limitations (commonly 6-10 years post-termination)National labour law
CCTV recordingsGenerally 30 days or less unless specific need to retainDPA guidance + legitimate-interest balance
Loyalty programme dataTied to consent scope; typically membership + 1-3 yearsConsent (Article 6(1)(a))

At the end of the retention period there are two options: deletion or anonymisation. Deletion permanently removes the data; anonymisation permanently severs the link to identifiable individuals. Anonymised data falls outside GDPR scope and may be retained for statistical analysis. Pseudonymised data (re-identifiable with a separate key) is still personal data under GDPR Recital 26.

Technical and organisational measures (Article 32)

Article 32 requires controllers to implement “appropriate technical and organisational measures” proportional to the risk. For a restaurant, the practical translation:

  • Encryption: customer phone/email records encrypted at rest in the database; HTTPS/TLS for data in transit.
  • Access control: role-based permissions — the cashier sees their shift report, the server can’t export the full customer list, the location manager sees their location, the owner sees everything.
  • Audit logs: who accessed what data, when, from which device — reviewable.
  • Periodic review: at least once a year, review the access list; former employees must lose system access.
  • Backup and disaster recovery: documented restore procedure for data loss.

Documents you can request from your POS provider in writing: a signed GDPR-compliant DPA, ISO 27001 or SOC 2 certification (if applicable), sub-processor list, data residency statement, and breach notification procedure.

What to do if there’s a data breach (Article 33-34)

Under GDPR Article 33, the controller must notify the supervisory authority of a personal data breach without undue delay and, where feasible, not later than 72 hours after becoming aware of it. Where the breach is likely to result in a high risk to data subjects’ rights, Article 34 requires notification to affected individuals as well.

Typical incident response sequence:

  1. Detection: system alert, security review, or third-party notification.
  2. Containment: isolate affected systems, reset passwords, freeze logs (as evidence).
  3. Scope and impact assessment: which personal data, which individuals, over what period.
  4. DPA notification within 72 hours (via your national authority’s breach notification form).
  5. Notification to affected individuals if there is high risk to their rights and freedoms.
  6. Post-incident remediation: root cause analysis, hardening technical measures, training.

Article 83 sets administrative fines up to €20 million or 4% of total worldwide annual turnover, whichever is higher for the most serious infringements; lower-tier breaches are capped at €10 million or 2% of turnover. Member-state DPAs publish enforcement decisions — the GDPR Enforcement Tracker aggregates them.

Cross-border data transfers (Articles 44-49)

If your cloud POS, SMS gateway, or analytics provider stores or processes data outside the EEA, GDPR Chapter V governs the transfer. Following the Schrems II ruling (CJEU C-311/18) the regime tightened significantly2. The main routes:

  1. EU/EEA data residency: the simplest path — the provider has data centres inside the EEA and contractually commits not to transfer outside.
  2. Adequacy decision: transfers to countries the European Commission has deemed adequate (currently includes Japan, UK, Switzerland, South Korea, and others; the US is covered via the EU-US Data Privacy Framework for participating organisations).
  3. Standard Contractual Clauses (SCCs) + transfer impact assessment: the most common path for transfers to non-adequate countries; SCCs alone are not sufficient post-Schrems II — a TIA documenting supplementary safeguards is required.
  4. Binding Corporate Rules for intra-group transfers within multinational organisations.

Questions to ask a cloud provider:

  • Where are your data centres? EEA, UK, US, or elsewhere?
  • Are backups in the same region or replicated cross-border?
  • Which transfer mechanism do you offer (SCCs, DPF, BCRs)?
  • Do you publish a transfer impact assessment template?

A brief note on CCPA (United States)

If you serve California residents online or run a chain with California locations, the California Consumer Privacy Act (CCPA) as amended by CPRA may apply. Thresholds (gross revenue >US$25M, processing data of 100,000+ Californians, or 50%+ revenue from selling/sharing personal information) exclude most independent restaurants, but chains should review applicability. Other US state laws (Virginia VCDPA, Colorado CPA, Connecticut CTDPA, Texas TDPSA, etc.) are emerging quickly.

Five common GDPR mistakes in restaurants

  1. SMS marketing without consent: the “they were a customer, we had their phone” approach is a GDPR + ePrivacy violation.
  2. CCTV recordings retained for years: the camera’s “everything is on record” reassurance crosses into illegal territory once the purpose has expired. Typical practice is 30 days or less.
  3. All staff have access to all customer data: without role-based permissions, a single server or cashier could export 50,000 phone numbers. Access is the breach point.
  4. POS contract has no Article 28 DPA: “the provider holds the data, but there’s no signed DPA” is the number-one finding in DPA audits.
  5. Former employee accounts not disabled: a separated cashier who can still log in is a breach risk. Disabling system access is the first step of any offboarding procedure.

FAQ

Do small restaurants need to register with a Data Protection Authority? Registration thresholds vary by country. Some EU members require all data controllers to register; others have employee-count or revenue thresholds. Confirm with your national DPA — but note that GDPR’s other obligations (lawful basis, retention, security) apply regardless of registration.

Can I store customer phone numbers for loyalty? Yes, with explicit consent (Article 6(1)(a)) for a specific purpose, retained only as long as necessary, and protected with appropriate technical safeguards. Consent text must clearly state what data is processed and why. The customer must be able to withdraw consent as easily as they gave it (Article 7(3)).

Is my POS GDPR-compliant? Modern cloud POS systems typically offer EU/EEA data residency, GDPR-compliant DPAs (Article 28), and technical safeguards (encryption, access control). Your business is the data controller and ultimately responsible — request a signed DPA from your provider, and ensure data residency, sub-processors, and breach procedures are documented in writing.

Does GDPR apply to UK businesses after Brexit? The UK GDPR (mirrored from EU GDPR with minor divergences) continues to apply. UK-EU cross-border transfers are covered by the European Commission’s adequacy decision for the UK (subject to renewal).

Legal disclaimer (repeated): the content above is general information. Regulation, supervisory-authority guidance, and case law evolve over time, and your specific obligations may differ. For situations under GDPR, work with a qualified data-protection lawyer or DPO. Example consent text, retention tables, and timelines in this article are starting points, not binding templates — they require legal review.

Sources

Primary sources used in this article:

  • Regulation (EU) 2016/679 (General Data Protection Regulation) — consolidated text on EUR-Lex
  • European Data Protection Board (EDPB) — Guidelines and Recommendations
  • Court of Justice of the European Union, C-311/18 (Schrems II)
  • ICO (UK), Lawful basis for processing
  • CNIL (France), Restauration et données personnelles
  • US California Privacy Rights Act (CPRA, amended CCPA)
Try Mytabble — POS, QR menu, and loyalty designed for GDPR compliance →

EU data residency. Signed DPA on request.

Footnotes

  1. Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data, https://eur-lex.europa.eu/eli/reg/2016/679/oj — consolidated text of the General Data Protection Regulation. ↩

  2. Court of Justice of the European Union, Case C-311/18 (Data Protection Commissioner v. Facebook Ireland and Maximillian Schrems), 16 July 2020 — invalidated the EU-US Privacy Shield and tightened requirements for SCCs with supplementary measures. ↩