How to evaluate the security of a point of sale for a hotel before you sign

When you choose the system that will run your hotel restaurant, the demo always looks good: the screen is fast, the server rings up an order in seconds, the room charge appears with a pleasant animation. What almost nobody shows you in the demo is what happens the day an employee tries to see something outside their role, or someone asks to delete a line from a shift close that was already closed. That day is the one that decides whether you chose well.

Why security is not a checkbox on the comparison sheet

Most comparison sheets for a hotel restaurant system have a row that says “security” with a checkmark. That checkmark says nothing. A system can have passwords, roles and even a lock icon, and still let any server with access to the tablet edit a ticket that was already paid, or let a manager who left the property six months ago still have an active session on some forgotten device.

Real security for a hotel restaurant’s point of sale is judged on three concrete fronts: who can do what, and who decides that; whether what already happened can be altered afterward; and how well protected guest data is as it travels between the tablet, the server and the front desk system. Let’s go through the three.

Where permissions live: on the server, not in the app

There is a huge difference between a system that hides a button on the server’s screen and a system that blocks the action on the server. In the first case, the “apply discount” button simply does not appear on the server’s tablet, but if someone knows the right way to send the order directly, bypassing that screen, the discount goes through anyway. In the second case, it does not matter where the request comes from: the server asks who is making it and checks whether that person has the permission, and if not, it rejects the request regardless of screen, device or app version.

This distinction is not a minor technical detail. Hiding a button in the interface protects against the honest mistake of a server who should not have touched something. Verifying the permission on the server protects against the person who knows exactly what they are doing and is looking for a shortcut. A hotel with staff turnover, unsupervised night shifts and devices that sometimes sit unlocked needs the second protection, not only the first.

The question to ask the vendor is direct: if I request an action my role does not allow, from another device or even a direct call to your system, does your server reject it, or does it just trust that the app was not going to let me do it? If the answer is slow or sounds evasive, you already have your answer.

An immutable audit log: the key phrase is “cannot be edited”

Every serious system for a hotel restaurant has an audit log: a record of who did what and when. The question that separates a useful log from a decorative one is whether that record can be modified or deleted after it is created. A log that can be edited is not evidence of anything, because anyone with enough access can rewrite history before someone reviews it.

An immutable audit log works differently: every event that happens in the system, from opening a table to applying a comp or voiding a dish already sent to the kitchen, is written once and stays there forever, no matter who reviews it later or with what level of access. Fixing a mistake does not erase the original record: it adds a new event saying what was fixed, by whom and why. The full history stays visible, mistake included.

Why this matters more in a hotel than in a standalone restaurant

A hotel restaurant carries an extra layer of risk that a standalone restaurant does not: room charge moves money between the restaurant and the guest folio, and that movement ends up on the statement the front desk hands the guest at check-out. If someone can silently edit a charge already posted to a folio, it is not only the restaurant’s internal control that breaks: it opens the door to a guest dispute that nobody will be able to resolve, because there will be no way to reconstruct what actually happened.

Encryption: in transit and at rest, not just in the sales pitch

When a vendor says “we use encryption”, the follow-up question is at which moments. There are two distinct moments and both matter. The first is in transit: when the server’s tablet talks to the server, when the server talks to the front desk system to verify a folio, when someone opens the reports panel from their phone. That traffic must travel end-to-end encrypted, so that if someone intercepts the hotel network they see nothing useful.

The second moment is at rest: data stored on the server, including payment card numbers when the system processes them. A serious vendor never stores the full card number in plain text in any database, and works with a payment processor certified to the card industry standard, so that sensitive data never lives exposed inside the restaurant system.

• Encrypted traffic between the server’s tablet, the server and the front desk system.
• Passwords stored with a one-way function, never in plain text.
• Card numbers processed by a certified third party, never stored in full inside the restaurant system.
• Backups encrypted too, not only the live database.

Access keys by property: one hotel should never see another hotel’s data

If the system you are evaluating serves more than one hotel, the next question is mandatory: what separates your data from the property across town that uses the same vendor? The right answer is that every property has its own access key, and that neither a poorly written query, nor a human mistake, nor a loosely configured permission can mix the data of two different properties. This is called isolation by property, and it has to be guaranteed by the system’s design, not by the good faith of whoever administers it.

Ask specifically how that isolation is implemented. A vendor who answers with technical clarity, mentioning that every request to the server carries the property’s identity and that the server validates it before touching any data, builds trust. A vendor who answers “don’t worry, we handle that” without explaining how, does not.

Ten questions to ask the vendor before you sign

1. Are permissions verified on the server, or only hidden on the app screen?
2. Can the audit log be edited or deleted by someone with administrative access?
3. What gets recorded when a mistake is fixed: only the final state, or also the original error?
4. Does traffic between the tablet, the server and the front desk system travel encrypted?
5. Where and how are card payments processed, and who holds the relevant certification?
6. How is my property isolated from other properties using the same system?
7. Who inside your company can see my operational data, and under what justification?
8. What happens to my data if I stop being a customer: is it deleted, kept, for how long?
9. Do you have a documented process for when you detect an improper access attempt?
10. Can I request the full audit history of my property at any time?

A vendor does not need a huge security department to answer these ten questions well. They need to have thought about them before you asked, and the answers have to be specific, not generic.

An illustrative example of the cost of missing an audit log

The figures below are made up to show the calculation; they do not describe any real property. Imagine that a shift close is short by some amount and nobody can explain where the difference came from because the previous system allowed a ticket to be edited after payment without leaving a trace of what it said before.

In the example, the missing immutable log not only leaves the original 1,850 unexplained: it adds 1,800 more in management and controller hours trying to reconstruct something a system with real auditing would have shown in a one-minute report. With a log that cannot be edited, the same investigation takes the time it takes to open the ticket’s history and see exactly what happened, who did it and when.

Warning signs during evaluation

Some answers should make you pause before signing any contract with a point of sale vendor for your hotel restaurant.

• The vendor cannot explain at which layer permissions are verified, only says the system “is secure”.
• The audit log is described as just another report, not as a history that cannot be altered.
• There is no clear answer about isolation between properties when the system serves multiple hotels.
• Card handling never mentions a certified processor, only that “the system stores data securely” with no further detail.
• Nobody on the sales team knows who to route you to when you ask for the technical or security team.

What to do this week

1. Write out the ten questions from this guide and email them to your current vendor or the ones you are evaluating; ask for answers in writing, not on a call.
2. Ask for a test case: have someone try to edit a ticket already paid and show what the history records.
3. Check with your systems team whether traffic between your devices and the point of sale server uses an encrypted connection.
4. Review the contract to confirm card payments go through a certified processor, not through the restaurant’s own server.
5. If you operate more than one property, ask for a specific demonstration of how data is separated between them.
6. Keep the answers in writing; you will need them the day you have to reconstruct an incident.

Inn Restaurant builds these three protections into the design of the system, not as an optional layer: permissions verified on the server, an audit log that cannot be edited, and real isolation between properties. If you want to see it in practice, check the security page (Security and control) or book a 15-minute demo (contact) where we show you the live audit history.