What your technology team will want to ask.
We process guest data on the hotel’s behalf. This page sets out, plainly, the practices and the responsibilities of each party.
Clearly defined roles
The hotel is the controller of its guests’ data. Guestdash acts as processor, on the hotel’s instructions, under a data processing agreement.
Hosting in the European Union
The production infrastructure is hosted in the European Union. For clients in Brazil, the location is set contractually.
Encryption in transit and at rest
All traffic is encrypted in transit, and data is encrypted at rest in the database and in the backups.
Access by role
Users, roles and API keys managed at group level, with visibility limited to what each role needs to see.
Auditable log
Actions on the platform are logged, allowing an audit of who did what and when, including access to guest data.
Isolation by property
Each property has its own context and knowledge base. We do not mix data between clients.
AI with no cross-training
We do not use one client’s guest data to train general-purpose models. Each agent’s knowledge belongs to the hotel.
Declared sub-processors
The list of providers that process data on our behalf is made available and kept up to date, under a duty of confidentiality.
Backups and recovery
Periodic backups with a tested recovery procedure, and recovery objectives defined in the contract.
Access control and authentication
Who logs in, from where, when and with what proof.
Two-step verification
Beyond the password, login can require a one-time code generated by an authenticator app — Google Authenticator, Microsoft Authenticator, Authy and equivalents. It can be made mandatory for the whole environment, with recovery codes in case the device is lost.
Single sign-on (SSO)
Login with the hotel’s corporate credentials, via OIDC — compatible with Google Workspace, Microsoft Entra and Okta. Users are created automatically on first access, with the default role set by the hotel. With SSO active, the second factor is managed by the hotel’s identity provider.
IP-restricted access
Each environment can limit access to authorised addresses and network ranges. Outside the list, access is blocked — at login and on every request. With safeguards so nobody locks themselves out.
Time windows
Access can be limited to defined days and hours — by user, by role or for the whole environment, always in the property’s time zone. At the end of the window, the session is actually closed, with a configurable warning to finish what is in progress.
Authorised email domains
Only accounts from the domains defined by the hotel can enter — for example, only @yourhotel.com addresses. The rule applies at login, on environment switching and when inviting new users.
Access logs
Who logged in, from where and when, with the outcome and reason for each block — unauthorised IP, outside hours, second factor. With filters, per-event detail, CSV export and retention configurable by the hotel.
The questions we always get.
Who is the controller of the guests’ data?
Where is the data hosted?
Do you use guest data to train AI models?
Can you audit who accessed what?
Do you have two-factor authentication and SSO?
Can you restrict access by network or by time?
Send us your security questionnaire.
We answer the questionnaire and provide the data processing agreement before any commitment.