A European hotel is the data controller for every guest record that moves between its PMS and its guest-room technology, and that responsibility does not transfer to the integrator or the vendor. In practice this means the hotel needs a data processing agreement with each vendor that touches guest data (PMS, electronic locks, Wi-Fi, casting), a defined retention period for the profile fields that flow into room systems, documented limits on where cameras can point in public and semi-public areas, and a clear record of what happened to a guest's data at checkout. None of this is exotic engineering — it is paperwork and configuration decisions that should be settled before a system goes live, not after a guest files a subject access request.
This matters more in Europe than it does in the US market because GDPR puts legal weight behind data-subject rights that most US hotel brands treat as a courtesy. Cave Group designs hotel technology for properties in Monaco, on the Côte d'Azur, in Italy, Greece, and Poland, and the paperwork trail behind the system is as much a part of the design as the wiring behind it — see how that work is scoped on the Europe page.
What guest data actually moves from the PMS into room systems?
A PMS like Oracle's OPERA Cloud stores guest profiles that go well beyond name and room number — language, preferences, loyalty membership, negotiated rates, and in some cases a scanned identification document, all linked to a single guest profile record. OPERA Cloud's documentation describes this profile as the record that "plays a part in almost all the activities you perform in OPERA Cloud," and notes that profiles can be anonymized — masking or removing personal information from the record — and that a guest or contact requesting a copy of their data can be given a Profile Details Report, with that disclosure logged under a dedicated activity type in the system's changes log. That built-in reporting function is exactly what a hotel needs to answer a guest's access request, so it is worth confirming at commissioning that staff know how to generate it.
Only a subset of that profile needs to reach room systems at all. A lock encoder needs a room number, a stay date range, and a credential — not a loyalty tier or a negotiated rate. A myRoom XC or Crestron guest-room controller needs occupancy and checkout status, not a guest's full contact history. Scoping the PMS interface so it sends only what each downstream system needs is a design decision worth raising with your PMS integrator before go-live, not an afterthought.
What does Mews or a cloud PMS promise about guest data handling?
Mews, a cloud PMS increasingly used in European boutique properties, documents its own compliance posture directly: the platform states it is "GDPR, ISO27001, NF525, PCI DSS and SOC 2 Type 2 compliant" and that it gives "guests control" to "manage their personal data, request profile deletion and select which data can be shared with the property," according to Mews's security page. That guest-facing deletion control is a feature the hotel should understand before opening — if a guest requests deletion through the PMS, the hotel needs to know whether that deletion also reaches the lock system, the Wi-Fi captive portal logs, and any casting device history, or whether those systems need a separate manual step.
This is the gap integrators should close at handover: a PMS vendor's own compliance certifications (GDPR, SOC 2, PCI DSS) cover the PMS platform itself, not the downstream systems the PMS talks to. The hotel, as controller, still needs a DPA with the lock vendor and the network vendor separately, even if the PMS vendor's paperwork looks complete.
Where do access-control credentials and logs fit in?
Electronic lock platforms generate their own category of personal data: access logs tied to a guest's stay, and increasingly mobile or cloud-issued credentials. Salto describes its role as "securely managing sensitive data such as user credentials, access logs, and system configurations" across its "cloud-based access platforms," according to Salto's security and data protection page. That access-log data is personal data under GDPR when it is tied to an identifiable guest, which raises the same retention question as the PMS profile: how long should a hotel keep a log entry showing a specific guest opened room 412 at 11:47pm, and who can pull that log if asked? Those retention periods and access permissions belong in the DPA with the lock vendor, agreed before the system goes live. For how a stay record becomes a door credential in the first place, see SALTO Access Architecture: Reservation to Door, Mapped.
What should an integrator hand over at commissioning?
At minimum, the handover package should let hotel staff answer three questions without calling the integrator: what guest data lives in each system, how long it is kept, and how to delete or export a specific guest's record on request. That means a list of every vendor touching guest data (PMS, locks, Wi-Fi, casting, and any voice device), the DPA status with each one, the retention setting configured in each system, and the steps to run a deletion or export. Casting devices and voice assistants in guest rooms deserve their own line in that handover: confirm with each manufacturer what gets reset between stays and whether a prior guest's paired devices, viewing history, or voice recordings can persist into the next occupancy, since this is a configuration setting to verify rather than something that can be assumed solved by default.
Camera placement in hotel public areas — lobbies, corridors, elevator lobbies — is a separate compliance question from guest-room data, governed by notice and purpose limitation rather than a DPA, and it is worth raising directly with whoever is advising the property on GDPR compliance before cameras go in rather than after. Cave Group's guest-room automation work across Monaco, the Côte d'Azur, Portofino, the Athens Riviera, Mykonos, Lake Como, and Warsaw is scoped from the drawings and commissioned with the qualified local firm each country requires; see the Europe service page for how that project sequencing works, or the general approach on hotel PMS integration.
Frequently asked questions
Who is the data controller for guest data in a hotel's technology systems?
The hotel is the data controller. The PMS vendor, lock vendor, and network vendor are processors acting on the hotel's instructions, which means the hotel needs a data processing agreement with each one rather than relying on the vendor's own compliance certifications to cover the relationship.
Does OPERA Cloud have a built-in way to answer a guest data request?
Yes. OPERA Cloud's documentation describes a Profile Details Report that can be generated for a guest or contact requesting a copy of their data on file, and that disclosure is tracked in the system's changes log under a dedicated activity type.
Can a guest request deletion of their data directly through the PMS?
With Mews, yes — the platform states that guests can manage their personal data and request profile deletion directly. Whether that deletion also removes the guest's access logs on the lock system or Wi-Fi captive portal is a separate question to confirm with each vendor, since PMS-level deletion does not automatically reach every downstream system.
Are electronic lock access logs considered personal data under GDPR?
When a log entry is tied to an identifiable guest, yes. Salto's own documentation describes its platforms as managing "user credentials, access logs, and system configurations," which makes retention period and access permissions for that log data a point to settle in the DPA with the lock vendor.
What should a hotel ask its integrator before guest-room systems go live?
Ask for a list of every vendor touching guest data, confirmation that a DPA is in place with each one, the retention period configured in each system, and a tested procedure for exporting or deleting one guest's data on request — plus confirmation of what resets on casting and voice devices between stays.