You are putting your guest database, your staff files and your pay figures into this. So the interesting questions are who can reach them, whether that is actually enforced, and what happens when someone asks you to delete them.
A permission that only hides a button is a suggestion. The grid that decides what a role can do is applied to every read and every write, which is what makes it safe to give a supervisor an account at all.
Most disputes in a pub are not about malice. They are about nobody being able to say what happened. An audit trail is worth more than another approval step.
A privacy policy is a promise. What matters is whether the system can actually do the thing the promise describes on the day someone asks.
Your booking widget, feedback form and pre-order links are open to the internet by definition. They are the parts that need protecting from automation rather than from your staff.
A pub holds a surprising amount of sensitive data. Guest names, phone numbers, dietary and allergy notes, card details on file for no-show fees. Staff dates of birth, National Insurance numbers, pay rates, right-to-work documents. In most pubs that data is spread across a booking system, a spreadsheet, a WhatsApp group and a folder in the office, and the honest answer to "who can see the pay file" is "whoever knows where it is".
Consolidating it into one system is only an improvement if the permissions are real. That is why the grid is per-action, why it is enforced on the server, and why pay defaults to No even for the people running the site. Fewer places for the data to be is worth a great deal, but only alongside a genuine answer to who can reach it.
The full detail is in our privacy policy and data processing agreement. If you have a security question that is not answered here, ask it on a demo: it will be answered by the person who wrote the rules.
That the check happens where it cannot be bypassed. Hiding a button in the interface stops an honest person clicking it; it does not stop anyone who opens the developer tools. Every read and write in Hendra One is checked on the server against the permission grid for that role, so a hidden feature is genuinely unavailable rather than merely invisible.
Only roles you have granted it to, per action. Pay visibility defaults to No, including for site managers. Guest data is scoped to the sites a person has access to. Every sensitive reveal, such as a password from the shared vault, is logged with who looked and when.
Both are built in rather than being a manual database job. There is a subject-access export for a guest, and an erasure that reaches the payment records held at Stripe as well as the booking history. Staff records are archived for six years and then anonymised, with restore available in the meantime.
Yes. Public endpoints are rate limited and carry app attestation, so an automated script cannot sit filling your diary with fake covers or harvesting availability.
Data is tenant-isolated: one company cannot read another, enforced by the same server-side rules rather than by a filter in the interface. Documents such as contracts and right-to-work scans are held in private storage, not on public links.
A 30-minute walkthrough with someone who has run a service, not a sales deck.