Data Processing Agreement

1. Parties and Context

Controller: The venue operator ("Venue", "Controller") who has entered into a subscription agreement with Mise Platform for use of the Mise restaurant management platform.

Processor: Mise Platform ("Mise", "Processor"), which operates the Mise multi-tenant restaurant SaaS platform.

This Data Processing Agreement ("DPA") forms part of and is incorporated into the main subscription agreement between the Controller and the Processor. In the event of conflict, the terms of this DPA prevail with respect to data protection matters.

The parties agree that the Processor shall process personal data on behalf of the Controller strictly in accordance with this DPA, the subscription agreement, and applicable data protection law, including Regulation (EU) 2016/679 (the "GDPR").

2. Subject Matter and Duration

Subject matter: The Processor provides a multi-tenant restaurant management and guest ordering platform (the "Service"). In the course of providing the Service, the Processor processes personal data of the Controller's guests and staff on the Controller's behalf.

Duration: This DPA is effective from the date the Controller accepts the subscription agreement and remains in force for the duration of that agreement. Upon termination, the obligations in this DPA survive until all personal data has been returned or deleted in accordance with Section 13.

3. Nature and Purpose of Processing

The Processor processes personal data for the following purposes:

• Operating guest ordering sessions, including table assignment, order management, and payment processing.
• Managing guest loyalty accounts and points balances.
• Storing and enforcing guest GDPR consent records (purpose, status, consent text version, timestamp, IP address, user agent).
• Displaying the Controller's menu, pricing, and promotional content to guests.
• Routing order items to kitchen and bar stations.
• Generating operational analytics and reports accessible to the Controller's authorised staff.
• Sending transactional communications (e.g. order confirmations) on behalf of the Controller where configured.
• Enabling guest loyalty features and, where a guest has provided separate consent, cross-venue recognition and loyalty sharing across the Mise network.

The Processor does not use personal data processed on behalf of the Controller for its own commercial purposes beyond those described in this DPA, except that anonymised, aggregated, non-identifiable data may be used for platform benchmarking as described in the applicable guest consent (ANONYMIZED_ANALYTICS purpose) and detailed in Section 3a, in which Mise acts as an independent Data Controller.

4. Categories of Data Subjects

• Guests — individuals who scan a QR code, join a dining session, place an order, or otherwise interact with the Service at a venue operated by the Controller.
• Staff and administrators — employees of the Controller who access the Mise dashboard, including owners, managers, waiters, cashiers, and kitchen staff.

5. Categories of Personal Data

The Processor does not intentionally collect special categories of personal data (GDPR Article 9). Dietary preferences may incidentally reveal health information; the Controller is responsible for ensuring appropriate notice is given to guests.

6. Obligations of the Processor

The Processor shall:

1. Process personal data only on documented instructions from the Controller, including with regard to transfers to third countries, unless required to do so by applicable law.
2. Ensure that all persons authorised to process personal data have committed themselves to confidentiality.
3. Implement and maintain appropriate technical and organisational security measures as set out in Section 10.
4. Respect the conditions for engaging sub-processors as set out in Section 7.
5. Assist the Controller in responding to requests from data subjects exercising their GDPR rights, including via the guest-facing My Data page.
6. Assist the Controller in ensuring compliance with GDPR Articles 32–36 (security, breach notification, data protection impact assessments, prior consultation).
7. Delete or return all personal data after the end of the provision of services, and delete existing copies unless applicable law requires storage.
8. Make available to the Controller all information necessary to demonstrate compliance with GDPR Article 28, and allow for audits on reasonable prior written notice.
9. Immediately inform the Controller if, in the Processor's opinion, an instruction infringes applicable data protection law.

7. Sub-Processors

The Controller authorises the Processor to engage the following sub-processors. The Processor shall ensure each sub-processor is bound by data protection obligations equivalent to those in this DPA.

The Processor shall notify the Controller of any intended additions to or replacements of sub-processors, providing at least 14 days' written notice before engaging a new sub-processor and giving the Controller the opportunity to object.

8. Data Subject Rights

The Controller is the primary point of contact for data subjects exercising GDPR rights (access, rectification, erasure, restriction, portability, objection). The Processor shall promptly forward any data subject request it receives to the Controller and provide reasonable assistance.

The Processor provides the following mechanisms to assist the Controller:

• Guest-facing My Data page — guests may view their consent state, withdraw individual consents, or withdraw all consents via /restaurant/{slug}/table/{qrCode}/my-data.
• Right to erasure — the Controller may request deletion of a guest's personal data via the admin interface. Consent audit records are retained per Section 9; all other identifiable data is anonymised or deleted within 30 days.
• Data portability — the Processor will provide personal data in a machine-readable format on written request from the Controller.

9. Data Retention

10. Security Measures

• Encryption in transit: All data is encrypted using TLS 1.2 or higher.
• Encryption at rest: Database storage is encrypted at rest using Render's managed encryption.
• Access control: Role-based access control is enforced at the application layer. Staff access is scoped to the Controller's own tenant.
• Authentication: Passwords are hashed using bcrypt. JWT access tokens expire in 15 minutes; refresh tokens in 7 days.
• Multi-tenancy isolation: All database queries are scoped by restaurant_id; cross-tenant data access is prevented at the application layer.
• Backups: Render performs automated daily database backups per their own policies.

11. Breach Notification

The Processor shall notify the Controller without undue delay, and in any event within 72 hours of becoming aware of a personal data breach, describing:

• The nature of the breach, including categories and approximate number of data subjects and records affected.
• The name and contact details of the data protection point of contact.
• The likely consequences of the breach.
• Measures taken or proposed to address and mitigate the breach.

12. International Transfers

Render and Stripe are located in the United States. Transfers of personal data to these processors rely on Standard Contractual Clauses (SCCs) approved by the European Commission (Commission Implementing Decision (EU) 2021/914). DeepL SE is located in Germany (EU) — no international transfer occurs for data processed by DeepL.

3a. Network Benchmarking — Mise as Independent Controller

What network benchmarking is

The Mise platform offers a Network Benchmarking feature that shows venue operators how their performance (revenue per cover, average check size, category mix, repeat visit rate, etc.) compares to anonymised aggregates derived from other venues on the Mise network. The benchmark reports contain no individual guest data and no identifiable venue datafrom any specific competitor — only statistical aggregates (medians, percentile bands, distribution histograms) computed across a minimum cohort size sufficient to prevent re-identification.

Mise's dual role

When Mise aggregates data across venues to produce benchmark reports, it does so for its own commercial purpose and under its own determination of means and purposes. This makes Mise an independent Data Controller for the benchmark processing activity, operating alongside its role as your Data Processor for venue operations. The two roles are distinct and do not affect each other: Mise's processor obligations under Sections 3–13 of this DPA remain fully in force regardless of its independent controller activities for benchmarking.

Lawful basis chain

The lawful basis for including a venue's guests in benchmark aggregation is explicit guest consent (GDPR Article 6(1)(a)). Specifically:

1. When a guest scans a QR code at a venue, they are shown the consent modal. One of the four consent purposes is ANONYMIZED_ANALYTICS: "your anonymised spend and visit data (never linked to your name or email in any report) may be used in aggregated benchmarking reports sold to venue operators."
2. This consent is freely given, specific, informed, and unambiguous (Article 7): it is presented as a separate, independently ticked checkbox; it is not bundled with venue-local consent; the checkbox is unchecked by default; and the guest can decline without any detriment to their ordering experience.
3. Only data from guests who have an active (non-revoked) ANONYMIZED_ANALYTICS consent record is included in benchmark aggregation. The consent gate is enforced at the application layer by GuestConsentService.hasActiveConsent(). No bypass is possible through direct database queries.
4. Guests may withdraw this consent at any time via the My Data page. Withdrawal takes effect immediately: the consent record is updated to REVOKED and the guest's data is excluded from all subsequent benchmark computations. Historical aggregates already published are unaffected because they contain no individually identifiable information.

Anonymisation standard

Before any data point from a guest or venue enters a benchmark report, it is processed as follows:

• Individual guest records are aggregated at venue level; no per-guest row is ever included in a report.
• Venue-level figures are aggregated across a minimum cohort of 5 venues before a percentile or median is published. Cohorts below this threshold are suppressed.
• No venue name, slug, or identifier appears in benchmark output delivered to other venues — only statistical bands.
• The output meets the standard for anonymisation under GDPR Recital 26: it is not reasonably possible to re-identify an individual guest or a specific venue from the published figures.

Because the output of benchmark processing is anonymous data, it falls outside the scope of GDPR once produced. The input processing (aggregating individual guest transactions) is personal data processing and is governed by the consent described above.

What Mise does not do

• Mise does not sell, share, or disclose individual venue revenue figures, guest counts, or order data to any other venue.
• Mise does not use benchmark processing to profile individual guests for advertising or profiling purposes.
• Mise does not combine benchmark data with external data sources to attempt re-identification.
• Mise does not use benchmark processing as a pretext for its own commercial profiling of venues beyond the analytics product described here.

Venue opt-out

As a venue operator, you do not need to take any action to comply with this section — guest consent is collected and enforced automatically by the platform. If you wish to exclude your venue entirely from benchmark aggregation (for example, if your local data protection authority requires it), contact the platform support team and your venue will be flagged as excluded. This does not affect your access to the benchmarking feature — you will continue to see network benchmarks; your data simply will not contribute to them.

13. Termination and Data Deletion

Upon termination or expiry of the subscription agreement:

1. The Processor shall cease processing personal data on behalf of the Controller.
2. Within 30 days of the termination date, the Processor shall — at the Controller's written election — delete all personal data, or return a copy in a portable machine-readable format and then delete its copies.
3. Consent audit records shall be retained for the period specified in Section 9 regardless of termination, to support regulatory compliance.
4. The Processor shall provide written confirmation that deletion has been completed, identifying categories of data deleted and the approximate date.