1Each restaurant’s data is kept apart by the database
Every table that holds a restaurant’s records carries a row-level security policy in the database. A query made for one restaurant cannot read another restaurant’s rows, and a write into them is refused by the database itself, not by application code remembering to filter. In production the server will not start if its database role could get around those policies.
A test suite tries both, a read and a write across two restaurants, and fails if either gets through.
2Guest records are encrypted
A guest’s phone number, name and email on their customer record are encrypted with AES-256-GCM before they are stored, and the server will not start without its encryption key. Finding a guest by phone uses a keyed hash, so the number itself is never searched in the clear. A name and number taken for the waiting list or a banquet booking are stored without that encryption today.
Consent is recorded purpose by purpose. A guest’s name, phone number and email are erased from their customer record automatically two years after their last order. Bills, tax records and the audit log are kept for at least eight years.
3People act within their role
Everyone signs in with a role: owner, manager, cashier, captain, waiter or kitchen, among others. A void, a discount and a refund are permissions a role holds. Managers hold them; a cashier needs a manager’s PIN to use one.
4Actions leave a record the owner can export
Orders, payments and the other actions taken at the till are written to an audit log with who did it, what they did and when. Each of those entries is sealed to the one before it, so an entry edited or removed later shows. Some changes made in settings are logged without that seal today. The owner can export the whole log as a file.
When someone from CountStand opens your data to help you, that access is recorded in the same sealed log, with a reason and the ticket that allowed it, and it is in the file you export.
5No agent can move money
The agents have no tool that pays, refunds or transfers money: for them, those tools do not exist. No agent moves money, changes a price or sends a purchase order without a person. Sending a purchase order and approving payroll ask a person for an explicit confirmation before they go through.
What each agent reads and does, and the two that are switched off for the launch, are set out on the AI trust page.
6When the internet drops
The till keeps billing, taking cash and settling. Each action is saved on the device first, then sent in order, exactly once, when the line returns. Kitchen tickets and bills print when the line returns, not during the outage.
7Backups
The nightly backup is built: the database is copied, the copy is encrypted with AES-256-GCM before it leaves the server, and it is stored away from that server. A restore drill rebuilds a working database from a backup every night in testing and records how long it took. Both run against restaurants’ data from launch.
8Your data leaves with you
Export is an endpoint, not a promise to do it by hand. The owner calls POST /api/tenancy/export and gets the whole restaurant as one file, with a row count, a byte count and a SHA-256 to check that it arrived complete. It works while an account is suspended: a billing dispute is not a reason to hold your data. Erasing a restaurant entirely is done with us, on request, because it cannot be undone. The privacy policy sets out both.
9What we do not have
CountStand holds no security certification: no SOC 2 report and no ISO 27001 certificate. If your business needs a security questionnaire answered, write to us, and we will say what is in place and what is not.
10Reporting a security issue
Write to security@countstand.com with the steps to reproduce the issue, and give us reasonable time to fix it before you publish. The same address is in /.well-known/security.txt, as RFC 9116 sets out. We credit researchers who ask to be credited.