Security

This page describes the controls we actually operate. It deliberately makes no certification claims: OwnTable does not currently hold SOC 2 or ISO 27001, and we would rather tell you that plainly than imply otherwise. If your procurement process requires a certified provider, say so early and we will tell you honestly whether we can meet it.

1. Tenant isolation

Every restaurant is a separate tenant. Isolation is enforced by row-level security in the database, not by filtering in application code — so a bug in a page or an API route cannot expose another restaurant’s data. Each tenant table carries a restaurant identifier, and access is resolved from the signed-in user’s membership rather than from anything the browser sends.

We test this rather than assume it. Our isolation tests sign in as two real restaurant owners and assert that each sees only their own orders, customers and menu, and that an anonymous caller sees neither.

2. Access control

• Four roles — owner, manager, kitchen and rider — enforced in the database, not only in the interface. Hiding a button is not our security model.
• Per-page access can be narrowed further for an individual team member, and is checked on the server before a page renders.
• Financial and reporting functions require an owner or manager role at the database layer.
• Optional two-factor authentication (TOTP) for accounts that want it.

3. Encryption

• All traffic is served over HTTPS, with HSTS set.
• Data is encrypted at rest by our hosting and database providers.
• Third-party credentials you connect — payment keys, messaging tokens, AI keys — are held in an encrypted secrets store, readable only by the server process that needs them at the moment it needs them. They are never returned to a browser.
• Saved payment cards are stored as gateway tokens. No card number ever reaches our database, and a saved card is matched on the card, the restaurant and a verified phone number together.

4. Least privilege

The high-privilege database key exists only on the server and is never exposed to the browser or to a client bundle. Public endpoints — the ordering page, booking, order tracking — run as an anonymous role with a deliberately narrow set of permitted functions, each of which validates its own input and is rate limited.

When an AI assistant is connected to a restaurant, it acts strictly as the person who connected it, with that person’s role and permissions. It is not given elevated access, and its token is revocable at any time and re-checked against team membership on every call.

5. Audit trail

Price changes, refunds, cancellations, role changes and account status changes are captured automatically with the acting user and their email address. The log is written by database triggers rather than by application code, so an action cannot be performed without being recorded.

6. Data protection and your rights

• A restaurant owns its customer data and can export it — customers, order history and totals — at any time.
• Diner-level export and erasure are supported. Erasure anonymises the person and scrubs order personal data while retaining the financial totals a restaurant needs for its accounts.
• Marketing consent is recorded with its source and enforced in the database, with opt-in required in regions whose law requires it.
• Every vendor that may process personal data on our behalf is listed publicly on our subprocessors page.

7. Availability and backups

The platform runs on managed infrastructure with automated database backups. Uploaded files — menu photographs and logos — are backed up separately on a weekly schedule with extended retention, because managed database backups cover rows and not stored files.

We do not currently publish a status page or contractual uptime guarantee. If your agreement requires one, raise it during procurement rather than assuming it.

8. Reporting a vulnerability

If you believe you have found a security issue, email sales@owntable.io with the words “security report” in the subject line and enough detail to reproduce it. We will acknowledge receipt, keep you updated while we investigate, and will not pursue action against anyone who reports a genuine issue in good faith and does not access or alter data belonging to other people.

Please do not test against a live restaurant’s account, place real orders, or attempt denial-of-service. Ask us and we will arrange a safe way to test.

9. What we do not claim

We are not SOC 2 or ISO 27001 certified. We are not “GDPR certified” — no such certification exists — though the rights and controls described above are built into the product. Our Saudi e-invoicing support is implemented and runs against the tax authority’s sandbox; it is deliberately locked out of production until independently validated, and we will not describe ourselves as compliant before that is done.

Questions about this policy: sales@owntable.io