Data Processing Agreement

Last updated: 2026-05-15 Effective date: 2026-05-15 Version: 1.0

Template — review with counsel before signing customers. This DPA reflects doppa’s current architecture and the Article 28 GDPR requirements. Adjust governing law, jurisdictional details, and the SCC module before going live.

This Data Processing Agreement (“DPA”) forms part of the Master Services Agreement between doppa (the “Processor”) and the restaurant operator who has signed up for a doppa subscription (the “Controller”). It governs the processing by doppa of personal data on the Controller’s behalf in connection with the doppa platform.

In the event of conflict between this DPA and the Master Services Agreement, this DPA prevails for matters of personal-data processing.

1. Definitions

Capitalised terms not defined here have the meaning given in Regulation (EU) 2016/679 (GDPR).

• “Personal Data” — personal data (Art 4(1) GDPR) processed by doppa under this DPA, including the categories in Annex 1.
• “Sub-processor” — a third party engaged by doppa to process Personal Data on the Controller’s behalf, listed in Annex 3.
• “Services” — the doppa platform as described in the Master Services Agreement.

2. Subject-matter, duration, nature, and purpose

doppa processes Personal Data only to provide the Services described in the Master Services Agreement: QR-menu ordering, pay-at-table, reservations, loyalty, and the supporting operational functions (analytics opt-in, notifications, etc.).

The processing lasts for the duration of the Master Services Agreement plus the retention windows specified in the Privacy Policy.

3. Categories of data subjects and Personal Data

See Annex 1.

4. Obligations of the Processor

doppa shall:

1. Process on documented instructions. Process Personal Data only on the Controller’s documented instructions, including the instructions implicit in the Controller’s use of the Services. If doppa is required by EU or member-state law to process Personal Data otherwise, it will inform the Controller before processing, unless that law prohibits such notice on important grounds of public interest.

2. Confidentiality. Ensure that everyone authorised to access Personal Data is under an obligation of confidentiality (employment contract, NDA, or statutory duty).

3. Security. Implement the technical and organisational measures listed in Annex 2 and update them as the state of the art evolves.

4. Sub-processing. Engage sub-processors only as listed in Annex 3. The Controller authorises the use of those sub-processors. doppa will notify the Controller of any intended addition or replacement at least 30 days in advance, giving the Controller the opportunity to object on reasonable grounds.

5. Assistance. Assist the Controller in fulfilling its obligations to respond to data-subject rights requests (Art 12–22 GDPR), including by exposing the GDPR data-export endpoint and an erasure procedure.

6. Assistance for security incidents. Notify the Controller without undue delay (and in any case within 48 hours) of becoming aware of a Personal Data breach affecting the Controller’s data. Provide reasonable assistance with the Controller’s obligations under Art 33–34 GDPR.

7. Data Protection Impact Assessments. Provide the Controller with reasonable information to support its DPIAs (Art 35) and prior-consultation procedures (Art 36).

8. Return or deletion. On termination of the Services, return all Personal Data to the Controller, or delete it, at the Controller’s choice — except where retention is required by EU or member-state law (statutory bookkeeping for payments, tax records).

9. Audit. Make available to the Controller all information necessary to demonstrate compliance with Art 28 GDPR, and allow for and contribute to audits. doppa publishes annual SOC 2 Type II reports (planned; the first window opens 2026-06-01). An on-site audit may be requested with 60 days’ notice, scoped to verify compliance with this DPA.

5. International transfers

Where doppa transfers Personal Data outside the EU/EEA to a sub-processor, the transfer is governed by the European Commission’s Standard Contractual Clauses (Decision 2021/914) — Module Two (Controller-to-Processor) between the Controller and doppa, with doppa relying on Module Three (Processor-to-Sub-processor) for the onward transfer.

The transfer-impact assessments doppa performs are available on request.

6. Liability

Liability for breach of this DPA is governed by the limitation clauses of the Master Services Agreement, subject to the mandatory liability framework in Art 82 GDPR.

7. Term and termination

This DPA enters into force on the Effective Date and remains in force for as long as doppa processes Personal Data on the Controller’s behalf.

Annex 1 — Categories of data subjects and Personal Data

Data subjects

• Guests of the Controller’s restaurants who scan a QR code, order food, pay, or make a booking through the doppa platform.
• Staff users the Controller has invited to the platform.

Categories of Personal Data — guests

• Contact data (phone, email — when provided by the guest at receipt opt-in or booking)
• Identity data (first name, last name — when entered on an order or booking)
• Order data (items, modifiers, totals, timestamps)
• Payment metadata (payment method, status, Stripe PaymentIntent id — no card data)
• Booking data (party size, table, time, contact details)
• Loyalty data (points balance, ledger entries, allergen notes the guest has chosen to record)
• Session data (table QR scanned, browser session id)
• Device tokens (for staff app push — applies to staff users, not guests)

Categories of Personal Data — staff users

• Contact data (email)
• Authentication metadata (Supabase user id, role assignments)
• Action logs (audit log of administrative actions)
• Device tokens for the staff / KDS mobile app

Special-category data

The Services are not designed to process special-category data (Art 9 GDPR). Allergen notes are processed for the vital interest of the data subject and are limited to the minimum necessary to prevent harm.

Annex 2 — Technical and organisational measures

doppa maintains the following measures (Art 32 GDPR).

Access control

• Operator accounts authenticated via Supabase Auth (email + password, with magic-link as fallback).
• Role-based access via user_venue_role table; staff cannot see venues outside their tenant.
• All operator-side admin actions logged to a tamper-evident audit table.
• Production database access is restricted to a named list of doppa engineers, with all access logged and reviewed quarterly.

Data segregation

• Postgres row-level security (RLS) policies enforce per-tenant isolation on every tenant-scoped table. RLS denial is verified by a dockertest-backed CI suite on every commit (see TDD.md §16).
• Every multi-tenant SQL query takes venue_id as a required parameter — the application is the first defence, RLS is the safety net.

Encryption

• Transport: TLS 1.3 in production. HSTS enabled on every domain.
• At rest: AES-256 disk encryption (Supabase managed).
• Backups: Supabase point-in-time-recovery snapshots, encrypted at rest, retained 30 days.

Resilience

• Multi-AZ Postgres replication via Supabase.
• Stateless API replicas behind Fly.io’s load balancer.
• Restore-from-backup procedure tested quarterly.

Logging and monitoring

• Sentry captures application errors. Logs do not contain raw card data, full payment intents, or unredacted authentication credentials.
• OpenTelemetry traces are emitted for the redline business operations; span attributes contain identifiers (UUIDs) only, never PII.

Personnel

• Background checks for engineers with production database access.
• Annual security and privacy training.
• Confidentiality obligations in every employment contract.

Incident response

• Documented incident-response runbook reviewed every six months.
• 48-hour notification commitment to Controllers (Section 4(6) above).

Annex 3 — Sub-processors

doppa’s most up-to-date sub-processor list is published at doppa.com/legal/sub-processors. Controllers may subscribe to changes via a notification feed.