DATA PROCESSING AGREEMENT (DPA)

DATA PROCESSING AGREEMENT (DPA)

1. Introduction and the parties

1.1. This agreement (the Addendum) is an inseparable part of the General Terms and Conditions (GTC) and governs, with the mandatory content required by Article 28(3) GDPR, the processing that the Provider carries out on behalf of and on the instructions of the Subscriber. It enters into force upon acceptance of the GTC, by electronic means and without a separate signature [Article 28(9) GDPR; section 17.2 of the GTC].

1.2. Controller (Subscriber): the business that has subscribed to the Service and whose details appear in the billing profile and workspace records of the Service; identification is based on those details, and the interface logs the declarations of the Subscriber's representative. Processor (Provider):

1.3. The Addendum is not a document concluded with the End User (the natural person making the booking): in relation to them the Subscriber is the controller, and informing them is the Subscriber's obligation (section 6.1).

1.4. Unless provided otherwise, the terms used in the Addendum have the meaning given to them in the GTC and in the Privacy Notice.

2. The roles of the parties and delimitation

2.1. The Subscriber is the controller, determining the purposes and means of the processing through its calendars, services, resources, retention and access settings. The Provider is the processor, processing the data exclusively on the Subscriber's documented instructions and to the extent necessary to provide the Service. There is no joint controller relationship (Article 26 GDPR) between the parties in respect of End User data.

2.2. Delimitation. The Provider acts as its own controller in respect of workspace user accounts and identity management, subscription and billing data, evidence of acceptance of the legal documents, and operational security, abuse prevention and logging processing; these are governed not by this Addendum but by the Privacy Notice (sections 17.1 and 17.3 of the GTC). This is the case irrespective of the role of the account (owner/admin/staff): the Provider determines the purposes and means of authentication and session management in the same way for every account — whether the account belongs to the Subscriber's own representative (owner), to an invited administrative colleague with narrower permissions (admin), or to a staff member assigned to a resource (staff). This is not the same question as what the person holding the account may do in the Workspace (calendar, booking and resource management permissions) — that question concerns the work-organisation data determined by the Subscriber under section 3.4, where this Addendum applies. Out of this own-controller scope the Provider does not create a customer database that is independent of the Subscriber, does not use the data for marketing purposes and — in the absence of an artificial intelligence / large language model layer (section 3.8) — does not use or disclose it for model training either.

2.3. In the event of a conflict, the order of precedence — solely in the subject matter of processing on behalf of the controller — is: (1) this Addendum, (2) the GTC, (3) other documents.

3. The subject matter, duration, nature and purpose of the processing

3.1. Subject matter: to the extent necessary to provide the Service, the personal data of the Subscriber's End Users (its customers) and — within the scope set out in section 3.4 — of its staff members.

3.2. Duration: the term of the subscription contract, and thereafter as set out in section 4.7.

3.3. Nature and purpose: calculating and displaying bookable appointments, receiving, storing, modifying and cancelling bookings, sending transactional e-mails, generating the calendar feed (ICS), providing access through programmatic interfaces, and operating the foregoing (storage, backup, troubleshooting).

3.4. Data subjects: the Subscriber's End Users who book appointments (including where the booking is recorded by the Subscriber's staff member or through an integration channel); and the Subscriber's staff members to whom a resource or user account in the Service corresponds. In the case of staff members, this Addendum extends to the work-organisation data that the Subscriber configures in the Service (resource assignment, per-calendar role, work schedule, exceptions, time-off requests); the classification of the user account and of identity management itself is governed by section 2.2, under which — irrespective of the role of the account — the Provider is its own controller and not this Addendum but the Privacy Notice applies.

3.5. Categories of data:

What the above list does not contain — evidence of acceptance. The evidence of acceptance stored in connection with the booking (the identifier of the accepted version of the GTC and the time of acceptance) demonstrates the End User's acceptance of sections 18–21 of the GTC, and therefore serves the Provider's own contractual and accountability interest: in this area the Provider is the controller under section 2.2, and not this Addendum but section 5.4 of the Privacy Notice applies. The data is physically created in the booking records, which is why this section names it for the sake of transparency. On the integration (MCP/API) channel this evidence is not necessarily created (section 3.7; sections 13.7(3) and 18.6 of the GTC).

Special categories of data: the Service does not request and does not intentionally process data falling under Article 9 GDPR; however, the free-text comment and the service name chosen by the Subscriber may indirectly carry such data — see section 6.3.

3.6. The four booking channels.

3.7. Identity transfer on the integration (MCP/API) channel (sections 11.4 and 13.7 of the GTC). If the Subscriber enables the programmatic interface, an external system (for example a chatbot platform or the Subscriber's own system) may create bookings on behalf of the Subscriber. In that case the name, e-mail address and phone number of the person booking are transferred by the calling system in a short-lived identity assertion digitally signed by it and redeemable once, which the Provider verifies cryptographically; the booking is marked according to the channel, so that it can be established afterwards where it came from; the Provider processes this data as a processor in exactly the same way as data provided on the public page. The calling system receives access on the basis of the Subscriber's decision; responsibility for informing the users of the calling system and for the legal basis lies with the operator of the calling system and with the Subscriber — the Provider cannot observe what was displayed in the interface of a third-party system. On this channel the evidence of acceptance (which version of the GTC, and when) is not necessarily created: the channel is able to pass on the version identifier, but this is not mandatory. In this area, responsibility for informing the End User and for making the terms known lies with the operator of the calling system and with the Subscriber; the Provider recommends that the Subscriber agree separately on this with its integration partner.

3.8. The Service has no artificial intelligence / large language model layer of its own, and it does not transfer personal data to any provider operating a language model. If the Subscriber uses an external system employing such technology, that is the processing of that system.

4. Obligations of the Processor (Provider)

4.1. Processing on instructions [Article 28(3)(a)]. The Provider processes the personal data exclusively on the documented instructions of the Subscriber — including with regard to transfers of personal data to a third country or an international organisation —; this Addendum, the GTC, and the settings made and operations performed by the Subscriber in the interface of the Service together constitute documented instructions. If Union or Member State law requires it to process data differently, it will inform the Subscriber beforehand unless that law prohibits it. It will also inform the Subscriber if, in its opinion, an instruction infringes the GDPR or other data protection provisions.

4.2. Confidentiality [(b)]. The persons who have access to the data are subject to an obligation of confidentiality or are under a statutory obligation of confidentiality; their access is limited to what is necessary for the performance of their tasks.

4.3. Security of processing [(c); Article 32 GDPR]. The Provider applies in particular the following technical and organisational measures; their level may be improved in line with the state of the art but may not be lowered:

• separation: a separate database schema per Subscriber, with tenant scope enforced on the server side on every request; a calendar-level, second scope axis in which a staff member sees only the data belonging to their own resource, with participants' e-mail addresses and phone numbers partially masked; a "not found" response for a foreign or non-existent resource, so that the response itself does not leak information; the principle of least privilege and regular review of access rights;
• encryption, authentication: encrypted transmission (TLS); passwords stored exclusively as non-reversible cryptographic hashes, in a separately managed identity management component; session cookies with the HttpOnly, Secure and SameSite=Lax attributes, with a short-lived session token and a separate refresh token; API key authentication for the programmatic interfaces, an origin allowlist for the embedded interface, and a revocable, rotatable identifier for the calendar feed; signature verification of the identity assertion arriving on the integration channel, with short validity and single redemption (3.7);
• data minimisation, logging: logs do not contain End User names, e-mail addresses, phone numbers or comments, nor any payment data or secrets (masking is ensured by tests); an audit trail of operations performed in the Workspace, without quoting personal data; from the event message of the payment service provider only the identifier and the type are stored;
• availability: regular, encrypted backups and a recovery procedure; database-level constraints to rule out booking conflicts; rate limiting on the public interfaces;
• organisational measures: confidentiality, security review built into the development process (code and configuration review, isolation tests), change management, separated development and production environments, incident handling procedure (4.6).

Operating parameters. Backups are made at least once a day, encrypted; the retention period of the backups is at most 30 days (section 4.5). The Provider verifies that the recovery procedure works by performing a test restore at least every six months. The Provider reviews access rights at least every six months. These parameters may be improved in line with the state of the art but may not fall below the above level.

4.4. Sub-processors [(d); Articles 28(2) and 28(4) GDPR]. The Subscriber gives a general authorisation for the use of the sub-processors listed in Annex 1. The Provider gives notice of any extension of that set, or of a change in a sub-processor, at least 30 days before the planned introduction, by electronic means and in the interface of the Service, by amending the annex. The Subscriber may object to the change — on reasonable data protection grounds — within 15 days of the notice; if the parties do not find a solution within a reasonable time, the Subscriber may terminate the subscription contract with effect from the date on which the change takes effect, in which case the Provider will refund the unused, prepaid fee on a pro rata basis. The Provider imposes on the sub-processor — in a written contract — data protection obligations at the same level as those applicable to itself, and is liable for the sub-processor's activities as for its own. The Provider engages every sub-processor listed in Annex 1 subject to written data processing terms under Article 28(4) GDPR; these follow the data processing agreement of the sub-processor concerned as applicable from time to time. At the Subscriber's request, the Provider will demonstrate, under the procedure set out in section 4.8, that such terms are in force with a given sub-processor.

4.5. Data subject rights and retention period [(e)]. Taking into account the nature of the processing, and by appropriate technical and organisational measures, the Provider assists the Subscriber, insofar as this is possible, in fulfilling data subject requests under Chapter III GDPR:

Retention period. The retention period for booking data is set by the Subscriber per calendar; this constitutes a documented instruction under section 4.1. The default is 365 days after the appointment, upon the expiry of which the personal data of the booking is erased or anonymised. The cancellation identifier is valid for 30 days from being sent; after that the link cannot be used, while the stored hash is deleted together with the booking when the booking's retention period expires. The retention period of the notification log is 90 days. The Subscriber, as controller, is responsible for the purpose limitation and justifiability of the period chosen. The duty to assist and the data subject rights can extend only to data actually present in the live system at the time of the request; erased data cannot be retrieved or restored. Erasure takes effect in the backups through the rotation of the backups, as they expire; the retention period of the backups is at most 30 days, upon the expiry of which the erased data is also removed from the backups. The Provider ensures that in the event of a restore, previously erased data is not returned to processing.

A stated limitation and the manual procedure. In this version of the Service, no dedicated self-service data subject request interface and no automatic, scheduled deletion process is in operation. The Provider fulfils requests and the deletion linked to the expiry of the retention period manually, on the Subscriber's instruction, using the tools above, under a documented procedure: the request must be submitted to the data protection contact address set out in section 1.2, the managing director of the Provider is responsible for fulfilment, and the Provider confirms fulfilment in writing within the deadline set by the GDPR. Automatic enforcement of the retention period and the self-service interface are under development; their introduction does not narrow this commitment.

Effect on the calendar feed. The calendar feed (section 6.2) does not maintain a separate copy of the data: it is generated at each request from the booking data existing at that moment, and it always shows only a limited time window. Therefore, erasure or anonymisation under this section takes effect in the feed as well, without any separate operation. This does not extend to a copy that the calendar application has already downloaded and stored in its own system; its removal can be initiated in the relationship between the Subscriber and the operator of the calendar application concerned.

4.6. Assistance, personal data breach, requests from authorities [(f)]. On the basis of the information available to it, the Provider assists the Subscriber in fulfilling its obligations under Articles 32–36 GDPR, including the impact assessment (Article 35) and prior consultation (Article 36). It notifies the Subscriber of any personal data breach affecting the Subscriber's data without undue delay, but at the latest within 48 hours, by electronic means; the notification contains — to the extent available — the nature of the breach, the estimated scope of the categories of data and data subjects concerned, the likely consequences, the measures taken and planned, and the contact person, after which it provides information on the progress of the investigation. Notification of the authority and of the data subjects (Articles 33–34 GDPR) is the obligation and decision of the Subscriber; the Provider supplies information for this but does not act in the Subscriber's place. If the Provider receives a request from an authority concerning the Subscriber's data, it notifies the Subscriber without delay — unless the law prohibits this — and discloses the data only within the limits of the requirement.

4.7. Deletion or return on termination of the contract [(g)]. After termination, the Provider returns or deletes the data at the Subscriber's choice. The method of return is the free-of-charge data export available in the interface, in a structured, machine-readable format (section 15.6 of the GTC); for this the Provider allows a grace period of 30 days (section 15.9 of the GTC). Upon expiry of the grace period — or, at the Subscriber's earlier written request to that effect, already during the grace period — the Provider deletes the data of the workspace, including from the backups within the framework of backup rotation. In the case of cancellation during the Trial Period, before any payment, deletion takes place without a grace period and without delay, in accordance with section 15.8 of the GTC. Data that the Provider is required by Union or Member State law to retain cannot be deleted (in particular accounting and tax vouchers), nor can data whose retention is necessary for the enforcement of claims between the parties; for such data, restriction of storage and narrowing of access apply. At the Subscriber's separate request, the Provider issues a statement of deletion.

4.8. Demonstration and audit [(h)]. At the Subscriber's request, once a year at most, and within a reasonable deadline, the Provider makes available the documentation supporting compliance (the description of the measures set out in section 4.3, a summary of the security reviews, the list of sub-processors). The Subscriber — or an auditor mandated by it who is not a competitor of the Provider and who is bound by confidentiality — is entitled to an on-site or remote audit if this documentation does not render it unnecessary; in that case the parties agree in advance on the time, scope and manner of the audit, the audit may not disrupt the operation of the Service, and it may not be directed at the data of another Subscriber; the costs — beyond the cost of the Provider's own assistance — are borne by the Subscriber. This manner of exercise does not limit the Subscriber's statutory rights; in the case of an audit by an authority, the Provider cooperates in accordance with the law.

5. International data transfers

5.1. Data falling within the scope of this Addendum — hosting and transactional e-mail. The Provider stores and processes the data set out in section 3.5 within the European Union: hosting, object storage and backups operate in the German and Finnish data centres of the provider named in Annex 1, and transactional e-mails are delivered through the system of Mailjet SAS (France). In this area the Provider — subject to section 5.4 — does not engage any sub-processor in a third country and does not rely on the derogations under Article 49 GDPR. The terms under Article 28(4) GDPR referred to in section 4.4 apply to the sub-processors engaged in this area.

5.2. Transfers connected with the Provider's own processing. Stripe — which processes the Subscriber's subscription and billing data and does not receive End User booking data (Annex 1) — may, through its affiliates, also process data in a third country. In respect of payment card data and of Stripe's own regulatory obligations (PCI-DSS, fraud prevention and anti-money laundering), Stripe is not the Provider's processor but an independent controller; in this area the Provider has no access to the data (section 5.3 of the Privacy Notice). The safeguard applicable in this area is the European Commission's standard contractual clauses (SCC) or — within the scope of the Commission's adequacy decision — the EU–US Data Privacy Framework (DPF) (section 4.2 of the Privacy Notice). This processing falls within the scope not of this Addendum but of the Privacy Notice; the Addendum names it for the sake of transparency. The safeguard applicable at any given time is set out in Stripe's data processing agreement, which is publicly available on Stripe's website.

5.3. The following do not fall within this scope: the integration client engaged by the Subscriber on its own decision (3.7) — this calls the Provider and not the other way round, see Annex 1 —, the issuing of the calendar feed (ICS) link by the Subscriber (section 6.2), and the "Add to Google Calendar" link initiated from the End User's own browser (see section 6.3 of the Privacy Notice): compliance for these transfers rests with the Subscriber and with the End User respectively, and the Provider does not participate in them as a transferring party.

5.4. Calendar connection (currently: Google Calendar). The one-way calendar mirroring carried out by the Provider's own system under section 6.2 — for those resources where the Subscriber or its staff member activates it — engages the calendar provider as a sub-processor (Annex 1). The scope of data transferred is narrow (service and resource name, time, occupancy; without End User personal data), but the calendar provider may, through its affiliates, also process data in a third country. In the European Economic Area the contracting entity is Google Ireland Limited (Ireland); the safeguard for the transfer is the European Commission's standard contractual clauses (SCC) or, within the scope of the Commission's adequacy decision, the EU–US Data Privacy Framework (DPF), in accordance with Google's data processing terms as applicable from time to time (section 4.2 of the Privacy Notice).

6. Obligations of the Controller (Subscriber)

6.1. The Subscriber warrants that it has an appropriate legal basis for the processing of the personal data entered into the Service or collected through the Service, that its instructions comply with the GDPR, and that it informs the data subjects in its own name in accordance with Articles 13–14 GDPR — including the fact that the Provider participates in the processing as a processor.

6.2. The Subscriber is responsible for the parameters it sets, in particular: the retention period set for the calendar; the correctness of the set of users and of the roles granted per calendar (who sees End User data); the service and resource names that appear on the public booking interface and in the notification e-mails; the embedding allowlist; and the issuing and revocation of the calendar feed (ICS) links and the API keys. Anyone who knows the calendar feed link has access to the data contained in it, and the link must therefore not be shared and must be rotated in the event of compromise; the transfer of data to the operator of the calendar application is the Subscriber's decision and responsibility.

The content of the feed and the End User's name. The content of the feed is set by the Subscriber per calendar. The default level contains no End User personal data (service and resource name, time, occupancy count). The Subscriber may depart from this by an express setting so that the End User's name also appears in the feed for individual appointments; for group appointments no name appears even then. The Provider logs any change to the setting. The setting affects the entire time window of the feed — thus also bookings already recorded and upcoming. Activating this level is the Subscriber's decision as controller and at the same time a documented instruction under section 4.1: the Subscriber is responsible for having an appropriate legal basis for it, for informing the data subjects in accordance with section 6.1 of this Addendum (the Provider gives its own information in section 6.1 of the Privacy Notice), and for observing the limits set out in section 6.3. The feed is downloaded by the calendar application; in this area the Provider does not engage a sub-processor, and the calendar provider does not become a sub-processor of the Provider. No level of the feed contains End User e-mail addresses, phone numbers or the comment written for the booking.

Calendar connection (external calendar provider, currently: Google Calendar). If the Subscriber or its staff member connects an external calendar account to a resource, the Service mirrors the appointments of that resource one-way into that calendar — by a process running on the Provider's own server and operated by the Provider —, automatically and for every appointment, following the authorisation of access (OAuth). The mirrored entry contains the name of the service and of the resource, the time and the occupancy count; it does not contain End User names, e-mail addresses, phone numbers or comments — not even where the Subscriber has activated the level that includes the name for that calendar's feed. Creating and terminating the connection is the decision of the Subscriber or its staff member — but the continuous data transfer that follows is carried out by the Provider's own system, not by the browser of the Subscriber or of the End User (this differs from the "Add to Google Calendar" link described in section 6.3 of the Privacy Notice, where the End User's browser transfers the data directly, without any involvement of the Provider's system). For that reason, for this function the calendar provider is a sub-processor of the Provider — see Annex 1 and section 5 — and not an independent transfer decision of the Subscriber made separately from the Provider.

6.3. Special categories of data and the service names. The Subscriber may enter data falling under Article 9 GDPR into the Service, or make it possible to enter such data, only if it has an appropriate legal basis for doing so. An appointment is in itself an appointment, and a service name is a name — not medical treatment documentation. However, a name chosen by the Subscriber may indirectly convey information relating to health or to another sensitive circumstance (in particular in the case of healthcare, therapeutic or similar activities), as may the free-text comment that can be written for the booking. Assessing whether this results in processing under Article 9 GDPR is the responsibility of the Subscriber (controller); the Provider recommends the use of neutral names (e.g. "consultation", "check-up"). This question requires a separate compliance assessment in respect of the Subscriber's activity, which the Subscriber must carry out. The same consideration applies where the Subscriber also displays the End User's name in the feed described in section 6.2: the combination of the name and the service name may allow a more sensitive inference than either on its own.

6.4. The primary addressee of End Users' data subject requests is the Subscriber. The Provider forwards any request submitted directly to it to the Subscriber without undue delay.

7. Liability

7.1. The liability of the parties is governed by Article 82 GDPR and by the liability provisions of the GTC (section 13 of the GTC), including the monetary limits, exclusions and claim-enforcement rules set out there.

7.2. The indemnification obligation under section 13.9 of the GTC applies in this area as well, in particular where the claim arises from a breach of the Subscriber's controller obligations, from data or content entered into the Service, or from the use of an Integration client (sections 13.9(1)(c), (a) and (d) of the GTC). The limits set out in sections 13.9(3)–(4) of the GTC — the relative effect of contracts and the exclusion of the Provider's own sphere of liability — continue to apply.

7.3. Sections 7.1–7.2 do not affect the statutory allocation of liability towards the data subject under Article 82 GDPR.

8. Term, amendment and governing law

8.1. The Addendum enters into force and terminates at the same time as the GTC, with the exception of the post-termination provisions set out in section 4.7.

8.2. Amendment of the Addendum — with the exception of Annex 1 — takes place in accordance with the provisions on amendment of the GTC, by issuing a new version. Annex 1 is updated by the notice set out in section 4.4.

8.3. Hungarian law and Union data protection law are the governing law.

Annex 1 — List of sub-processors

Note. Stripe and Számlázz.hu do not receive End User booking data: they are processors for the Provider's own processing (subscription, billing) and appear in the table only for the sake of transparency. Within that, Stripe's role is likewise twofold: in respect of payment card data and its own regulatory obligations (PCI-DSS, AML/KYC) it acts not as a processor but as an independent controller (section 5.2). Of those listed, the data falling within the scope of this Addendum (section 3.5) is processed by the hosting provider, by Mailjet SAS (transactional e-mail) and by Google (solely for those Subscribers/resources that activate the calendar connection, see section 6.2). The complete list covering all of the Provider's processing is set out in section 9 of the Privacy Notice.

The Provider runs the identity management software (Ory Kratos) and the object storage itself, on Hetzner's infrastructure; these are not separate sub-processors but components of the Provider's system. The integration client engaged by the Subscriber on its own decision (3.7) is not included in the list: it calls the Provider (the calling party sends data to the Provider, with a digitally signed identity assertion, see section 3.7), and the Provider therefore does not engage a sub-processor there. This direction is the opposite of the Google Calendar connection, where the Provider's own system sends data outwards — which is why the former is not, but the latter is, a sub-processor.

The annex is updated when the set of sub-processors changes, under the procedure set out in section 4.4.

Language. This document is an English translation of the Hungarian-language Data Processing Agreement and is provided for convenience only. In the event of any discrepancy or inconsistency between the Hungarian version and this translation, the Hungarian version shall prevail.