Data Processing Agreement

1 Parties, subject matter and duration

1.1The controller is the customer (the restaurant) that uses QR Table. The processor is Rani Kais (sole proprietorship, trading as “Kais Solutions”), Adelheid-Popp-Gasse 12/10, 1220 Vienna, VAT ID ATU83512003, email office@kaissolutions.at (“Processor”).

1.2The subject matter is the processing of personal data on behalf of the customer when operating the QR Table platform: digital menu, admin area, tables and QR codes, waiter calls, orders (depending on the package), notifications and statistics. The basis is the main contract (terms and conditions).

1.3This DPA is concluded together with the main contract (see section 10 of the terms) and applies as long as the Processor processes personal data of the customer, including the deletion periods under section 8.

2 Nature of the processing, types of data and data subjects

2.1Nature and purpose:Storing, displaying, transmitting, analysing and deleting data to the extent necessary for operating the platform; the purpose is to provide the functions of the booked package to the customer.

2.2Data subjects and types of data:

2.3Special categories of data (Art. 9 GDPR) are not intended. Guest notes (e.g. on intolerances) may relate to health in individual cases; the customer instructs its staff to use such notes only for preparing food. Payment data is not processed, because payment is made on site.

2.4Documents the customer submits for the menu entry service (existing menu) generally contain no personal data. The Provider processes contact and delivery data for additional services (QR stickers, table stands, menu entry service) as an independent controller; like billing data, it does not fall under this DPA.

3 Instructions of the controller

3.1The Processor processes the data exclusively on documented instructions from the customer. Instructions are this DPA, the main contract and the settings the customer makes in the platform (e.g. packages, users, enabled functions, languages).

3.2The customer gives further instructions in text form to office@kaissolutions.at. If the Processor considers an instruction unlawful, it informs the customer without delay and may suspend its execution until it is confirmed or changed.

3.3The Processor does not process data for its own purposes. Excluded are anonymous figures on the use of the platform from which no individual person and no individual customer can be derived, and legal obligations that apply to the Processor itself; it informs the customer of these in advance where the law permits.

4 Obligations of the Processor

4.1Confidentiality:Persons with access to the data are bound to confidentiality. Only the operator has access, and only to the extent necessary for operation and support.

4.2Security:The Processor takes the technical and organisational measures pursuant to Art. 32 GDPR described in Annex 1 and develops them in line with the state of the art. An equivalent or higher level of protection is maintained.

4.3Access by the operator:The operator accesses a customer's restaurant (support) only via a logged, time-limited support session (two hours) and only as needed by the customer or to resolve faults.

4.4Data breaches:The Processor reports a personal data breach to the customer without delay, at the latest within 48 hours of becoming aware of it, and provides the information the customer needs for its notification obligations under Art. 33 and 34 GDPR.

4.5Records:The Processor keeps a record of processing activities pursuant to Art. 30(2) GDPR, insofar as it is obliged to do so.

4.6Data protection officer:No data protection officer has been appointed, as there is no legal obligation to do so. The contact for data protection is office@kaissolutions.at.

5 Sub-processors and third-country transfers

5.1The customer consents to the use of the sub-processors listed in Annex 2 (general authorisation with information).

5.2The Processor informs the customer by email at least four weeks before engaging a new sub-processor or changing a sub-processor. The customer may object in text form within two weeks for an important reason relating to data protection. If no solution is found, the customer may terminate the contract extraordinarily as of the time of the change.

5.3The Processor contractually binds every sub-processor to at least the same data protection obligations as in this DPA and remains responsible to the customer for their fulfilment.

5.4Data is generally processed in the EU / EEA. If data is transferred to a third country (in particular to providers based in the USA), this only happens with appropriate safeguards under Chapter V GDPR, such as the EU-US Data Privacy Framework or standard contractual clauses. Details are set out in Annex 2. The application and database run on servers in the EU (Annex 2, Netcup); the QR Table website phrases this as “server and database are located in the EU”. Email delivery (Resend) and delivery via Cloudflare remain third-country connections with the safeguards mentioned.

6 Assistance with data subject rights and obligations of the customer

6.1If a data subject (guest, employee) contacts the Processor directly with a request for access, rectification, erasure, restriction, data portability or objection, the Processor forwards it to the customer and does not answer it itself.

6.2The Processor assists the customer with appropriate technical and organisational measures in fulfilling these requests, for example by deleting or handing over data on instruction within 14 days.

6.3It also assists the customer with data protection impact assessments and consultations with the supervisory authority (Art. 35, 36 GDPR), insofar as they relate to this processing. The effort for this assistance is remunerated at €100 net per hour after prior agreement, insofar as it goes beyond the usual.

6.4The customer remains responsible for the lawfulness of the processing towards its guests and employees, for informing them under Art. 13 and 14 GDPR and for safeguarding data subject rights. The platform provides a privacy policy for the customer's subdomain; the customer reviews it and adds its own details.

7 Audits and evidence

7.1On request, the Processor provides the customer with the information necessary to demonstrate the obligations under Art. 28 GDPR, such as the description of the measures in Annex 1 and the results of its internal checks (backup check, restore test).

7.2The customer may audit compliance with this DPA once a year and when there is a specific reason, or have it audited by an auditor bound to confidentiality. It announces an on-site audit at least four weeks in advance, does not disrupt operations and may not view data of other customers. The customer bears the costs of the audit; it reimburses the Processor's effort insofar as it exceeds one working day.

7.3Audits are preferably carried out by means of written information and evidence.

8 Deletion and return after the end of the contract

8.1During the contract,the Processor deletes individual data on the customer's instructions. The customer can delete a lot of data itself in the platform (dishes, categories, users, tables).

8.2After the end of the contract,the Processor provides the customer with the menu in a common format within 30 days on request and deletes all personal data of the customer from the live platform 90 days after the end of the contract, unless a statutory retention obligation prevents this.

8.3Backups(encrypted) are not edited individually. They expire according to their retention periods: daily backups after 14 days, weekly after 8 weeks, monthly after 12 months. The customer's data has also disappeared from the backups no later than 12 months after deletion from the live platform; until then it is not used otherwise and is deleted again without delay if the overall system is restored.

8.4On request, the Processor confirms the deletion in text form.

9 Liability and final provisions

9.1Liability is governed by Art. 82 GDPR and the liability rules of the main contract (section 11 of the terms).

9.2In the event of contradictions between this DPA and the main contract, this DPA takes precedence in data protection matters.

9.3Amendments and additions require text form. Annex 2 may be changed in accordance with 5.2.

9.4Austrian law applies; the place of jurisdiction is Vienna (Innere Stadt).

9.5Should any provision be invalid, the remaining provisions remain valid.

Annex 1: Technical and organisational measures

As of 1 October 2026. The measures describe the actual state of the system.

System access control (sign-in)

• Sign-in to the admin area with email address and password; passwords are only stored as an Argon2 hash.
• Session via a cookie that can only be read server-side (httpOnly) and in production can only be transmitted via HTTPS; protection against cross-site request forgery.
• Limits on sign-in attempts and other requests (rate limits); invitation and password links are time-limited and can only be used once.

Data access control (permissions and tenant separation)

• Roles per restaurant (owner, manager, waiter) with graded rights; roles are checked server-side.
• Tenant separation: every query and every change is restricted server-side to the restaurant of the signed-in user; the frontend never supplies an authoritative restaurant identifier. Tests safeguard this.
• Guests can only access order and call data with the table token from the QR code and only for their own table.
• The operator can only access a restaurant via a logged support session limited to two hours.
• Operator server access via SSH with a key pair.

Transfer control (transmission and storage)

• Encrypted transmission (TLS) between browser, network service and server.
• Uploads are checked by file type and scanned for malware; unchecked files are not stored. The object storage is private.
• Backups are encrypted (restic) and kept separately from the server.

Input and order control

• Orders keep a status history; support sessions are logged.
• Application logs do not store the IP address in plain text, only as a truncated hash, and are rotated by size.
• Sub-processors are contractually bound (Annex 2).

Availability and resilience

• Daily database backup (02:20) with automatic verification, copied encrypted to private storage at Cloudflare R2; retention of 14 daily, 8 weekly and 12 monthly backups. Images are copied as well.
• Weekly verification of the backups, monthly restore test in a separate environment, alert on failure via an external heartbeat service.
• Deployment via tested build processes; recovery by redeploying the version and the backup.

Data minimisation and separation

• No cookies and no trackers for guests; the statistics consist of counters without IP address and device identifier.
• Guest orders record no name and no contact details; payment data is not processed.
• Secrets (keys, service passwords) are not in the source code but in protected environment files on the server.

Operator accounts and devices:Two-factor sign-in at the hosting provider (Netcup), Cloudflare, GitHub and Resend; password manager for all service accounts (as of 5 October 2026).

Annex 2: Sub-processors

As of 1 October 2026.

Not sub-processors, but recipients at the device's initiative: push services of the browser vendors (Google, Apple, Mozilla, Microsoft) receive the device address and the short notification (order number, table) when an employee enables push notifications on their own device. An external heartbeat service (Healthchecks.io) only receives a status signal of the backup without personal data.