The PMS (Property Management System) is the hotel's operating system. It concentrates bookings, check-in, check-out, guest records, billing, consumption charges, loyalty, connection with the booking engine and, in many cases, with the channel manager, with the OTAs, with the payment gateway and with the system communicating to the Ministry of the Interior. Whoever provides that PMS is not a simple software vendor: it is someone who processes the hotel's personal data on its behalf. And that, in GDPR terms, has a specific name and a specific contract.
This guide reviews the processor regime (art. 28 GDPR) applied to the hotel sector: what the hotel must sign with its PMS provider, what safeguards to require, what happens with servers outside the EU, how access profiles should work and what happens to the database when the contract ends.
Why the PMS, the booking engine and the channel manager are processors
The GDPR differentiates two clear roles:
- Controller (art. 4.7): the party that decides the purposes and means of the processing. In this case, the hotel.
- Processor (art. 4.8): the party that processes personal data on behalf of the controller, following its instructions.
The PMS provider does not decide which guests the hotel rewards with loyalty, which preference is noted in the guest's record or which offer is sent. It executes what the controller needs: it records bookings, stores records, bills, synchronises availabilities. It is a processor. The same applies to the booking engine provider and to the channel manager when they process data on behalf of the hotel.
OTAs: a special case. When an OTA (Booking, Expedia, Hotels.com, etc.) captures the guest from its own platform, it decides the means and purposes of that acquisition: it acts as an independent controller in that phase. When it transmits the data to the hotel to execute the booking, the hotel becomes the controller of that data in its own operations. In certain specific functionalities the OTA may act as the hotel's processor; in others, both parties may face joint controllership scenarios. It is advisable to analyse the specific relationship with each OTA case by case and reflect it in the contract and in the information notice.
Also beware of a frequent scenario: if the PMS provider reuses the hotel's data for its own purposes (aggregated market analytics, benchmarking, marketing of the platform itself), in that part it no longer acts as a processor but as an independent controller, and must have its own legal basis. It is advisable to read the terms carefully and clarify this by contract.
The art. 28 GDPR contract: minimum content (art. 28.3)
Art. 28.3 GDPR requires the controller-processor relationship to be documented in a contract or other binding legal act, with a fixed 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 must be regulated |
|---|---|
| Subject matter and duration | What service the PMS provides and for how long it processes data on behalf of the hotel. |
| Nature and purpose | Why the data are processed under the service (bookings, check-in, billing, loyalty, communications). |
| Type of data and categories of data subjects | Guest identification, contact, stay data, payment data, preferences, staff records with access to the system. |
| Art. 28.3.a — Documented instructions | The processor only processes data following the controller's documented instructions, including 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 measures of art. 32 GDPR appropriate to the risk (encryption, authentication, access control, backups, ability to restore). |
| Art. 28.3.d — Sub-processors | Authorisation regime and notification to the controller; sub-processors assume the same obligations. |
| Art. 28.3.e — Assistance with rights | Assist the controller through technical and organisational measures to handle data subjects' rights (arts. 15–22 GDPR). |
| Art. 28.3.f — Auxiliary compliance | Help the controller to comply with the obligations of arts. 32–36 GDPR (security, breach notification, DPIA, prior consultation). |
| Art. 28.3.g — End of contract | Return or delete the data at the controller's choice and delete copies, except where retention is required by law. |
| Art. 28.3.h — Information and audit | Make available to the controller the information necessary to demonstrate compliance and allow audits or inspections. |
Many providers have their own contract model (DPA, Data Processing Addendum). That does not exempt the hotel from reading it: the DPA must fit with the content of art. 28.3 GDPR and not contradict it. And it must cover, in addition to the PMS, the other contracted modules (booking engine, channel manager, integration with SES.HOSPEDAJES, payment gateway) or be accompanied by the corresponding specific DPAs.
Sub-processors: when the PMS relies on AWS, Azure or Google Cloud
The vast majority of cloud PMS providers 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 GDPR require:
- Controller authorisation, specific or general (usually formalised in the initial contract with a list of sub-processors already accepted).
- Prior information to the controller of any change or addition of new sub-processors, with an opportunity to object.
- Same regime: the sub-processor is bound, by an analogous contract, to the same data protection obligations as the main processor.
- Processor's liability to the controller for breaches by its sub-processors (art. 28.4 GDPR).
As a controller hotel, it is advisable to require the PMS provider to publish a public and up-to-date list of sub-processors (accessible URL) with country of location and purpose. That facilitates transparency vis-à-vis the guest and traceability in the event of an incident.
International transfers: DPF and Standard Contractual Clauses
Knowing where the servers of the PMS and its sub-processors are physically located is a concrete and reasonable question. The usual options:
- Servers in the EU / EEA: no international transfer. Ordinary GDPR regime.
- Servers in countries with an adequacy decision (art. 45 GDPR): United Kingdom (with a specific regime), Switzerland, Canada (partially), Japan, South Korea, among others. Lawful transfer without additional safeguards.
- Servers in the US: since July 2023, adequacy decision based on the Data Privacy Framework (DPF). Transfers to providers certified under the DPF are covered by art. 45 GDPR. Before contracting, it is advisable to verify active certification of the provider (and of its US sub-processors) on the official DPF list. If the provider is not certified, Standard Contractual Clauses (art. 46 GDPR) must apply and, depending on the case, supplementary measures after a transfer impact assessment (TIA).
- Servers in other third countries without adequacy: strict regime under art. 46 GDPR — Standard Contractual Clauses, binding corporate rules — and, failing that, the exceptional grounds of art. 49 GDPR.
The hotel's privacy policy must state whether there are international transfers and what safeguard covers them. That information is obtained from the provider by contract; if it is not provided, there is a problem.
Security and access profiles: a role per hotel area
Art. 32 GDPR requires technical and organisational measures appropriate to the risk. In a well-configured PMS, that translates, as a minimum, into:
- Encryption of data in transit (HTTPS/TLS) and, where proportionate, at rest.
- Robust authentication: passwords with demanding policies and, preferably, second factor for administrator accounts.
- Role-based access profiles (see table below): each hotel area sees only what is necessary.
- Access logs and logs of sensitive operations, with a reasonable retention period and consultation by management/controller.
- Backups and documented restore 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 without undue delay, with enough margin for the hotel to comply with art. 33 GDPR before the AEPD (72 hours as a guideline from awareness).
- PCI-DSS if the PMS or its integrations process card data.
| Profile | What they access | What they do not |
|---|---|---|
| Reception | Guest record, booking, check-in, account charges, SES.HOSPEDAJES communication | Payroll, global reporting, system configuration |
| Housekeeping / Floors | Room status and occupancy, cleaning incidents | Payment data, full guest records, loyalty |
| F&B (restaurant / bar) | Consumption charges to room, table reservations | Full payment data, HR data |
| Maintenance | Technical incident reports by room or area | Guest personal data, financial data |
| Management / Administration | Global reporting, configuration, user management, logs | Restrictions according to internal policy and the principle of least privilege |
A PMS that only offers a single shared generic user does not reasonably comply with art. 32 GDPR and does not allow access traceability. Each person at the hotel must have their own user with permissions adjusted to their role.
At the end of the contract: return or export, do not just destroy
This is one of the most expensive mistakes in the hotel sector: changing PMS and discovering, weeks later, that the history of guests, bookings, billing and traveller register has been left in a system that can no longer be accessed.
Art. 28.3.g GDPR obliges the processor, once the service ends, to delete or return personal data to the controller, at the controller's choice, and to delete existing copies, except where retention is required by law. The correct practice is:
- Request the export of the data in a useful format (CSV, JSON, structured database). That export must include guest records, booking history, billing, traveller register, loyalty and relevant communications.
- Verify the integrity of what has been exported before considering the migration closed. Check that everything necessary for the hotel's statutory periods (tax, employment, RD 933/2021) has been exported.
- Request in writing the deletion from the outgoing provider's systems, including backups, within the periods that the provider can document.
- Keep evidence of the export and of the deletion request.
A provider that only offers to destroy without allowing prior export does not comply with art. 28.3.g GDPR. A serious one facilitates the exit in a structured and useful format. Regional and sectoral regulations may affect the retention periods the hotel must apply after receiving the data.
Audits and inspection rights
Art. 28.3.h GDPR 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 through an authorised auditor. How this is exercised without overwhelming a provider with hundreds of hotel clients:
- Recognised certifications (ISO/IEC 27001, SOC 2, ENS where applicable): the provider makes them available to the controller.
- Independent audit reports (SOC 2 type II, for example) on the relevant controls.
- Security and privacy questionnaires answered by the provider.
- On-site audit, reserved for situations with justified cause and with reasonable advance notice.
The contract must specify the channel and frequency. Refusing en bloc any audit mechanism is incompatible with art. 28 GDPR.
How to choose a responsible provider: checklist
| # | What to verify before signing |
|---|---|
| □ | Has a processor contract (DPA) complying with art. 28.3 GDPR for the PMS and integrated modules. |
| □ | Identifies the internal person responsible for data protection (name or role + contact email). |
| □ | Publishes the list of sub-processors (AWS / Azure / Google Cloud and others) with country and purpose, and notifies changes. |
| □ | Indicates server location and, if there are international transfers, the legal basis (adequacy decision, DPF, SCCs). |
| □ | Active DPF certification verifiable on the official list, if it processes data in the US. |
| □ | Allows the creation of role-based access profiles (reception, housekeeping, F&B, maintenance, management) with access logs. |
| □ | Robust authentication with password policies and second factor available for administration. |
| □ | Encryption in transit and, where appropriate, at rest. |
| □ | Holds recognised certifications (ISO/IEC 27001, SOC 2) or equivalent reports. |
| □ | Notifies breaches to the controller without undue delay. |
| □ | Allows exporting the complete database at the end of the contract and only then deletes it. |
| □ | Does not reuse the hotel's data for its own purposes without an appropriate and independent legal basis. |
| □ | Provides a proportionate and documented audit channel. |
The PMS is the most critical tool for the hotel's day-to-day operations, but also the most sensitive information repository: guests, traveller register, payment data, loyalty, staff. Choosing the provider well, signing the right contract and having a clear exit is what turns data protection into part of the hotel trade, and not into an extra concern.
"El día que cambias de PMS descubres si firmaste un buen contrato. Si tu proveedor solo sabe borrar, no es un encargado serio; un encargado serio te devuelve la base de huéspedes antes."
Mario P. Talamillo · Managing Partner, Certix®
If you manage a hotel, hostel or accommodation chain and want to review your data protection documentation, at Certix we work specifically with hotels and accommodation providers. No salespeople: from the first contact, you will speak to a specialist.
Data protection guide for hotels
This content is merely indicative and informative; it does not in any case constitute specialised legal advice. Regional sectoral regulations may extend or modify the periods and requirements of the national rule. The application of the regulations to each specific case requires individualised analysis.