Your guest list and your staff files go in here, pay rates included. So it is fair to ask who can open them and what stops everyone else. This page answers that, and covers what the system does when a guest asks to be deleted.
There is no security tier. A pub with one site gets the same controls as a group with fifty.
Hiding a button stops an honest member of staff clicking it, and that is all it stops. The grid that says what each role may do is applied to every read and every write, which is what makes it safe to give a supervisor a login in the first place.
Most arguments in a pub come down to nobody being able to say what happened. An audit trail settles more of them than another approval step would.
A privacy policy tells guests they can see the data held on them and have it erased. These are the parts of Hendra One that let you do it on the day a guest asks.
The booking widget, the feedback form and the pre-order links are on the open internet by design. The worry there is scripts and bots.
A pub holds more sensitive data than most people expect. On the guest side there are names, phone numbers, dietary and allergy notes, and cards kept on file for no-show fees. On the staff side there are dates of birth, National Insurance numbers, pay rates and right-to-work documents. In most pubs it 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”.
Putting all of it in one system only helps if the permissions hold. So the grid works action by action and is enforced on our servers, and pay starts at No even for the people running the site. Having fewer places for the data to sit is worth a great deal, as long as you can say exactly who can reach it.
Whether booking software is GDPR compliant depends partly on how you use it, because each venue is the data controller for its own guests, but the software has to make it possible. For GDPR, hospitality software should be able to export what it holds on a guest, erase them properly when asked, respect their marketing consent and show you which of your team can open their record. For pub software security, that last part should be a grid you can read, checked on the server where nobody can get round it.
If you have a security question this page does not answer, ask it on a demo and it will be answered by the person who wrote the rules.
The legal side of the same ground, for whoever looks after it at your end.
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.
All of it is in the same £100 a site.
A 30-minute walkthrough with someone who has run a service. Email us and we will arrange a time that suits you.