GDPR and guest data

Guest data is some of the most sensitive information a hotel handles. A name, a room, a set of dates and a list of requests add up to a fairly complete picture of someone's life over several days. That is why the GDPR treats it more strictly than an ordinary email address, and why choosing hotel software is not only a product decision. It is a compliance decision too.

This guide explains what the GDPR asks of a hotel and its provider, how Estevano protects guest data and which six questions to put to any provider before you sign. With one commitment: we won't claim certifications we don't have. ISO and SOC 2 type questions are discussed with each client who asks.

Why guest data is so sensitive

A hotel brings together three things that would be sensitive on their own and are far more so together:

• Identity. First name, surname, language and, where the law requires it, an ID document. Enough to identify the person beyond doubt.
• Whereabouts. The room and the arrival and departure dates. They say where that person is right now.
• Behavior. Requests, allergies, tastes and complaints. Enough to infer habits, health and preferences.

A leak here is not an abstract risk. It means knowing who is in which room, whether they are alone, what they are allergic to and what time they ordered their last meal. That is why it pays to be strict.

What the GDPR asks of the hotel and the provider

Under the GDPR, the hotel is the data controller and the provider is the data processor. Each has its own role, but both are accountable. The non-negotiables:

• A clear legal basis. Use the data for what the guest expects (their stay and their requests) or, for anything else, with their explicit consent.
• Data minimization. Ask only for what is needed. If a guest doesn't need to show ID to ask for a towel, don't ask for it.
• A data processing agreement. It sets out how the provider handles the data, where it is stored and what happens if there is an incident.
• Guest rights. Access, correction, deletion and portability. The provider has to make them technically possible.
• Breach notification. If something goes wrong, there are 72 hours to notify the data protection authority, and the people affected where required.

That is the theory. What matters is how it turns into an architecture that actually protects guests, not one that just passes an audit.

How Estevano does it

Estevano was built this way from the start. Without claiming certifications we don't have:

• The guest PIN, hashed on the server. The PIN guests use to open the app and confirm phone requests is stored with bcrypt. It never travels in plain text and can't be recovered from the database.
• Lockout after failed attempts. If someone tries to guess a PIN by trial and error, the system locks them out. The check always happens on the server, never on the phone.
• Every hotel isolated. The database enforces row-level security (RLS): a member of staff or a guest at hotel A cannot read data from hotel B, not even through a bug in the app. It is not a screen filter that can be bypassed. It is a barrier in the database itself.
• Data hosted in the EU. The hotel's database and files are stored on servers in the European Union, encrypted at rest and in transit.
• Little personal data. Estevano doesn't need a guest's ID or payment details to run the day. It works with the room, the PIN and operational data. The less you collect, the less you have to protect.
• Access and deletion. Today this is a manual process: at the hotel's request, and under the data processing agreement, the Estevano team exports or deletes a guest's data.

What we don't claim: we don't currently hold a published ISO 27001 or SOC 2 Type II certification. Serious compliance conversations happen with each client, with their own data processing agreement and evidence for every control on this list.

Compliant on paper, or built to isolate

Some providers are compliant on paper: a polished agreement, a privacy policy and a security page, while underneath every hotel shares the same tables with no real isolation. That is legally shaky and fragile in practice: one badly written query and a hotel sees another hotel's data.

Being built to isolate is different: the database itself stops one hotel from reaching another's data, whatever the app code does. It is a difference in architecture, not in marketing. Estevano was built this way from day one because it was made for many hotels and many brands.

Where AI fits under the GDPR

When a guest writes to the AI concierge, the conversation is processed to understand what they want and act on it. Here the GDPR asks for two things: that guests know they are talking to an AI, and that their data is not used to train models without their consent.

With Estevano, guests know they are talking to the hotel's AI concierge, not to a person. Conversations are used to serve that guest, not as training material for third-party models. Language models are used through providers that commit not to train on customer data. To understand each message, the conversation goes through those providers, and that processing doesn't always happen inside the EU. It's exactly what you should ask any provider about.

Six GDPR questions to ask before you sign

If you are choosing software for your hotel, take these questions to the meeting and ask for specific answers:

1. How do you keep each hotel's data separate? You want to hear "row-level security in the database" or an equivalent, not "we filter by hotel in the code".
2. Where is the data processed and stored? The region (EU, US and so on), the cloud provider and whether any data leaves the EU.
3. How do you identify the guest? A hashed PIN, lockout after failed attempts and a server-side check. If the answer is "by room number" and nothing more, that is not identification.
4. Will you sign a data processing agreement with the GDPR details? Ask to see it before you sign the commercial contract.
5. How do you handle guest rights? Access, deletion and portability: what the process is and who runs it.
6. Is guest data used to train models? If the answer isn't a clear "no", keep looking.

The bottom line

GDPR compliance isn't bought with a marketing page. It shows in the architecture. Isolating every hotel, hashing the PIN, keeping data in the EU, collecting little personal data and having a clear process for guest rights are the foundations. Certifications come later, on top of those foundations, not instead of them.

To see how it all fits into the platform, take a look at the product or white label.