Restaurant data security under KVKK and GDPR, in plain terms
Hotel IT contacts and managers at mid-size restaurants ask the same three questions about restaurant software: where does the data live, who can see it, and what happens if you get breached. The answers should be specific, not legal boilerplate. This guide names where MobiTaste hosts the data, the database mechanism that keeps one restaurant’s rows out of another’s queries, and the commitments we honor under KVKK (Kişisel Verilerin Korunması Kanunu, law 6698) and GDPR.
It is not a legal document. The privacy policy is. This is the mechanism story behind that policy, written for the person who has to answer “is this safe?” without quoting statutes.
The three questions, answered up front
Where is the data? EU servers in Frankfurt, on managed Postgres. Encrypted at rest with AES-256. Backups encrypted and held 30 days.
Who can see it? Your own staff, by role. A small MobiTaste support team under NDA, for incident response only. No advertising, no third-party access for marketing or analytics. Subprocessors: Paddle (billing) and Cloudflare (CDN), both under signed DPA.
What happens in a breach? GDPR Article 33 notification within 72 hours to the data controller (you, the restaurant). Post-mortem within 14 days, shared with affected restaurants. The current incident response plan is on the about page.
The rest of this guide is the detail behind those three.
Tenant isolation: the mechanism
MobiTaste is a multi-tenant SaaS. One software instance serves many restaurants; each restaurant’s data lives in the same database, separated by tenant identifier. The multi-tenant glossary entry is the 19-word definition.
The risk in multi-tenant systems is the cross-tenant leak: a query that should only return restaurant A’s rows returns restaurant B’s by accident. The standard mitigation is application-level filtering (“WHERE restaurant_id = X”). The stronger mitigation is database-level filtering, enforced by row-level security (RLS).
MobiTaste uses both. Every Postgres table that holds tenant data has an RLS policy that restricts visibility to the current restaurant context. The application sets the context per request from the authenticated session; the database refuses to return rows outside that context. If the application code had a bug and forgot a filter, the database would still refuse the cross-tenant read.
The RLS glossary entry is the short version. The pattern is the same one used in healthcare and banking SaaS, and it is the highest standard available in a managed Postgres deployment.
What we collect from your guests
By default, almost nothing. A guest scans the QR, opens the menu, picks items, submits the order. The data MobiTaste stores about that interaction:
- The table token (a UUID, not personally identifiable).
- The items chosen, prices, modifiers, allergen flags.
- The timestamp.
- The HTTP user-agent header (for diagnostics; rotated out of logs after 30 days).
That is the entire dataset on a default order. No name, no email, no phone, no IP address kept beyond rotated logs.
If you turn on the optional call-waiter feature, the guest may type a name they want the waiter to see on the floor tablet. That name is the only personal field, and it is the guest’s choice to type it. The name is stored against the table session and clears at session expiry, defaulting to 30 minutes.
Card numbers never touch MobiTaste servers. If pay-at-table ships later through iyzico, Paddle, or another payment vendor, that vendor handles card data under PCI-DSS scope, not us. Until then, the guest pays at your existing card terminal.
What we collect from your staff
Staff accounts carry email, password (argon2id hash, OWASP-recommended), display name, role, and audit trail. Two-factor login is on the roadmap. Sessions are JWT-backed with refresh tokens, httpOnly cookies, SameSite=Lax.
The audit log glossary entry describes the trail in 24 words. The log records every menu change, price change, table state change, and approval. Useful when a team grows and you want to know who edited what. Retention runs 12 months on Starter and Growth, 36 on Pro, unlimited on Enterprise.
The KVKK fit
For restaurants in Turkey, KVKK (Kişisel Verilerin Korunması Kanunu, law 6698) applies. Under KVKK, the restaurant is the veri sorumlusu (data controller), and MobiTaste is the veri işleyen (processor). Our processor obligations are codified in the privacy policy and in the data processing addendum (DPA) you accept at signup.
Practical implications:
- You publish an aydınlatma metni (privacy notice) to your guests. We provide a template; you adapt it for your restaurant’s name and contact.
- Data subject requests (access, erasure, rectification) reach you first; you forward to support@mobitaste.com if execution requires our help.
- Cross-border data transfer to MobiTaste’s Frankfurt servers is a Türkiye-EU transfer; the DPA includes the standard contractual clauses that KVKK currently accepts for EU destinations.
For the legal text, see the privacy policy. For an operational question that needs a human, the support address is the route.
The GDPR fit
For restaurants in the EU and the UK, GDPR applies. The roles are the same: restaurant is the controller, MobiTaste is the processor.
- Lawful basis: contract performance, Article 6(1)(b), for staff and order data; legitimate interest, Article 6(1)(f), for diagnostics.
- Data subject rights (access, rectification, erasure, portability, restriction) handled through the dashboard for restaurant staff, and through a 30-day support ticket for guest data.
- Sub-processors: Paddle (billing), Cloudflare (CDN). Both are listed in the privacy policy and under DPA.
- Breach notification: 72 hours to the controller per Article 33, with the controller responsible for notifying data subjects under Article 34 where required.
We do not transfer guest data to the United States. Cloudflare’s edge cache may briefly hold non-sensitive static content; orders and tenant data live in Frankfurt only.
What stops one restaurant from seeing another’s data
The short answer: Postgres row-level security, layered on top of application-level filtering. The long answer is in the RLS glossary entry and the multi-tenant glossary entry.
The defense in depth means: a developer who forgot a WHERE restaurant_id = X clause in the application code does not cause a leak, because the database refuses the cross-tenant read. The database, in turn, gets its tenant context from the authenticated session, which is set at the start of each request from a signed JWT. Tampering with the JWT requires the server’s secret, which is rotated and stored in environment variables, not in code.
That is the technical mechanism. The organizational mechanism is the audit log, which records every staff action and surfaces unusual access for review.
Subprocessor list
| Vendor | Purpose | Where | DPA |
|---|---|---|---|
| Paddle (UK) | Billing, MoR | UK + EU | Yes |
| Cloudflare (US) | CDN, DDoS | Global edge, EU origin | Yes |
| Hetzner (DE) | Hosting | Frankfurt | Yes |
That is the full list at launch. Any addition will be announced in the privacy policy 30 days before it takes effect.
What happens if you cancel
After cancellation, you have 30 days to export menus, orders, audit log, and staff records as CSV. On day 31 we delete the data from production. On day 60 we delete it from backups. A confirmation email goes to the owner address at each step.
If you cancel by mistake, contact support within 30 days and we restore from backup. After day 60, the data is gone; that is the GDPR commitment and we honor it.
Where to go next
For the legal text in full, the privacy policy is the source. For the broader product context, the about page covers the team and the hosting story. For the operational questions that come up after install, the FAQ page has the standard answers and the audit log glossary entry is the short version of what gets recorded.