Data Processing Agreement

between the Subscriber (controller) and the Operator (processor), pursuant to Article 28 GDPR

DRAFT for legal review. Version 0.1, 2026-10-02. English translation of Adatfeldolgozói megállapodás; if the texts differ, the Hungarian text prevails. Not final, not legal advice. [FOR THE LAWYER: ...] is the English form of the Hungarian [JOGÁSZNAK: ...] marker (open question or missing data); the full list, the assumptions and the statement-to-code table are in the README. Annex 2 (technical and organisational measures) states only measures that verifiably work in the code state of 2026-10-02 (main a71f768) or that the Operator confirms separately. Measures that are planned but not yet working are intentionally left out (see the README list "Known gaps").

1. Scope, parties, relation to the Terms

1.1. Parties. Controller: the Subscriber (as in clause 1.2 of the Terms). Processor: the Operator ([FOR THE LAWYER: the Operator's details, as in clause 1.1 of the Terms]).

1.2. Relation to the Terms. This agreement is an integral part of the Terms and comes into being with their acceptance. On data-processing matters, in case of conflict this agreement prevails. [FOR THE LAWYER: the technical manner of acceptance; registration records the acceptance (version, time, acceptor), see clause 1.5 of the Terms.]

1.3. Subject. The Operator processes personal data on behalf of the Subscriber when providing the [PRODUCT NAME] service. The Subscriber's and its representatives' own data related to using the service (account, billing, security logs) is processed by the Operator as an independent controller; the Operator's Privacy Notice covers it.

2. Details of the processing

The subject matter, duration, nature and purpose of the processing, the type of data and the categories of data subjects are in Annex 1.

3. The Subscriber's instructions

3.1. The Operator processes personal data only on the Subscriber's documented instructions. The instructions are: (a) this agreement and the Terms; (b) the use and configuration of the Service by the Subscriber and its Users (for example recording, deleting, exporting, retention settings, notification rules, connected services); (c) the Subscriber's separate written instruction through the Operator's support channel.

3.2. If in the Operator's view an instruction infringes the law, it informs the Subscriber without delay and may suspend carrying it out.

3.3. The Operator does not use guest data for its own purposes. Exception: aggregated indicators that cannot be traced to a person and are needed to operate the service (for example the counts of bookings, guests and staff for usage and plan checks). [FOR THE LAWYER: whether this exception is acceptable; anonymous, aggregated statistics for the Operator's own purposes.]

4. The Operator's obligations

4.1. Confidentiality and access. The Operator ensures that persons with access to personal data are bound by confidentiality. An Operator employee accesses the Subscriber's data through support access, which takes place with a mandatory stated reason, a time limit (default 30, at most 120 minutes), an indicator visible in the Subscriber's interface and logging (Terms 3.6). The platform layer (background jobs, platform console, database migration, backup) uses a database connection that is not restricted per Subscriber; only the Operator's systems and designated staff reach it. The platform console does not display guest data, only aggregate counts. [FOR THE LAWYER: staff confidentiality undertakings and an access-management policy; the Operator's organisational side cannot be seen from the repository.]

4.2. Security. The Operator applies technical and organisational measures appropriate to the risk under Article 32 GDPR, set out in Annex 2. The Operator may develop them further but may not lower the level of security.

4.3. Sub-processors. The Subscriber gives the Operator general authorisation to engage sub-processors. The current sub-processors are in Annex 3. The Operator announces any addition or replacement at least [30] days in advance by e-mail and in the interface; during that time the Subscriber may raise a reasoned objection. If the objection cannot be resolved, the Subscriber may terminate the contract free of charge until the change takes effect. The Operator imposes on the sub-processor the same data protection obligations that bind the Operator under this agreement and is liable to the Subscriber for the sub-processor's failure. [FOR THE LAWYER: general or specific authorisation; the deadline and consequence of an objection; existence of the sub-processor contracts.]

4.4. Data subjects' rights. The Operator provides tools in the Service to handle data subjects' requests: a complete per-guest data export (JSON, portability), deleting/anonymising a guest (with administrator permission), a log of consents and their withdrawal, automatic retention settings. If a data subject's request reaches the Operator, it forwards it to the Subscriber without delay and does not answer it on its own unless the law requires. [Complete salon export: the salon administrator can download it (POST /api/admin/export/salon, lib/tenant-exit/export.ts buildTenantExport()); automatic clean-up of expired sessions and tokens: lib/auth/token-sweep.ts, part of the per-minute background job.]

4.5. Assistance with obligations under Articles 32 to 36 GDPR. The Operator assists the Subscriber, taking into account the nature of the processing and the information available, in meeting its security, breach-notification, data protection impact assessment and prior consultation obligations. [FOR THE LAWYER: whether the assistance is chargeable.]

4.6. Personal data breach. If the Operator becomes aware of a personal data breach affecting the Subscriber's personal data, it notifies the Subscriber's contact given in Annex 4 without undue delay, [FOR THE LAWYER: a concrete deadline, for example within 48 hours]. The notification states (if known): the nature of the breach, the categories and approximate number of data and data subjects concerned, the likely consequences, the measures taken and planned, and the Operator's contact. The Operator cooperates in investigating the breach and in the Subscriber's notification of the authority and data subjects. [FOR THE LAWYER: the repository contains no written incident-handling procedure of the Operator; producing one may be a precondition of this agreement. The platform has no active alerting today; the System screen shows state only to whoever opens it.]

4.7. Returning and deleting data on termination. For 90 days from termination the Subscriber may export its complete data set (the account is read-only during this time). When the 90 days have passed the Operator anonymises or deletes the personal data, except what the law requires to be retained. Booking history may remain without personal data for statistical purposes. Terminated data drops out of backups gradually within the backup retention period (default: 14 days for local backups; retention of off-site copies depends on the Operator's configuration). On the Subscriber's request the Operator gives a certificate of deletion. [FOR THE LAWYER: content and form of the certificate. Automatic anonymisation (lib/tenant-exit/anonymise.ts, anonymiseTenant(), runTenantAnonymisation()) and complete salon export (lib/tenant-exit/export.ts, buildTenantExport()) are written; the contract records decision D9. The depth of anonymisation at salon level (the Subscriber's staff, logs) is open.]

4.8. Demonstrating compliance and audit. On request the Operator makes available the information needed to demonstrate compliance with this agreement. The log of support access for the Subscriber's account can be retrieved through the system's programming interface (API); there is no screen for it in the Subscriber's interface today (Terms 3.6). The Subscriber (or an independent auditor it appoints) may audit the Operator's compliance, [FOR THE LAWYER: frequency, prior notice, scope, cost, confidentiality].

5. The Subscriber's obligations

5.1. The Subscriber is the controller: it is responsible for the lawfulness of processing (proper legal basis, purpose limitation, data minimisation), for giving data subjects proper information and for its instructions being lawful.

5.2. The Booking page settings let the Subscriber enter the web address of its own privacy notice, which the Guest confirms with a mandatory checkbox when booking; the Operator neither supplies nor reviews the notice text. The system records the Guest's acceptance in a consent log (with the language and version of the text).

5.3. The Subscriber is responsible for obtaining the separate consents needed for processing health-related and other special data (the "processing of health data" consent that can be recorded in the Service), for managing marketing consents, and for recording only the data that is necessary.

5.4. The Subscriber is responsible for configuring its Users' permissions correctly, protecting credentials and removing a departing staff member's access.

5.5. The Subscriber is responsible for setting its retention options (automatic anonymisation of guest data) in line with its own privacy notice.

6. Services connected by the Subscriber

6.1. The Subscriber may connect third-party services with its own account in the Service (card payment, invoicing, newsletters, calendar, measurement tags; listed in Annex 3, part B). They are not the Operator's sub-processors: the Subscriber contracts with the provider and is responsible for settling the processor or controller relationship with them. The Operator transmits data to the provider on the Subscriber's instruction, according to the connection's settings. [FOR THE LAWYER: whether this construction (the Subscriber's own contract with the connected provider) is appropriate or whether the Operator should also name them as sub-processors; in particular for measurement tags, where the provider may be an independent controller.]

6.2. Measurement tags (Meta Pixel, Google Analytics 4, Google Ads, TikTok Pixel, Google Tag Manager) load on the Booking page only if the Subscriber has entered their identifiers and the visitor has consented in the bar; the consent stays in the visitor's browser. Loading Google Tag Manager is in addition tied to an operator gate that is off by default. The Subscriber uses the tags as its own controller. See the Cookie Policy.

7. International transfers

[FOR THE LAWYER: which of the sub-processors (Annex 3, part A) process data outside the European Economic Area, and on what appropriate safeguard (adequacy decision, standard contractual clauses, supplementary measures). Neither the hosting location nor the providers' places of processing can be determined from the repository, so the Operator fills this in. This clause must not be left empty in the final text.]

8. Liability

The liability of the Operator and the Subscriber is governed by Article 82 GDPR and clause 12 of the Terms. [FOR THE LAWYER: relation of the liability limitation to damage arising from data protection infringements; internal recourse.]

9. Term and termination

This agreement is valid during the Terms and until the personal data is returned, anonymised or deleted under clause 4.7, and until it has dropped out of backups. Clauses 4.1, 4.6, 4.7 and 8 remain in force after termination for as long as the Operator processes the data.

10. Governing law

Hungarian law and the GDPR govern this agreement. [FOR THE LAWYER: jurisdiction; mandatory local rules for foreign Subscribers.]

Annex 1: Details of the processing

1.1. Subject matter, nature and purpose

Operating the [PRODUCT NAME] salon booking and salon-management service: storing, querying and displaying personal data to the Subscriber's Users and to the Guest (public booking page, viewing one's own bookings), running booking and notification processes (e-mail, SMS, staff mobile notifications), export, deletion and anonymisation, backup and recovery, troubleshooting at the Subscriber's request.

1.2. Duration

The term of the contract, the 90-day export window, then dropping out of backups (clause 4.7).

1.3. Categories of data subjects

• the Subscriber's Guests (people who book on the booking page and customers recorded by the Subscriber, including an unregistered guest entered by name);
• prospects who send a message through the booking page's contact form;
• the Subscriber's staff (Users).

1.4. Categories of data

1.5. Special categories of data

Where the Subscriber records data indicating health status, the system may contain: contraindication flags (for example allergy, contraindication to laser treatment), the result and date of an allergy (sensitivity) test, a consultation release ("fit for the treatment"), the text of signed declarations and the image of the Guest's signature, the treatment card (work, recipe, note), answers to custom fields and free-text answers, notes. The Subscriber decides what to record; the product also records the Guest's separate "processing of health data" consent. The Service does not store guest photographs (images are only the booking page's header and staff portraits).

1.6. Frequency and retention

Continuous processing. The Subscriber sets retention: automatic anonymisation of guest data is off by default and, when on, anonymises after 5 years of inactivity by default; the log of outgoing messages is deleted after 365 days by default; contact messages are deleted at the same inactivity limit as guest data when automatic retention is on.

Annex 2: Technical and organisational measures (as currently operating)

A. Access and separation between Subscribers

1. Every Subscriber-scoped data model carries a tenant identifier, and every query made on the Subscriber's behalf is automatically filtered by the Subscriber's identifier (and populated on write); automatic tests check the completeness of the schema. The exception is the platform layer (see 4.1).
2. As a second line of defence, the database's row-level security (RLS) is enabled and enforced on every Subscriber-scoped table (ENABLE and FORCE ROW LEVEL SECURITY); the application's connection carries the Subscriber's identifier as a database setting. RLS takes effect only with a non-superuser, non-RLS-bypass database role; its presence was measured on the test environment (2026-08-24), and the platform's go-live checklist measures it. [FOR THE LAWYER: the operator fills this in; verifying this in the production environment.]
3. Roles and capabilities: access is governed by the staff member's role and the permissions set with switches; sensitive operations (exporting guest data, deleting a guest) require a separate capability or administrator role, and exporting requires a password (not PIN) sign-in.
4. The PIN quick sign-in used at the desk works only on a device the salon has separately enrolled.

B. Authentication and session

5. Passwords and PINs are stored as argon2id hashes; a password is at least 10 characters and its strength is also checked against the salon's name and the user's data.
6. Optional two-step verification (authenticator app) for the salon's staff, with recovery codes; the secret is stored encrypted with AES-256-GCM, the recovery codes as hashes.
7. Sign-in attempts are limited (rate limits per IP address and per e-mail, a limit on two-step codes, PIN lockout); the counters live in process memory.
8. The session token is stored only as a hash; the cookie is HttpOnly, in production Secure and SameSite=Lax; a staff session expires after 30 minutes of inactivity and after at most 12 hours.
9. Mobile client sessions are carried by rotated, revocable tokens; reuse of a revoked token invalidates the whole token chain and is logged.

C. Encryption and transmission

10. Third-party service keys (e-mail password, SMS key, deposit-payment and invoicing keys, Mailchimp key, Google Calendar tokens) and two-step verification secrets are stored encrypted with AES-256-GCM; the encryption key is an environment variable, to be managed separately from the database. Without a key the system stores no secret.
11. Towards the browser HSTS (max-age=63072000; includeSubDomains; preload), X-Content-Type-Options, Referrer-Policy, Permissions-Policy headers and a Content-Security-Policy that by default allows only the product's own source apply; because of Next.js, inline scripts are allowed ('unsafe-inline', no nonce), so the policy does not restrict inline scripts. On the admin interface no third-party script or font is loaded (fonts are bundled). [FOR THE LAWYER: the booking page, the admin interface and the platform console run on the same origin, so a third-party script that gets onto the booking page (the measurement tags gated by consent and by the Operator's GTM switch) could in principle reach the admin interface's API; the remedy is a separate origin or a nonce-based policy (README H11). Whether this must be flagged in the annex.]
12. Encryption in transit (TLS termination at the front proxy) and encryption of data at rest (disk): [FOR THE LAWYER: the operator fills this in; to be confirmed; the repository records only the application's headers, not the hosting and proxy configuration; the docs/04 plan speaks of a "managed" database whereas the actual deployment is a Postgres running on Coolify].

D. Logging and accountability

13. Changes to bookings and master data produce a log row (who, when, what); personal fields that entered the log are scrubbed when a guest is erased (see 17). The log records modification, not reading.
14. Support access takes place with a stated reason, a time limit and a visible indicator. The start of the access is logged; so is its end if it ends by exit, sign-out or termination by the Subscriber (access that ends when its time limit expires has no separate closing log row). The log rows for the Subscriber's account can be retrieved through the system's programming interface (API); there is no screen for it in the interface today. The marking of operations performed in support access is partial: writes that go through the shared logging point and the booking operations (creation, confirmation, cancellation, no-show, reschedule) are marked; several modules (among others the cash register, stock, guest merge, the payroll period, deposit refunds and the payment of a booking) write to the log directly, without the marking. [FOR THE LAWYER: until the Subscriber-side interface and the complete marking exist, the annex describes this partial state; the Operator builds the missing part (README H17).]
15. A separate log is kept of the Guest's consents (kind, channel, text version and language, time, withdrawal).

E. Data minimisation, deletion, portability

16. A complete per-guest data export in JSON (an administrator or a staff member with the separate capability, signed in with a password).
17. Erasing a guest (the right to be forgotten) anonymises personal data, deletes health-related and other special data (contraindication flags, allergy tests, signed declarations, treatment cards, feedback, custom-field answers), overwrites the recipient and content in the log of outgoing messages, scrubs personal fields from the audit log, and stops messages not yet sent.
18. Optional automatic guest anonymisation after inactivity; automatic deletion for the log of outgoing messages (365 days) and for expired session and password-reset tokens.
19. Staff mobile notifications are neutral in content (no guest data); an event placed in Google Calendar contains the guest's initials by default, not the name.

F. Abuse and load protection

20. Every server-side input goes through schema validation; public endpoints are rate-limited; at booking completion Cloudflare Turnstile and risk signals protect the system (booking reliability ranks above the protection: an outage of the provider does not lock the guest out).

G. Backup and recovery

21. The backup script makes a compressed database backup and a separate roles backup daily, checks the backup's size, keeps local backups for 14 days by default (it does not rotate off-site copies), optionally makes an off-site copy, includes a monthly restore-test mode, and reports the run's result to the platform console. [FOR THE LAWYER: the operator fills this in; the actual schedule, encryption, off-site location and retention of backups. The script does not encrypt; according to the operator an off-site encrypted backup runs, which the repository does not prove.]

H. Organisational measures

22. [FOR THE LAWYER: the operator fills this in; staff confidentiality, management of access rights, training, incident-handling procedure, physical and hosting-side security. These cannot be determined from the repository; the Operator fills this in or removes the item.]

Annex 3: Sub-processors and connected services

A. The Operator's sub-processors

B. Services connected by the Subscriber with its own account (not sub-processors, see 6.1)

Annex 4: Contacts and breach notification

• The Operator's data protection and incident contact: [FOR THE LAWYER: name, e-mail, telephone, out-of-hours contact.]
• The Subscriber's incident contact: the registered e-mail address, and the contact the Subscriber gave at [FOR THE LAWYER: whether a separate data protection contact can be entered in the interface; there is no such field today].