Security & Your Data
Who can do what — and what happened when they did
RestioX ships the controls a restaurant group actually needs: staff roles built per action rather than per job title, records that stay branch-scoped whether or not a query remembered to filter, and an audit log that names the person, the action and the minute.
0
Card numbers held in RestioX — your gateway or terminal keeps them
Access control
A role for the job, not a role for the job title
Most restaurant software hands you three fixed roles and hopes your floor matches. RestioX lets you build the role you actually staff: a shift lead who can comp a dessert, a Friday-only waiter who can push orders to the kitchen and nothing else, a bookkeeper who reads reports and never sees a table. Permissions are set per module and per action, so the line between reading something and changing it is yours to draw.
- Custom staff roles, built per venue rather than picked from a fixed list
- Per-module and per-action permissions — viewing an order and voiding a line are separate rights
- Per-device registration for the staff app
- OTP login with throttling, so repeated attempts stop being useful long before they work
Permissions are checked on the server on every request. Hiding a button is never the only thing standing between a waiter and a refund.
The controls
Four things you can switch on before your first dinner service
None of these are add-ons or a higher tier. They are configuration screens in the admin, and they are worth an hour of someone’s afternoon on day one.
Custom roles and permissions
Build roles per venue and tick permissions module by module, action by action. Change the role and every account holding it changes with it — no editing twenty staff records by hand.
Registered devices
The staff app registers the device it runs on.
OTP login with throttling
One-time codes for sign-in, rate-limited so a stolen phone number does not turn into an unlimited guessing game against your account.
Audit log and print log
Who cancelled, who refunded, who discounted, who reprinted a bill — recorded with a timestamp, and kept for a retention window you set yourself.
Tenant isolation
The branch filter is not optional, because nobody types it
The usual way a group leaks data between its own branches is mundane: somebody writes a report query and forgets the branch condition. RestioX applies the restaurant and branch scope at the model layer, so the query that forgot is filtered anyway. And when the scope cannot be resolved at all — a background job with no session, a request that arrives without context — the answer is nothing, not everything.
- Deny by default — unresolved scope returns an empty result, never the whole table
# a report query written without a branch filter
SELECT * FROM orders WHERE status = 'completed'
# what runs, once the global scope is applied
SELECT * FROM orders WHERE status = 'completed'
AND restaurant_id = 12
AND branch_id = 4
# background job, no session, scope unresolved
SELECT * FROM orders WHERE 0 = 1 -- deny by defaultAuditability
The morning-after question, answered from one screen
Every service produces a handful of exceptions: a comped starter, a main voided after it was fired, a card refunded at the door, a price typed over for a regular. Each one is written to the action audit log with the person, the action and the timestamp, so the conversation the next morning starts from a record instead of four people’s memories.
Printing is logged too — every bill and kitchen ticket that left a printer and who asked for it, which is usually how a duplicate KOT gets explained. Retention is configurable, so you keep the history your own bookkeeping and local rules require, and no longer.
- Cancellations
- Refunds
- Voided items
- Discounts
- Price changes
- Reprints
Data protection
The unglamorous measures, actually switched on
A vault for other people’s keys
Marketplace and payment gateway credentials are stored encrypted rather than sitting in a settings table in clear text. The manager who connects an integration does not have to be able to read the secret in order to use it, and a database export does not hand over your gateway.
Signed inbound webhooks
Delivery marketplace and payment callbacks are checked against their signature before anything is written. A payload that arrives unsigned, or signed with the wrong key, is refused.
Payment hooks fail closed
If a payment callback cannot be verified, RestioX refuses it rather than marking the order paid on a maybe. An unverifiable payment is a payment that did not happen.
Hardened session cookies
Sessions are HttpOnly, SameSite and Secure — not readable from page scripts, and not carried along by a request that came from somewhere else.
CSRF protection
State-changing requests carry a token, so a page on another site cannot quietly make one of your signed-in managers act on its behalf.
What happens to your data
From the first tap at the till to the backup — and out again
- At the till
It is written with its owner
The record is created carrying the restaurant and branch it belongs to. That stamp is what every later read gets filtered against, for the whole life of the row.
- Immediately
Sensitive changes are logged
Cancellations, refunds, voids, discounts and price changes are appended to the audit log with the person who made them and the minute they did it.
- On your schedule
The database is backed up
Scheduled backups run on the interval you set, to the storage location you configure. Backup and storage are both admin settings, not a support request.
- When you need it
A backup is restored
Restore runs from the same module that made the backup, so recovery is a screen you have already seen rather than a ticket and a hopeful wait.
- Whenever you want
You take it with you
Reports export to Excel (and PDF for the sales report). Nothing here depends on your data being hard to remove.
- Eventually
Old entries age out
Audit-log retention is a setting rather than a default you inherit, so the history you keep is the history you decided to keep.
A health check reports on the database, the queue and whether storage is writable — so a backup that quietly stopped running is something you can see, rather than something you find out about later.
Payments and card data
What we hold, and what your payment provider holds
RestioX does not process card payments itself. The gateway or card terminal you configure does that, and the card data stays with them. What RestioX keeps is the commercial record: what was paid, in which currency, against which order, through which provider — the things a sales report needs, and nothing you would rather not be storing.
| Data | Held in RestioX | Held by your gateway or terminal |
|---|---|---|
| Full card number | No | Yes |
| Card security code | No | Yes |
| Authorising and settling the card | No | Yes |
| Amount, currency and payment status on the order | Yes | Yes |
| Which gateway or terminal took the payment | Yes | Yes |
| A refund raised at the POS and executed by the provider | Yes | Yes |
RestioX does not hold a SOC 2 report, an ISO 27001 certificate or a PCI DSS attestation, and we are not going to imply otherwise. What the platform gives you are the controls those programmes ask about — scoped access, role-based permissions, an audit trail with retention, encrypted storage of third-party credentials, signed webhooks and scheduled backups — so that meeting your own obligations is a matter of configuring the software rather than working around it. Where card data is in scope, it is handled by the payment provider you choose.
Who this matters to
Three situations where these controls earn their keep
Multi-branch groups
A branch manager sees their own floor, an area manager sees the branches they run, and the group sees all of it — from one installation and one set of roles, instead of three databases and a spreadsheet that reconciles them.
Franchise and partner estates
A franchisee runs their venue without ever reaching into anyone else’s numbers, while the brand keeps a reporting view across the estate. The separation is enforced by the platform, not by an agreement everyone promises to honour.
Venues with heavy staff turnover
Seasonal and part-time staff get a narrow role and a registered device on their first shift, and lose both on their last — without anyone sharing a manager login to get through a busy Saturday.
Read next
Straight answers
The questions a cautious buyer actually asks
Who can see my data?
The people you give a role to, inside the branch you give it for. A staff account cannot reach another venue’s orders by changing a number in a URL. When the scope cannot be resolved at all, the result is empty rather than complete — the platform denies rather than guesses.
Can I get my data out?
Yes. Reports export to Excel (and PDF for the sales report), and the backup module produces a full database backup you can restore from. Nothing about the platform depends on your data being difficult to take with you.
How often are backups taken?
As often as you schedule them. Backups run on the interval you configure, to the storage location you configure, and restoring is done from the same module in the admin. There is also a built-in health check covering the database, the queue and storage, so a backup that has quietly stopped running is visible rather than assumed.
Do you store card numbers?
No. Card payments are processed by the gateway or card terminal provider you configure, and the card data is handled by them. RestioX keeps the commercial record — the amount, the currency, the order it belongs to and which provider took it — plus your gateway credentials, which are stored encrypted rather than in clear text.
Are you SOC 2 or ISO 27001 certified?
No, and we would rather say so plainly than dress it up. RestioX does not hold a SOC 2 report, an ISO 27001 certificate or a PCI DSS attestation. What it does give you are the controls those programmes ask about — role-based access, tenant scoping, an audit trail with configurable retention, encrypted storage of third-party credentials, signature-verified webhooks and scheduled backups — which is what your own obligations are usually built on.
Set it up on day one
Configure the controls before the first shift
Create your account, build the roles your floor actually needs and turn the backup schedule on. It is an afternoon of work now, and it is far easier than retrofitting all of it during a busy December.