Is the TPV or booking software supplier a controller or a processor?

The restaurant decides for what purposes the customer's data are processed (booking, invoicing, loyalty) and with what means: it is the controller (art. 4.7 RGPD). The TPV or booking software supplier processes those data on behalf of the restaurant and according to its instructions: it acts as a processor (art. 4.8 RGPD). That relationship requires signing the contract under art. 28 RGPD with the minimum content set out in art. 28.3. If the supplier reuses the data for its own purposes — for example, aggregate marketing — in that part it stops being a processor and becomes a controller, with its own independent obligations.

What if my booking supplier has its servers in the United States?

There is an international data transfer. Since July 2023, the EU–US Data Privacy Framework (DPF) is in force, based on the European Commission's adequacy decision. Transfers to US suppliers adhering to the DPF rely on that legal basis under art. 45 RGPD. If the supplier is not adhered to the DPF, the transfer must rely on Standard Contractual Clauses (art. 46 RGPD) and, depending on the case, on supplementary measures following a transfer impact assessment. The restaurant's privacy policy must indicate that there is an international transfer and what safeguards apply.

Can the supplier subcontract part of the service (for example, hosting on AWS or Azure)?

Yes, but it is subject to the rules of art. 28.2 and 28.4 RGPD. The controller — the restaurant — must have authorised the subcontracting, either specifically or generally; the processor must inform of any change to sub-processors and give an opportunity to object; and the sub-processor is subject to the same data protection obligations as the main processor, through an analogous contract. The list of sub-processors (AWS, Azure, transactional email providers, payment integrations) must be accessible to the controller.

At the end of the contract, does the supplier delete everything it held about the restaurant?

Not directly, and this is one of the most important points of the contract. Art. 28.3.g RGPD requires the processor, once the service has ended, to delete or return the data to the controller, at the controller's choice. The correct operational rule is: the supplier exports or returns the data to the restaurant (in a usable format), and only then proceeds to delete them, save for retention required by law. That allows the controller to continue complying with its own legal retention periods (tax, employment, accounting) without depending on the outgoing supplier.

Do I have the right to audit the TPV or booking software supplier?

Yes. Art. 28.3.h RGPD requires the processor to make available to the controller all information necessary to demonstrate compliance with its obligations, and to allow for and contribute to audits, including inspections carried out by the controller or by an auditor authorised by it. In practice, serious suppliers channel this through recognised certifications (ISO/IEC 27001, schemes such as ENS), SOC reports, or documented audit procedures. The contract must regulate how the audit right is exercised without disrupting the operation.

Booking software and TPV in a restaurant: the supplier's obligations under the RGPD

The TPV and the booking software are two of the most critical tools in any restaurant. They concentrate name, phone, email, time, number of diners, allergies, receipts, payment methods, loyalty and, in many cases, also staff lists. Whoever provides them is not a simple software vendor: it is someone who processes personal data of the restaurant on its behalf. And that, in RGPD terms, has a specific name and a specific contract.

This guide reviews the regime of the processor (art. 28 RGPD) as applied to the hospitality sector: what the restaurant has to sign with its supplier, what guarantees it must require, what happens with servers outside the EU and what happens with the data when the contract ends.

Why the TPV and booking software are processors

The RGPD distinguishes two clear roles:

Controller (art. 4.7): the one who decides the purposes and means of the processing. In this case, the restaurant.
Processor (art. 4.8): the one who processes personal data on behalf of the controller, following its instructions.

The TPV supplier does not decide who the restaurant builds loyalty with, which allergy is recorded or which offer is sent. It executes what the controller needs: it records receipts, stores bookings, provides reporting. It is a processor. The same applies to the booking system supplier, the loyalty CRM, the payroll firm, the transactional email provider or the QR menu supplier if it captures data.

Watch out for a frequent case: if the supplier reuses the restaurant's data for its own purposes (aggregate analytics, marketing of its own platform, lead selling), in that part it no longer acts as a processor but as an independent controller, and must have its own legal basis. Read the terms carefully and clarify it in the contract.

The processor contract: minimum required content (art. 28.3 RGPD)

Art. 28.3 RGPD requires that the controller-processor relationship be documented in a contract or other binding legal act, with mandatory minimum content. It is not a suggestion: it is a requirement of the Regulation itself. These are the points that cannot be missing:

Section	What it must regulate
Subject matter and duration	What service is provided and for how long the processor handles data.
Nature and purpose	What the data are processed for within the service (bookings, TPV, invoicing, loyalty…).
Type of data and categories of data subjects	Identifying data, contact, financial data, service-related notes (allergies on the docket), categories of customers, employees, etc.
Art. 28.3.a — Documented instructions	The processor only processes data following documented instructions from the controller, including for international transfers.
Art. 28.3.b — Confidentiality	Persons authorised to process the data commit by contract or by law to respect confidentiality.
Art. 28.3.c — Security measures	Apply the art. 32 RGPD measures appropriate to the risk (encryption, authentication, access control, backups, ability to restore).
Art. 28.3.d — Sub-processors	Authorisation and notification regime to the controller; sub-processors must take on the same data protection obligations.
Art. 28.3.e — Assistance with rights	Assist the controller through technical and organisational measures to handle data subject rights (arts. 15–22 RGPD).
Art. 28.3.f — Ancillary compliance	Help the controller comply with the obligations of arts. 32–36 RGPD (security, breach notification, DPIA, prior consultation).
Art. 28.3.g — End of contract	Return or delete the data at the controller's choice and remove copies, save for retention required by law.
Art. 28.3.h — Information and audit	Make available to the controller the information necessary to demonstrate compliance and allow for audits or inspections.

Many suppliers have their own contract template (DPA, Data Processing Addendum). That does not exempt the restaurant from reading it: that DPA must align with the content of art. 28.3 RGPD and not contradict it.

Sub-processors: when the TPV supplier uses AWS or Azure

The vast majority of cloud-based booking and TPV suppliers do not host the servers themselves: they contract them from a hyperscaler (Amazon Web Services, Microsoft Azure, Google Cloud). Those hyperscalers are sub-processors.

Art. 28.2 and 28.4 RGPD require:

Authorisation by the controller, specific or general (in practice, it is usually formalised in the initial contract with a list of sub-processors already accepted).
Prior information to the controller of any change or incorporation of new sub-processors, with the opportunity to object.
Same regime: the sub-processor is contractually bound by the same obligations as the main processor.
Liability towards the controller: the processor is liable for the breaches of its sub-processors (art. 28.4 RGPD).

As a controller, the recommendation is to require the supplier to provide a public and up-to-date list of sub-processors (accessible URL) with the country of location and purpose. That makes transparency towards the final customer and traceability in the event of an incident easier.

Server location and international transfers

Knowing where the servers physically are that store the restaurant's bookings is a specific and reasonable question. The usual options:

Servers in the EU / EEA: no international transfer. Ordinary RGPD regime.
Servers in countries with an adequacy decision (art. 45 RGPD): for example, the United Kingdom (with specific regime), Switzerland, Canada (in part), Japan, South Korea. Legitimate transfer without additional safeguards.
Servers in the US: since July 2023, an adequacy decision based on the Data Privacy Framework (DPF). Transfers to suppliers adhering to the DPF are covered by art. 45 RGPD. If the supplier is not adhered, Standard Contractual Clauses (art. 46 RGPD) and, depending on the case, supplementary measures following a transfer impact assessment (TIA) must be applied.
Servers in other third countries without adequacy: strict regime of art. 46 RGPD — Standard Contractual Clauses, binding corporate rules — and, failing that, the exceptional grounds of art. 49 RGPD.

The restaurant's privacy policy must state whether there are international transfers and what safeguard supports them. That information is obtained from the supplier by contract; if it is not provided, there is a problem.

Information security: what the supplier must guarantee

Art. 32 RGPD requires technical and organisational measures appropriate to the risk. For a TPV or booking supplier, that translates, at a minimum, into:

Encryption of data in transit (HTTPS/TLS) and, where proportionate, at rest.
Robust authentication: passwords with demanding policies and, preferably, a second factor for administrative accounts.
Role-based access control both for the restaurant's staff and for the supplier's internal staff.
Traceability / logs of access and sensitive operations, with a reasonable retention period.
Backups and documented restoration tests.
Continuity and incident management plan.
Compliance with recognised standards (ISO/IEC 27001, SOC 2, Esquema Nacional de Seguridad where applicable).
Breach notification to the controller within a timeframe that allows it to comply with art. 33 RGPD vis-à-vis the AEPD (in practical terms, without undue delay and certainly with margin for the controller's indicative 72 hours).

If the supplier handles payment data (PAN, dates, CVV), compliance with the PCI-DSS standard is added by the payment networks.

At the end of the contract: return or export, do not simply destroy

This is one of the most expensive mistakes in hospitality: changing TPV or booking supplier and discovering, weeks later, that the history of customers, bookings and invoicing has been left in a system that can no longer be accessed.

Art. 28.3.g RGPD requires the processor, once the service has ended, to delete or return the personal data to the controller, at the controller's choice, and to delete the existing copies, save for retention required by law. The correct practice is:

Request the export of the data in a usable format (CSV, JSON, structured database).
Verify the integrity of the export before regarding the migration as complete.
Request deletion in writing from the outgoing supplier's systems, including backups, within the timeframes the supplier can document.
Keep evidence of the export and of the deletion request.

The restaurant needs that data to comply with its own legal retention periods — tax, employment, accounting — and to avoid losing its customer history. A supplier that only offers to destroy without allowing prior export does not comply with art. 28.3.g; a serious one makes that exit easy.

Regional and sectoral rules may affect the retention periods that the controller must apply after receiving the data.

Audits and inspection rights

Art. 28.3.h RGPD recognises the controller's right to obtain from the processor all the information necessary to demonstrate compliance, and to carry out audits, including inspections, by itself or by an authorised auditor. How this is exercised without overwhelming a supplier with hundreds of customer restaurants:

Recognised certifications (ISO/IEC 27001, SOC 2, ENS Medio or Alto, Privacy by Design scheme): the supplier makes them available.
Independent audit reports (SOC 2 type II, for example) on the relevant controls.
Security and privacy questionnaires answered by the supplier.
On-site audit, reserved for situations with justified cause and with reasonable advance notice.

The contract must spell out the channel and the frequency. A blanket refusal of any audit mechanism is incompatible with art. 28.

How to choose a responsible supplier: checklist

#	What to verify before signing
□	Has a processor contract (DPA) that complies with art. 28.3 RGPD.
□	Identifies the internal data protection contact (name or function + contact email).
□	Publishes the list of sub-processors and notifies changes.
□	Indicates the server location and, if there are international transfers, the legal basis (adequacy decision, DPF, SCCs).
□	Describes its security measures (encryption, authentication, role-based access, logs, backups).
□	Holds recognised certifications or equivalent reports.
□	Notifies breaches to the controller without undue delay.
□	Allows export of data in a usable format at the end of the contract and only then deletes them.
□	Does not reuse the restaurant's data for its own purposes without an adequate and independent legal basis.
□	Enables a proportionate and documented audit channel.

The TPV and the booking system are critical tools for daily operations, but also sensitive information assets. Choosing the supplier well, signing the right contract and having a clear exit is what turns data protection into part of the craft, and not into an added concern.

"El día que cambias de TPV descubres si firmaste un buen contrato. Si tu proveedor solo sabe borrar, no es un encargado serio; un encargado serio te devuelve los datos antes."

Mario P. Talamillo · Managing Partner, Certix®

If you run a restaurant or restaurant group and want to review your data protection documentation, at Certix we work specifically with hospitality. No salespeople: from the very first contact, you will speak with a specialist.

Data protection guide for restaurants

This content is for general guidance and information purposes only; it does not in any case constitute specialised legal advice. Regional sectoral rules may extend or modify the deadlines and requirements of national legislation. The application of the rules to each specific case requires individual analysis.