Security & GDPR
The questions procurement asks.
Answered here rather than in a follow-up email, because these are the ones that decide whether a hotel group gets past a first meeting. Where the data lives, what stops one property seeing another, how long anything is kept, and who signs what.
- Frankfurt, European Union
- Isolation enforced by the database
- DPA per property
Residency
Guest records live in the EU
Guest data — names, room numbers, stays, orders, messages — is stored in Frankfurt, and the application runs in Germany. For a Maltese or European property that removes an entire category of question before it is asked, and it means a transfer-impact assessment is not part of your purchase.
It also has a practical edge nobody mentions in a brochure: latency. A guest on hotel Wi-Fi in Malta is talking to a machine in Germany rather than Virginia, and live order status feels immediate rather than approximate.
Isolation
One property cannot see another, and not because we remembered
The isolation is a database policy, not a WHERE clause somebody has to write correctly every time.
- Enforced on every query
- Row-level security applies the property boundary inside PostgreSQL, so it holds for the guest app, the staff app, the console, a scheduled job and anything built later. Repository code is deliberately forbidden from adding the filter itself: repeating it would hide a broken policy rather than expose one.
- A restricted role
- The applications connect as a role that cannot bypass those policies and does not own the tables. Even a serious application bug cannot read across the boundary, because the credentials it holds are not permitted to.
- Tested as an attacker, every build
- A suite connects as that same restricted role and tries to breach the tenant boundary, the department scoping and the order state machine. It has caught real bugs. A policy nobody tests is a policy nobody has.
- Departments too
- The same mechanism scopes a queue to its own department. A write a user is not entitled to make is filtered out rather than refused, which is worth knowing: a test that only asserts an exception passes by accident. We assert the state afterwards.
Personal data
Kept as briefly as the job allows
- Retention and purge
- A retention window per property, after which guest personal data is removed automatically. The number is agreed with you rather than assumed by us.
- Right to erasure
- A guest can be erased while the operational record stays: that an order happened and what it cost, without who placed it.
- Identity documents
- Where a property must collect identity or passport details, they are encrypted at rest and fall under the shortest retention of anything in the system.
- Malta guest registration
- Maltese law requires guest data submission. It is a requirement we design for explicitly with the property rather than something to be discovered after go-live.
- Notification consent
- A guest is asked for browser permission before anything can be sent, and installing the app and allowing notifications are asked as two separate questions, never on the same screen — plenty of people want one and not the other.
- No profiling across properties
- A guest at one hotel is not joined to a guest at another. Each property is a separate controller of its own guests’ data.
Access
Who can sign in, and for how long
A guest’s access ends at checkout plus a short grace period, and that is checked on every request rather than only at sign-in — a session minted at nine in the morning does not outlive the stay. Staff sign in with an email address and a password; the property is only asked for when the same address exists at more than one, and only after the password has been checked, so the picker cannot be used to discover which properties exist.
Two things we would rather tell you than have you find: staff two-factor authentication is outstanding and is on the list before a property with a large front office goes live, and the marketing site and demo environment are separate from any production property.
“A cross-tenant leak between two competing hotels is not a bug you recover from commercially. So it is not left to be remembered.”
Questions
Answered plainly
Where is guest data stored?
In Frankfurt, in the European Union. Not a United States region with a European label on it. The application servers sit in Germany as well.
What stops one hotel seeing another hotel’s guests?
Row-level security in PostgreSQL. Every table carries the property it belongs to, and the policies are applied by the database to every query, from every caller, including any future integration. The application connects as a restricted role that cannot bypass them. A test suite connects as that same role on every build and attempts to breach the boundary; if it ever succeeds, the build fails.
Is that different from how most systems do it?
Yes. The common approach is to add a property filter in application code. It works until one query forgets, and the failure is silent — you do not find out from an error, you find out from a customer. Putting it in the database means it cannot be forgotten, only removed deliberately.
How long do you keep guest data?
A retention window per property, after which guest personal data is purged automatically. The mechanism exists and takes the period as a setting; agreeing the number is part of your data processing agreement rather than something we pick for you.
Can a guest ask to be deleted?
Yes. Erasure removes the guest’s personal data while leaving the operational record — that an order happened, and what it cost — intact and anonymous, which is what both the regulation and your accountant need.
Do you sign a data processing agreement?
Yes, one per property. You are the controller of your guests’ data and we are the processor.
What is in a push notification?
Only the words to show and where to go. No order contents, no guest name, no room number. It travels through Apple’s or Google’s push service and lands on a lock screen in a public place, so anything private is fetched behind the session when the guest taps through.
Do you use guest data to train anything?
No. It is not used to train models and it is not sold, shared or pooled across properties.
Send us your security questionnaire.
We would rather answer it before a demo than after one. If something on it we cannot do, we will say so on the call.