← All policies
ensv

Security and Privacy

A plain summary of how Dinebase protects restaurant and guest data.

Version 1.0 · Last updated 2026-07-27

Draft: the bracketed company details must be filled in before these documents are relied on.

This page is maintained by [LEGAL ENTITY NAME] to answer common security and privacy questions about Dinebase. It describes controls that are in place today. It is not a certification, an audit report or an independent verification.

Access and authentication

  • Accounts use email and password, with email verification before full access.
  • Password reset runs through a time-limited link sent to the verified address.
  • Each workspace has owner, manager and staff roles with different permissions.
  • Invitations are per-email, expire, and can be revoked.
  • Signed-in users can see their active sessions and revoke them.
  • Shared restaurant tablets can be marked as shared, which activates a restricted Host View with a PIN to leave it.

Platform and hosting

  • The application runs on managed cloud infrastructure with an EU-hosted primary database.
  • Traffic is encrypted in transit with TLS; the database and file storage are encrypted at rest.
  • Access to data is enforced at the database level so a workspace can only read its own rows.
  • Backups and restore procedures are operated by the hosting provider.

Data collection and use

We collect what is needed to run reservations: account details for staff, and name, contact details and booking details for guests. We do not sell data, and data is not used to train third-party AI models. Full details are in the Privacy Policy and the Guest Privacy Notice.

Payments

Card data is handled entirely by our payment provider. We store only a reference, the card brand and the last four digits when a restaurant uses card holds. Restaurant payouts run through the restaurant's own connected payment account.

Sub-processors and integrations

Hosting, email, SMS, payments, maps and optional AI features are provided by named sub-processors, listed with their purpose and hosting region on the Sub-processor page.

Cookies and analytics

The application uses only strictly necessary cookies and preferences you set yourself. There are no advertising cookies and no cross-site tracking. See the Cookie Policy.

Retention and deletion

Restaurants can delete guest records and reservations from their workspace. On account closure, data is exportable for 30 days and then deleted within the periods described in the Privacy Policy and the Data Processing Agreement.

Privacy requests

Guests should contact the restaurant they booked with, since the restaurant decides how the data is used. We assist restaurants in answering requests. Write to [PRIVACY EMAIL] and we will route it.

Reporting a vulnerability

Send security reports to [SECURITY EMAIL] with enough detail to reproduce the issue. We acknowledge reports and keep the reporter updated. Please do not run automated scanning or load testing against the production service without written permission.

Shared responsibility

  • [LEGAL ENTITY NAME] operates the platform, its security controls and its sub-processors.
  • The restaurant controls who has access to its workspace, what it writes about guests, its booking and fee policies, and how it responds to guest privacy requests.
  • Guests are responsible for the accuracy of the contact details they provide.
No compliance certification is claimed on this page. We do not state that Dinebase is SOC 2, ISO 27001, PCI or HIPAA certified.